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 <[email protected]> > 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. _______________________________________________ boot-architecture mailing list [email protected] http://lists.linaro.org/mailman/listinfo/boot-architecture
