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

[Gaëtan Carlier]

Hi,
On 09/11/2012 09:17 AM, Sascha Hauer wrote:
> 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.
I don't see where the problem is. The fact that bad block marker are 
used or not, is not related to "my" patch. This patch just places data 
where they should be. If I take the Nand and connect it to a not-bugged 
NFC controller, all data will be read correctly with data is main area 
and OOB is spare area.
>
> In this form the patch is simply not correct and should be dropped.
>
Now I want to adapt and publish my platform file to latest kernel 
version and I am still stopped with this biswap patch that is not 
applied. As I said before, I must not be the only that have used this 
damned original patch from Freescale that swaps byte in their ATK 
programming soft, redboot and Kernel and it is impossible to fallback to 
current NAND handling (without swapping).

Is there any chance that if I send this patch against linux-next/master 
branch, it will be finally accepted. Only people that needs it will use 
it. There is so much option in menuconfig with so little explaination 
and mark as "Only say Yes if you known what you do".
> Sascha
>
Thank you.
Best regards,
Gaëtan Carlier.