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

Wolfgang Denk wd at denx.de
Wed Apr 18 11:52:25 CEST 2012


Dear Andy,

In message <F9C551623D2CBB4C9488801D14F864C614E679 at 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?


More information about the U-Boot mailing list