Linux 5.18 kernel unable to read from NAND on i.MX6Q phycore SOM about meta-phytec

[smk-embedded]

The Error is reported upstream and will be fixed by Sascha Hauer:
https://lore.kernel.org/all/[email protected]/
We will wait for the upstream solution.

[smk-embedded]

Thanks for the report! We will have a look at the issue.

[S4mw1s3]

In the mean time I switched back to LTS 5.15 and I am now also experiencing the same issue on 5.15.48 kernel. After investigating and reverting only commit mtd: rawnand: gpmi: fix controller timings setting, the NAND issue was solved.

Coincidentally I just stumbled on https://lore.kernel.org/linux-mtd/[email protected]/ which I assume will fix the issue (still need to test). I see that commit has just been added to kernels 5.15.51 and 5.18.8 so I think from those kernels on, the phycore i.MX6 NAND SOM will boot again.

[smk-embedded]

We can reproduce the issue with the 5.15 upstream kernel.
If we revert "mtd: rawnand: gpmi: fix controller timings setting" the device boots and NAND works.
Applying "mtd: rawnand: gpmi: Fix setting busy timeout setting", like suggested, doesn't fix the problem. It boots, but NAND tests still show errors. We are investigating on the current LTS v5.15.51.

[S4mw1s3]

After doing some additional testing I can confirm your observations. In fact, the issue I encounter is that mounting another ubifs volume fails:

[   11.498822] UBIFS (ubi0:4): Mounting in unauthenticated mode
[   11.506009] UBIFS (ubi0:4): background thread "ubifs_bgt0_4" started, PID 267
[   11.550442] UBIFS error (ubi0:4 pid 266): ubifs_unpack_nnode: invalid type (15) in LPT node type 1
[   11.559750] CPU: 0 PID: 266 Comm: mount Tainted: G           O      5.15.48 #1
[   11.567004] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[   11.573556] [<c01107b8>] (unwind_backtrace) from [<c010b99c>] (show_stack+0x10/0x14)
[   11.581338] [<c010b99c>] (show_stack) from [<c07f17bc>] (dump_stack_lvl+0x80/0x90)
[   11.588932] [<c07f17bc>] (dump_stack_lvl) from [<c03b1b68>] (ubifs_unpack_nnode+0x110/0x134)
[   11.597403] [<c03b1b68>] (ubifs_unpack_nnode) from [<c03b1ec4>] (ubifs_read_nnode+0x1a0/0x21c)
[   11.606039] [<c03b1ec4>] (ubifs_read_nnode) from [<c03b251c>] (ubifs_lpt_lookup_dirty+0x1d8/0x288)
[   11.615024] [<c03b251c>] (ubifs_lpt_lookup_dirty) from [<c03a5b4c>] (ubifs_replay_journal+0x44/0x1570)
[   11.624356] [<c03a5b4c>] (ubifs_replay_journal) from [<c039ab94>] (ubifs_mount+0x468/0x1614)
[   11.632816] [<c039ab94>] (ubifs_mount) from [<c03155a0>] (legacy_get_tree+0x24/0x4c)
[   11.640589] [<c03155a0>] (legacy_get_tree) from [<c02d1598>] (vfs_get_tree+0x24/0xe8)
[   11.648446] [<c02d1598>] (vfs_get_tree) from [<c02fdd1c>] (path_mount+0x2cc/0xb68)
[   11.656039] [<c02fdd1c>] (path_mount) from [<c02feb7c>] (sys_mount+0x178/0x288)
[   11.663367] [<c02feb7c>] (sys_mount) from [<c0100080>] (ret_fast_syscall+0x0/0x1c)

Mounting the rootfs (also ubifs) does work though (after applying "mtd: rawnand: gpmi: Fix setting busy timeout setting") but there is indeed still something going on :(

Above issues where not encountered in 5.15.32.