[PATCH 0/5] Enable Qi / avoiding re-introducing "hidden variable"

Werner Almesberger werner at openmoko.org
Fri Aug 22 12:04:09 CEST 2008

Andy Green wrote:
> On the one hand it can be useful to control the commandline -- although
> it isn't actually generally useful for production device.

Well, many of our users are developers or technophile enough that
they wouldn't be afraid of adding, say, an option that changes the
kernel's log buffer, or some of the other command line options we
introduce along the way.

> If we can hold on to this situation where there is no persistent state
> at all in the bootloader world except its own patchlevel,

Now I'm confused. I'm proposing to make it externally settable,
e.g., with a file in /boot when booting from SD. Right now, that
command line is hard-coded into qi, which seems to be the worst
kind of persistent state.

For NAND, the equivalent would be a well-known location there the
command line is/can be placed, i.e., another one of our new-style
NAND partitions. Again, qi only needs to know that basic layout,
which it already has to for the kernel, without being concerned
what is exactly in that command line or how it gets set.

> So it means
> we need a convincing story about why we need to re-introduce "hidden
> variable" concept before we do that.

Not any more hidden than the kernel itself.

> We have to do some small meddlings in the kernel world now to adapt to
> the absence of PMU init and so on.  But really those meddlings are a lot
> more contained than I imagined, kernel and rootfs comes up already fine
> and only charging is likely broken, it's a few lines.

Cool ! We can probably move most of the GPIO settings as well.
If a GPIO is really unhappy with its reset default state (Z, with
pull-down), it's probably something we want to try to fix anyway,
lest its unhappiness turns into one of those "systems kills itself
faster than it can come our of reset" issues.

So all qi really has to know is how to configure the few pins it
needs to talk to NAND, SD (possible via Glamo), and maybe serial,
while we can leave the rest to the kernel.

- Werner

More information about the openmoko-kernel mailing list