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@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:
- a bootloader runtime ABI usable by a generic 'osloader' executable.
in Barebox we use the kernel module ABI
- 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.