Fix no settings saved

Some time ago, I found that openwrt keeps configuration updates on gl-ar150 and gl-ar300m, which may cause the loss of configuration files. A search revealed that many people have similar problems with me.
https://dev.archive.openwrt.org/ticket/20982
https://forum.archive.openwrt.org/viewtopic.php?id=72173
https://patchwork.ozlabs.org/patch/651199/

I found that the following steps will inevitably lead to mistakes:
Step.1 read the data block. The read length should be less than or equal to 32 bytes.
Step.2 erase the same data block
Step.3 read the same data block (at this time, the correct data cannot be read, and the correct data can only be read after a period of delay or operation on other blocks. Some of the operations in /etc/init.d/done will do the above,therefore, a little delay in /etc/init.d/done can also make the phenomenon disappear)

In AR9331 and QCA9531, there are two ways to READ NOR FLASH, either directly through memory mapping or through SPI controller. According to the description on page 24 of ar9331_1210.pdf, CACHE READ is used if memory mapping is used.Therefore, it is possible to read the last results.

In the driver of M25P80, the priority is to read in the memory-mapped way, reading the wrong data, causing JFFS2 to misjudge the bad block, resulting in file loss.
I did not find a way to clean up the memory map cache, so I temporarily chose to read NOR flash data without memory mapping, and my patch was submitted in the openwrt code tree of gl-inet


The patch has been verified by gl-ar150 and gl-ar300m

Hi,

I can confirm this fixes the problem I described in Configuration loss after reboot

Great work, thanks!

Add flash caching reasons.
Flash is read using a memory-mapped data cache that uses MIPS. The cache's validity is usually determined by its address. if the same address is accessed and the CPU considers the data unchanged, the cache is hit.
In this BUG, from the first block of rootfs_data JFFS read 4 byte of data, the data will be written in the data cache of MIPS, then JFFS will erase the first block, and then to read the data check whether erase success, success is written JFFS file system identifier, or marked as bad block, because use SPI command to erase flash, the CPU does not know the data has been changed, therefore, to check and fetch the data from the data cache, cause the failure of check, because is the first block rootfs_data,Therefore, a restart rebuilds the file system, causing configuration files to be lost.
In the case of 9331 and 9531, the MIPS cache line is 32byte, so any data read beyond 32byte will not be cached

1 Like