Linux Boot Architecture coordination meeting
grant.likely at secretlab.ca
Thu Jun 23 13:22:14 UTC 2011
On Thu, Jun 23, 2011 at 5:25 AM, Olivier Martin <olivier.martin at 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
> 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:
> 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
> 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
> 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
More information about the boot-architecture