Hi all,
I've like to open the discussion about barebox
What is Barebox?
Barebox is a fork of U-Boot which was named before the elce 2009 U-Boot-V2 with the target to have a modern internal Implememtation derived from the Linux kernel and user friendly interface
The current design of barebox is very near from the kernel as example on AT91 I've update the current API to be as near as possible as the one in the kernel so it's now really easy to port a new board and on contrary of U-Boot we can have the multy instance of the drivers.
I'm start to push the SH with the same idea
As example have the prompt on all uart at the same time or be able to use them independently.
We also support FastBoot, Framebuffer, USB ohci & Ehci, network, nor, nandflash, dfu, usb ethernet (very usefull for soc without net device), Menu Framework, etc...
inprogress mmc, spi flash
DFU for Device Firmware Upgrade is very use full to update device from usb device from a PC so you will have an generic updater from the bootloader
The Menu Framework will help you to create friendly interface to manage the booloader via key specially on device without keyboard as cellphone, STB etc...
We have also a true shell support with scripting so it's very easy to create complex command via sheel script and also complex boot sequence
We have modules support as the kernel which allow to load code based on the need and speed up the boot but also allow to update the bootloader functionnality in the feature
etc...
Best Regards, J.
Cc -dev
On 06:15 Mon 06 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote:
Hi all,
I've like to open the discussion about barebox
What is Barebox?
Barebox is a fork of U-Boot which was named before the elce 2009 U-Boot-V2 with the target to have a modern internal Implememtation derived from the Linux kernel and user friendly interface
The current design of barebox is very near from the kernel as example on AT91 I've update the current API to be as near as possible as the one in the kernel so it's now really easy to port a new board and on contrary of U-Boot we can have the multy instance of the drivers.
I'm start to push the SH with the same idea
As example have the prompt on all uart at the same time or be able to use them independently.
We also support FastBoot, Framebuffer, USB ohci & Ehci, network, nor, nandflash, dfu, usb ethernet (very usefull for soc without net device), Menu Framework, etc...
inprogress mmc, spi flash
DFU for Device Firmware Upgrade is very use full to update device from usb device from a PC so you will have an generic updater from the bootloader
The Menu Framework will help you to create friendly interface to manage the booloader via key specially on device without keyboard as cellphone, STB etc...
We have also a true shell support with scripting so it's very easy to create complex command via sheel script and also complex boot sequence
We have modules support as the kernel which allow to load code based on the need and speed up the boot but also allow to update the bootloader functionnality in the feature
etc...
Best Regards, J.
boot-architecture mailing list boot-architecture@lists.linaro.org http://lists.linaro.org/mailman/listinfo/boot-architecture
Hi Jean-Christophe,
Thanks for sharing your notes; we actually had a call the 26th of August on Barebox; I don't think the notes from the call were shared, so I'm sharing them below.
I think much more would have to be discussed, so certainly I suspect there will be more calls. Grant is probably the guy who will make that happen.
Cheers,
== Attendees ==
Arnd Bergmann Shaju Abraham Matt Waddel Paul McKenney Loïc Minier Robert Schwebel John Rigby Grant Likely Steve Sakoman Mounir Bsaibes Dave Martin Nicolas Pitre (mid-call)
== Minutes ==
* Quick mention of what Linaro is for Robert * Grant working on defining a boot architecture * Telling manufacturers what firmware should be doing, where it stops * Not trying to cover the whole world, but more the fairly common case * Predictable set of interfaces * Barebox updates * Sascha Hauer main maintainer * Biggest problem was u-boot's architecture; old, full of ifdefs, not well designed structure * Pengutronix making a lot of bootloaders for industrial systems * Trying to be a mini-kernel, with the same coding style, modules etc. BUT trying to keep it to a minimum * Why not evolve u-boot instead of forking? * Wolfgang pushed back when introducing Kconfig, modules etc. * Not much feedback on the new ideas * Upstream policy would prevent breakage of old boards; but priority was fixing the architecture rather than keeping support for hundreds of boards which they didn't have access to * Was a bad idea to use the new u-boot * Is Barebox trying to replace u-boot, or will the two exist together? * Pengutronix using it because they see it as useful * Presented at conferences, trying to gain more community around the project * Why not strip down the kernel down to be a bootloader? * Some SH4 people do this * Problem is that it takes longer to boot the kernel * Will likely remain too slow and too large to be a production bootloader, since drivers rely on too much functionality * If the kernel is the bootloader, no need for two sets of drivers * Need to communicate on upgrade risks in the field, more than how the bootloader is laid out * Trying to write common device drivers * Is there effort to be 100% compatible at the source level with the kernel drivers? * Problem is getting rid off the possibility of running user programs? * Current kexecbooting needs some way of loading the initial kernel from NAND or whatever * U-Boot and Barebox don't ship in production; why? * Pengutronix has industry and automotive customers, and they do ship Barebox * RedBoot has the same issue -- but there's the copyright assignment as well * Real devices don't really care about loading the kernel from different places, or even replacing the kernel * Size and hence price of flash is also a pressure * In terms of boot time, managed to boot an init in 326ms on imx35 w/Barebox; can also strip down 30 kB * Apparently, phone manufacturers are really concerned about speed of boot, and GPL (even v2) because they don't want to share some changes * Size impacts speed, so is an indirect constraint * e.g. allows running on SRAM instead of regular RAM on OMAP * Good idea to allow upgrading the device tree and the kernel, but not exposing the bootloader * Would be nice to unify into a common tree the first and second stage bootloader * Is it possible to build a single barebox which supports multiple boards? Is it relocatable? * Might be some limitations, Sascha would know
== Minutes ==
- Quick mention of what Linaro is for Robert
- Grant working on defining a boot architecture
- Telling manufacturers what firmware should be doing, where it stops
- Not trying to cover the whole world, but more the fairly common case
- Predictable set of interfaces
- Barebox updates
- Sascha Hauer main maintainer
- Biggest problem was u-boot's architecture; old, full of ifdefs, not well designed structure
- Pengutronix making a lot of bootloaders for industrial systems
- Trying to be a mini-kernel, with the same coding style, modules etc. BUT trying to keep it to a minimum
- Why not evolve u-boot instead of forking?
- Wolfgang pushed back when introducing Kconfig, modules etc.
yeah I was pushed everytime I try to do it
* Not much feedback on the new ideas * Upstream policy would prevent breakage of old boards; but priority was fixing the architecture rather than keeping support for hundreds of boards which they didn't have access to
yeah I remember when I try to put the initcall
* Was a bad idea to use the new u-boot
- Is Barebox trying to replace u-boot, or will the two exist together?
- Pengutronix using it because they see it as useful
- Presented at conferences, trying to gain more community around the project
And really more friendly as example with Menu Framework
- Why not strip down the kernel down to be a bootloader?
- Some SH4 people do this
SH4 on barebox now :)
* Problem is that it takes longer to boot the kernel
agree
* Will likely remain too slow and too large to be a production bootloader, since drivers rely on too much functionality * If the kernel is the bootloader, no need for two sets of drivers
- Need to communicate on upgrade risks in the field, more than how the bootloader is laid out
- Trying to write common device drivers
- Is there effort to be 100% compatible at the source level with the kernel drivers?
- Problem is getting rid off the possibility of running user programs?
I'm currently re-writing the application support for barebox
- Current kexecbooting needs some way of loading the initial kernel from NAND or whatever
- U-Boot and Barebox don't ship in production; why?
- Pengutronix has industry and automotive customers, and they do ship Barebox
I put it also
- Good idea to allow upgrading the device tree and the kernel, but not exposing the bootloader
- Would be nice to unify into a common tree the first and second stage bootloader
yes I did it
- Is it possible to build a single barebox which supports multiple boards? Is it relocatable?
- Might be some limitations, Sascha would know
yes I did and multiple soc
Best Regards, J.
boot-architecture@lists.linaro.org