mediatek: various efforts to improve SNFI reliability

[dangowrt]

The Linksys E8450 aka. Belkin RT3200 suffers from a hard-to-catch issue with unreliable writes to the SPI-NAND flash which is attached via the SNFI interface (ie. using SoC BCH engine instead of on-die ECC of the flash chip).
Apply various changes which hopefully help to get rid of what has been dubbed the "OpenWrt Kiss of Death" (OKD) once we create an updated UBI installer for the device based on them.

[aiamadeus]

For the kernel part changes, I can confirm this works on
MT7981 + DS35Q1GA (which uses on-die ECC).
Before this change:

[    0.713881] spi spi0.0: setup: ignoring unsupported mode bits a00
[    0.720304] spi-nand spi0.0: Fidelix SPI NAND was found.
[    0.725615] spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
[    2.057819] ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 17, need 19
[    9.654826] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 11 bytes from PEB 244:7585, read only 11 bytes, retry
[    9.666820] UBIFS error (ubi0:2 pid 463): ubifs_lpt_init: invalid type (15) in LPT node type 2
[    9.743737] UBIFS (ubi0:2): background thread "ubifs_bgt0_2" stops
[    9.750287] mount_root: failed to mount -t ubifs /dev/ubi0_2 /tmp/overlay: Invalid argument

After this change:

[    0.716792] spi spi0.0: setup: ignoring unsupported mode bits a00
[    0.723257] spi-nand spi0.0: Fidelix SPI NAND was found.
[    0.728569] spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
[    2.049643] ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 17, need 19
[    9.770535] mount_root: overlay filesystem has not been fully initialized yet
[    9.777911] mount_root: switching to ubifs overlay

[mrkiko]

Is switching to the performance governor or leaving cpufreq alone alltogeter considered still something important?
May this be an occasion to do that?

[dangowrt]

@mrkiko While cpufreq causes some issues when running at too low voltage (or frequency?) while rebooting the SoC and this leads to hang inside DRAM calibration, I don't think the issue is related to the SPI-NAND corruption issues we are seeing. Maybe indirectly, as hanging in DRAM calibration for hours and hours could result in a lot of heat, I've never tried that, but it's unlikely as it happens while CPU is running at slow clock only, and hence should get less hot compared to normal operation even.

Resetting the CPU to run at full speed and voltage before entering DRAM calibration would be the best possible fix for that. Maybe open an issue on https://github.com/mtk-openwrt/arm-trusted-firmware/issues for that?

[rsalvaterra]

too low voltage (or frequency?)

It was the voltage. I reinstated the 300 MHz OPP in my tree at 1 V and it never failed on me (minus the hang I started having at reboot with Linux 6.6, but that's another issue, surely).

[mrkiko]

What's the merging perspective for this PR?

[dangowrt]

Currently @onlyfly34 is working with some people on the forum with bricked devices to figure out how to address the root cause. I'm waiting for the result, and then would go ahead and merge this PR if it is deemed suitable.