On 19 January 2015 at 17:09, Varad Gautam varadgautam@gmail.com wrote:
On 01/12/15 at 08:06 AM Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 11 January 2015 at 17:23, Varad Gautam varadgautam@gmail.com wrote:
A couple problems with the patch:
- accessing `linux_banner` in `libstub/fdt.c:update_fdt` causes a Data
Abort; need a better place to define it.
This is undoubtedly caused by the fact that the decompressor is built with -fPIC. This results in external references to go via a Global Offset Table (GOT) entry, which requires load time relocations as the GOT contains absolute addresses. You can try to work around this by adding a forward declaration
extern __attribute__((visibility("hidden"))) char const linux_banner[];
This will tell the compiler that the dependency will be fulfilled at link time (i.e., not by a shared library) so the emitted symbol reference will be PC relative.
Thanks, that fixed it.
Good!
- arch/arm/boot/compressed/head.S: jump to zImage `mov pc, r3` fails,
although jump to hard-coded relocated address (`ldr pc, =0x80008000`) works, 0x80008000 being the new zImage location. Need help with calling convention - am I setting *image_addr correctly?
I am not sure if I understand the purpose of this patch: the decompressor is position independent, so the best place to load it is between 32 MB and 128 MB from the base of DRAM. If you load it way at the beginning, the first thing zImage needs to do when executed is relocate itself /again/ so it can make room for its uncompressed self at the base of DRAM.
The current implementation fails in `handle_kernel_image()` when UEFI finds a discontinuity in the memory map during `allocate_pages()`[1]. This patch
Footnote?
reserves a low / available memory range for the uncompressed image and copies zImage, similar to the arm64 stub; but I see that this could cause problems during decompression and that zImage would need to be relocated once again.
How does the decompressor identify the memory region it must write to? Is it set to ZRELADDR?
I am not exactly sure, but as far as I know it just rounds down from its current offset, hence the requirement to load in the first 128 megs (or you will lose 128 megs of memory)