mediatek: snfi: FM35Q1GA is x4-only and needs 12mA pin drive strength

[dangowrt]

Dont allow x2 read and cache read operations on FM35Q1GA as they seem to be unstable. Also the Linux drivers does not allow x2 ops:
https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/patches-6.1/340-mtd-spinand-Add-support-for-the-Fidelix-FM35X1GA.patch#L49

We may need a similar fix for the U-Boot driver, though problems have not been observed there. However, we sporadically see bl2 failing to load fip for no apparent reason (ie. after the device was powered-off and working fine before, or after a reboot). The error then persists.

F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 02D4 [000F]
Jump to BL

NOTICE:  BL2: v2.9(release):OpenWrt v2023-07-24-00ac6db3-2 (mt7622-snand-1ddr)
NOTICE:  BL2: Built : 21:45:35, Oct  9 2023
NOTICE:  CPU: MT7622
NOTICE:  WDT: Cold boot
NOTICE:  WDT: disabled
NOTICE:  SPI-NAND: FM35Q1GA (128MB)
ERROR:   BL2: Failed to load image id 5 (-2)

Also using UBI apparently didn't help

F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 02F1 [000F]
Jump to BL

NOTICE:  BL2: v2.9.0(release):OpenWrt v2023-10-13-0ea67d76-1 (mt7622-snand-ubi-1ddr)
NOTICE:  BL2: Built : 11:23:19, Feb 18 2024
NOTICE:  WDT: Cold boot
NOTICE:  CPU: MT7622
NOTICE:  WDT: disabled
NOTICE:  SPI-NAND: FM35Q1GA (128MB)
NOTICE:  UBI: scanning [0x80000 - 0x8000000] ...
NOTICE:  UBI: scanning is finished
NOTICE:  UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
NOTICE:  UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
NOTICE:  UBI: Volume fip (Id #0) size is 1019644 bytes
ERROR:   BL2: Failed to load image id 5 (-2)

@hackpascal @nbd168

[dangowrt]

@hackpascal Does the change suggested here generally look acceptable to you? Handling this "properly" in pinctrl/gpio driver looks a bit more complicated...

[hackpascal]

@hackpascal Does the change suggested here generally look acceptable to you? Handling this "properly" in pinctrl/gpio driver looks a bit more complicated...

Actually I want to add a simple pinctrl layer to make it "generic" :p

[hackpascal]

@dangowrt I managed to buy a spi-nand flash DS35Q1GA. It seems to use exactly the same die that FM35Q1GA is using.
Not sure if this nand chip can reproduce the issue.
Datasheet: http://www.dosilicon.com/resources/new_Datasheet/DS35X1GAXXX_rev07.pdf

[pepe2k]

@dangowrt @981213 @hackpascal if you are looking at driver strength on the SOC's I/O side, I would also look how it's configured on the SPI-NAND side (usually, by default it should be set to 100%).

[dangowrt]

...and another brick with full debug log here:
https://gist.github.com/taylorkline/64da33842b464b4e27bda7ec04113aec

[onlyfly34]

Hi @dangowrt
I've heard this issue from @hackpascal
According to @hackpascal, if DS35Q1GA uses the same die as FM35Q1GA, here's something worth to note in Dosilicon's datasheet, page 28:

Prior to performing a PROGRAM LOAD RANDOM DATA operation, a WRITE ENABLE (06h) command must be
issued to change the contents of the memory array. Following a WRITE ENABLE (06) command, first a PROGRAM
LOAD (02h or 32h) command must be issued to reset the cache, then issue a PROGRAM LOAD RANDOM DATA
(84h or 34h) command

Since we use 0x84/0x34 for x1/x4 program load random data in Linux(https://elixir.bootlin.com/linux/latest/source/include/linux/mtd/spinand.h#L138), issues occur with such combination: FM35Q1GA(DS35Q1GA)+Uboot/Linux spi-mem framework. We observed the same thing on Foresee's F35SQA001G.

I'm not 100% sure if the above issue has something to do with this ticket. But it indeed causes serious problems when we program NAND flash, and impacts further reading behavior.

Here's dirty fix you may try (apply both to Uboot & Linux):
In FM35Q1GA's patch, change update_cache_variants macro from:

+static SPINAND_OP_VARIANTS(update_cache_variants,
+		SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+		SPINAND_PROG_LOAD(false, 0, NULL, 0));

to this:

+static SPINAND_OP_VARIANTS(update_cache_variants,
+		SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+		SPINAND_PROG_LOAD(true, 0, NULL, 0));

This is pretty dirty because it makes SPI controller unable to send 0x84/0x34. This is a big problem for SPI controllers which can't send data of page size(2K or 4K bytes) in one transfer.

For example, if the SPI controller is capable to transfer only 512bytes with one command, it needs to issue 0x84/0x34 command four times to transfer 2K bytes data onto NAND flash's cache.

[dangowrt]

Summarizing all discoveries I've opened a PR for openwrt.git to add all of that, in the hope that we can rescue users from OKD asap:

openwrt/openwrt#15112

[lynxthecat]

Summarizing all discoveries I've opened a PR for openwrt.git to add all of that, in the hope that we can rescue users from OKD asap:

openwrt/openwrt#15112

Will this potentially prevent OKD even for devices that haven’t been OKD’ed?