[U-Boot] FW: I want to use Barebox

[ANDY KENNEDY]

> > 1)  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.

> 
> > 2)  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.

> > 3)  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