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

[Paul Fertser]

Hi,

Andy Green <andy at openmoko.com> writes:
> The following series allows Qi to dynamically compute the
> partition offsets in NAND to arrive at the same offsets as
> U-Boot would have stored in its environment.  Qi is able to
> do it fast enough to not be noticable and therefore no
> storage (aka persistent state or environment) is needed.
>
> It means the Qi is now safely compatible with NAND usage in
> Linux same as U-Boot.

I'm sorry, but i have some doubts wrt this. I might be
misunderstanding all that stuff though. OTOH almost all users are as
clueless as i'm here, so any clarifications (that i'm going to wikify)
will be good.

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

> 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"
their new kernel to kernel partition but it failed _marking plenty of
blocks as bad_. After that they obviously were unable to flash the
kernel via DFU anymore (because too little space left). The only
solution we were able to come up on IRC with was using "nand scrub" in
NOR u-boot followed by "nand createbbt". If possibility to use NAND
u-boot is desired, one will also want to issue "dynpart", "dynenv set
u-boot_env" to store start of the environment in OOB. After that
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).

I hope you can at least try to look at the "nandwrite -pm" issue and
outline possible solutions for the failing case.

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.

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