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

[Jonas Karlman]

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.

I am thinking we could use some sort of mechanism to signal mkimage that we want to
keep the parts that should be loaded into SRAM as embedded data instead of external data.
That way the FIT can be loaded using DMA into DRAM, and the embedded data will then
be memcpy into SRAM using CPU.

I quickly tested [0] and this seem to work and we do not need to use the fifo-mode
to work around this DMA to SRAM issue. Will work on a proper RFC for such solution.

[0] https://github.com/Kwiboo/u-boot-rockchip/commit/551b02a5cd7d28244f44b2e7d7a29196305c26f6

Regards,
Jonas

> 
> 
> Thanks,
> 
> - Kever
>