[RFC PATCH 00/16] arm: Add Rockchip RK3588 support

[Jagan Teki]

Hi Kever,

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