Loading a variable number of "modules"
plagnioj at jcrosoft.com
Thu Jun 30 07:40:55 UTC 2011
On 22:40 Wed 29 Jun , Grant Likely wrote:
> Okay, I think we have our topic for tomorrow's meeting. comments below...
> On Wed, Jun 29, 2011 at 7:37 AM, Olivier Martin <Olivier.Martin at arm.com> wrote:
> > 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).
> So from both Loïc and Olivier's posts, I discern two proposals on the table:
> 1) a bootloader runtime ABI usable by a generic 'osloader' executable.
in Barebox we use the kernel module ABI
> 2) a rich boot descriptor file format that instructs firmware how and
> where to load binary images before booting the client
> These two options aren't even mutually exclusive. It seems to me that
> option 1) is also Loïc's first concluding option, and it is what
> Olivier is talking about above. Option 2) is Loïc's second concluding
> option. Jump in and correct me if I'm wrong here.
> Just to be backwards, I'll start with my thoughts on option 2. I
> think this is exactly what we need. It would be incredibly powerful
> to have a standardized data file or even simple script language for
> loading images into RAM, updating the DT to point to the images, and
> executing one of the binaries, and it could be designed in such a way
> as to fetch images from any of: the same place the boot script was
> loaded from, an http/ftp/tftp url, a local storage url, or firmware's
> default configuration storage.
> Downsides: each firmware needs to implement the scripting language or
> data parser, plus a scripting language needs to be created. Neither
> are great scenarios. However, the first could be mitigated if we
> create a BSD licensed library that does the parsing (and hooks into
> the firmware-specific apis). For the second, I'd rather investigate
> and adopt an existing data/script format than create something new.
> Surely there is something suitable that is straight forward, simple,
> and doesn't require a huge amount of resources to implement. (/me
> wonder's if Lua would be suitable for the job). U-Boot does have a
> scripting language, but it's pretty ad-hoc and centric to the U-Boot
> way of doing things. I doubt it is the thing to standardize on.
In U-Boot or Barebox we use hush from busybox so it's GPLv2
> Option 1 both intrigues me and frightens me. Intrigues me because it
> would be /really cool/ to have a reliable runtime ABI for client
> programs regardless of firmware implementation. Frightens me since I
> greatly fear that this will be difficult to get fimrware to implement
> correctly, far more so than pulling in a data/script parser. I worry
> that it will take a lot longer to both define and get all the major
> Firmware projects to adopt. Also, I suspect that option 2 actually
> provides all of the features that are actually needed. I'd like to
> hear thoughts and use cases of what a runtime ABI can provide that
> option 2 wouldn't be able to handle.
> Having said that, I think that from a development standpoint a runtime
> ABI actually fits in well with what needs to be done to implement
> option 2. In some ways the only difference between the two is that
> option 1 defines an ABI at the machine code level, while option 2
> defines it at the data/script/interpreter level. Either way, the
> provided behaviours are going to need to be the same. If we started
> with standardizing a data/script format, it could also be used to lay
> out and define what is required for a binary ABI, and it also takes
> the pressure away from needing to get a binary ABI defined and
> implemented /right/freaking/now/. :-)
> One final point on a runtime ABI; just like with a data/script format,
> I don't think inventing something new is the right thing to do. I'd
> much rather adopt something existing than delve into new territory.
> Let's discuss at the meeting.
I think we can simplify it to non C implementation as Lua or jimtcl which are
MIT and BSD-like licence
We can simply specify function/class that need to be implemented to
manipulate DT or other
But this will have huge down side effect the boot loader size will increase a
lot but it will be 100% portable and very easy to use and powerfull
More information about the boot-architecture