On Tue, Jun 21, 2011 at 12:00 PM, Nicolas Pitre <[email protected]> wrote: > 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.html
That's useful information. Is that recored anywhere in Documentation/arm? > 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. I agree here. The zImage should be the canonical kernel image format. >> 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. +1. We're going full throttle on DT support now. I don't think it makes any sense to spend a lot of effort standardizing UEFI ATAG support. For a common UEFI implementation, focus only on DT. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ boot-architecture mailing list [email protected] http://lists.linaro.org/mailman/listinfo/boot-architecture
