On Thu, Jun 23, 2011 at 5:25 AM, Olivier Martin <olivier.martin(a)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.
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.ht…
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 18:01 Tue 21 Jun , 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.
>
> 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.
> 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.
in Barebox we use the same as u-boot but we can boot a zImage directly
>
>
> BTW, Thursday 15:00UTC is fine for me.
15:00UTC is a bit late for I as I live now in China Shanghai
I'd prefer 14:00UTC as if the call take 2h it will be already midnight here
Best Regards,
J.
Hi all,
Following up from the decisions made at UDS last month[1], we need to
organize a boot architecture coordination meeting. Currently the
proposal is to hold a meeting either as part of the Linaro platform
sprint[2] in the week on August 1-5, 2011, or in the weekend between
the platform sprint and the ARM Partners Meeting the week after.
Personally, my preference is to schedule a full day meeting on Friday,
Aug 5 as part of the platform sprint, but I'd like to get some
feedback before settling on that date.
[1] https://blueprints.launchpad.net/linaro/+spec/linaro-kernel-o-bootarchitect…
[2] https://wiki.linaro.org/Events/2011-08-LDS
Right now I'm in the process of organizing the information and topics
which were discussed during UDS and get them out onto the Linaro wiki.
Expect to see some early draft documents showing up late this week or
early next week. After that, I'm going to be soliciting feedback and
help to make them reflect the priorities and requirements that Linux
vendors, users and developers have for the boot architecture. By the
time the Linaro platform sprint rolls around, we should have a solid
set of documents covering both requirements and a draft boot
architecture. At the boot architecture meeting, my goal is to first
come to agreement on the general approach and draft design, second to
make decisions about how the boot architecture fits in with existing
technologies like Fastboot, UEFI and U-Boot, and third to kick off
work on implementation and detailed design.
In order to be successful, we need to make sure the appropriate people
are involved. I've started by sending this email to the people who I
know are interested in the topic, but I know I've missed folks. I'm
also going to cc: the boot-architecture(a)lists.linaro.org[3] for any
boot architecture traffic. Please let me know if there is anybody
else that I should be inviting. In addition to the meeting in August,
I'm considering a regular boot architecture conference call as part of
the document drafting process, so I'd like to put together a list of
critical stakeholders by the end of next week.
[3] http://lists.linaro.org/mailman/listinfo/boot-architecture
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On Mon, Jun 13, 2011 at 7:56 AM, Steve McIntyre
<steve.mcintyre(a)linaro.org> wrote:
> On Mon, Jun 13, 2011 at 07:51:05AM -0600, Grant Likely wrote:
>>Hi everyone,
>>
>>Note: I'm sending this directly to everyone on my 'interested
>>individuals' list, but future traffic will only get sent to the
>>boot-architecture(a)lists.linaro.org mailing list. If you're not
>>already, and would like to stay in the loop, please subscribe to the
>>list.
>>
>>Given the feedback I've received so far, I'm going to tentatively
>>schedule the meeting for Friday, July 5, at the end of the Linaro
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^August, surely?
Gah! yes. Friday, August 5th. Thanks for catching that.
g.
Hi all,
I've like to open the discussion about barebox
What is Barebox?
Barebox is a fork of U-Boot which was named before the elce 2009
U-Boot-V2 with the target to have a modern internal Implememtation
derived from the Linux kernel and user friendly interface
The current design of barebox is very near from the kernel as example
on AT91 I've update the current API to be as near as possible as the
one in the kernel so it's now really easy to port a new board and on
contrary of U-Boot we can have the multy instance of the drivers.
I'm start to push the SH with the same idea
As example have the prompt on all uart at the same time or be able to use
them independently.
We also support FastBoot, Framebuffer, USB ohci & Ehci, network, nor,
nandflash, dfu, usb ethernet (very usefull for soc without net
device), Menu Framework, etc...
inprogress mmc, spi flash
DFU for Device Firmware Upgrade is very use full to update device from
usb device from a PC so you will have an generic updater from the
bootloader
The Menu Framework will help you to create friendly interface to manage
the booloader via key specially on device without keyboard as cellphone,
STB etc...
We have also a true shell support with scripting so it's very easy to
create complex command via sheel script and also complex boot sequence
We have modules support as the kernel which allow to load code based
on the need and speed up the boot but also allow to update the
bootloader functionnality in the feature
etc...
Best Regards,
J.
Follow up to the initial poll for interest on an ARM Boot Architecture
working group (You can read the initial posting below for those people
I've just added to the to: list).
Linaro has graciously offered to host a mailing list and provide a
conference bridge for meetings. You can subscribe to the mailing list
here:
http://lists.linaro.org/mailman/listinfo/boot-architecture
I'm ready to kick off the first phase of the working group, which is
to start collecting requirements and to define the boot use-cases that
the working group will focus on solving (for example, one use-case is
supporting a generic ARM distro on netbooks and tablets). There is a
start to capturing requirements on the wiki page[1] and some
discussion on the associated talk page[2].
[1] http://devicetree.org/Boot_Architecture
[2] http://devicetree.org/Talk:Boot_Architecture
I propose having a kick-off conference call in about 2 weeks (week of
September 13th). Goal of the first call will be settle on a
first-draft for the requirements, and to figure out if there are
additional people or companies that we should be soliciting feedback
from. Then we can begin drafting the interface and recommended
practices document.
If you're interested in being in on the call, let me know and I'll
send you an invite and if you've got a preference on a day of the
week. Regardless of the day, It will probably have to be at about
9:00MDT/16:00GMT to handle everyone's timezones.
Cheers,
g.
---------- Forwarded message ----------
From: Grant Likely <grant.likely(a)secretlab.ca>
Date: Wed, Jul 21, 2010 at 1:31 PM
Subject: ARM Boot Architecture working group idea
Following up on a discussion from UDS-M in Brussels this year, the
idea was raised to put together a working group to define a
recommended firmware architecture for ARM systems. The goal being to
have something usable by both the hardware and operating system
vendors (notably Android and Linaro) to reduce the cost associated
with board ports, and to have a common method for operating system
installation across a wide range of devices.
The goal of this working group would be to produce a specification
including the following 3 things:
1) A set of requirements that meets the needs of hardware vendors,
operating systems vendors, and software engineers
2) A recommended architecture for boot firmware.
3) A reference design implementing the first two items in a form
usable by hardware vendors.
I'm in the early planning stages now, and I'm looking for volunteers
and interested parties to join the working group. To get things
rolling, I've set up a wiki page[1] with a very early draft of
requirements which captures some of the issues brought up at UDS-M.
[1] http://devicetree.org/Boot_Architecture
I've not yet set up any kind of charter or procedures for the working
group. Nor have I done an exhaustive search for people who should be
involved, so if there is anybody you can think of who I should
contact, then please let me know.
If you (or your company) is interested and would like to be involved,
then please let me know. Once we've got a few people to kick things
off, I'll set up a mailing list, try to pull together something about
how this working group will be organized, and probably make an lwn or
linux-embedded announcement.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
