I want to use Barebox

I want to use Barebox

[ANDY KENNEDY]

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: I want to use Barebox

[Sascha Hauer]

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)
- 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

> 
> 
> 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.

You're right, U-Boot drivers are usually simple to port over to barebox.
Many subsystems like mmc, network and USB are derived from U-Boot,
others like gpio or mtd are from the kernel. Porting these over usually
means some refactoring. For example U-Boot has no device/driver model,
so you would have to add registration and probe functions. The
complicated thing about drivers (at least in the bootloader world) is
getting the hardware accesses right, and these can be copied from the
original driver.

I hope this helps with your decision

 Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

RE: I want to use Barebox

[ANDY KENNEDY]

> > 1)  I have a concern that barebox is not mainstream enough yet.
> 
> Well by using it you could make it a bit more mainstream ;)

Hmmm.  That will be an UP HILL battle for me, I'm sure.  Are there any
stats on how many folks / who all uses Barebox currently?


> others like gpio or mtd are from the kernel. Porting these over usually
> means some refactoring. For example U-Boot has no device/driver model,
> so you would have to add registration and probe functions. The
> complicated thing about drivers (at least in the bootloader world) is
> getting the hardware accesses right, and these can be copied from the
> original driver.
> 

Confused.  So, you are saying that going from U-Boot to Barebox is
not trivial (being the driver model is different), but these BSPs
often times have drivers in the Linux kernel.  Granted, these are
arch drivers and thus are probably not easily ripped out of the Linux
kernel (most platform specific drivers I've seen are so intermingled
with other Kernel calls it would be difficult to detach that).  Would
it be less painful to port from the arch directory in the kernel than
from U-Boot?

> I hope this helps with your decision

This does not sway me more to using Barebox, that is impossible ;).
Perhaps it will give me fodder for convincing others.

> 
>  Sascha

Thanks for your reply.  It was most useful.
Andy

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: I want to use Barebox

[Eric Bénard]

Hi Andy,

Le Fri, 13 Apr 2012 20:38:12 +0000,
ANDY KENNEDY <ANDY.KENNEDY@adtran.com> a écrit :

> > > 1)  I have a concern that barebox is not mainstream enough yet.
> > 
> > Well by using it you could make it a bit more mainstream ;)
> 
> Hmmm.  That will be an UP HILL battle for me, I'm sure.  Are there any
> stats on how many folks / who all uses Barebox currently?
> 
we are using it on all our i.MX based SOM (i.MX25/35/51/53), and have
been using it in several custom product developped (mainly i.MX & AT91
based, some of them being in production) for customers (in one product
the bootloader is even still named u-boot-v2 as the code for i.MX27 was
already in a very good shape at that time ;-)

In the past, RedBoot was often available in official BSPs and at that
time some people had the same hesitation to use the community u-boot
instead of the manufacturer's RedBoot ... and after a few years u-boot
became the de facto standard bootloader for many official BSP.

Moreover, some manufacturer's BSP can be quite hard to adapt to a
custom hardware which is not the exact copy of the evaluation board,
but of course, for a manager, using an official BSP gives a feeling of
security and seems to be the obvious choice (even if the official BSP is
not maintained once it's available and not really validated outside the
case of one evaluation board) ...

Eric

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: I want to use Barebox

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:12 Fri 13 Apr     , Eric Bénard wrote:
> Hi Andy,
> 
> Le Fri, 13 Apr 2012 20:38:12 +0000,
> ANDY KENNEDY <ANDY.KENNEDY@adtran.com> a écrit :
> 
> > > > 1)  I have a concern that barebox is not mainstream enough yet.
> > > 
> > > Well by using it you could make it a bit more mainstream ;)
> > 
> > Hmmm.  That will be an UP HILL battle for me, I'm sure.  Are there any
> > stats on how many folks / who all uses Barebox currently?
> > 
> we are using it on all our i.MX based SOM (i.MX25/35/51/53), and have
> been using it in several custom product developped (mainly i.MX & AT91
> based, some of them being in production) for customers (in one product
> the bootloader is even still named u-boot-v2 as the code for i.MX27 was
> already in a very good shape at that time ;-)
> 
> In the past, RedBoot was often available in official BSPs and at that
> time some people had the same hesitation to use the community u-boot
> instead of the manufacturer's RedBoot ... and after a few years u-boot
> became the de facto standard bootloader for many official BSP.
> 
> Moreover, some manufacturer's BSP can be quite hard to adapt to a
> custom hardware which is not the exact copy of the evaluation board,
> but of course, for a manager, using an official BSP gives a feeling of
> security and seems to be the obvious choice (even if the official BSP is
> not maintained once it's available and not really validated outside the
> case of one evaluation board) ...
I agree with Sasha and Eric

I've sevral customer using barebox in productoin on AT91, IMX, OMAP and SH
and asking to do not use U-Boot anymore.

and yes we port or re-write the bsp of the vendor in Barebox but you do it
once. After you just have to add board which is really more esaly and less
time consuming.

Some vendor start now to take a look on barebox to propose both BSP U-Boot and
Barebox.

I personnaly maintain U-Boot ARM for few years and switch to barebox as to
have the feature and code quality I need it was too much time consuming.

Best Regards,
J.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: I want to use Barebox

[Jean-Christophe PLAGNIOL-VILLARD]

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