Re: [RESEND 0/3] rockchip: Fix RAM training on RK3399 based platforms (Rock Pi 4)
On Thu, 11 Aug 2022, Lee Jones wrote:
This set fixes several issues found on the Rock Pi 4.
For full context, please see this initial bug report:
"There appear to be a number of issues with the Rockchip rk3399 DDR RAM initialisation sequence in Mainline. Specifically, I'm seeing consistent failures on the Rock Pi 4+ during early boot. A typical failure looks something like this:
U-Boot TPL 2022.07-rc3-00005-g1b04a961c6 (May 25 2022 - 11:09:19) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB Channel 1: col error Cap error! 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM...Even when the system boots to a terminal, which happens very infrequently, the LPDDR4 RAM chip at Channel 1 can have conflicting discovery information printed during TPL. The following 3 lines were printed during successive reboots using the same SD card with no changes:
# Boot 1: BW=32 Col=9 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=384MB # Boot 2: BW=32 Col=10 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=768MB # Boot 3: BW=32 Col=10 Bk=4 CS0 Row=15 CS=1 Die BW=16 Size=512MBThe story changes when I build the idbloader.img image with Rockchip's TBL (?) binary blob [0]. With that built in, presumably in place of the upstream TBL, both RAM chips are successfully enumerated and boot succeeds with 100% success rate:
tools/mkimage -n rk3399 -T rksd -d \ rk3399_ddr_933MHz_v1.25.bin:spl/u-boot-spl.bin idbloader.imgAnother thing that is very different between the 2 is the initial frequency the LPDDR4 chips are clocked at. Using the upstream TBL version, the default is 50Mhz, which seems very low. If using the Rockchip supplied binary blob file, this is increased to a respectable 416MHz:
# Mainline Channel 0: LPDDR4, 50MHz # Rockchip TBL blob Channel 0: LPDDR4,416MHzOne thing I did try was to load in the 400Mhz configuration settings from drivers/ram/rockchip/sdram-rk3399-lpddr4-400.inc as the default initial values, instead of the 50MHz default taken from arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi, but this failed in a number of ways:
Setting clock: Freq: 400MHz (400000000) Calling SDRAM init: 2 Channels Starting SDRAM initialization... mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 1 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 1 (ret: -22) Rank for Channel 1 is 0x0 Rank for Channel 0 is 0x0 Rank for Channel 1 is 0x0 sdram_init: LPDDR4 - 400MHz failed! rk3399_dmc_init DRAM init failed -22So my question is; does Rockchip, or anyone else for that matter, have any plans on updating Mainline U-Boot with the upgraded/working LPDDR4 initialisation sequence?"
Lee Jones (3): ram: rk3399: Fix .set_rate_index() error handling ram: rk3399: Fix faulty frequency change reports ram: rk3399: Conduct memory training at 400MHz
drivers/ram/rockchip/sdram_rk3399.c | 38 +++++++++++++++++------------ 1 file changed, 23 insertions(+), 15 deletions(-)
Looks as though we have all the Reviews we need.
Would someone be kind enough to merge these patches please?
They solve some pretty serious user reported issues.
Thank you.
Hi Lee Jones,
On 2022/9/8 15:44, Lee Jones wrote:
On Thu, 11 Aug 2022, Lee Jones wrote:
This set fixes several issues found on the Rock Pi 4.
For full context, please see this initial bug report:
"There appear to be a number of issues with the Rockchip rk3399 DDR RAM initialisation sequence in Mainline. Specifically, I'm seeing consistent failures on the Rock Pi 4+ during early boot. A typical failure looks something like this:
U-Boot TPL 2022.07-rc3-00005-g1b04a961c6 (May 25 2022 - 11:09:19) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB Channel 1: col error Cap error! 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM...Even when the system boots to a terminal, which happens very infrequently, the LPDDR4 RAM chip at Channel 1 can have conflicting discovery information printed during TPL. The following 3 lines were printed during successive reboots using the same SD card with no changes:
# Boot 1: BW=32 Col=9 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=384MB # Boot 2: BW=32 Col=10 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=768MB # Boot 3: BW=32 Col=10 Bk=4 CS0 Row=15 CS=1 Die BW=16 Size=512MBThe story changes when I build the idbloader.img image with Rockchip's TBL (?) binary blob [0]. With that built in, presumably in place of the upstream TBL, both RAM chips are successfully enumerated and boot succeeds with 100% success rate:
tools/mkimage -n rk3399 -T rksd -d \ rk3399_ddr_933MHz_v1.25.bin:spl/u-boot-spl.bin idbloader.imgAnother thing that is very different between the 2 is the initial frequency the LPDDR4 chips are clocked at. Using the upstream TBL version, the default is 50Mhz, which seems very low. If using the Rockchip supplied binary blob file, this is increased to a respectable 416MHz:
# Mainline Channel 0: LPDDR4, 50MHz # Rockchip TBL blob Channel 0: LPDDR4,416MHzOne thing I did try was to load in the 400Mhz configuration settings from drivers/ram/rockchip/sdram-rk3399-lpddr4-400.inc as the default initial values, instead of the 50MHz default taken from arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi, but this failed in a number of ways:
Setting clock: Freq: 400MHz (400000000) Calling SDRAM init: 2 Channels Starting SDRAM initialization... mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 1 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 1 (ret: -22) Rank for Channel 1 is 0x0 Rank for Channel 0 is 0x0 Rank for Channel 1 is 0x0 sdram_init: LPDDR4 - 400MHz failed! rk3399_dmc_init DRAM init failed -22So my question is; does Rockchip, or anyone else for that matter, have any plans on updating Mainline U-Boot with the upgraded/working LPDDR4 initialisation sequence?"
Lee Jones (3): ram: rk3399: Fix .set_rate_index() error handling ram: rk3399: Fix faulty frequency change reports ram: rk3399: Conduct memory training at 400MHz
drivers/ram/rockchip/sdram_rk3399.c | 38 +++++++++++++++++------------ 1 file changed, 23 insertions(+), 15 deletions(-)
Looks as though we have all the Reviews we need.
Would someone be kind enough to merge these patches please?
Yes, I will merge this patch set soon.
Thanks,
- Kever
They solve some pretty serious user reported issues.
Thank you.
On Fri, 09 Sep 2022, Kever Yang wrote:
Hi Lee Jones,
On 2022/9/8 15:44, Lee Jones wrote:
On Thu, 11 Aug 2022, Lee Jones wrote:
This set fixes several issues found on the Rock Pi 4.
For full context, please see this initial bug report:
"There appear to be a number of issues with the Rockchip rk3399 DDR RAM initialisation sequence in Mainline. Specifically, I'm seeing consistent failures on the Rock Pi 4+ during early boot. A typical failure looks something like this: U-Boot TPL 2022.07-rc3-00005-g1b04a961c6 (May 25 2022 - 11:09:19) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB Channel 1: col error Cap error! 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... Even when the system boots to a terminal, which happens very infrequently, the LPDDR4 RAM chip at Channel 1 can have conflicting discovery information printed during TPL. The following 3 lines were printed during successive reboots using the same SD card with no changes: # Boot 1: BW=32 Col=9 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=384MB # Boot 2: BW=32 Col=10 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=768MB # Boot 3: BW=32 Col=10 Bk=4 CS0 Row=15 CS=1 Die BW=16 Size=512MB The story changes when I build the idbloader.img image with Rockchip's TBL (?) binary blob [0]. With that built in, presumably in place of the upstream TBL, both RAM chips are successfully enumerated and boot succeeds with 100% success rate: tools/mkimage -n rk3399 -T rksd -d \ rk3399_ddr_933MHz_v1.25.bin:spl/u-boot-spl.bin idbloader.img Another thing that is very different between the 2 is the initial frequency the LPDDR4 chips are clocked at. Using the upstream TBL version, the default is 50Mhz, which seems very low. If using the Rockchip supplied binary blob file, this is increased to a respectable 416MHz: # Mainline Channel 0: LPDDR4, 50MHz # Rockchip TBL blob Channel 0: LPDDR4,416MHz One thing I did try was to load in the 400Mhz configuration settings from drivers/ram/rockchip/sdram-rk3399-lpddr4-400.inc as the default initial values, instead of the 50MHz default taken from arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi, but this failed in a number of ways: Setting clock: Freq: 400MHz (400000000) Calling SDRAM init: 2 Channels Starting SDRAM initialization... mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 1 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 1 (ret: -22) Rank for Channel 1 is 0x0 Rank for Channel 0 is 0x0 Rank for Channel 1 is 0x0 sdram_init: LPDDR4 - 400MHz failed! rk3399_dmc_init DRAM init failed -22 So my question is; does Rockchip, or anyone else for that matter, have any plans on updating Mainline U-Boot with the upgraded/working LPDDR4 initialisation sequence?"
Lee Jones (3): ram: rk3399: Fix .set_rate_index() error handling ram: rk3399: Fix faulty frequency change reports ram: rk3399: Conduct memory training at 400MHz
drivers/ram/rockchip/sdram_rk3399.c | 38 +++++++++++++++++------------ 1 file changed, 23 insertions(+), 15 deletions(-)
Looks as though we have all the Reviews we need.
Would someone be kind enough to merge these patches please?
Yes, I will merge this patch set soon.
Thank you Kever.
On Fri, 09 Sep 2022, Kever Yang wrote:
Hi Lee Jones,
On 2022/9/8 15:44, Lee Jones wrote:
On Thu, 11 Aug 2022, Lee Jones wrote:
This set fixes several issues found on the Rock Pi 4.
For full context, please see this initial bug report:
"There appear to be a number of issues with the Rockchip rk3399 DDR RAM initialisation sequence in Mainline. Specifically, I'm seeing consistent failures on the Rock Pi 4+ during early boot. A typical failure looks something like this: U-Boot TPL 2022.07-rc3-00005-g1b04a961c6 (May 25 2022 - 11:09:19) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB Channel 1: col error Cap error! 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... Even when the system boots to a terminal, which happens very infrequently, the LPDDR4 RAM chip at Channel 1 can have conflicting discovery information printed during TPL. The following 3 lines were printed during successive reboots using the same SD card with no changes: # Boot 1: BW=32 Col=9 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=384MB # Boot 2: BW=32 Col=10 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=768MB # Boot 3: BW=32 Col=10 Bk=4 CS0 Row=15 CS=1 Die BW=16 Size=512MB The story changes when I build the idbloader.img image with Rockchip's TBL (?) binary blob [0]. With that built in, presumably in place of the upstream TBL, both RAM chips are successfully enumerated and boot succeeds with 100% success rate: tools/mkimage -n rk3399 -T rksd -d \ rk3399_ddr_933MHz_v1.25.bin:spl/u-boot-spl.bin idbloader.img Another thing that is very different between the 2 is the initial frequency the LPDDR4 chips are clocked at. Using the upstream TBL version, the default is 50Mhz, which seems very low. If using the Rockchip supplied binary blob file, this is increased to a respectable 416MHz: # Mainline Channel 0: LPDDR4, 50MHz # Rockchip TBL blob Channel 0: LPDDR4,416MHz One thing I did try was to load in the 400Mhz configuration settings from drivers/ram/rockchip/sdram-rk3399-lpddr4-400.inc as the default initial values, instead of the 50MHz default taken from arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi, but this failed in a number of ways: Setting clock: Freq: 400MHz (400000000) Calling SDRAM init: 2 Channels Starting SDRAM initialization... mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 1 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 1 (ret: -22) Rank for Channel 1 is 0x0 Rank for Channel 0 is 0x0 Rank for Channel 1 is 0x0 sdram_init: LPDDR4 - 400MHz failed! rk3399_dmc_init DRAM init failed -22 So my question is; does Rockchip, or anyone else for that matter, have any plans on updating Mainline U-Boot with the upgraded/working LPDDR4 initialisation sequence?"
Lee Jones (3): ram: rk3399: Fix .set_rate_index() error handling ram: rk3399: Fix faulty frequency change reports ram: rk3399: Conduct memory training at 400MHz
drivers/ram/rockchip/sdram_rk3399.c | 38 +++++++++++++++++------------ 1 file changed, 23 insertions(+), 15 deletions(-)
Looks as though we have all the Reviews we need.
Would someone be kind enough to merge these patches please?
Yes, I will merge this patch set soon.
Any luck with this Kever?
On Wed, Sep 28, 2022 at 10:26:35AM +0100, Lee Jones wrote:
On Fri, 09 Sep 2022, Kever Yang wrote:
Hi Lee Jones,
On 2022/9/8 15:44, Lee Jones wrote:
On Thu, 11 Aug 2022, Lee Jones wrote:
This set fixes several issues found on the Rock Pi 4.
For full context, please see this initial bug report:
"There appear to be a number of issues with the Rockchip rk3399 DDR RAM initialisation sequence in Mainline. Specifically, I'm seeing consistent failures on the Rock Pi 4+ during early boot. A typical failure looks something like this: U-Boot TPL 2022.07-rc3-00005-g1b04a961c6 (May 25 2022 - 11:09:19) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB Channel 1: col error Cap error! 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... Even when the system boots to a terminal, which happens very infrequently, the LPDDR4 RAM chip at Channel 1 can have conflicting discovery information printed during TPL. The following 3 lines were printed during successive reboots using the same SD card with no changes: # Boot 1: BW=32 Col=9 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=384MB # Boot 2: BW=32 Col=10 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=768MB # Boot 3: BW=32 Col=10 Bk=4 CS0 Row=15 CS=1 Die BW=16 Size=512MB The story changes when I build the idbloader.img image with Rockchip's TBL (?) binary blob [0]. With that built in, presumably in place of the upstream TBL, both RAM chips are successfully enumerated and boot succeeds with 100% success rate: tools/mkimage -n rk3399 -T rksd -d \ rk3399_ddr_933MHz_v1.25.bin:spl/u-boot-spl.bin idbloader.img Another thing that is very different between the 2 is the initial frequency the LPDDR4 chips are clocked at. Using the upstream TBL version, the default is 50Mhz, which seems very low. If using the Rockchip supplied binary blob file, this is increased to a respectable 416MHz: # Mainline Channel 0: LPDDR4, 50MHz # Rockchip TBL blob Channel 0: LPDDR4,416MHz One thing I did try was to load in the 400Mhz configuration settings from drivers/ram/rockchip/sdram-rk3399-lpddr4-400.inc as the default initial values, instead of the 50MHz default taken from arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi, but this failed in a number of ways: Setting clock: Freq: 400MHz (400000000) Calling SDRAM init: 2 Channels Starting SDRAM initialization... mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 1 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 1 (ret: -22) Rank for Channel 1 is 0x0 Rank for Channel 0 is 0x0 Rank for Channel 1 is 0x0 sdram_init: LPDDR4 - 400MHz failed! rk3399_dmc_init DRAM init failed -22 So my question is; does Rockchip, or anyone else for that matter, have any plans on updating Mainline U-Boot with the upgraded/working LPDDR4 initialisation sequence?"
Lee Jones (3): ram: rk3399: Fix .set_rate_index() error handling ram: rk3399: Fix faulty frequency change reports ram: rk3399: Conduct memory training at 400MHz
drivers/ram/rockchip/sdram_rk3399.c | 38 +++++++++++++++++------------ 1 file changed, 23 insertions(+), 15 deletions(-)
Looks as though we have all the Reviews we need.
Would someone be kind enough to merge these patches please?
Yes, I will merge this patch set soon.
Any luck with this Kever?
Merged in 337e92e79c95ffb8c0c6e7b4023c955c50fca018
HTH
Michal
On Wed, 28 Sep 2022, Michal Suchánek wrote:
On Wed, Sep 28, 2022 at 10:26:35AM +0100, Lee Jones wrote:
On Fri, 09 Sep 2022, Kever Yang wrote:
Hi Lee Jones,
On 2022/9/8 15:44, Lee Jones wrote:
On Thu, 11 Aug 2022, Lee Jones wrote:
This set fixes several issues found on the Rock Pi 4.
For full context, please see this initial bug report:
"There appear to be a number of issues with the Rockchip rk3399 DDR RAM initialisation sequence in Mainline. Specifically, I'm seeing consistent failures on the Rock Pi 4+ during early boot. A typical failure looks something like this: U-Boot TPL 2022.07-rc3-00005-g1b04a961c6 (May 25 2022 - 11:09:19) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB Channel 1: col error Cap error! 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... Even when the system boots to a terminal, which happens very infrequently, the LPDDR4 RAM chip at Channel 1 can have conflicting discovery information printed during TPL. The following 3 lines were printed during successive reboots using the same SD card with no changes: # Boot 1: BW=32 Col=9 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=384MB # Boot 2: BW=32 Col=10 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=768MB # Boot 3: BW=32 Col=10 Bk=4 CS0 Row=15 CS=1 Die BW=16 Size=512MB The story changes when I build the idbloader.img image with Rockchip's TBL (?) binary blob [0]. With that built in, presumably in place of the upstream TBL, both RAM chips are successfully enumerated and boot succeeds with 100% success rate: tools/mkimage -n rk3399 -T rksd -d \ rk3399_ddr_933MHz_v1.25.bin:spl/u-boot-spl.bin idbloader.img Another thing that is very different between the 2 is the initial frequency the LPDDR4 chips are clocked at. Using the upstream TBL version, the default is 50Mhz, which seems very low. If using the Rockchip supplied binary blob file, this is increased to a respectable 416MHz: # Mainline Channel 0: LPDDR4, 50MHz # Rockchip TBL blob Channel 0: LPDDR4,416MHz One thing I did try was to load in the 400Mhz configuration settings from drivers/ram/rockchip/sdram-rk3399-lpddr4-400.inc as the default initial values, instead of the 50MHz default taken from arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi, but this failed in a number of ways: Setting clock: Freq: 400MHz (400000000) Calling SDRAM init: 2 Channels Starting SDRAM initialization... mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 0 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 2, ch 1 (ret: -22) mr5:0 mr12:0 mr14:0 Training failed for rank 1, ch 1 (ret: -22) Rank for Channel 1 is 0x0 Rank for Channel 0 is 0x0 Rank for Channel 1 is 0x0 sdram_init: LPDDR4 - 400MHz failed! rk3399_dmc_init DRAM init failed -22 So my question is; does Rockchip, or anyone else for that matter, have any plans on updating Mainline U-Boot with the upgraded/working LPDDR4 initialisation sequence?"
Lee Jones (3): ram: rk3399: Fix .set_rate_index() error handling ram: rk3399: Fix faulty frequency change reports ram: rk3399: Conduct memory training at 400MHz
drivers/ram/rockchip/sdram_rk3399.c | 38 +++++++++++++++++------------ 1 file changed, 23 insertions(+), 15 deletions(-)
Looks as though we have all the Reviews we need.
Would someone be kind enough to merge these patches please?
Yes, I will merge this patch set soon.
Any luck with this Kever?
Merged in 337e92e79c95ffb8c0c6e7b4023c955c50fca018
That's great.
Is it not common practice to send out "applied" messages?
HTH
Yes, thank you Michal.
participants (3)
-
Kever Yang -
Lee Jones -
Michal Suchánek