Hi Kever,
On Mon, 30 Jan 2023 at 06:25, Kever Yang kever.yang@rock-chips.com wrote:
Hi Jonas,
On 2023/1/29 17:58, Jonas Karlman wrote:
Hi Kever, On 2023-01-29 10:47, Kever Yang wrote:
Hi Jonas, Jagan,
On 2023/1/26 06:47, Jonas Karlman wrote:
Hi Jagan,
On 2023-01-25 23:27, Jagan Teki wrote:
This series support Rockchip RK3588. All the device tree files are synced from linux-next with the proper SHA1 mentioned in the commit messages.
Unfortunately, the BL31 from rkbin is not compatible with U-Boot so it is failing to load ATF entry from SPL and hang.
Verified below BL31 versions, bl31-v1.15 bl31-v1.21 bl31-v1.22 bl31-v1.23 bl31-v1.24 bl31-v1.25 bl31-v1.26
Rever-engineered with respect to rockchip u-boot by using the same FIT_GENERATOR being used in Mainline, rockchip u-boot is booting but mainline showing the same issue.
Log:
LPDDR4X, 2112MHz01-00642-g6bdfd31756-dirty (Jan 26 2023 ���3:44:34 +0530) channel[0] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out
U-Boot SPL 2023.01-00642-g6bdfd31756-dirty (Jan 26 2023 - 03:44:34 +0530) Trying to boot from MMC1 bl31_entry: atf_entry start << hang >>
Any information on BL31 for RK3588 please share.
I had a similar strange booing issue with RK3568 and mainline U-Boot, turned out to be related to all parts of ATF not being properly loaded into PMU SRAM.
For this issue, could you try to add below property for mmc dts node?
"u-boot,spl-fifo-mode"
The emmc/sdmmc controller do not have a direct path to the SRAM, so we can't use
its internal DMA to do the data transfer. The "fifo-mode" will use CPU to do the data
copy instead of the internal DMA.
For sdmmc this worked, but for emmc it did not, trying to use the emmc without SDMA seemed to cause issues reading data in general, did not fully investigate why.
The sdmmc is using driver rockchip_dw_mmc.c while the emmc is using the driver rockchip_sdhci.c,
I think this is the root cause for the "spl-fifo-mode" only only works on sdmmc.
Apart from this, the 400KHZ clock workaround is required to boot the SDMMC. I feel this hack of 400KHZ cannot be proper, we need to handle that via CLK drivers to get the rate.
Jagan.