[PATCH 1/1] mxc_nand : allow swapping the Bad block Indicator for NFC v1.

[Sascha Hauer]

On Mon, Sep 10, 2012 at 04:31:23PM +0200, Gaëtan Carlier wrote:
> Hi Juergen,
> On 09/06/2012 10:56 AM, Juergen Beisert wrote:
> >Hi Gaëtan,
> >
> >Gaëtan Carlier wrote:
> >>Any comments for this patch ?
> >
> >Sorry, a little bit late.
> >
> >>Swap the BI-byte on position 0x7D0 with a data byte at 0x835.  To fix a bug
> >>in Freescale imx NFC v1 SoC's for 2K page NAND flashes: imx27 and imx31.
> >>Warning: The same solution needs to be applied to the boot loader and the
> >>flash programmer.
> >
> >What sense does it make to swap the bytes at offset 0x7D0 and 0x835?
> >
> >Background: the NFC in the i.MX27/i.MX31 (NFCv1) and i.MX25/i.MX35 (NFCv2) can
> >only handle 512 byte pages with 16 bit OOB at once. To get them work with 2 k
> >page NANDs they only do the 512 + 16 step four times. The result is, a 2 k
> >page NAND is not handled as 2 k data and 64 bytes OOB, its handled instead as
> >a stream of 2112 bytes:
> >
> >                |<-------- 2112 bytes --------->|
> >                512+16 | 512+16 | 512+16 | 512+16
> >
> >Which means the NFC mixes data and OOB/checksums into its internal SRAM. But
> >all upper routines still use this SRAM content with a 2048 (data) + 64 (OOB)
> >bytes layout (to be more precise also the NFC hardware uses this layout).
> >Result is, the factory bad block markers are lost, because the NFC stores the
> >first 48 bytes from each OOB into the SRAM's data area (beginning with offset
> >2000 (= 0x7D0) in the data area).
> >
> >So, the main goal of this swap patch should be to keep the factory bad block
> >markers _and_ to make use of them.
> >
> >But the i.MX driver does not register its own bad block pattern description,
> >so the default one is used with the BBM at position NAND_LARGE_BADBLOCK_POS
> >(which means offset 0 in the OOB area).
> >
> >So, I think, all upper layers still search for the BBM at offset 0 of the OOB
> >area, which results to SRAM's offset 0x800 (for NFCv1) and not 0x835. This
> >means this patch keeps the factory bad block markers, but they won't still be
> >used as expected.
> >
> >IMHO the bytes at SRAM's offset 0x7D0 and 0x800 for the NFCv1 must be swapped
> >(and 0x7D0 and 0x1000 for the NFCv2) to keep the factory bad block markers
> >_and_ to make use of them. Or am I wrong?
> >
> >Regards,
> >Juergen
> >
> The point is not the necessity of swapping bytes if factory bad
> block markers are not used.
> In my case, the bytes must be swapped because all previous
> operations on flash swapped these bytes :
> * Flashes redboot (bootloader) via JTAG using OpenOCD which swaps bytes;
> * Writes kernel and rootfs via TFTP using redboot which swaps bytes;
> So to be able to read rootfs partition, mxc-nand driver have to swap
> bytes otherwise, JFFS2 detects error on partition and is unable to
> mount it.

I am all in favour to be able to swap the factory bad block marker with
the position the mtd framework expects it.

That according to our understanding are bytes 0x7d0 in the main area
and byte 0x0 in the spare area.

> 
> I have not chosen to swap these bytes. In a training, I received
> redboot and kernel 2.6.22 with set of patches to support i.MX27 and
> these patches included swap of bytes in nand driver. So I start my
> development with this workaround and it is now impossible to get
> back because boards are already in production.

So you are swapping the factory bad block marker with some position
where the mtd layer does not expect the bad block marker. With this
you preserve the factor bad block marker, but do not use it to detect
bad blocks.

In this form the patch is simply not correct and should be dropped.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |