When testing Roy Franz's ARM UEFI stub kernel loader patches on a TC2 platform, the loader (correctly) highlighted an issue that has been lurking unnoticed for a while: the very UEFI image actually makes following the Linux boot protocol impossible.
Roy's stub takes the paranoid (and correct) approach of explicitly allocating in UEFI the regions the zImage may need to be relocated to (based on original load address) and that which it will decompress into (based on some masking operations relative to the resulting entry point). It also attempts to allocate a "big enough" region to ensure the decompressed kernel, with BSS, will fit. This operation fails on the TC2 tianocore port, and if basic arithmetic does not fail me, would also fail at least on Samsung Arndale and TI Beagleboard (I have yet to verify).
The problem is that on all these platforms, the UEFI binary is linked to execute at or near the start of RAM on the platform. Oliver figured this out for me for TC2, and has promised to look into what would be the best way of resolving this for that platform.
On these platforms, kernel decompression may result in overwriting the initial UEFI image in RAM, before ExitBootServices(). While this may work on some platforms, there are no guarantees. This region could even contain code or data required by runtime services.
I have updated the (fairly random) list of UEFI port requirements at https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/BSP But several BSPs will need to change, along with their documentation.
/ Leif
boot-architecture@lists.linaro.org