From: "Michal Suchánek" <msuchanek@suse.de>
To: Jagan Teki <jagan@amarulasolutions.com>
Cc: u-boot@lists.denx.de, Kever Yang <kever.yang@rock-chips.com>
Subject: Re: rk3399 TPL memory setup code triggers clock frequency limit assertion
Date: Sun, 7 Aug 2022 17:18:34 +0200 [thread overview]
Message-ID: <20220807151834.GK17705@kitsune.suse.cz> (raw)
In-Reply-To: <CAMty3ZAALZK=2KuSKHDrQsMaHTiYwHy7TGjHTPp5hrC9Tygszw@mail.gmail.com>
On Sun, Aug 07, 2022 at 08:31:56PM +0530, Jagan Teki wrote:
> On Sun, Aug 7, 2022 at 8:14 PM Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > Hello,
> >
> > when compiled with clock debug rk3399 cannot be booted because memory
> > setup code triggers clock assertion:
> >
> > U-Boot TPL 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 16:13:17)
> > TPL PLL at ff760000: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=1200000 khz, output=600000 khz
> > TPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=1200000 khz, output=600000 khz
> > TPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, vco=1188000 khz, output=594000 khz
> > TPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, vco=1536000 khz, output=384000 khz
> > TPL PLL at ff760040: fbdiv=12, refdiv=1, postdiv1=3, postdiv2=2, vco=288000 khz, output=48000 khz
> > drivers/clk/rockchip/clk_rk3399.c:347: rkclk_set_pll: Assertion `vco_khz >= VCO_MIN_KHZ && vco_khz <= VCO_MAX_KHZ && output_khz >= OUTPUT_MIN_KHZ && output_khz <= OUTPUT_MAX_KHZ && div->fbdiv >= PLL_DIV_MIN && div->fbdiv <= PLL_DIV_MAX' failed.Channel 0: LPDDR4, 50MHz
>
> Does it an external print for trigger mode?
Do you mean the asserion?
That's defined in lib/panic.c and include/log.h
I patched assert() to not panic and only print the message.
> > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> > Channel 1: LPDDR4, 50MHz
> > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> > 256B stride
> > TPL PLL at ff760040: fbdiv=50, refdiv=1, postdiv1=3, postdiv2=1, vco=1200000 khz, output=400000 khz
> > lpddr4_set_rate: change freq to 400000000 mhz 0, 1
> > TPL PLL at ff760040: fbdiv=100, refdiv=1, postdiv1=3, postdiv2=1, vco=2400000 khz, output=800000 khz
> > lpddr4_set_rate: change freq to 800000000 mhz 1, 0
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> > SPL PLL at ff760000: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=1200000 khz, output=600000 khz
> > SPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=1200000 khz, output=600000 khz
> > SPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, vco=1188000 khz, output=594000 khz
> > SPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, vco=1536000 khz, output=384000 khz
>
> Look good to me at least on PLL detections on respective clocks.
Yes, I don't obeserve anything that is defeinitely a clock problem, I
just cannot boot with clock debug enabled.
> >
> > U-Boot SPL 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 16:13:17 +0200)
> > mmc@fe320000: Got clock clock-controller@ff760000 76
> > Trying to boot from MMC2
> > NOTICE: BL31: v2.6(debug):
> > NOTICE: BL31: Built : 14:50:40, Jul 1 2022
> > INFO: GICv3 with legacy support detected.
> > INFO: ARM GICv3 driver initialized in EL3
> > INFO: Maximum SPI INTID supported: 287
> > INFO: plat_rockchip_pmu_init(1624): pd status 3e
> > INFO: BL31: Initializing runtime services
> > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied
> > WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!
> > INFO: BL31: Preparing for EL3 exit to normal world
> > INFO: Entry point address = 0x200000
> > INFO: SPSR = 0x3c9
>
> Maybe TF-A?
What with TF-A?
Yes, it's used but the problem happens before it's loaded.
> Here is the output when we s/debug/printf/ for your reference.
>
> U-Boot TPL 2022.10-rc1-00077-g23c0174967-dirty (Aug 07 2022 - 20:26:36)
> PLL at ff760000: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1,
> vco=1200000 khz, output=600000 khz
> PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1,
> vco=1200000 khz, output=600000 khz
> PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1,
> vco=1188000 khz, output=594000 khz
> PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2,
> vco=1536000 khz, output=384000 khz
> PLL at ff760040: fbdiv=12, refdiv=1, postdiv1=3, postdiv2=2,
> vco=288000 khz, output=48000 khz
Which looks exactly the same, except with s/debug/printf/ the assert is
not enabled, that only happens with DEBUG defined.
Thanks
Michal
next prev parent reply other threads:[~2022-08-07 15:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-07 14:44 rk3399 TPL memory setup code triggers clock frequency limit assertion Michal Suchánek
2022-08-07 15:01 ` Jagan Teki
2022-08-07 15:18 ` Michal Suchánek [this message]
2022-08-08 14:28 ` [SPAM] " Xavier Drudis Ferran
2022-08-08 16:16 ` Michal Suchánek
2022-08-08 17:52 ` Jagan Teki
2022-08-08 20:05 ` Xavier Drudis Ferran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220807151834.GK17705@kitsune.suse.cz \
--to=msuchanek@suse.de \
--cc=jagan@amarulasolutions.com \
--cc=kever.yang@rock-chips.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.