Hi, Andy Green <[email protected]> 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:[email protected]
