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

[Paul Fertser]

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

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

> | 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
a dynpart command in NOR u-boot? Not exactly handy... Probably not a
big deal if one writes a helper script automating that (but how to
make that helper script compatible with MacOS X and windows?..)

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

As far as i understand, NOR u-boot doesn't care about environment at
all, so in the case of using Qi that doesn't matter.

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

I didn't complain. As a matter of fact, nobody has taken care of it. I
didn't (and i probably could). Other developers who saw that on IRC
didn't. You didn't but you wasn't aware of it anyway. Please don't
think that i complain.

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

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

At present, this trac works good only as a mailing list poster that
draws attention.

Please, please, don't be offended, i never mean personal offences. But
the way bugtracking at OM works presently is suboptimal, to say the least.

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

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?

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

I get depressed every time i see your Trac :(.

Basically, people tried to "nandwrite -pm /dev/mtd3 uImage-GTA02.bin"
and nandwrite marked plenty of blocks bad.

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

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.

Please, don't be offended by anything i say, especially today, as i
feel bad and depressed and so on :-/

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com