[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