[PATCH 0/8] Qi solve GTA02 dynparts compatability and parse idenity partition
andy at openmoko.com
Wed Feb 4 10:29:51 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| As far as i understand, NAND u-boot does this dynparts
| computation only on user's request, not on every boot. That way, if
| e.g. one block wears out in "u-boot" partition that's no big deal, the
| user won't ever notice that and partition offsets will be
If you run dynpart again in U-Boot it too recognizes the new bad blocks
and does exactly what Qi does, and U-Boot can never regenerate the old
dynpart list from before. So U-Boot is in a dangerous fragile temporary
situation courtesy of it's then outdated private environment copy of the
bad block situation.
The bad block is the reality, you are only think you are able to say
"it's no big deal" that U-Boot fails to adjust to it because it happens
U-Boot isn't using all of its NAND partition space and it's 2KByte block
However, on this s3c2442 MCP Flash, the erase block size is 128KBytes,
not 2KBytes as the read block. On the GTA02 I have with some bad blocks
in the environment, the 128KByte (0x20000 byte) ERASE block is all
marked as bad.
Now "if one block wears out in 'u-boot' partition that's no big deal"
becomes failure to boot because current U-Boot for GTA02 is 211KByte in
a 256KByte partition and you just lost 128KBytes. If the first sector
dies then you have just had it, although that is guaranteed for 1000
erase cycles with ECC (which we don't use in Qi), compared to 100K erase
/ write endurance for any cell. Probably 1000 is enough bootloader updates.
Similarly you assume any other partition contents can just absorb the
loss of one or more 128KBytes and I'm not sure that's going to be so
going on, eg, kernel part + backup / menu rootfs.
| unaltered. With this Qi patches, the start of kernel partition will be
| shifted forward (as well as start of all other partitions) to
| compensate for one block and user won't be able to boot because he has
| to reflash both kernel and rootfs, is this correct? So, the user
| starts NOR u-boot to reflash but does NOR u-boot perform dynparts
| calculation on every start? If not, then the user will be using wrong
| offsets again, if yes, then it will be inconsistent with NAND u-boot.
You can run dynpart in there to get a new session dynpart (just tried
it) and then DFU in according to that rather than any environment one.
Also if you trash the U-Boot env partition, then blow a new NAND U-Boot
(what always starts from block +0 so is independent of dynparts) via
NOR, when it runs it will create a default env with dynpart so you can
always recover if it's not the first erase block died.
|> In addition, the identity or factory partition is mounted
|> and the USB Mac address is recovered and appened to the
|> commandline suitable for use by the Ethernet gadget.
| This reminds me of one issue seen "in the wild" nobody's taken care of
| yet. I've seen several user reports that they tried to "nandwrite -pm"
I googled "openmoko-kernel nandwrite" and didn't see anything.
I search on trac for "nadwrite" and get one hit that is not related.
Where is this in trac or on the list? If you choose to talk about stuff
on IRC then you're choosing to make it pretty invisible, please don't
then complain that "nobody has taken care of it".
| u-boot environment can be flashed to the corresponding partition. This
| example is also probably illustrates some incompatibilities between
| NAND and NOR u-boot wrt partition offsets (that is, everything's all
| right until dynparts will calculate non-default offsets).
It illustrates raw NAND is evil and flaky as told many times here.
| I hope you can at least try to look at the "nandwrite -pm" issue and
| outline possible solutions for the failing case.
If you or another sufferer can write it up in trac how to reproduce it,
I try get someone to take a look at it.
| And as i see it Qi should be maximum compatible with NOR u-boot (that
| can assumed to be untouchable), not some particular usage case of NAND
Qi has a lot of conflicting requirements it needs to find the best path
through. It's not going to do the wrong thing badly because that's how
U-Boot of one flavour or another happened to do it a year ago, it's
going to try to just work in the bulk of cases better than U-Boot, which
is what we have now.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel