Loading a variable number of "modules"

[Jean-Christophe PLAGNIOL-VILLARD]

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
> (kernel/osloader/memtest/grub/whatever).
> 
> 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

Best Regards,
J.