reset command doesn't work on MT7628 (CPU: MediaTek MT7628A ver:1 eco:2)
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
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
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
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
Hi Stefan,
---- On Wed, 12 Aug 2020 15:08:41 +0300 Stefan Roese sr@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? 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
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@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.
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
Hi Stefan,
---- On Wed, 12 Aug 2020 15:57:31 +0300 Stefan Roese sr@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@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
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@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@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
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.gao@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:
- By using the dedicate opcodes which always require 4-byte address
- 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@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@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
participants (3)
-
Andrii Voloshyn -
Stefan Roese -
Weijie Gao