Linux Boot Architecture coordination meeting

[Olivier Martin]

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: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On Behalf Of Grant
Likely
Sent: 21 June 2011 19:33
To: Nicolas Pitre
Cc: Olivier Martin; octo at linaro.org; boot-architecture at lists.linaro.org; 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
<nicolas.pitre at linaro.org> 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.