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

[Kever Yang <kever.yang@rock-chips.com>]

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.


Thanks,

- Kever

> 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
>>