[U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks

[Trent Piepho]

On Fri, Apr 19, 2013 at 6:03 PM, Paul B. Henson <henson at acm.org> wrote:
> On 4/11/2013 4:25 PM, Trent Piepho wrote:
>>
>> Maybe it would make more sense for mxsboot to write two files?  One
>> with the FCBs and one with everything else?
>
> Hmm, possibly; I guess that would be conceptually simpler but require more
> commands to execute to get done.

Don't see why.  If mxsboot wrote both files at once, there'd be the
same number of commands to generate them.  When flashing with
nandwrite, the commands to split the file would no longer be
necessary.  U-boot would have to load and flash two files, but it
could avoid having to calculate where to split the file like it does
now.

>> The FCBs are only 1036 byes long.  The OOB isn't used by the FCB.  So
>> when writing the FCBs, the OOB should not be written and whatever
>> bad/good flag is in there left alone.  But u-boot flashes the entire
>> block with zeros (the first 2112 page and also the 63 unused pages
>> after it too).  So the OOB is also zeroed out, and that marks the
>> block as bad.
>
>
> I'm not that familiar with the intricacies of NAND, it sounds like you're
> saying each FCB should be written separately rather than in one fell swoop
> as it does currently?

Yes.  Or at least it should not write the OOB.  Basically you have a
136 KB NAND block, including data+OOB.  The first 1036 bytes are FCB
data.  Bytes 2048 to 2112 contain a bad block marker.  The remaining
~134 KB after byte 2112 are entirely unused.  kobs-ng writes only the
first 2048 bytes, and thus does not write bytes 2048-2112, which
contain the marker.  u-boot writes all 136 KB, including the marker.
There are 4 FCB blocks like this.  While U-boot gets the first one
correct (other than the bad block marker), it doesn't write the 3
after it correctly.

>>> I think we're going to always have u-boot boot the recovery kernel and
>>> have
>>> that bootstrap the production kernel. We plan to have a physical reset
>>
>>
>> You'll boot slower then, as you're basically booting twice.  Maybe
>> that doesn't matter for you.
>
>
> Boot time doesn't matter too much for our application, it shouldn't boot
> very often and if it does a couple extra seconds won't be a problem.
>
> What is your recovery plan in the case of the production kernel/file system
> becoming corrupt and unbootable? u-boot, per the environment variable, will
> try to load the production kernel, which then can't boot far enough to reset
> the environment variable to load the recovery kernel?

The production rootfs and kernel are read-only, so shouldn't become
corrupted on SLC nand.  So there isn't anything to detect that and
switch to a backup.  If something does happen, then recovery would be
by microSD card boot/reflash.  The ROM bootloader supposedly supports
two firmware images to boot from.  That's one of the reasons why the
output of mxsboot is so big, as it contains two images.  It's not
clear to me if the bootloader supports switching between image in any
useful way.