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