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