On Wed, 2009-12-02 at 13:46 -0800, Tim Bird wrote:

It applies to anything in the "embedded Linux" ecosystem. This
would very much include open source boot loaders like U-Boot.

And coreboot.

The world needs more coreboot.

If coreboot were on ARM, it would be more interesting.
That would make an interesting proposal, I suppose. :-)
-- Tim

Sorry I'm not threading this right, just subscribed to the list and don't have
the old posts to reply to. Reading the web archive...

Bios issues like this come up in the context of qemu sometimes:

http://www.mail-archive.com/qemu-devel@nongnu.org/msg15078.html

As I am prone to do, I wrote a _massive_ pseudo-documentation rant about this
issue (with lots of links, of course) on my Firmware Linux project's mailing
list:

http://lists.impactlinux.com/pipermail/firmware-impactlinux.com/2009-
October/000377.html

I'll attempt to summarize:

BIOSes come in two parts, DRAM controller init and bootloader. In the open
source x86 world, coreboot handles the first part and the Bochs bios handles
the second part. In the ARM world, u-boot handles both, which is nasty and
tangled and not orthogonal and has downsides.

Lots of people want to use u-boot as _just_ a bootloader, not as a hardware
initializer. (For example, they want to use it under qemu and their DRAM
controller doesn't need initialization before they have writable memory.)
This confuses the u-boot guys, who have a FAQ about it:

http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM

Which boils down to "you are weird for wanting our code to be orthogonal, if
you know enough about the problem space to ask you MUST already know enough
about the u-boot implementation to do this yourself".

I would love to dig into u-boot and beat orthogonality out of the sucker,
document the issues involved, and thus let people use it A) as a lilo/grub
alternative bootloader on the PC, B) under qemu on every supported target.

Unfortunately, I haven't had the time. (And using u-boot on the PC would also
involve pushing the device tree genericization going on, since u-boot thinks
in terms of device trees and x86 does not.)

Is it cheating to write up a proposal for something you would yourself be
willing to be funded to spend a few weeks doing?

Rob

P.S. Yes, that was the summary. The rant I linked to is much, much.
Somebody should write documentation about all this crap, and I'm sort of
dreading the idea that it'll wind up being me again...
--
Latency is more important than throughput. It's that simple. - Linus Torvalds

Rob,

On Sun, Dec 13, 2009 at 02:03:43AM -0600, Rob Landley wrote:

Lots of people want to use u-boot as _just_ a bootloader, not as a
hardware initializer. (For example, they want to use it under qemu and
their DRAM controller doesn't need initialization before they have
writable memory.)

Note that Barebox (aka u-boot-v2) can be built as a second stage
bootloader ontop of any other bootloader (which is basically what you
want), and especially on x86, we recently ported it ontop of a normal
BIOS. I assume we need a little bit more documentation (and for the long
term surely also drivers for the usual filesystems), but the
infrastructure is there.

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

On Sunday 13 December 2009 13:23:50 Robert Schwebel wrote:

Rob,

On Sun, Dec 13, 2009 at 02:03:43AM -0600, Rob Landley wrote:

Lots of people want to use u-boot as _just_ a bootloader, not as a
hardware initializer. (For example, they want to use it under qemu and
their DRAM controller doesn't need initialization before they have
writable memory.)

Note that Barebox (aka u-boot-v2) can be built as a second stage
bootloader ontop of any other bootloader (which is basically what you
want), and especially on x86, we recently ported it ontop of a normal
BIOS. I assume we need a little bit more documentation (and for the long
term surely also drivers for the usual filesystems), but the
infrastructure is there.

Does u-boot acknowledge your status as u-boot-v2?

The u-boot project seems to be the dominant bootloader out there right now for
non-x86 stuff. It would be nice if it could be simplified and genericized to be
_more_ widely applicable.

Pointing out that grub and redboot and the dozens of other bootloaders can do
things u-boot can, in a subset of the contexts u-boot currently supports and
with a syntax and codebase not as many developers are already familiar with,
strikes me less interesting.

Googling for "barebox" brought up a first page consisting almost entirely of
various reviews of some kind of movie series starring Doris Wishman. Googling
for "barebox boot loader" brought up posts to this mailing list from last week
as the third hit...

Ah, you're probably referring to the _fifth_ hit, this thing:
http://www.barebox.de/

The project page it links to is in german. "By the power of
translate.google.com"...

Submarine is one of the best boot loader, which are available on the market
- at least from a user perspective. Due to its large submarine community
has continuously developed and now serves many functional requirements.

I certainly don't want to try to compete with it.

From developer's point of view in a U-boat, many contaminated sites that are

for us over the years, increasingly become a problem. The "normal"
community way now would have been to change with the help of small patches
in U-Boot v1 so that he no longer has these limitations. But we believe
that our ideas of a modern bootloader poorly with the requirement that the
U-boat must remain ever included in the code base for all the boards
stable. The changes are simply too intrusive to make this possible without
having access to the hardware.

I.E. changing u-boot was too hard, so you forked it. Yeah, been there, done
that. It's a lot of work, and the original project being _actually_dead_ is a
bit of a prerequisite. (It's hard to overtake even absolute crap with a 5
year headstart, and I'll avoid godwining the conversation with mention of What
Lies in Redmond.)

That's why when a team Pengutronix by Sascha Hauer, deals with the question
how would U-boat look like if there were no historical baggage

Please read Joel Spolsky's "Things you should never do, part I":

http://www.joelonsoftware.com/articles/fog0000000069.html

He wasn't talking about open source, so on top of that you have to worry about
forking your development community and "project gravity" attracting users and
developers to one project over another.

- the result
is U-Boot v2. We do not see v2 as a fork, but as a technology study for the
next generation of boot loader. Whether further establishing v2 in the
future as stand alone software, or if the features will be gradually back
to v1 of v2, we do not even know.

Wake me when you decide.

In any case, we want to see the v2
project in the submarine community.

That's nice. I'll add it to the pile of open firmware, smart firmware,
micromon, grub, lilo, silo, tilo, milo, nilo, rolo, syslinux and friends
(pxelinux, etherboot...), loadlin, linload, aboot, bootlx, bootx, blob,
bootldr, redboot, able, garux, ppcboot, yaboot, osloader, cyace, loadlce, sh-
ipl+g...

rsc

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds

"Rob" == Rob Landley <rob@...> writes:

Hi,

Rob> Ah, you're probably referring to the _fifth_ hit, this thing:
Rob> http://www.barebox.de/

Rob> The project page it links to is in german. "By the power of
Rob> translate.google.com"...

There's a nice UK flag you can click on to get the english version ;)

http://www.pengutronix.de/software/u-boot/v2/index_en.html

The u-boot-v2 -> barebox rename is very recent.

--
Bye, Peter Korsgaard

Rob Landley wrote:

Is it cheating to write up a proposal for something you would yourself be
willing to be funded to spend a few weeks doing?

Not at all. It's encouraged! :-)

People passionate about something are most likely to propose
it AND to be willing to work on it.
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Rob,

On Mon, Dec 14, 2009 at 05:42:40AM -0600, Rob Landley wrote:

On Sun, Dec 13, 2009 at 02:03:43AM -0600, Rob Landley wrote:

Lots of people want to use u-boot as _just_ a bootloader, not as a
hardware initializer. (For example, they want to use it under qemu and
their DRAM controller doesn't need initialization before they have
writable memory.)

Note that Barebox (aka u-boot-v2) can be built as a second stage
bootloader ontop of any other bootloader (which is basically what you
want), and especially on x86, we recently ported it ontop of a normal
BIOS. I assume we need a little bit more documentation (and for the long
term surely also drivers for the usual filesystems), but the
infrastructure is there.

Does u-boot acknowledge your status as u-boot-v2?

Our hope was that the u-boot community would acknowledge our activities
as some kind of next generation research, but as this didn't turn out
to be true, we are in the process of moving towards a separate project.

We had a talk about u-boot-v2 at ELCE in Grenoble [1], which received
quite some positive feedback, so our hope is that under a new project
name it will be more visible.

There are some design ideas in barebox which might attract kernel
developers:

- POSIXish shell scripting instead of environment-scripting
- Kconfig + kbuild based menuconfig and customizing
- driver model (devices+drivers)
- kernel coding style

Googling for "barebox" brought up a first page consisting almost
entirely of various reviews of some kind of movie series starring
Doris Wishman.

I've just uploaded the new website to http://www.barebox.org

Yes, we know that it is yet another bootloader. Barebox came up from our
own needs in our projects, and it helps us solving real world issues.
Like with every open source project, it is up to the community to decide
if others might be interested.

Thanks,
Robert

[1] http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations?action=AttachFile&do=get&target=Hauer-U_BootV2.pdf
--
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 |

Dear Robert,

in message <20091215140430.GZ22533@...> you wrote:

Does u-boot acknowledge your status as u-boot-v2?

Our hope was that the u-boot community would acknowledge our activities
as some kind of next generation research, but as this didn't turn out
to be true, we are in the process of moving towards a separate project.

Well, that's actually a pretty lopsided view. Fact is that what you
now call "Barebox" started as a secret behind-closed-doors project.
It has never been announced anywhere, nor was anybody outside your
company ever invited to discuss the design before you started. And it
took some persuasiveness to actually talk you into making the code
publicly available.

If there had been any prior discussion, and if there had been any
involvment of the community, it might have been possible to come up
with some migration path - in both directions.

Instead, you intentionally decided to cut off all history and start
from scratch, with no update path at all. Now it is impossible for a
U-Boot user with existing code to migrate to "Barebox" (except by
throwing all away and restarting from scratch), nor to move new
design ideas from "Barebox" into U-Boot (at least not easily).

Like with every open source project, it is up to the community to decide
if others might be interested.

Right.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@...
"There are three principal ways to lose money: wine, women, and en-
gineers. While the first two are more pleasant, the third is by far
the more certain." -- Baron Rothschild, ca. 1800

Wolfgang Denk wrote:

Dear Robert,

in message <20091215140430.GZ22533@...> you wrote:

Does u-boot acknowledge your status as u-boot-v2?

Our hope was that the u-boot community would acknowledge our activities
as some kind of next generation research, but as this didn't turn out
to be true, we are in the process of moving towards a separate project.

Well, that's actually a pretty lopsided view. Fact is that what you
now call "Barebox" started as a secret behind-closed-doors project.
It has never been announced anywhere, nor was anybody outside your
company ever invited to discuss the design before you started. And it
took some persuasiveness to actually talk you into making the code
publicly available.

If there had been any prior discussion, and if there had been any
involvment of the community, it might have been possible to come up
with some migration path - in both directions.

Instead, you intentionally decided to cut off all history and start
from scratch, with no update path at all. Now it is impossible for a
U-Boot user with existing code to migrate to "Barebox" (except by
throwing all away and restarting from scratch), nor to move new
design ideas from "Barebox" into U-Boot (at least not easily).

At the end of the story there are some interesting features in Barebox
that are not present in U-Boot however, it's a bit disappointing. Maybe
can be the example of how _not_ work with the community and the problem
of the interfaces between open source community and companies,
unfortunately it's a common problem. Robert do you see any "merge path"
in the future for Barebox and U-Boot?

Marco

Dear Wolfgang,

On Tue, Dec 15, 2009 at 05:44:27PM +0100, Wolfgang Denk wrote:

Our hope was that the u-boot community would acknowledge our
activities as some kind of next generation research, but as this
didn't turn out to be true, we are in the process of moving towards
a separate project.

Well, that's actually a pretty lopsided view. Fact is that what you
now call "Barebox" started as a secret behind-closed-doors project.

That's strong wording. We had requirements which could not be fulfilled
under the constraints of the u-boot project: mainly that we felt that
doing radical design changes wasn't possible while ensuring not to break
untestable existing boards. Nobody even has all that hardware, and the
changes Sascha made havn't been only a small patch here and there, they
have been fundamental.

Yes, the code has been developed somewhere, following the "working code
is better than words" paradigm. I see nothing bad with that, it's a
legitime possibility in open source land. We even didn't know if it was
possible at all before Sascha actually did it. It wasn't more than an
experiment and a weekend hack at that time.

It has never been announced anywhere, nor was anybody outside your
company ever invited to discuss the design before you started.

It has been announced on the u-boot list when it was in a state where we
actually had something that could be announced, and we made quite clear
that our aim was to collaborate with the u-boot community.

And it took some persuasiveness to actually talk you into making the
code publicly available.

I told you about our activities personally very early at an OSADL
meeting, at a time where it was really nothing more than a design study;
you indicated interest and even offered the git tree on the u-boot
server; we accepted that and made the code public as fast as it was in a
state that it was actually not crashing on the first run.

However, it very quickly turned out that there was no real interest on
your side about actually looking at the code and discussing the
technological steps. Instead, you started the same discussion as you do
today.

If there had been any prior discussion, and if there had been any
involvment of the community, it might have been possible to come up
with some migration path - in both directions.

The "don't break existing code" pattern was set in stone on your side.
Time is a limited resource, and under that constraints, I'm still not
convinced that it could have been done timely.

Other than that, we tried really hard to start a *technical* discussion
about our code on the u-boot list. Unfortunately, my impression is that
your interest was pretty low. I assume that you have your reasons.

Instead, you intentionally decided to cut off all history and start
from scratch, with no update path at all.

As it was not possible to test boards we don't have, we went the other
way around: starting with the core changes plus nothing, then adding
board by board. It scratched our personal itch, in a pragmatic way.

Now it is impossible for a U-Boot user with existing code to migrate
to "Barebox" (except by throwing all away and restarting from
scratch),

Experience shows that porting existing boards from u-boot to barebox and
vice versa is something like less than a day of effort, taken that all
necessary frameworks are there in barebox. In fact, porting a PXA270
board was recently done in < 2h.

nor to move new design ideas from "Barebox" into U-Boot (at least not
easily).

Well, that would have required that the U-Boot maintainer would actually
be interested in having a look at the design ideas.

I don't think this discussion leads somewhere. As you said: let the
community decide. I'm not religious in either way, really. There
actually *is* community which is interested, and our hope with the
renaming is that the code is more visible than before.

Regards,
Robert
--
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 |

On Tue, Dec 15, 2009 at 11:44, Wolfgang Denk wrote:

Instead, you intentionally decided to cut off all history  and  start
from  scratch, with no update path at all. Now it is impossible for a
U-Boot user with existing code to migrate  to  "Barebox"  (except  by
throwing  all  away  and  restarting  from  scratch), nor to move new
design ideas from "Barebox" into U-Boot (at least not easily).

it's going to be impossible shortly anyways because of your decision
to force u-boot to GPL-3. barebox is (thankfully) staying at GPL-2.
-mike

Marco,

I've tried to outline the history in my answer to Wolfgang.

On Tue, Dec 15, 2009 at 06:03:13PM +0100, Marco Stornelli wrote:

Robert do you see any "merge path" in the future for Barebox and
U-Boot?

We have tried that in the past, but Wolfgang's interest in even starting
a discussion on a feature and technology level was pretty low. So I
don't think it's easily possible.

The open source universe has the advantage that, if something makes
sense, somebody will do it. We'll see what happens.

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

Dear Robert,

In message <20091215183852.GG22533@...> you wrote:

On Tue, Dec 15, 2009 at 06:03:13PM +0100, Marco Stornelli wrote:

Robert do you see any "merge path" in the future for Barebox and
U-Boot?

We have tried that in the past, but Wolfgang's interest in even starting
a discussion on a feature and technology level was pretty low. So I
don't think it's easily possible.

Hm... was it me or you who asked to have your new code in a publicly
accessable repository?

And even if I had no interest - who cares? I have never attempted to
prevent any discussion about features or technological topics. Except
for SPAM-filtering, the U-Boot mailing list is open for everyone. If
you have anything to contribute, then post your proposals or submit
your patches on the mailing list like everybody else does. But I'm
repeating myself; for reference see
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/29597/focus=29613

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@...
The last thing one knows in constructing a work is what to put first.
- Blaise Pascal

On Tuesday 15 December 2009 12:30:22 Robert Schwebel wrote:

Dear Wolfgang,

On Tue, Dec 15, 2009 at 05:44:27PM +0100, Wolfgang Denk wrote:

Our hope was that the u-boot community would acknowledge our
activities as some kind of next generation research, but as this
didn't turn out to be true, we are in the process of moving towards
a separate project.

Well, that's actually a pretty lopsided view. Fact is that what you
now call "Barebox" started as a secret behind-closed-doors project.

That's strong wording. We had requirements which could not be fulfilled
under the constraints of the u-boot project: mainly that we felt that
doing radical design changes wasn't possible while ensuring not to break
untestable existing boards. Nobody even has all that hardware, and the
changes Sascha made havn't been only a small patch here and there, they
have been fundamental.

Ok, I'd like to propopse something I'm not likely to be able to _do_ but which
SOMEBODY should.

Integrate device tree support into QEMU.

What I mean by that is allow qemu to take a flattened device tree and parse it
the same way the Linux kernel does, only to determine what hardware to
_emulate_ rather than what hardware to attach drivers to.

That way, at some glorious future, date, qemu's board emulation boils down to
feeding it a device tree file, which it parses to set up the board emulation,
and then passes on to the -kernel so that knows which board it's using too.

Then testing at least some of the 8 gazillion existing boards becomes a
_lot_easier_.

(Yes, I've personally hit this in my Firmware Linux project, which is
essentially trying to get the same basic userspace booting under qemu for arm,
mips, powerpc, sh4, x86, x86-64, sparc, and everything else, so that you can
regression test things like busybox and uClibc and the generic parts of the
kernel itself. Setting up two boards that use the same compiler and even the
same squashfs root filesystem image shouldn't be nearly as hard as it is.)

I can put this in the same format as the others if it's interesting, but I'm
probably not the best peerson to actually _implement_ it.

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds

On Tuesday 15 December 2009 12:37:57 Mike Frysinger wrote:

On Tue, Dec 15, 2009 at 11:44, Wolfgang Denk wrote:

Instead, you intentionally decided to cut off all history and start
from scratch, with no update path at all. Now it is impossible for a
U-Boot user with existing code to migrate to "Barebox" (except by
throwing all away and restarting from scratch), nor to move new
design ideas from "Barebox" into U-Boot (at least not easily).

it's going to be impossible shortly anyways because of your decision
to force u-boot to GPL-3. barebox is (thankfully) staying at GPL-2.

Oh dear. That does make barebox a heck of a lot more interesting.

I'm sorry to hear about the end of u-boot as a Linux-kernel compatible
project. It's a pity, it _was_ close to becoming a de-facto Linux standard,
but a move to GPLv3 pretty thoroughly kills any interest I have in it.

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds