Loading a variable number of "modules"

[Olivier Martin]

I also had a thought about a 'general purpose ARM bootloader' approach after our phone call last week.

Linaro could provide a reference grub-style module/library/application which would be Boot Firmware agnostic but using wrapper functions to call firmware specific functions. These wrappers functions would allow to take advantages of the platform firmware features.
There would be an implementation of this wrapper for each supported boot firmware (eg: UEFI, u-boot, Barebox, etc). The wrapper API could export generic functions to load files from the network/filesystem/etc, load and store non volatile environment variables, etc
This OS loader could also be responsible for the DT edition if required. And it will be built in a suitable manner for the targeted boot firmware (static library, EFI application, baremetal application, etc).

The main benefit would be a common (user) interface between the different Linaro's platforms. The HW vendors would also not be tied to a specific boot firmware implementation. The wrapper API would define the requirements for the boot firmware.

Even if it is a reference implementation, HW/OS vendors could implement their own version as soon as their implementation ensure the same features (eg: boot from PXE, DT edition, etc).

Olivier



-----Original Message-----
From: boot-architecture-bounces at lists.linaro.org [mailto:boot-architecture-bounces at lists.linaro.org] On Behalf Of Loïc Minier
Sent: 23 June 2011 17:33
To: boot-architecture at lists.linaro.org
Subject: Loading a variable number of "modules"

        Hey

 (followup to today's call0

 This is an attempt to write down an use case which expresses the
 concept of "modules" that the boot architecture would cover.  I don't
 really like the name modules, if you have better names please propose!

 So here's the writeup; this is completely fictional, and is just meant
 to illustrate modules.

 Here are the steps that could be taken to load a plain linux kernel:
 a) your SoC starts up in a SoC-specific way
 b) the boot architecture mandates how vmlinuz is loaded and started
 c) control is passed to linux
 d) profit!1!

 in a very dumbed down version of our boot architecture, we could say
 for b):
    a file named "bootme" is loaded from the first FAT partition of the
    SD card; its type is detected and if it's a linux kernel, it's
    started with a device tree blob provided by the firmware to the
    kernel

Good:
 * easy to install or update a kernel by replacing the vmlinuz file

Bad:
 * miss way to pass kernel cmdline
 * miss way to pass (optional) initrd
 * miss way to load/replace the DT

 all of the above bad points could be alleviated by pushing this data in
 the vmlinuz file, but it's not as practical as the modern linux systems
 we know.
   Another approach would be to put U-Boot or Barebox in the "bootme"
 file, but then U-Boot or Barebox would have to decide how to load the
 kernel and implement drivers for the SD card and this wouldn't be a
 SoC-agnostic boot image anymore.
   So the only possible approach I see in this case is to put a general
 purpose ARM bootloader in the "bootme" file which will talk to firmware
 to load additional files from the SD card (thanks to non-resident
 support from the firmware); this would then go away once linux runs.


 Now to "modules": instead of defining b) as just loading a single
 "bootme" file, we'd define a config file which lists what to load (e.g.
 something like grub.cfg/menu.lst) so that we could pass combinations
 such as:
 - vmlinuz + initrd + DT
 - vmlinuz + DT
 - Xen + DT + the OS modules it should load (linux and initrd)
 it would also allow setting things like kernel cmdline or other OS
 specific things.

 Maybe I misunderstood Grant's idea, but it felt like he was mandating a
 single payload from being loaded and just deferring to that payload.  I
 feel that if we go that route, we've specified too little to be able to
 construct useful images and have deffered to an implementation specific
 architecture (even if it could support multiple SoCs).



 So my conclusion is that we should specify:
 * either a single payload to start which would be something like a
   generic ARM bootloader talking to the firmware to load the other bits
   (e.g. via UEFI), but then also how it loads the next things
 * or a config file which points at "modules" (by lack of a better name)
   to load; these will get loaded by SoC specific code (likely an UEFI
   implementation)
 the main difference is whether we specify how a generic ARM bootloader
 is loaded and then defer to it to decide how to load the OS, or whether
 we specify OS-ish bits to load, and leave the loading to the
 implementation.


 Does that make any sense?

    Cheers,
--
Loïc Minier

_______________________________________________
boot-architecture mailing list
boot-architecture at lists.linaro.org
http://lists.linaro.org/mailman/listinfo/boot-architecture


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.