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

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

[ANDY KENNEDY]

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

2)  I have a feeling we will always be porting everyone's bsp (that
    already has a working u-boot) to barebox.

3)  I also don't really see the real advantage over standard u-boot
    (what's the 'killer' application?).

[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@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

[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

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

[Graeme Russ]

Hi Andy,

On Wed, Apr 18, 2012 at 2:11 AM, ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:
>> > 1) ?I have a concern that barebox is not mainstream enough yet.

[snip]

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

I think you will find the answer is 'No, but it's not as bad as U-Boot'

barebox uses the same driver registration as the Linux kernel and also
uses the Linux 'initcall' mechanism so plugging in a driver is trivial

 - Write the driver
 - Add a device_initcall(driver_name) in the driver source
 - Add an entry to Kconfig

But you fall into the trap of thinking that driver porting from Linux is
trivial - I doubt this is the case as you do not have the feature rich
kernel API (locks, mutexes, memory management, etc)

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

Ditto - but what is the speed penalty?

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

Yep

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

I think they would like to maintain the perception of 'looks and feels
like Linux' without needing to worry about what is under the hood. The
claim to be using the Linux timer API but I had a really good look, and
when push comes to shove, it isn't. Their timer API is much better than
U-Boot's, but it ain't Linux ;)

[snip]

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

[snip]

> 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

Ah-Ha! Now we get to where we (the U-Boot community) need to have a good
hard look at ourselves. You imply that barebox is easier to use than U-Boot
Can you explain? Is it just the posix file API and the way barebox handles
scripting?

If support for U-Boot starts to drop because 'the other options are easier
to use', then we have to address that. But unless we know why 'Option B' is
easier to use than U-Boot, we don't stand a chance :(

> has enforced on us.

Regards,

Graeme

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

[Mike Frysinger]

On Tuesday 17 April 2012 19:40:08 Graeme Russ wrote:
> On Wed, Apr 18, 2012 at 2:11 AM, ANDY KENNEDY wrote:
> But you fall into the trap of thinking that driver porting from Linux is
> trivial - I doubt this is the case as you do not have the feature rich
> kernel API (locks, mutexes, memory management, etc)

it's good that you don't have that cruft :).  i've also found that many 
Blackfin linux drivers utilize IRQs/DMA heavily while the u-boot driver does 
polling/register banging.  sometimes this can make a huge difference to the 
code base, as well as hit a completely different set of issues (such as 
hardware or documentation bugs).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120417/1251b34c/attachment.pgp>

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

[Wolfgang Denk]

Dear Andy,

In message <F9C551623D2CBB4C9488801D14F864C614E679@ex-mb1.corp.adtran.com> you wrote:
> 
> >  - 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 exampl> e,
> >    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

Actually this is an area where you can collect objective, unbiased
information from a number of data sources.  Each of them alone is
probably subject to error or misinterpretation, but together they give
a pretty clear picture.

1) Commit statistics; these are trivial to get from the respective
   git repositories using the "git-dm" tool by Jonathan Corbet (see
   http://repo.or.cz/w/git-dm.git). Here one should pay attention
   that up to and including U-Boot v1.2.0 (commit f4eb545, dated
   Sun Jan 7 00:13:11 2007) both trees share a common history, so
   let's look at this separately:

   Common history: commits 0b666f8..f4eb545

   	2154 csets from 38 developers
	8 employers found
	A total of 1919992 lines added, 279294 removed (delta 1640698)

   U-Boot history since: commits f4eb545..f5cdc11 (=v2012.04-rc2)

   	12648 csets from 647 developers
	54 employers found
	A total of 1632473 lines added, 1132225 removed (delta 500248)

   BareBox history since: commits f4eb545..6a0ab1d   (2012-04-14)

   	4346 csets from 72 developers
	6 employers found
	A total of 458345 lines added, 1404718 removed (delta -946373)

   It has to be pointed out that the inital phase of Barebox is
   probably a bit untypic as it consisted mainly of large removals of
   major parts of U-Boot code, so let's also have a look at a
   somewhat shorter period - we skip the period where BareBox was
   using SVN and start with the first git commit (bc1e507, 2007-07-05
   21:23:42). For U-Boot we chose a close date: commit f1152f8
   (2007-07-06 02:50:19)

   U-Boot history since: commits f1152f8..f5cdc11

   	12212 csets from 630 developers
	52 employers found
	A total of 1531006 lines added, 1099069 removed (delta 431937)

   Barebox history since: commits bc1e507..6a0ab1d

   	3657 csets from 72 developers
	6 employers found
	A total of 377290 lines added, 865712 removed (delta -488422)

   So in the last ~5 years (since 2007-07-05 = 1748 days) we get these numbers:

   			U-Boot	BareBox	ratio
	Commits		12212	3657	3.3
	Developers	630	72	8.8
	Employers	52	6	8.7
	add per day	876	216	4.1
	rm  per day	629	495	1.3
	chg per day	+247	-279

   As you can see, U-Boot has a significantly bigger community
   (both in terms of developers and contributing companies).
   Development is faster, too.


2) Project statistics at ohloh.net:
   compare http://www.ohloh.net/p/u-boot
   versus  http://www.ohloh.net/p/barebox

   Note: this comparison is in favour of the BareBox project, as it
   includes all the common history up to and including commit
   f4eb545 (U-Boot release v1.2.0).


3) Mailing list statistics:
   compare http://lists.denx.de/pipermail/u-boot/
   versus  http://lists.infradead.org/pipermail/barebox/

   For the period of October 2009 (when the BareBox mailing list was
   started) until today we see:

   U-Boot:  total 57.3  MiB gzipped text = 1893 KiB/month
   Barebox: total  7.08 MiB gzipped text =  234 KiB/month

   Also,
   compare http://dir.gmane.org/gmane.comp.boot-loaders.u-boot
   versus  http://dir.gmane.org/gmane.comp.boot-loaders.barebox

   For U-Boot see also:
   http://gmane.org/details.php?group=gmane.comp.boot-loaders.u-boot
   [http://gmane.org/details.php?group=gmane.comp.boot-loaders.barebox
   does not give much information.]


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

This is true. Prediction is always difficult.  On the other hand,
U-Boot is a de-facto standard in the embedded industry; we currently
support 990 board configurations in mainline (not counting the many,
many out-of-tree vendor ports).  This indicates a pretty high momentum
for the project - it is unlikly that it would go out of scope any
time soon - especially if you also take into account that the speed
of development is still increasing.

Compare the 990+ board configurations in U-Boot to 72 configurations
in BareBox.


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

Neither way is easy, but usually it is probably easier to adapot U-Boot
driver code to BareBox, than to port Linux driver code to either
environment.

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

Agreed - the file model and the driver interface are two areas where
BareBox has a much cleaner design.  Well, the driver model is
something where U-Boot will soon draw level.

> 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

You do not _have_ to do it this way.  You can also run plain shell
scripts.  And there are other methods, like importing the envrionment
from files on external media and file systems.


> > > 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 this is definitely not true.  There are many things are are
_not_ easy to port to a boot loader - no matter wether it's U-Boot or
anything else.  An OS is a significantly different beast.  Just to
name a few things that make a lot sense in an OS but are not easy to
add to a boot loader:

- complete TCP/IP stack (especially if you also want it to be robust
  and reliable, and eventually even IPv6 aware)
- concepts like processes, users, name spaces, ...
- encryption and key management (which implies user management)
- full RAID support


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

These requirements are probably fulfilled by both U-Boot and BareBox,
and depending on your personal preferences you may prefer one or the
other here or there. Regarding the "wide range of platforms" the
board count is 990 : 72 for U-Boot (in mainline; note that barebox
has 65 in ARM, and only one each in blackfin, nios2, openrisc, ppc,
and x86; and two for mips) - it is pretty much clear that BareBox is
almost exclusively ARM-centric.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Is a computer language with goto's totally Wirth-less?

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

[Dirk Behme]

Dear Wolfgang,

On 18.04.2012 11:52, Wolfgang Denk wrote:
...
>    U-Boot history since: commits f4eb545..f5cdc11 (=v2012.04-rc2)

Totally off-topic in this thread, but:

Oh, indeed, looking into git we have a v2012.04-rc2 :)

Have I missed the release mail?

Best regards

Dirk

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

[Wolfgang Denk]

Dear Dirk Behme,

In message <4F8E999F.8060304@de.bosch.com> you wrote:
>
> Oh, indeed, looking into git we have a v2012.04-rc2 :)
> 
> Have I missed the release mail?

No - I did not manage to send one yet. [Don't have much to write,
either.]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are always alternatives.
	-- Spock, "The Galileo Seven", stardate 2822.3