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

Andy Green andy at openmoko.com
Mon Dec 24 13:19:19 CET 2007

Hash: SHA1

Somebody in the thread at some point said:
> 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 :-(

They can DFU-update to a contemporary GTA-01 U-Boot and they're away
again, if I understood you.

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

My point is that the even more ultimate goal is to get a production
version out.  For example I don't have a GTA-01 and I can't test what I
am putting out for GTA-01... should that really delay what can usefully
be done towards GTA-02?  These kind of thoughts lead me to this
backporting concept.

> 2) Implement #ifdef-like functionality in envedit.pl and pass these
>    items on the command line. That way, environment.in can stay the
>    same.
> 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.

If the future is kind that can work fine.  Or it can turn into an
impenetrable #ifdef forest :-)

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-uboot mailing list