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

[Paul B. Henson <henson@acm.org>]

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.

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

There haven't been any responses or follow-ups to this thread, so I 
guess they either think it's working fine as is or aren't 
interested/don't have the time to follow up on the issue. I'm not 
accusing anything of being broken, just explaining what I'm seeing and 
offering to help :)...

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