On Tue, 21 Jun 2011, Olivier Martin wrote:
Thanks Grant for adding me to the list, To introduce myself, I am part of the UEFI team at ARM Ltd. I am also the maintainer of the ARM Packages in the Open Source implementation of UEFI (http://www.tianocore.org/ ).
Maybe an issue this "ARM Boot Architecture" topic should solve is the interface between the boot loader and the Linux kernel binary.
Recently, I was trying to extend our ARM UEFI boot loader to detect the type of the Linux kernel binary:
- zImage, non-compressed Image, uImage format
- ATAG or FDT support
... to start any kernel by passing the correct parameters and jump to the right offset.
Unfortunately, it was not as easy as it should be. In fact it does not look to be possible right now. Defining a signature (eg: kernel binary format + machine type) in the kernel binary would make the task easier. Some of the formats have a signature (eg: u-boot) but not all the formats.
The zImage format has a signature too. I documented it here a _long_ time ago:
http://lists.arm.linux.org.uk/lurker/message/20020226.165754.4c7e6539.en.htm...
Of course some things have changed since then. For a while now, the zImage is fully position independent. I can be loaded anywhere in memory and branched directly to it as it takes care of relocating itself when needed. Therefore the load address at offset 0x28 is now always zero, except when the zImage is linked to be executed directly from flash memory (but I doubt that case is relevant to UEFI).
For that matter, the uImage format is broken. It insists on absolute addresses in its header. This is therefore not a good format if we want to support multiple SoCs with the same kernel binary, as some of them have their physical RAM at different addresses. You may want to support it if you want, but it is likely not to be suitable anymore in the future. Hence having the ability to boot a zImage directly is likely to be the most flexible option.
Actually, if we try to boot a Linux kernel with the wrong settings then the kernel would crash or raise an error. And it is not be possible to recover from this state without restarting the platform.
What kind of parameters do you have in mind?
Making these information available to the boot loader (u-boot, uefi, etc) would also make easier the migration from the legacy ATAG to the Flat Device Tree (FDT) support.
How would it make that transition easier? The link between those issues is not obvious to me.
With regard to ATAGs, I don't think UEFI should bother with them. If we really want to move to device tree, and it seems we do, then ATAGs should be left behind. We do have a compatibility layer going into zImage to convert ATAGs into DT properties at run time to allow booting a DT kernel on legacy bootloaders. Adding ATAg support to UEFI might impair the move to DT in the kernel by making it a lower priority.
Nicolas