Hi Kever, On Mon, 30 Jan 2023 at 06:25, Kever Yang <kever.y...@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.
