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

[Graeme Russ]

Hi Andy,

On Tue, Apr 17, 2012 at 1:58 AM, ANDY KENNEDY <ANDY.KENNEDY at adtran.com> wrote:
> Wolfgang corresponded with me over the weekend asking me to (in the
> interest of being fair) repost this message to the U-Boot list as well
> to allow you the opportunity to expound upon the benefits of U-Boot
> as our selection for our in-house universal boot loader.
>
> You guys know best the glories of U-Boot.  Convince me.
>
> Andy
>
> -----Original Message-----
> From: ANDY KENNEDY
> Sent: Friday, April 13, 2012 10:37 AM
> To: 'barebox at lists.infradead.org'
> Subject: I want to use Barebox
>
> I first saw Barebox about a year ago, did a little poking around and
> realized that this seems like the way to go for booting an embedded

Can you provide us (the U-Boot community) some deeper insight into this
conclusion? This would help us to decide what development is needed in
order to assure U-Boot best meets the needs and desires of the end users

> system.  I am, however, meeting opposition to implementing Barebox in
> our current system.  I need some help on questions I cannot answer.  If
> you could, please take the time to answer the following few issues.
>
> 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

> 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


> 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

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

> 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

Regards,

Graeme