Thanks Nicolas for the link. You right the zImage has a signature. I read again the code I wrote and it is the signature for the non compressed image I have not found. My function was able to detect uImage and zImage but I had to assume if it is not one of these formats the image was a non-compressed image. Which it is ok as far as we have got only 3 formats, but that could cause trouble for any additional formats that would have some requirements from the boot loader.
FYI, our UEFI implementation already supports ATAG (and partially DT). We can pass a DT to the kernel but we have not implemented yet the update of the tree in the firmware; for example to pass new arguments to the kernel. Again same argument as the binary format, if in the future a new format incompatible with the DT format is introduced to answer some limitations of the Flat Device Tree at this time; should the ARM boot 'standardization' be rewriting again and break the legacy mechanism ? I had a look again to this page: https://wiki.linaro.org/OfficeofCTO/BootArchitecture It seems the current concern is more about the firmware itself than the interface between the OS loader and the kernel. I guess this Blue Print has been created to solve the issues of the boot fragmentation in the ARM world. I suppose the idea is to introduce some requirements for booting ARM platforms. But should we only limit our view to the requirements of booting Linux 3.0 (zImage? and Device Tree). Could we also think about defining some 'standards' in the interface between the OS Loader and the Linux kernel to leave some flexibility for any future technology that involves the boot firmware to initialize the platform for the Linux kernel. As I suggested in my first email, defining a signature (binary format:zImage + machine type:DT) could be a way to define our current requirements and leave some place for any future requirements (... and even not break the legacy kernel). Olivier -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Grant Likely Sent: 21 June 2011 19:33 To: Nicolas Pitre Cc: Olivier Martin; [email protected]; [email protected]; Jon Masters; Jeremy Kerr; Bobby Batacharia; David Rusling; Loïc Minier; Roger Teague; Jason Parker; Dan Handley; Andrew Pickard; Olivier Martin; Jean-Christophe PLAGNIOL-VILLARD Subject: Re: Linux Boot Architecture coordination meeting 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.htm l 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
