New u-boot-aspeed-sdk runs slow and cause wdt2 timeout on ast2500

Joel Stanley joel at jms.id.au
Thu Feb 24 14:45:48 AEDT 2022


On Wed, 23 Feb 2022 at 10:02, Lei Yu <yulei.sh at bytedance.com> wrote:
>
> > > > > Could you share us the boot log with timestamps?
> > > > > It would be nice to know the time elapsed at each stage.
> > > >
> > > > Pasted to https://pastebin.com/emseqW6c
> > > > It contains two logs, the first one is good, and the second has the issue.
> >
> > Working:
> > [2022-02-23 02:47:03] U-Boot 2019.04 (Jan 24 2022 - 10:18:18 +0000)
> > [2022-02-23 02:47:06] ## Loading kernel from FIT Image at 20100000 ...
> > [2022-02-23 02:47:12] Starting kernel ...
> >
> > 3 + 6 seconds.
> >
> > broken:
> > [2022-02-23 02:58:07] U-Boot 2019.04 (Feb 15 2022 - 07:22:14 +0000)
> > [2022-02-23 02:58:12] ## Loading kernel from FIT Image at 20100000 ...
> > [2022-02-23 02:58:22] Starting kernel ...
> >
> > 5 + 10 seconds.
> >
> > Interesting that the pre-hashing part is also slower.
> >
> > The old branch was based on v00.04.03. The new branch is based on v00.04.09.
> >
> > I wonder if this is the cause:
> >
> > $ git diff  v00.04.03..v00.04.09 -- configs/evb-ast2500_defconfig
> > diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig
> > index 9fcf55b05ebb..000ed3f90bdd 100644
> > --- a/configs/evb-ast2500_defconfig
> > +++ b/configs/evb-ast2500_defconfig
> > @@ -1,4 +1,5 @@
> >  CONFIG_ARM=y
> > +CONFIG_SYS_DCACHE_OFF=y
> >  CONFIG_ARCH_ASPEED=y
> >  CONFIG_SYS_TEXT_BASE=0x0
> >  CONFIG_SYS_MALLOC_F_LEN=0x2000
> >
> > Lei, can you re-test with CONFIG_SYS_DCACHE_OFF=n ?
> >
>
> Yiwei helped to test with CONFIG_SYS_DCACHE_OFF=n, and it works fine now.
> So it seems we get the root cause!

I'm glad this worked. The bill is in the mail :)

I would suggest this is not the root cause. This is a workaround that
speeds up booting enough that you make it to linux, but if your kernel
image got a bit larger (for example), it would take longer and the
issue would show up again.

To properly fix the issue, we need to ensure the watchdog is serviced,
as I mentioned in my previous email.

Cheers,

Joel


More information about the openbmc mailing list