reset command doesn't work on MT7628 (CPU: MediaTek MT7628A ver:1 eco:2)

[Weijie Gao]

Hi Andrew,

According to my past experience, I believe this is caused by the
W25Q256 NOR flash.

Your bootlog shows that it's booted with SPI-NOR 3-Byte Addr, and your
board is using W25Q256 which requires 4-byte address access when
accessing the higher 16MB memory array.

According to the datasheet of W25Q256, there are three ways to use the
4-byte address mode:

1. By using the dedicate opcodes which always require 4-byte address
2. By using "Enter 4-Byte Address Mode" opcode, to convert all opcodes
   to use 4-byte address
3. By using the Extended Address Register to specify the 4th address
   byte for opcodes which require 3-byte address

The spi-nor driver in u-boot uses combined 2 & 3 for W25Q256.
For details please refer to set_4byte() in
drivers/mtd/spi/spi-nor-core.c

However, u-boot only enables 4-byte mode and never disables it. So after
you reset the board, the flash will remain in 4-byte mode, and the CPU
tries to access the flash with 3-byte address mode. In this situation
the flash will return unexpected data to the CPU, and the CPU will
apparently fail to boot.

The solution is simple, just set the flash to 3-byte mode before
resetting the board by calling set_4byte() with enable=0. But you can
never 100% fix this because the watchdog reset won't give you a chance
to call set_4byte() before resetting the board.

Best Regards,
Weijie


On Wed, 2020-08-12 at 16:14 +0300, Andrii Voloshyn wrote:
> Hi Stefan,
> 
> ---- On Wed, 12 Aug 2020 15:57:31 +0300 Stefan Roese <sr at denx.de> wrote ----
> 
>  > Hi Andrew, 
>  >  
>  > On 12.08.20 14:48, Andrii Voloshyn wrote: 
>  > > Hi Stefan, 
>  > > 
>  > > ---- On Wed, 12 Aug 2020 15:08:41 +0300 Stefan Roese <sr at denx.de> wrote ---- 
>  > > 
>  > >   > Hi Andrew, 
>  > >   > 
>  > >   > On 12.08.20 14:04, Andrii Voloshyn wrote: 
>  > >   > > Hi Stefan, 
>  > >   > > 
>  > >   > >   > Hi Andrew, 
>  > >   > >   > 
>  > >   > >   > (added Weijie to Cc) 
>  > >   > >   > 
>  > >   > >   > On 12.08.20 09:18, Andrii Voloshyn wrote: 
>  > >   > >   > >    Hi there, 
>  > >   > >   > > 
>  > >   > >   > >    There is one issue, I experience with (U-Boot 2020.07) on MT7628DAN, "reset" command issued in hush prompt 
>  > >   > >   > >    causes board to hang, until I do a power cycle. On the other hand there is no such issue on mt7688 board. 
>  > >   > >   > 
>  > >   > >   > Do you see no further output? Or is it perhaps stuck at the DDR init 
>  > >   > >   > code in SPL? Can you please post the log (complete boot log with reset 
>  > >   > >   > command)? 
>  > >   > > 
>  > >   > > There is only "resetting..." printed, once the reset command is executed. 
>  > >   > 
>  > >   > I see. Thanks. 
>  > >   > 
>  > >   > >  By the way, I am not using SPL loader. 
>  > >   > 
>  > >   > Why not? Did you give the version with SPL a try? Here most of the 
>  > >   > lowlevel init stuff is executed. Something might be missing in the 
>  > >   > general HW setup if its not used. 
>  > > 
>  > >     Then I will need to flash two binaries, spl + uboot, right? 
>  >  
>  > Not really. The 2 images are generated automatically and combined into 
>  > one image (u-boot-with-spl.bin) that needs to be flashed instead. The 
>  > main pro of this SPL + U-Boot proper is that the resulting image is 
>  > *much* smaller (because of the compression of the U-Boot proper) and 
>  > therefore, booting is usually faster as well compared to the "old" 
>  > non-SPL only image. 
>  >  
>  > In my case its ~250kByte (combined image) compared to ~600kByte. 
>  >  
>  > > In any case SPL is optional, at least it should be. :) on this hw. 
>  >  
>  > Yes, correct. But frankly, I have not tested without SPL for a few 
>  > months now. Mainly because of the reasons I mentioned above. 
>  >  
>  
> Just tried u-boot-with-spl.bin image, the result is the same reset command doesn't work :(
>  
>  > >   > 
>  > >   > How are you running the non-SPL (main) U-Boot on your board? Do you 
>  > >   > load it via an old U-Boot? Or is it configured for SPI flash usage 
>  > >   > without SPL instead? 
>  > > 
>  > > I am running the way it was done prior to recent SPL changes. 
>  > > SPI NOR flash  is mapped to 0x9c000000 address, and that's what the text base address is set to when SPL is disabled: 
>  > > arch/mips/mach-mtmips/Konfig 
>  >  
>  > Okay. So you are flashing a non-SPL only image into SPI NOR and you are 
>  > not loading it via some other bootloader. That is what I wanted to make 
>  > sure of. 
>  >  
>  > > config SYS_TEXT_BASE 
>  > >> ---default 0x9c000000 if !SPL 
>  > >> ---default 0x80200000 if SPL 
>  > > 
>  > > Also, I'd like to note that all other functionality in the u-boot works fine, booting of FIT images, other commands I use, 
>  > > the only problem is with the reset command. 
>  > > 
>  > > When I trigger reset manually (writing to RSTCTL register), I get the same behavior: 
>  > > mw 0x10000034 0x1 
>  >  
>  > I see. Again, I have no real clue, sorry. 
> 
>  Thank you for your help in any case. I've seen that Weijie made a lot of work for the chip, may be he will have some clue.
> 
>  >  
>  > Thanks, 
>  > Stefan 
>  > 
> Thanks,
> Andrii
>