[PATCH 2/3 Try#2] NOR Flash Support (U-Boot env)

Werner Almesberger werner at openmoko.org
Mon Dec 24 12:53:38 CET 2007

Andy Green wrote:
> If the kernel that devirginator drops in the device on GTA-01 also has
> the NOR patch, it will create a (useless, but logically present) MTD
> device representing the (IIRC, on GTA-01 nonexistent) NOR device's
> footprint and make the partitions match up.

Hmm, and people installing the new kernel on GTA01 like they
always did so far would find themselves with an unbootable system.
Not nice :-(

> there is a clear problem of scaling the
> development effort over multiple variants

Our ultimate goal is to merge all our code into the respective
upstream sources, so creating permanent branches would actually
move us away from where we want to be, and make life harder for
everyone concerned.

Since the GTA01, GTA02, and whatever code has to co-exist in the
same tree in the end anyway, it's better to do this right from
the beginning.

So the question would be if we can disable the NOR partition at
run time (i.e., when running on GTA01), or, failing that, we can
leave it as a compile-time option.

It's nice if one doesn't have to worry about matching builds with
the exact hardware version. With u-boot, we've lost that a long
time ago (actually, even before I got involved), and have suffered
for it often enough. So let's keep things sane and simple at least
for the kernel.

For the devirginator, three ideas come to mind:

1) Just use a different set of configuration files. They're quite
   simple, so branching these wouldn't be all that much of a pain.

2) Implement #ifdef-like functionality in envedit.pl and pass these
   items on the command line. That way, environment.in can stay the

3) Like 2), and add an environment variable with the hardware version
   to u-boot. That way, envedit.pl could implement the #ifdef-like
   functionality with only looking at the environment obtained from
   the machine.

I'll make the changes for 2) and 3) to envedit.pl. They look like
something that's good to have anyway. Then we can think about what
we want to do on the u-boot side.

- Werner

More information about the openmoko-uboot mailing list