On Thu, Jun 23, 2011 at 5:25 AM, Olivier Martin olivier.martin@arm.com wrote:

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.

I think in general, yes we should constrain our view to 3.0+. That doesn't preclude firmware from supporting what it already supports. Indeed it would be crazy to ask firmware projects to remove things that it currently supports. Rather, I think that the process of creating a standard implementable by any firmware should be /focused/ on new kernels since we cannot change the stuff that is already deployed anyway.

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

I've added signature/CRC/identification as a topic to the boot architecture page.

g.