[PATCH 0/8] Qi solve GTA02 dynparts compatability and parse idenity partition

Wed Feb 4 20:04:31 CET 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green <andy at openmoko.com> writes:
|> 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.
|
| In this case, yes. With Qi in NAND that's not so, as far as i
| understand. Nevertheless, what will be if one block wears out in the

Qi fits in one erase block because it's slim, but if the first erase
block is marked as bad we're also screwed.

| kernel partition? The user won't be able to even mount his NAND rootfs
| after the next boot to save configuration/data and that is probably
| important for many users.

Well people seem to mass-nuke their mtdblock6 with jffs2 images at the
drop of a hat; his valuable data can go on SD card.

Yes, in the event that a kernel partition block goes bad (rated for 100K
erase-write cycles) even allowing for ECC which is used in that
partition from U-Boot and Linux context, the only things that write to
it, then Qi'll "work around it" by moving up the rootfs.  Same as U-Boot
will if you lost your environment and ran dynparts again.

Even I'm not planning to update 100,000 kernels, I think I'm up to a few
thousand in over a year, and that on different GTA02s.

|> 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.
|
| I don't assume and don't say that the previous scheme is correct or
| better. This whole idea of NAND partitions is somehow flawed, imho.

Everyone agrees with that.  There's an overcommit alternative where you
start the partitions at fixed offsets always but pad each with "spare"
sectors that will get used as the others go bad.  But we're playing this
dynparts game because that's what's on GTA02s and we can't update NOR.

|> | 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.
|
| That is, to be absolutely sure that the flashing will be done to the
| correct addresses, everytime before dfu-ing anything a user must issue

Seems like that's taken care of.

| But i can complain about your Trac, that's for sure. Trac lacks many
| capabilities that are considered basic for bugtracking. It even has no
| dup tracking. And bugzilla had that for ages. And it's weirdly
| configured: there's no component "kernel" but there're both "System
| Software" (which includes questions about ASU and X) and "u-boot"
| (which is not system software, indeed).

Fine... but it does have one important thing which is I get an email for
every trac in my areas.  So I should see every trac thing and if my head
isn't exploding even read it.  Then there's a URL to point to, I can
still find things in my mailreader too.

| I don't complain about how you personally work with Trac, but i see
| many obsolete or just plain wrong tickets (#1991), some legitimate
| tickets (#1884, ) are not closed (though it doesn't make any sense
| development-wise).

There's a ton of political difficulty awaiting people who go through
closing old Trac / Bugzilla entries, been there got beaten up.

| And yet it was choosen as a main kernel and rootfs storage for GTA02
| :-/ . Why don't you advice everybody to use only SD boot and rip NAND
| kernel boot possibility from Qi completely?

That's what I have done for GTA03.  It was very difficult to get people
out of U-Boot mindset... again there was a political difficulty
rejecting U-Boot even.

I expect people will ride over the reasoning and implement it anyway
because that's what they're used to seeing.

It's hard to ban it in GTA02 case anyway, we have to support it to pull
the second stage of the bootloader.

As Werner said, it doesn't erase, it means it can't write anything from
0 -> 1 bit.  That would be a nice simple explanation.

|> | 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
|> | u-boot.
|>
|> 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.
|
| I agree that Qi should work better than U-boot. But the idea that
| after this update one should issue "dynpart" command in NOR u-boot
| first to proper dfu any image was not mentioned anywhere and a
| convenient way to do that is yet to be proposed.

It seems it's not needed happily enough.

| BTW, i tried to provide end-user support for those who wanted to run
| Qi and it wasn't that easy :( Some can't accurately read and
| understand the wiki page even! The bug with trailing \n in append-
| file was also annoying (and i didn't know about it myself for a long
| time). But lack of reading the documentation is the most serious
| problem for end-users. Qi is definetely more simple and transparent to
| set up, but not everybody does that right the first time because of
| all kinds of "impossible" mistakes.

I'll will work on the Wiki page tomorrow and make things clearer.

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

iEYEARECAAYFAkmJ5r8ACgkQOjLpvpq7dMqFUgCfY8j0y+JatnHH0lZMGKgIznW3
VhEAn1ZwsegZlk8d1GV4GjXDfVjdACKO
=9c7i
-----END PGP SIGNATURE-----