GPMI NAND Regression on i.MX6S

[Frieder Schrempf]

Hi Sean,

Am 17.03.22 um 14:14 schrieb Sean Nyekjaer:
> [Sie erhalten nicht oft E-Mail von "sean at geanix.com". Weitere Informationen, warum dies wichtig ist, finden Sie unter "http://aka.ms/LearnAboutSenderIdentification".]
> 
> Hi Frieder,
> 
> On Thu, Mar 17, 2022 at 01:59:07PM +0100, Frieder Schrempf wrote:
>> 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%7C7a58965995b34fe86ef808da08180b2a%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637831196603019724%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eexagX96EdnCNJiOvxTL%2FXVVWtQYsF5yt1zeMy2SghQ%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://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20210510100043.449294-1-sean%40geanix.com%2F&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C7a58965995b34fe86ef808da08180b2a%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637831196603019724%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZzCm2Jl9BPd8hP%2B13judqwblR4tzmyZnIHUR922KLdQ%3D&reserved=0
>> [2]
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Flinux-mtd%2Fpatch%2F20210522205136.19465-1-han.xu%40nxp.com%2F&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C7a58965995b34fe86ef808da08180b2a%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637831196603019724%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iiBenZkPMWw%2Bg%2FLQjnBSgqZABScRQXt6%2F08typx7buY%3D&reserved=0
>>
> 
> Thanks for bringing this up again. I have only had time to send Han a
> ping a few times.
> I would still prefer that we added the new(correct) metod as a option.

The top priority should be to fix the regression. And reading the
discussion with the Linux MTD maintainer Miquel in the thread for Han's
kernel patches linked above makes me doubt that the new method is really
a good option. Even if it would land in the kernel, it would break
systems that use older versions of U-Boot which is just not acceptable
in my opinion.

Frieder