Hi, Stefan:
Thanks for your reply.
The uboot in the zbtlink mt7620 router has the signatures follows:
U-Boot 1.1.3 (Nov 9 2016 - 15:34:50)
SoC:MediaTek MT7620 DRAM: Memory Testing..131072K OK. is 128 MB relocate_code Pointer at: 87fb0000 enable ephy clock...done. rf reg 29 = 5 SSC disabled. spi_wait_nsec: 29 spi device id: ef 40 18 0 0 (40180000) Flash: W25Q128BV
I would like to share my strange experience about RAM version uboot for mt7620. By pure luck, I found that when I tried to load a newly built uboot with startup menu option 8, unless I change the filename, say, from uboot.bin to uboot1.bin, the newly loaded uboot would not startup properly in RAM.
I don't have the knowledge to find out why this variable "modifies" to be none-zero is so important to the execution of uboot in RAM. Maybe some expert in this group can easily figure that out.
Thanks.
Kang-sen
On Tue, Oct 18, 2022 at 7:53 AM Stefan Roese sr@denx.de wrote:
Hi Kang-sen,
(added Weijie Gao to Cc)
On 17.10.22 14:11, Kang-sen Lu wrote:
I am building uboot.bin for mt7620 router.
I used start menu option 8, a hidden one choice, to load uboot.bin
through
tftp.
The tftp transfer is OK. But when the new uboot starts, it hang.
So which mainline U-Boot build target did you use? Don't you see any output on the serial console at all?
I am wondering if the RAM_VERSION for mt7620 still works.
In mainline U-Boot this is usually handled this way. The SPL U-Boot version is responsible for the low-level HW init, like DRAM/DDR init etc. It's hard to impossible to chainload this SPL part from a running U-Boot version.
The "RAM_VERSION" is usually the main U-Boot proper image "u-boot.bin". So in general you are using the correct file here. Even though I have not idea, if the build target is correct for your "mt7620 router".
Thanks, Stefan