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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Andrii Voloshyn
  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.
  What's interesting, is that "reboot" issued in Linux shell makes board reboot as expected on mt7628 board.
   
  It seems like some sort of configuration issue, but I couldn't find anything specific in the datasheet. Maybe
  you have some idea what could cause it?
   
  One more thing, when running the following version of bootloader (https://github.com/gnubee-git/GnuBee-MT76x8-uboot)
  "reset" command works as expected.
   
  Thank you for your help
   
  Cheers,
  Andrew  
Reply | Threaded
Open this post in threaded view
|

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

Stefan Roese
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)?

>    What's interesting, is that "reboot" issued in Linux shell makes board reboot as expected on mt7628 board.
>    
>    It seems like some sort of configuration issue, but I couldn't find anything specific in the datasheet. Maybe
>    you have some idea what could cause it?
>    
>    One more thing, when running the following version of bootloader (https://github.com/gnubee-git/GnuBee-MT76x8-uboot)
>    "reset" command works as expected.

I do not have a MT7628 based board, so I can't test. Perhaps Weijie has
an idea?

Thanks,
Stefan
Reply | Threaded
Open this post in threaded view
|

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

Andrii Voloshyn
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.  By the way, I am not using SPL loader.
Console output below:

U-Boot 2020.07

CPU:   MediaTek MT7628A ver:1 eco:2
Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: test
DRAM:  64 MiB
Loading Environment from SPI Flash... SF: Detected w25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
OK
Net:  
Warning: eth@10110000 (eth0) using random MAC address - ba:f6:29:35:59:b5
eth0: eth@10110000
Hit any key to stop autoboot:  0
=> reset
resetting ...


 >  
 > >    What's interesting, is that "reboot" issued in Linux shell makes board reboot as expected on mt7628 board.
 > >
 > >    It seems like some sort of configuration issue, but I couldn't find anything specific in the datasheet. Maybe
 > >    you have some idea what could cause it?
 > >
 > >    One more thing, when running the following version of bootloader (https://github.com/gnubee-git/GnuBee-MT76x8-uboot)
 > >    "reset" command works as expected.
 >  
 > I do not have a MT7628 based board, so I can't test. Perhaps Weijie has
 > an idea?
 >  
 > Thanks,
 > Stefan
 >
Thanks,
Andrew

Reply | Threaded
Open this post in threaded view
|

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

Stefan Roese
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.

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?

> Console output below:
>
> U-Boot 2020.07
>
> CPU:   MediaTek MT7628A ver:1 eco:2
> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
> Model: test
> DRAM:  64 MiB
> Loading Environment from SPI Flash... SF: Detected w25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
> OK
> Net:
> Warning: eth@10110000 (eth0) using random MAC address - ba:f6:29:35:59:b5
> eth0: eth@10110000
> Hit any key to stop autoboot:  0
> => reset
> resetting ...

Thanks,
Stefan
Reply | Threaded
Open this post in threaded view
|

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

Andrii Voloshyn
Hi Stefan,

---- On Wed, 12 Aug 2020 15:08:41 +0300 Stefan Roese <[hidden email]> 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?
In any case SPL is optional, at least it should be. :) on this hw.

 >  
 > 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

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

 >  
 > > Console output below:
 > >
 > > U-Boot 2020.07
 > >
 > > CPU:   MediaTek MT7628A ver:1 eco:2
 > > Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
 > > Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
 > > Model: test
 > > DRAM:  64 MiB
 > > Loading Environment from SPI Flash... SF: Detected w25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
 > > OK
 > > Net:
 > > Warning: eth@10110000 (eth0) using random MAC address - ba:f6:29:35:59:b5
 > > eth0: eth@10110000
 > > Hit any key to stop autoboot:  0
 > > => reset
 > > resetting ...
 >  
 > Thanks,
 > Stefan
 >

Thanks.
Andrii
Reply | Threaded
Open this post in threaded view
|

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

Stefan Roese
Hi Andrew,

On 12.08.20 14:48, Andrii Voloshyn wrote:

> Hi Stefan,
>
> ---- On Wed, 12 Aug 2020 15:08:41 +0300 Stefan Roese <[hidden email]> 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.

>   >
>   > 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.

Thanks,
Stefan
Reply | Threaded
Open this post in threaded view
|

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

Andrii Voloshyn
Hi Stefan,

---- On Wed, 12 Aug 2020 15:57:31 +0300 Stefan Roese <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Weijie Gao-2
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 <[hidden email]> 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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

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

Andrii Voloshyn
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
 > >
 >  
 >