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 mailing list
boot-architecture@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to