[U-Boot] FW: I want to use Barebox
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@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?).
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.
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.
Thanks in advance for any help you can provide.
Andy
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@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.
- 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
- 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
- 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
- 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.
- 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 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
Hi Andy,
On Wed, Apr 18, 2012 at 2:11 AM, ANDY KENNEDY ANDY.KENNEDY@adtran.com wrote:
- I have a concern that barebox is not mainstream enough yet.
[snip]
- 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)
- 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
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
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.
- 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.
- 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
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
participants (5)
-
ANDY KENNEDY -
Dirk Behme -
Graeme Russ -
Mike Frysinger -
Wolfgang Denk