From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: I want to use Barebox
Date: Sat, 14 Apr 2012 06:28:32 +0200 [thread overview]
Message-ID: <20120414042832.GB2074@game.jcrosoft.org> (raw)
In-Reply-To: <20120413202303.GT3852@pengutronix.de>
On 22:23 Fri 13 Apr , Sascha Hauer wrote:
> On Fri, Apr 13, 2012 at 03:37:04PM +0000, ANDY KENNEDY wrote:
> > 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.
>
> Well by using it you could make it a bit more mainstream ;)
>
> >
> > 2) I have a feeling we will always be porting everyone's bsp (that
> > already has a working u-boot) to barebox.
>
> I'd say that usually barebox better abstracts from the hardware, so
> different boards usually feel much more the same. With U-Boot the usage
> often differs across different boards. Having a common environment
> becomes a real advantage when you have many different boards.
>
> > 3) I also don't really see the real advantage over standard u-boot
> > (what's the 'killer' application?).
>
> For me the basic killing feature is that barebox has filesystem support
> which means that you can mount filesystems and only have one
> 'ls' (cp, rm,..) command to access all files and devices. U-Boot instead
> has a set of these commands for each filesystem and device:
>
> fatload <interface> <dev[:part]> <addr> <filename> [bytes]
> nand read - addr off|partition size
> mmc read addr blk# cnt
> eeprom read devaddr addr off cnt
>
> All these commands have a different syntax and are non obvious to use.
> Also note that the target of all the commands above is a chunk of plain
> SDRAM. This means that in case of a system update you always have to
> copy the update image first from the device to SDRAM and then from SDRAM
> to the target device. To do this you have to know where SDRAM is (varies
> across different boards) and also the size of the update image is
> limited by the amount of free SDRAM you have. With barebox all this goes
> down to for example cp /mnt/usb0-fat/rootimage /dev/nor0.root.
>
> There are other things aswell:
>
> - barebox has a sane configuration system (U-Boot is configured using
> several thousand CFG_* defines)
> - barebox can always start itself as a second stage loader (with U-Boot
> you have to compile a special ramboot image which then again can't
> start first stage)
> - barebox can start zImages, raw Linux images, uImages, all using the
> same command (U-Boot is limited to uImages)
you forget Android Image
> - barebox has command line options, U-Boot only supports positional
> arguments
> - barebox has a driver model which means that you can register devices
> which automatically find the correct driver.
> - you can put your environment into files as opposed to 'executable
> environment variables' in U-Boot
we have full feature bootp support with a dhcp client supporting
vondor id
client id
client uuid
user class
and very esay to extend
we have menu support that you can write in c or shell
we have shell support with shell script (file)
U-Boot use var to store the shell which is quite hard to customised
and make it nearly imposssible to foactorize.
On barebox we have a defaultenv that you just need to cusmoize in your board
without having to touch it. (this simplify to adding of platform quite a lot).
We have DFU support, srial of USB device that you can select at the runtime
(take a look on the Atmel reference baord or the Calao)
We have pull support that allow you to have recurent task evenif we do not
support IRQ (impossible in u-boot)
And if you need modules support to extend barebox feature at the run time
And framebufer support (derived from the kernel)
I'm sure I forget some feature but barebox is design to easly share the code
with the kernel and to simplify the life of the developper and the end
customer
And I implement complex boot sequence easly in barebox where in U-Boot evenif
I known perfecly I get hard time.
Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2012-04-14 4:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-13 15:37 ANDY KENNEDY
2012-04-13 20:23 ` Sascha Hauer
2012-04-13 20:38 ` ANDY KENNEDY
2012-04-13 21:12 ` Eric Bénard
2012-04-14 4:18 ` Jean-Christophe PLAGNIOL-VILLARD
2012-04-14 4:28 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120414042832.GB2074@game.jcrosoft.org \
--to=plagnioj@jcrosoft.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox