- I have a concern that barebox is not mainstream enough yet.
I don't think 'maintstream' is the right focal point. Have a look at (for both busybox and U-Boot)
- How often a patches committed to the public repository
- What is the patch review procedure - Has it changed recently? Why? do _you_ think it is a good procedure?
- How many people are actively contributing - Is there are large enough core contribution team that you believe can support you going forward
- What level of support can you expect from the community both now and in the future
- Are there any clear policies (either explicit or implicit). For example, U-Boot has a policy of not introducing board-breaking changes unless there is a really good reason. Also, U-Boot questions patches that cause code/data size increases for arches/boards which do not benifit from a particular new feature
Looking at the two choices side by side, these appear to be equal. This is one of those areas, however, that no one can be 100% sure about for the next 5-10 years. Barebox may overtake U-Boot just like U-Boot did for RedBoot. Or some other bootloader may take the center stage. This is an unknown risk that has to be owned by the company that chooses to adopt any third party code.
- I have a feeling we will always be porting everyone's bsp (that
already has a working u-boot) to barebox.
Which should not be _that_ hard considering that barebox is based on U-Boot, but I think the code has diverged quite a lot
Which is what I said below. If it wasn't clear, these three "questions" were presented to me in opposition of my choice to investigate more Barebox as our universal bootloader. And yes, you are correct, the code appears to have changed drastically. According to the Barebox list, there would be a port required from U-Boot to Barebox for all drivers that are needed from U-Boot as the driver model is more closely aligned to the Linux kernel, though I never was answered whether drivers from the Linux kernel would be easier to port.
- I also don't really see the real advantage over standard u-boot
(what's the 'killer' application?).
I like the idea of barebox's posix file system API and environment handling. But I think that comes at a cost of size and speed
The ability to have real mounted file systems in the bootloader, as well as the posix like environment that Barebox uses are the two biggest reasons for my wanting Adtran to use Barebox. This seems to me to be less cumbersome than the way that U-Boot requires scripts to be written inside of variables. Whereas I am use to this type of scripting (being that I've been using U-Boot for ~6-8 years) I know that this approach is foreign to the way of thinking inside this company. The ability to look at things more along the lines of files is appealing.
From my point of view, the answer to 3 is clear: It uses the Linux kernel as part of the boot, it can house an initrd so that extending the utilities of the bootloader will be easier to handle, etc. If this is in error, please correct me.
I do not think it uses the linux kernel. Like U-Boot, it borrows code from the kernel (I think the device driver model in barebox is closer to Linux, but maybe not close enough to allow native porting of drivers)
This was my misunderstanding, however, no one from the Barebox list corrected me on this as you just did. I do not know whether this is because this is still a basically true statement, or whether this is something that is the desired perception.
As for 1 & 2, these I just don't know about. I'm guessing that anything supported in either the Linux kernel or already in u-boot should be fairly easy to port into Barebox. Here, however, I have to define for Mgt clearly what does "fairly" mean.
I think you are looking at this from the wrong angle (or if you are, you are not expressing it clearly to us)...
What is it you need from the bootloader - Lay out the requirements and the specifications first. List them as a series of yes/no questions and rank them in order of importance. Answer each question yes/no/maybe/don't know for both barebox and U-Boot
Put the answers for U-Boot and barebox side-by-side and then come back to the U-Boot and barebox communities and start asking about the 'no', 'maybe' and 'don't know' answers. You should then get a bunch of answers like
- yes out of the box
- no, and never will
- no, but it is being worked on
- no, but sounds like a great idea, let's do it
- no, but should be simple enough
- no, but hey, if you write it, there is no reason not to add it
don't get caught up be 'hey, that's a great feature, I want it' - That is how MS managed to become so massively 'popular'. Everyone _thought_ they needed all those fancy features but really, who uses them (let me remind you of 'clippy'). You end up with a big, slow, hard to maintain system which you only actually use 10% of the features
Right. This is what we have done already. The requirements list for the universal boot loader is not that vast. There are truly only a few requirements: Must be able to load a fail-safe application that would rebuild itself remotely, must be able to boot either our IP Binary image or a Linux kernel, must be able to read/write both NAND and NOR flash devices, and must support a wide range of platforms.
As you see, the requirements fit both Barebox and U-Boot at the moment. My requirement of being easy to use, is not a requirement the company has enforced on us.
Regards,
Graeme
Andy