mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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

      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