Boot loader is not just booting, but is also a debug interface for hardware bringup. Therefore it should be
- maintainable codebase
- driver model
- FS support
- See every device as a file (even tftp paths, automounted whenever you access /mnt/tftp/)
Originally fork of U-Boot (with the intention of merging it back) but reactions weren’t positive so renamed to barebox and continues as independent project. 92 boards supported.
Configuration with Kconfig for things like which commands and drivers are supported.
Lowlevel init is most important board-specific code. It mainly sets up SDRAM.
Barebox uses initcalls to order things at boot time (cfr. kernel), with a driver model that registers and then probes.
It has advanced things like menu, various input and output and storage devices, … in a very small footprint (400K). You can put a lot in 128K – with compressed image you can even get a functional (though non-interactive) boot loader in 33K.
To be fast, the MMU is enabled. Even caching in the block layer (useful for FAT).
Barebox has a lot of tools to bring up a new system, including gpio, clock, tab completion.
Device tree: plan is to move barebox hardware configuration to DT. Currently already code to unflatten the tree and connect it to existing barebox devices – which will allow barebox to update the DT. Note that startup code (set up SDRAM) will always be board-specific. Sasha even dreams of multiarch support, i.e. a single barebox binary that contains the startup code for many boards. E.g. host tool or update tool that chooses board-specific startup code and combines it with the rest of the image. But the question is if then there’s still any value in having the boot loader in production – you can just load the kernel from the startup code.