Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mediatek: various attempts to fix FM35Q1GA SPI-NAND flash #15375

Closed
wants to merge 4 commits into from

Conversation

dangowrt
Copy link
Member

@dangowrt dangowrt commented May 3, 2024

This is a collection of potential fixes for the OKD ("OpenWrt Kiss of Death") issue which has been a curse on the Belkin RT3200 aka. Linksys E8450 router.

It includes changes to TF-A which are discussed here as well as (different) attempts to correct various potential causes in Linux and U-Boot.

See also mtk-openwrt/arm-trusted-firmware#7

Update ARM TrustedFirmware-A to the most recent release of
MediaTek downstream patched version released 2024-01-17.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Import pending patches to set pinconf settings for SPI-NAND pins on
MT7622 identical to what the old proprietary preloader did.

Should further increase the reliability of some SNFI-attached SPI-NAND
flash chips.

Link: mtk-openwrt/arm-trusted-firmware#7
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
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.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
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

This is dirty fix provided to use by MediaTek engineer Sky Huang which
may resolve the "OpenWrt Kiss of Death" issue we've been seeing on the
Linksys E8450 aka. Belkin RT3200. However, it means that everything has
to be re-written with that patch already applied, ie. we need to rebuild
the installer once it is part of snapshot builds to have any effect.

Users already on FIP-in-UBI layout are advised to re-write 'fip' UBI
volume and 'bl2' MTD partition manually once from within Linux after
this fix has been applied.

A similar fix will also be required for U-Boot.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
@github-actions github-actions bot added core packages pull request/issue for core (in-tree) packages target/mediatek pull request/issue for mediatek target labels May 3, 2024
@mrkiko
Copy link
Contributor

mrkiko commented May 5, 2024

@dangowrt - so an u-boot related patch is still missing?
I unfortunately am not in the best position to help, stillI am available for testing once the puzzle is more or less complete.
I admit I feel little bit confused about where to grab what pieces.
I guess I could build the installer with this PR applied but that would only help with the recovery image itself, changing the behaviour in the kernel.

@dangowrt
Copy link
Member Author

dangowrt commented May 6, 2024

@mrkiko thank you for reviewing the patchset. An additional patch for U-Boot would only be needed if we would use this SPI-NAND chip directly on an SPI controller -- but in case of the RT3200/E8450 it is connected via the SNFI interface and the driver is completely different... I hope that all together this (and building a new installer based on all those changes) may resolve the OKD issue, but so far it's still not clear what the cause may be and people in forum have also been reporting the device just dropping dead entirely after a bit more than 3 years of use (coil chirps and no LEDs turn on -- sound like bad capacitor issue), so maybe the hardware design as such is not that great after all...

@KA2107
Copy link

KA2107 commented May 7, 2024

@dangowrt Though I do not claim to understand the OKD issue, I am just curious to know what's the difference between this Pull Request and #15112 .

@dangowrt
Copy link
Member Author

dangowrt commented May 7, 2024

Though I do not claim to understand the OKD issue

While I didn't see the true cause, there are several differences in how OpenWrt uses the flash chip and how the stock firmware does it, and how the features are documented in the chips datasheet. This PR tries to address at least parts of that.

I am just curious to know what's the difference between this Pull Request and #15112 .

None. I simply forgot I had already opened a pull request for that. Closing in favor of #15112

@dangowrt dangowrt closed this May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core packages pull request/issue for core (in-tree) packages target/mediatek pull request/issue for mediatek target
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants