GPMI NAND Regression on i.MX6S

[Frieder Schrempf]

Am 17.03.22 um 09:06 schrieb Frieder Schrempf:
> Hi Tim,
> 
> Am 16.03.22 um 17:34 schrieb Tim Harvey:
>> On Wed, Mar 16, 2022 at 7:09 AM Fabio Estevam <festevam at gmail.com> wrote:
>>>
>>> Adding Han Xu's NXP email on Cc.
>>>
>>> On Mon, Mar 14, 2022 at 10:31 AM Frieder Schrempf
>>> <frieder.schrempf at kontron.de> wrote:
>>>>
>>>> Hello everyone,
>>>>
>>>> sorry to dig out an old thread, but the below patch which was applied
>>>> upstream as 616f03dabacb causes a regression for me when trying to
>>>> attach an UBI volume with U-Boot 2022.01 on a board with i.MX6 Solo and
>>>> AMD/Spansion parallel NAND.
>>>>
>>>> The failure looks like this:
>>>>
>>>> ubi0: attaching mtd2
>>>> ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes
>>>> from PEB 0:0, read 64 bytes
>>>> ubi0 error: ubi_io_read: error -74 (ECC error) while reading 2048 bytes
>>>> from PEB 0:2048, read 2048 bytes
>>>> ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes
>>>> from PEB 1:0, read 64 bytes
>>>> ubi0 error: ubi_io_read: error -74 (ECC error) while reading 2048 bytes
>>>> from PEB 1:2048, read 2048 bytes
>>>>
>>>> The NAND as reported by Linux is:
>>>>
>>>> nand: device found, Manufacturer ID: 0x01, Chip ID: 0xdc
>>>> nand: AMD/Spansion S34ML04G1
>>>> nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>>>
>>>> A different revision of the same board with a different NAND from
>>>> manufacturer ESMT doesn't show the issue:
>>>>
>>>> nand: device found, Manufacturer ID: 0xc8, Chip ID: 0xdc
>>>> nand: ESMT NAND 512MiB 3,3V 8-bit
>>>> nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>>>
>>>> When I revert the mentioned commit (see patch here: [1]), the UBI boot
>>>> starts working again.
>>>>
>>>> Does anyone know what the problem is and how to properly solve it?
>>>>
>>>> Thanks for any help!
>>>> Frieder
>>>>
>>>> [1]
>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fzerobin.net%2F%3F57a57a322bbdcf3c%23rZa3vHlWi%2BRxtRomoljtrngqWwiv6v4Js%2F2LNfdV10o%3D&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C978979eaf1fa48171bab08da076aea84%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637830453031595997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NGl%2FrFnffV2oC90js0aHyTvoZjnrzW%2FD830lOnR4TbQ%3D&reserved=0
>>>>
>>
>> Frieder,
>>
>> I see the same issue here with IMX6Q/DL GPMI NAND.
>>
>> If I re-flash the ubi within U-Boot (tftpboot $loadaddr rootfs.ubi &&
>> nand erase.part rootfs && nand write $loadaddr rootfs $filesize) I
>> find that U-Boot can attach and mount the ubi fine but Linux will have
>> issues
> 
> Interesting! This sounds like U-Boot and Linux somehow diverge in how
> they handle the ECC data in OOB. I'm pretty confident that Linux does
> things "correctly" and U-Boot should match what Linux does in this case.
> 
> Does the patch (revert of 616f03dabacb) I mentioned before "solve" the
> issue for your case, too?
> 
> @Han, Ye, Peng: As you signed-off the mentioned commit, do you have any
> ideas for a fix?

So the proper fix seems to be to revert to the "legacy" BCH layout that
is used by Linux. Sean already tried to get this fixed almost a year ago
[1] but Han turned the change down in favor of changing the layout on
the kernel side. But this series [2] never made it upstream and it
doesn't look like it will anytime soon.

I will try to resurrect Sean's fix.

[1]
https://patchwork.ozlabs.org/project/uboot/patch/20210510100043.449294-1-sean@geanix.com/
[2]
https://patchwork.ozlabs.org/project/linux-mtd/patch/20210522205136.19465-1-han.xu@nxp.com/