Hi Kang-sen,

On 25.10.22 15:25, Kang-sen Lu wrote:
Thanks for your reply.

I cloned the uboot source code from here:
https://github.com/tessel/uboot-mt7620 <https://github.com/tessel/uboot-mt7620>

I built the uboot.bin for RAM_VERSION. If I select option 8 at power up with the uboot from zbtlink, the new uboot.bin will hang. But if I caused saveenv() to happen, by changing tftp filename artificially, the uboot.bin for RAM_VERSION will start and run properly, by the uboot from zbtlink.

Sorry, this is the ancient U-Boot version. I thought you were talking
about the mainline U-Boot version, which I ported for MT7620/80 some
years ago (with many extensions and fixes by Weijie later on).

I don't remember the details of this ancient MT7620 U-Boot version
and frankly don't want to dig into this (again).

Maybe Weijie can comment on the experimental result?

Maybe.

Thanks.

Kang-sen

BTW: How does uboot developer usually run the RAM_VERSION uboot.bin, I am curious. Is it loaded with tftp server, or something else?

Yes. This is very handy and frequently done. Load the RAM version
into RAM to the TEXT_BASE address and start it from there via the
"go" command.

BTW: Please keep the ML on Cc. It might be that someone else has
some answers. Or that this topic is interesting for other
people as well.

Thanks,
Stefan

On Tue, Oct 25, 2022 at 12:46 AM Stefan Roese <s...@denx.de <mailto:s...@denx.de>> wrote:

    Hi Kang-sen,

    On 24.10.22 19:58, Kang-sen Lu wrote:
     > I am wondering if you have read my reply on 10/18. It is very
    strange to
     > find that unless I had uboot to do a saveenv, the RAM_VERSION
    uboot.bin
     > would not run properly in DRAM.

    Frankly, I don't really understand this message. It's not clear to
    me, what you are doing and what is working and what is failing.

    I thought you were trying to boot the current mainline U-Boot RAM
    version u-boot.bin. If yes, which build target did you use? What
    does it show on the serial console?

    Thanks,
    Stefan

     > Thanks.
     >
     > Kang-sen
     >
     > On Tue, Oct 18, 2022 at 10:05 AM Kang-sen Lu <k...@waav.com
    <mailto:k...@waav.com>
     > <mailto:k...@waav.com <mailto:k...@waav.com>>> wrote:
     >
     >     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 <s...@denx.de
    <mailto:s...@denx.de>
     >     <mailto:s...@denx.de <mailto:s...@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
     >

    Viele Grüße,
    Stefan Roese

-- DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
    HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
    Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email:
    s...@denx.de <mailto:s...@denx.de>


Viele Grüße,
Stefan Roese

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Reply via email to