On Thu, Jun 23, 2011 at 5:25 AM, Olivier Martin <[email protected]> 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. _______________________________________________ boot-architecture mailing list [email protected] http://lists.linaro.org/mailman/listinfo/boot-architecture
