Current Bootchart / breaking SD boot

Carsten Haitzler (The Rasterman) raster at
Wed Jul 9 00:13:31 CEST 2008

On Tue, 8 Jul 2008 18:44:48 -0300 Werner Almesberger <werner at>

> Carsten Haitzler wrote:
> > 1. we dont ship with that uboot menu - or we shouldnt be. the uboot env i
> > know we ship waits 3 seconds then just boots.
> Huh ? Last time I checked, we very much did. It's the menu you get when
> you press and hold POWER and then press and hold AUX.

i mean the one where u just press power. it boots. no menu by default.

> > remember i said to build DIFFERENT images.
> Being able to have different images for different purposes is nice,
> but we have to be careful about having just too many different ways
> to run the system. Otherwise, it gets hard to reproduce problems
> that other people are seeing, slowing down problem resolution or
> even preventing it.

sure. the other solution is we end up with a slower kernel boot than we need
because of a "just in case someone wants to try this out and happens to know to
press both buttons at once to boot off an sd card they specially prepared for
this". if we want to product a product - which is what we are meant to do, not
just an endless development toy that has all thew wires poking out, we need to
sacrifice some things. this is one thing where we either decide the feature is
so important we will live with the slowdown on kernel boot, we invest lots of
effort to make it faster on kernel boot (so it has no actual impact), or we
remove it for production kernels (dev, debug, hacker etc. kernels can keep it).

at least that's how i see it. we are aiming to produce a slick product. we need
to take the training wheels off sooner or later (and for those not confident in
the product u can put them back on again). if we can get rootfs on sd for "no
(real) boot slowdown" i'm all for it! if it costs nothing - keep it, but it
costs something non-insignificant (or now it is not significant as a lot of
other things are bad, but it will be significant once enough has been optimised

Carsten Haitzler (The Rasterman) <raster at>

More information about the openmoko-devel mailing list