Hi Weijie,
I set (with a flash programmer) ADP bit in non-volatile register of W25Q256
to 1. To configure it
upon power up to 4-Byte Address Mode. I also used bootstrapping pins of mt7628
(CHIP_MODE[2:0]) to make it
boot from SPI 4-Byte Addr as well.
During boot could see the following line (confirming that 4-Byte Address Mode
is used):
Boot: DDR2, SPI-NOR 4-Byte Addr, CPU clock from XTAL
But "reset" command still didn't work. :(
I tried different things, but nothing worked until I removed 1K pull-down
resistor connected to UART_RXD0 pin (31).
Once the resistor is removed reset command works as expected. What's boggling
me is that according to a
reference design 1K pull-down resistor is a must for this pin, it is even
written like that on the schematic.
I am puzzled :). Do you by any chance know why the resistor is required and why
would it prevent reset happening?
Maybe I missed something else with the configuration?
Thank you so much Weijie for your wisdom
Cheers,
Andrew
---- On Thu, 13 Aug 2020 04:33:14 +0300 Weijie Gao <weijie....@mediatek.com>
wrote ----
> 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 <s...@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 <s...@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
> >
>
>
