rk3399 TPL memory setup code triggers clock frequency limit assertion
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 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
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
Clearly the assertion is wrong at least for this PLL because the system boots with the assertion disarmed. Then again, it is not clear that the PLL is operated at this frequency at all - it is immediately changed to higher frequency when the memory type is detected.
What would be a resonable way to make rk3399 bootable with clock debug enabled?
Thanks
Michal
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?
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.
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?
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 Channel 0: LPDDR4, 50MHz 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 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 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... 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
U-Boot SPL 2022.10-rc1-00077-g23c0174967-dirty (Aug 07 2022 - 20:26:36 +0530) Trying to boot from MMC1
U-Boot 2022.10-rc1-00077-g23c0174967-dirty (Aug 07 2022 - 20:26:36 +0530)
SoC: Rockchip rk3399 Reset cause: POR Model: Radxa ROCK Pi 4C DRAM: 3.9 GiB PLL at 00000000ff750000: fbdiv=112, refdiv=2, postdiv1=2, postdiv2=1, vco=1344000 khz, output=672000 khz Core: 283 devices, 29 uclasses, devicetree: separate MMC: Unknown clock 77 mmc@fe310000: 2, mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... Card did not respond to voltage select! : -110 *** Warning - No block device, using default environment
In: serial Out: serial Err: serial Model: Radxa ROCK Pi 4C can't get vref-supply: -121 rockchip_dnl_key_pressed: adc_channel_single_shot fail! Net: rk3399_gmac_set_parent: switching RGMII to CLKIN rk3399_gmac_set_parent: switching RGMII to CLKIN eth0: ethernet@fe300000 Hit any key to stop autoboot: 0
Thanks, Jagan.
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
El Sun, Aug 07, 2022 at 04:44:04PM +0200, Michal Suchánek deia:
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
Sorry, I don't have time now. But It might be related to
https://patchwork.ozlabs.org/project/uboot/patch/20220716103144.GA2167@begut...
Apparently this clock is wrong but nobody finds any consequence of it being wrong. If one asks for a 50MHz clock and gets a 48MHz clockthings might work anyway, but it's nice that at least when one asks to be told of problems one is told.
What would be a resonable way to make rk3399 bootable with clock debug enabled?
Try my patch, I don't think it can hurt ?
On Mon, Aug 08, 2022 at 04:28:33PM +0200, Xavier Drudis Ferran wrote:
El Sun, Aug 07, 2022 at 04:44:04PM +0200, Michal Suchánek deia:
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
Sorry, I don't have time now. But It might be related to
https://patchwork.ozlabs.org/project/uboot/patch/20220716103144.GA2167@begut...
Apparently this clock is wrong but nobody finds any consequence of it being wrong. If one asks for a 50MHz clock and gets a 48MHz clockthings might work anyway, but it's nice that at least when one asks to be told of problems one is told.
Yes, that's exactly what I was looking for. It resolves the discrepancy between the asssert and the set clock by adjusting the clock settings.
Thanks
Michal
U-Boot TPL 2022.07-00044-gc1e2523e7d-dirty (Aug 08 2022 - 18:10:27) 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=75, refdiv=2, postdiv1=3, postdiv2=6, vco=900000 khz, output=50000 khz rk3399_clk_set_rate: clk clock-controller@ff760000 170 rate 50000000 -> 50000000 Channel 0: LPDDR4, 50MHz 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 rk3399_clk_set_rate: clk clock-controller@ff760000 170 rate 400000000 -> 400000000 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 rk3399_clk_set_rate: clk clock-controller@ff760000 170 rate 800000000 -> 800000000 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 rk3399_clk_get_rate: clk clock-controller@ff760000 83
U-Boot SPL 2022.07-00044-gc1e2523e7d-dirty (Aug 08 2022 - 18:10:27 +0200)
On Mon, Aug 8, 2022 at 9:46 PM Michal Suchánek msuchanek@suse.de wrote:
On Mon, Aug 08, 2022 at 04:28:33PM +0200, Xavier Drudis Ferran wrote:
El Sun, Aug 07, 2022 at 04:44:04PM +0200, Michal Suchánek deia:
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
Sorry, I don't have time now. But It might be related to
https://patchwork.ozlabs.org/project/uboot/patch/20220716103144.GA2167@begut...
Apparently this clock is wrong but nobody finds any consequence of it being wrong. If one asks for a 50MHz clock and gets a 48MHz clockthings might work anyway, but it's nice that at least when one asks to be told of problems one is told.
Yes, that's exactly what I was looking for. It resolves the discrepancy between the asssert and the set clock by adjusting the clock settings.
If I remember correctly when I work with YouMin on LPDDR4 the initial code to start to check with was 50MHz (It was not working at that time with 48MHz). Not sure what to make other changes to fix that to try on 48MHz.
Better resend the patch again and add YouMin and others to see for comments.
Jagan.
El Mon, Aug 08, 2022 at 11:22:49PM +0530, Jagan Teki deia:
If I remember correctly when I work with YouMin on LPDDR4 the initial code to start to check with was 50MHz (It was not working at that time with 48MHz). Not sure what to make other changes to fix that to try on 48MHz.
Not sure I understand.
Do you mean when you and YouMin worked in this (thanks for your work) you had mesured that the code gave 50MHz ? Maybe. It seems out of spec, so it doesn't have to give 48MHz, I guess it can give whatever. 48MHz is the concluion of a theory for which we haven't satisfied the hypothesis.
Or do you mean the code for this clock was different when you worked initially, and that code gave 50MHz theoretically ? I haven't looked at the git log.
Better resend the patch again and add YouMin and others to see for comments.
I don't have much time right now to pull, see if it applies still and test again. Michal just tried, not sure how clean it might have been for him, or what base he used, so anyone feel free to resend if you think it's useful or know better who to put in cc. Who would "others" be ? If I got my Cc: wrong the first time I fear I'll fail again. Michal just sent a tested-by to my orignal patch[1]. Should a resend fare better ? Or how many resends? I may resend this one line patch when I have time if nobody has resent yet or merged the original.
YouMin helped me confirm and said something unconclusive in private, not opposing to change it.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20220716103144.GA2167@begut...
participants (3)
-
Jagan Teki -
Michal Suchánek -
Xavier Drudis Ferran