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?
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to