Hi folks
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-13 has the meeting minutes from yesterday's discussion. I have summarised below the highlights and Actions recorded in the etherpad.
----- = Highlights = We discussed the short term pain points, which should be possible to address via some engineering work - priorities were discussed here is where the discussion was left at the end of the meeting
RANKING - Rob's top two: 1) zImage support in u-boot. 2) How does the OS change which kernel gets booted.
- Olivier: 1) Get grub working with u-boot - get booting from a GPT partition 2) zImage update process 3) GPT support
- Jean-Christophe: 1) Investigate and begin using FIT image format 2) multiplatform kernel images 3) signed images - kernel, initrd, dtb
- Grant: 1) grub or grub config file on u-boot 2) Start using GPT support
----- = Actions from the meeting = - [CARRIEDOVER] Grant to followup the status of Linaro UEFI membership - INPROGRESS
- [CARRIEDOVER] Grant: Interact with Microsoft on ARM boot interface - there is some discussion more to say say by around mid October
- [CARRIEDOVER] Grant to draft a position on secure boot, from the Linaro perspective, which can be reviewed by Linaro TSC: TODO
- [CARRIEDOVER] Grant: Draft DTB recommended practices and getting the recommended practices document out and merged into a public tree by Linaro Connect (actually means the week before - as there are other events before the Connect) INPROGRESS,
- [CARRIEDOVER] Grant: Select date & time for the next f2f meeting (Next F2F in ELCE in Prague (OCT 27) ?) - 1/2 day in the afternoon. TODO: send out public announcement. + Option 1: half-day meeting during ELCE, some folks won't make it - this is the plan to go for Final confirmation
- [CARRIEDOVER] Will: Define SMP boot requirements - spin tables? Target Linaro Connect. No updates.
- [CARRIEDOVER] Jean-Christophe to send a RFC to the list regarding the kernel image format and entry protocol: INPROGRESS - target this weekend. + Related to these previous APs: o [CARRIEDOVER] Jean Christophe: Investigate entry point protocol - related to multi-image support. Proposal needed. o [CARRIEDOVER] Jean-Christophe: Investigate kernel image format - Target Linaro Connect. The proposal here is similar to the one handling the previous action point (entry point protocol).
- [CARRIEDOVER] Jean-Christophe to send some more details the list regarding the question : is it possible to put the initrd in the DT directly (similar to putting some firmware in the DT)? Proposal (JC) is to have 2 device trees, one very minimal with the boot arguments and another with the HW description. Issue: it is a requirement to be able to sign images passed in to the kernel; including the device tree. That makes it forbidden to modify the boot loader. - must support static DT. - TODO: sent proposal for how to sign device tree images.
- [ACTION] Jean-Christophe to put an example of the boot sequence to the mailing list - Under review - waiting for approval to release.
- [ACTION] Grant to post request for feedback for ACPI and UEFI - wants to have this checked from ACPI pov
Best regards,
On 10:47 Fri 14 Oct , Ilias Biris wrote:
Hi folks
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-13 has the meeting minutes from yesterday's discussion. I have summarised below the highlights and Actions recorded in the etherpad.
= Highlights = We discussed the short term pain points, which should be possible to address via some engineering work - priorities were discussed here is where the discussion was left at the end of the meeting
RANKING
- Rob's top two: 1) zImage support in u-boot. 2) How does the OS change
which kernel gets booted.
I would like t prpose to use a DTB for this
I implement a RFC on Barebox that can be tested on PC
This is not a replacement of the uImage FIT but a way to provide multiple kernel with different config
http://git.jcrosoft.org/git?p=barebox.git%3Ba=shortlog%3Bh=refs/heads/boot_m...
I attached an example fo dts
Best Regards, J.
On Fri, Oct 14, 2011 at 1:47 AM, Ilias Biris ilias.biris@linaro.org wrote:
Hi folks
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-13 has the meeting minutes from yesterday's discussion. I have summarised below the highlights and Actions recorded in the etherpad.
Hi Ilias,
Thanks for getting these out.
= Highlights = We discussed the short term pain points, which should be possible to address via some engineering work - priorities were discussed here is where the discussion was left at the end of the meeting
RANKING - Rob's top two: 1) zImage support in u-boot. 2) How does the OS change which kernel gets booted.
- Olivier: 1) Get grub working with u-boot - get booting from a GPT partition 2) zImage update process 3) GPT support
- Jean-Christophe: 1) Investigate and begin using FIT image format 2) multiplatform kernel images 3) signed images - kernel, initrd, dtb
- Grant: 1) grub or grub config file on u-boot 2) Start using GPT support
In the absence of a lot of follow-up discussion I'm going to propose the following ranking and set of priorities for short term pain-point resolution that can be presented to the TSC. I'll leave this on the table for a day or so to collect final comments before I pass this on to David. These are the items that I think are most valuable in preparing for "standard architecture" ARM machines with the expectation that distributions will be using separate kernel & initrd images, and boot loader configuration files for selecting which kernel to boot. I also think this list captures the items that there was consensus about on Thursday.
1) Add "grub" or "lilo" mode to u-boot for booting from disk 1a) add minimal grub-like config file support to u-boot when booting from disk 1b) When booting from disk, make u-boot use GPT boot partition to determine where to load config file and images - I've grouped 1a & 1b together because they don't have much value separately.
2) Implement rudimentary boot menu support in u-boot (if it doesn't already exist). Doesn't need to be graphical, but at least have a default boot with a list of other boot options.
3) Investigate implementing signed images a la secure boot. Need to investigate existing secure boot formats and policies so we don't do something gratuitously different.
I don't disagree with the FIT image topics, but I'm not including them in this list of recommendations because they don't have much bearing on the task of working out ARM server infrastructure.
= Actions from the meeting = - [CARRIEDOVER] Grant to followup the status of Linaro UEFI membership
- INPROGRESS
- [CARRIEDOVER] Grant: Interact with Microsoft on ARM boot interface - there is some discussion more to say say by around mid October
DONE
- [ACTION] Grant to post request for feedback for ACPI and UEFI - wants to have this checked from ACPI pov
DONE
On 22:30 Mon 17 Oct , Grant Likely wrote:
On Fri, Oct 14, 2011 at 1:47 AM, Ilias Biris ilias.biris@linaro.org wrote:
Hi folks
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-13 has the meeting minutes from yesterday's discussion. I have summarised below the highlights and Actions recorded in the etherpad.
Hi Ilias,
Thanks for getting these out.
= Highlights = We discussed the short term pain points, which should be possible to address via some engineering work - priorities were discussed here is where the discussion was left at the end of the meeting
RANKING - Rob's top two: 1) zImage support in u-boot. 2) How does the OS change which kernel gets booted.
- Olivier: 1) Get grub working with u-boot - get booting from a GPT partition 2) zImage update process 3) GPT support
- Jean-Christophe: 1) Investigate and begin using FIT image format 2) multiplatform kernel images 3) signed images - kernel, initrd, dtb
- Grant: 1) grub or grub config file on u-boot 2) Start using GPT support
In the absence of a lot of follow-up discussion I'm going to propose the following ranking and set of priorities for short term pain-point resolution that can be presented to the TSC. I'll leave this on the table for a day or so to collect final comments before I pass this on to David. These are the items that I think are most valuable in preparing for "standard architecture" ARM machines with the expectation that distributions will be using separate kernel & initrd images, and boot loader configuration files for selecting which kernel to boot. I also think this list captures the items that there was consensus about on Thursday.
- Add "grub" or "lilo" mode to u-boot for booting from disk
1a) add minimal grub-like config file support to u-boot when booting from disk 1b) When booting from disk, make u-boot use GPT boot partition to determine where to load config file and images
- I've grouped 1a & 1b together because they don't have much value separately.
I propose a format
- Implement rudimentary boot menu support in u-boot (if it doesn't
already exist). Doesn't need to be graphical, but at least have a default boot with a list of other boot options.
take a llok on Barebox
The format I propose will use the menu implemetation to display the boot choice
I really think we can have barebox on server very quicly as barebox already support the disk device and menu.
And if need I've an implementation of the framebuffer console
- Investigate implementing signed images a la secure boot. Need to
investigate existing secure boot formats and policies so we don't do something gratuitously different.
I don't disagree with the FIT image topics, but I'm not including them in this list of recommendations because they don't have much bearing on the task of working out ARM server infrastructure.
They are usefull to have in one image multple kernel/dtb/initrd
Best Regards, J.
On Mon, Oct 17, 2011 at 10:44 PM, Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com wrote:
On 22:30 Mon 17 Oct , Grant Likely wrote:
- Implement rudimentary boot menu support in u-boot (if it doesn't
already exist). Doesn't need to be graphical, but at least have a default boot with a list of other boot options.
take a llok on Barebox
The format I propose will use the menu implemetation to display the boot choice
I really think we can have barebox on server very quicly as barebox already support the disk device and menu.
And if need I've an implementation of the framebuffer console
I don't disagree here; but for the purpose of making recommendations for to the TSC for short term work items, it will not get any traction to propose barebox work items when I see pretty much zero interest among the Linaro member companies. That's why it is phrased in terms of u-boot specificly.
- Investigate implementing signed images a la secure boot. Need to
investigate existing secure boot formats and policies so we don't do something gratuitously different.
I don't disagree with the FIT image topics, but I'm not including them in this list of recommendations because they don't have much bearing on the task of working out ARM server infrastructure.
They are usefull to have in one image multple kernel/dtb/initrd
Yes it is for many embedded use cases. However, for the server use case the distribution vendors are pretty much needing separate kernel and initrd images since pretty much all their infrastructure is set up to work in that mode on x86.
g.
On 23:20 Tue 18 Oct , Grant Likely wrote:
On Mon, Oct 17, 2011 at 10:44 PM, Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com wrote:
On 22:30 Mon 17 Oct , Grant Likely wrote:
- Implement rudimentary boot menu support in u-boot (if it doesn't
already exist). Doesn't need to be graphical, but at least have a default boot with a list of other boot options.
take a llok on Barebox
The format I propose will use the menu implemetation to display the boot choice
I really think we can have barebox on server very quicly as barebox already support the disk device and menu.
And if need I've an implementation of the framebuffer console
I don't disagree here; but for the purpose of making recommendations for to the TSC for short term work items, it will not get any traction to propose barebox work items when I see pretty much zero interest among the Linaro member companies. That's why it is phrased in terms of u-boot specificly.
- Investigate implementing signed images a la secure boot. Need to
investigate existing secure boot formats and policies so we don't do something gratuitously different.
I don't disagree with the FIT image topics, but I'm not including them in this list of recommendations because they don't have much bearing on the task of working out ARM server infrastructure.
They are usefull to have in one image multple kernel/dtb/initrd
Yes it is for many embedded use cases. However, for the server use case the distribution vendors are pretty much needing separate kernel and initrd images since pretty much all their infrastructure is set up to work in that mode on x86.
So take a look on my proposal of the boot menu with DTB as input
Best Regards, J.
On Wed, Oct 19, 2011 at 8:14 AM, Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com wrote:
On 23:20 Tue 18 Oct , Grant Likely wrote:
On Mon, Oct 17, 2011 at 10:44 PM, Jean-Christophe PLAGNIOL-VILLARD
- Investigate implementing signed images a la secure boot. Need to
investigate existing secure boot formats and policies so we don't do something gratuitously different.
I don't disagree with the FIT image topics, but I'm not including them in this list of recommendations because they don't have much bearing on the task of working out ARM server infrastructure.
They are usefull to have in one image multple kernel/dtb/initrd
Yes it is for many embedded use cases. However, for the server use case the distribution vendors are pretty much needing separate kernel and initrd images since pretty much all their infrastructure is set up to work in that mode on x86.
So take a look on my proposal of the boot menu with DTB as input
Effectively, there isn't much functional difference between the dtb proposal and using a subset of the grub configuration format. Given the choice, I'd rather use an existing config file format instead of creating a new file format. Also, for config files, plain text is certainly more accessible for reading and editing than the dtb tokenized form.
g.
On 17:30 Wed 19 Oct , Grant Likely wrote:
On Wed, Oct 19, 2011 at 8:14 AM, Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com wrote:
On 23:20 Tue 18 Oct , Grant Likely wrote:
On Mon, Oct 17, 2011 at 10:44 PM, Jean-Christophe PLAGNIOL-VILLARD
- Investigate implementing signed images a la secure boot. Need to
investigate existing secure boot formats and policies so we don't do something gratuitously different.
I don't disagree with the FIT image topics, but I'm not including them in this list of recommendations because they don't have much bearing on the task of working out ARM server infrastructure.
They are usefull to have in one image multple kernel/dtb/initrd
Yes it is for many embedded use cases. However, for the server use case the distribution vendors are pretty much needing separate kernel and initrd images since pretty much all their infrastructure is set up to work in that mode on x86.
So take a look on my proposal of the boot menu with DTB as input
Effectively, there isn't much functional difference between the dtb proposal and using a subset of the grub configuration format. Given the choice, I'd rather use an existing config file format instead of creating a new file format. Also, for config files, plain text is certainly more accessible for reading and editing than the dtb tokenized form.
Except for the botloader binary size, we will have to support the DTB parser anyway
and for grub they do the same in grub2 they have a text configl file that they "compile" for grub. So with a DTB we do not need to add new source code in the bootloader.
The second advantage of the DTB is that libfdt is GPL or BSD so can be used in propriaritary bootloader or code
Best Regards, J.
On 10/17/2011 11:30 PM, Grant Likely wrote:
[snip]
- Implement rudimentary boot menu support in u-boot (if it doesn't
already exist). Doesn't need to be graphical, but at least have a default boot with a list of other boot options.
PXE boot support for u-boot just went in yesterday. This includes some generic menu support as part of it.
Rob
On Tue, Oct 18, 2011 at 11:08:04AM -0400, Rob Herring wrote:
On 10/17/2011 11:30 PM, Grant Likely wrote:
[snip]
- Implement rudimentary boot menu support in u-boot (if it doesn't
already exist). Doesn't need to be graphical, but at least have a default boot with a list of other boot options.
PXE boot support for u-boot just went in yesterday. This includes some generic menu support as part of it.
The PXE code also includes a parser for pxelinux config files (really a subset of pxelinux config file format). Since the syntax is the same for syslinux config files, it would be straightforward to readapt the parser to work for those too.
Jason
On Tue, Oct 18, 2011 at 10:35 AM, Jason Hobbs jason.hobbs@calxeda.com wrote:
On Tue, Oct 18, 2011 at 11:08:04AM -0400, Rob Herring wrote:
On 10/17/2011 11:30 PM, Grant Likely wrote:
[snip]
- Implement rudimentary boot menu support in u-boot (if it doesn't
already exist). Doesn't need to be graphical, but at least have a default boot with a list of other boot options.
PXE boot support for u-boot just went in yesterday. This includes some generic menu support as part of it.
The PXE code also includes a parser for pxelinux config files (really a subset of pxelinux config file format). Since the syntax is the same for syslinux config files, it would be straightforward to readapt the parser to work for those too.
I think syslinux would work. It is something the OS could generate at kernel upgrade time, and when booting off disk it would avoid the need for the OS to figure out what specific magic the firmware uses to boot. From what I can tell, the syslinux config file is limited, but it should be sufficient for what we need in the short term. If u-boot grows the ability to correctly identify the boot FAT partition for both the MBR & GPT uses cases, then making it pick up and use a syslinux file is trivial.
However, it does seem to require the kernel image to reside in the FAT partition which isn't really what we want in the longer term.
g.
On 10/19/2011 12:15 AM, Grant Likely wrote:
On Tue, Oct 18, 2011 at 10:35 AM, Jason Hobbs jason.hobbs@calxeda.com wrote:
On Tue, Oct 18, 2011 at 11:08:04AM -0400, Rob Herring wrote:
On 10/17/2011 11:30 PM, Grant Likely wrote:
[snip]
- Implement rudimentary boot menu support in u-boot (if it doesn't
already exist). Doesn't need to be graphical, but at least have a default boot with a list of other boot options.
PXE boot support for u-boot just went in yesterday. This includes some generic menu support as part of it.
The PXE code also includes a parser for pxelinux config files (really a subset of pxelinux config file format). Since the syntax is the same for syslinux config files, it would be straightforward to readapt the parser to work for those too.
I think syslinux would work. It is something the OS could generate at kernel upgrade time, and when booting off disk it would avoid the need for the OS to figure out what specific magic the firmware uses to boot. From what I can tell, the syslinux config file is limited, but it should be sufficient for what we need in the short term. If u-boot grows the ability to correctly identify the boot FAT partition for both the MBR & GPT uses cases, then making it pick up and use a syslinux file is trivial.
However, it does seem to require the kernel image to reside in the FAT partition which isn't really what we want in the longer term.
u-boot has ext2 support. But I guess your point is more about having a separate partition rather than supporting LVM, RAID, and all the latest filesystems.
Rob
boot-architecture@lists.linaro.org
-
Grant Likely -
Ilias Biris -
Jason Hobbs -
Jean-Christophe PLAGNIOL-VILLARD -
Rob Herring