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
