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

[Trent Piepho]

On Thu, Apr 11, 2013 at 11:33 AM, Paul B. Henson <henson at acm.org> wrote:
> On 4/11/2013 5:03 AM, Trent Piepho wrote:
>> What one should actually do to flash these blocks is write 2048 bytes
>> in raw mode.
>
>
> I guess that would only work if whatever reading the blocks also read them
> in raw mode, as otherwise the lack of ECC in the OOB area would fail the
> read?

See my second message in the thread.  The FCBs are in raw mode, all
the rest are in BCH/ECC mode.  The FCBs have the BCH parameters, so
the IPL can't switch to ECC mode until it gets the parameters from
them.  Also, the BCH/ECC data is NOT in the OOB area.  In BCH/ECC
mode, the data and the ECC bytes are intermixed throughout the full
2112 byte page.  So one MUST write the FCBs in raw mode and everything
else in ECC mode for it to work, as the IPL will read the data in this
manner.  That's why the image from mxsboot needs to be split into two.
 Maybe it would make more sense for mxsboot to write two files?  One
with the FCBs and one with everything else?

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've done that before.  The u-boot env was written from Linux to tell
>>  u-boot which kernel to boot, the firmware update kernel and rootfs
>> or the main kernel and rootfs.
>
>
> 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
> button on the device, which if held down when powered on will reset the
> device to factory defaults. The recovery kernel will check if that button is
> pressed when it loads and rewrite the production area of the flash if so
> from a recovery partition, otherwise just load the production kernel.

You'll boot slower then, as you're basically booting twice.  Maybe
that doesn't matter for you.  I'm usually trying to get booted and
have system startup done in <500 ms and two boots make that a lot
harder.