ningzichun:

Hello, I find a solution that seems to work. But I don't know how to change the source code.
Thank you.

http://m.blog.csdn.net/yubing_615/article/details/52649489 (Fix soft reset fail ,Chinese)

SerCom-KC:

I can confirm that both patches in this thread works: https://forum.lede-project.org/t/newifi-d1-unable-to-reboot/7910
Tested with snapshot at 5faa955, both kernel versions (4.9 & 4.14) worked fine.

Since I'm unsure about who to credit I'm not going to submit a pull request myself, but this needs to be fixed anyway.

easyteacher:

As I wrote in PR#464 the/a chip reset should not be done unconditionally as it can be seen here, here and here, since it isn't required for all flash chips. It should be done conditionally. One idea I had was a device tree property like reset-on-shutdown or a new spi_nor_ids array flag. If possible the workaround should be accepted upstream or upstream should at least signalise it is the best we can do in software.

@mkresin Now that a new flag in kernel 4.9/4.14 can be used to solve the soft reboot problem, what's the reason the patch mentioned in the LEDE forum will be rejected?

mkresin:

@easyteacher We are talking about different topics. Backporting 4-byte mode to 17.04. will be most likely not accepted.

Furthermore, there was a "fix" which sets some register values for all SPI flash chips (was either exit 4-byte mode or a chip reset, can't remember). It is a no go as well.

My NAK wasn't for your SPI_NOR_4B_READ_OP approach, which I obviously missed when I had a look at the forum topic.

Nevertheless, I'm kind of surprised that SPI_NOR_4B_READ_OP is supposed to work with the MX25L25635E. The [[http://www.macronix.com/Lists/Datasheet/Attachments/6639/MX25L25635E,%203V,%20256Mb,%20v1.3.pdf|MX25L25635E datasheet]] doesn't mention a stateless 4-byte read command (see table 5 "command sets"), where the [[https://www.winbond.com/resource-files/w25q256fv_revg1_120214_qpi_website_rev_g.pdf|W25Q256 datasheet]] does (Read Data with 4-Byte Address [13h]).

In fact, the MX25L25635E datasheet says:

The default read mode is 3-byte address, to access higher address (4-byte address) which requires to enter the 4-byte address read mode...

Entering the 4-byte mode is stateful and exactly the reason for the reboot hang. Since support isn't mentioned in the datasheet, SPI_NOR_4B_READ_OP isn't enabled for the MX25L25635E.

mkresin:

One more thing, have you actually tried to write > 16 MB to the flash chip, read back the data and compared checksums of input and output?

In case SPI_NOR_4B_READ_OP is enabled without support by the chip, you limit reading to the first 16 MB. And since the chip is never switched to 4-Byte mode during read (to read behind the 16 MB boundary), rebooting works fine.

mkresin:

Okay, I know what is going on. The Newifi D1 has most likely a MX25L25635F. But the MX25L25635E and MX25L25635F share the same "hardware id" 0xc22019, therefore can't be distinguished and are handled as MX25L25635E by the kernel.

The MX25L25635F supports stateless 4-byte read and write (you can use SPI_NOR_4B_OPCODES). Where the MX25L25635E does not support any stateless 4-byte command.

As it is very likely that we have in a big target like ramips boards with MX25L25635E and MX25L25635F, we can't enable SPI_NOR_4B_OPCODES, as it would break boards with MX25L25635E.

The only solution I can think of would be a compatible string for the MX25L25635F in the dts. But that is something I would like to see accepted by the spi-nor kernel maintainers first.

easyteacher:

I uploaded a 17M file generated by dd from /dev/urandom on my phone to the router, and their sha256sum results are the same.
BusyBox v1.28.3 () built-in shell (ash)

root@ASUS-PC:~# cd /etc
root@ASUS-PC:/etc# sha256sum testfile
4d6928d6837da79d560f695b8b2311ab4a6e6d6a5c3367d5559a6ed36c517687 testfile
root@ASUS-PC:/etc# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 9.0M 9.0M 0 100% /rom
/dev/zram0 11.5M 832.0K 10.4M 7% /tmp
tmpfs 123.8M 0 123.8M 0% /tmp/shm
tmpfs 123.8M 144.0K 123.6M 0% /tmp/root
tmpfs 512.0K 0 512.0K 0% /dev
/dev/mmcblk0p2 5.8G 39.1M 5.4G 1% /mnt/mmcblk0p2
/dev/mtdblock6 20.9M 18.7M 2.1M 90% /overlay
overlayfs:/overlay 20.9M 18.7M 2.1M 90% /
root@ASUS-PC:/etc#