[U-Boot] FW: I want to use Barebox

[Graeme Russ]

Hi Andy,

On Wed, Apr 18, 2012 at 2:11 AM, ANDY KENNEDY <ANDY.KENNEDY at adtran.com> wrote:
>> > 1)  I have a concern that barebox is not mainstream enough yet.

[snip]

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

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)

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