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

[Jonas Karlman <jonas@kwiboo.se>]

On 2023-01-27 14:21, Jagan Teki wrote:
> On Fri, 27 Jan 2023 at 05:13, Jonas Karlman <jonas@kwiboo.se> wrote:
>>
>> On 2023-01-26 23:16, Jonas Karlman wrote:
>>> Hi Jagan,
>>> On 2023-01-26 20:17, Jagan Teki wrote:
>>>> On Fri, 27 Jan 2023 at 00:33, Jonas Karlman <jonas@kwiboo.se> wrote:
>>>>>
>>>>> On 2023-01-26 19:26, Jagan Teki wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Thu, 26 Jan 2023 at 23:34, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Thu, 26 Jan 2023 at 10:42, Jagan Teki <jagan@edgeble.ai> wrote:
>>>>>>>>
>>>>>>>> On Thu, 26 Jan 2023 at 22:28, Jonas Karlman <jonas@kwiboo.se> wrote:
>>>>>>>>>
>>>>>>>>> Hi Jagan,
>>>>>>>>> On 2023-01-26 17:51, Jagan Teki wrote:
>>>>>>>>>> Hi Jonas,
>>>>>>>>>>
>>>>>>>>>> On Thu, 26 Jan 2023 at 04:17, Jonas Karlman <jonas@kwiboo.se> 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
>>>>>>>>>>>>
> 
> < snip >
> 
>>>
>>> As you can see in the logs above there is timeout waiting for data.
>>>
>>> I managed to find the issue and have a workaround that gets me longer
>>> in the boot process, there still seem to be other issue with the rk3588
>>> startup.
>>>
>>> --------
>>> U-Boot SPL 2023.01 (Jan 26 2023 - 22:03:00 +0000)
>>> Trying to boot from MMC1
>>> ## Checking hash(es) for config config-1 ... OK
>>> ## Checking hash(es) for Image atf-1 ... sha256+ OK
>>> ## Checking hash(es) for Image u-boot ... sha256+ OK
>>> ## Checking hash(es) for Image fdt-1 ... sha256+ OK
>>> ## Checking hash(es) for Image atf-2 ... sha256+ OK
>>> ## Checking hash(es) for Image atf-3 ... sha256+ OK
>>> INFO:    Preloader serial: 2
>>> NOTICE:  BL31: v2.3():v2.3-468-ge529a2760:derrick.huang
>>> NOTICE:  BL31: Built : 09:59:49, Nov 21 2022
>>> INFO:    spec: 0x1
>>> INFO:    ext 32k is not valid
>>> INFO:    ddr: stride-en 4CH
>>> INFO:    GICv3 without legacy support detected.
>>> INFO:    ARM GICv3 driver initialized in EL3
>>> INFO:    valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0
>>> INFO:    system boots from cpu-hwid-0
>>> INFO:    idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
>>> INFO:    dfs DDR fsp_params[0].freq_mhz= 2112MHz
>>> INFO:    dfs DDR fsp_params[1].freq_mhz= 528MHz
>>> INFO:    dfs DDR fsp_params[2].freq_mhz= 1068MHz
>>> INFO:    dfs DDR fsp_params[3].freq_mhz= 1560MHz
>>> INFO:    BL31: Initialising Exception Handling Framework
>>> INFO:    BL31: Initializing runtime services
>>> WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
>>> ERROR:   Error initializing runtime service opteed_fast
>>> INFO:    BL31: Preparing for EL3 exit to normal world
>>> INFO:    Entry point address = 0xa00000
>>> INFO:    SPSR = 0x3c9
>>> "Synchronous Abort" handler, esr 0x96000000
>>> elr: 0000000000a23650 lr : 0000000000a24d9c
>>> x0 : 0000000000b7fbe8 x1 : 350003402a0003f3
>>> x2 : 0000000000000000 x3 : 0000000000b80ff0
>>> x4 : 0000000000b80ff0 x5 : 0000000000b80e88
>>> x6 : 0000000000000054 x7 : 0000000000000044
>>> x8 : 000000000000000a x9 : 0000000000000000
>>> x10: 0000000000000034 x11: 0000000000000002
>>> x12: 0000000000001988 x13: 0000000000b7fadc
>>> x14: 0000000000a7e808 x15: 0000000000a7e808
>>> x16: 0000000000000000 x17: 0000000000000000
>>> x18: 0000000000b7fe50 x19: 0000000000b7fbe8
>>> x20: 000000003c14dc00 x21: 000000003c14dc00
>>> x22: 0000000000a7e808 x23: 0000000000000000
>>> x24: 0000000000000000 x25: 0000000000000000
>>> x26: 0000000000000000 x27: 0000000000000000
>>> x28: 0000000000000000 x29: 0000000000b7fb80
>>>
>>> Code: f90013f5 f9400001 b4000201 f9400021 (f9403435)
>>> Resetting CPU ...
>>> --------
>>>
>>> This was running on top of u-boot-dm/master 060a65e899859dcbf42049a18be20ce7118e7c0e
>>> with some rk3568 patches and this series, see [1].
>>>
>>> The last 3 commits contains workaround to issue with sdmmc clock.
>>> dwmmc driver set sclk to (uint)-2, my workaround just adds a
>>> fallback to default 400khz clock.
>>>
>>> Next issue is the sync abort, looks it happens when u-boot
>>> tries to set clock rates based on devicetree. this is the
>>> last debug line before the crash.
>>>
>>> clk_set_rate(clk=0000000000b7fba8, rate=1008000000)
>>
>> With the commit at [2] I can now successfully run U-Boot proper.
>>
>> Source of the two main issues to get this series to run have been the scmi clocks.
>> Vendor u-boot first load its scmi driver before trying to set the cpu clocks.
>> We can just remove it and leave setting a faster cpu rate to linux.
>>
>> I also noticed that my sdram size series only detect the first two channels of memory,
>> will respin a v2 of that series to add detection of all 4 channels of memory.
>>
>> [2] https://github.com/Kwiboo/u-boot-rockchip/commit/7e4fee945e725c0ec9ef3905c41ce367e77833b3
> 
> Okay. We need to find a way to handle the clock value 400Khz
> generically via the CLK framework or eMMC can be worth checking as it
> doesn't involve SCMI and have a working patch set before MW. I did
> that and was able to detect eMMC in U-Boot proper but got some issues
> while booting from eMMC [3]

I have an updated branch at [4] that should support booting from sdmmc and sdhci.
Tested booting from both sd-card and emmc on my Radxa ROCK 5 Model B.

This branch is based on u-boot/master f147aa80f52989c7455022ca1ab959e8545feccc
and I have included some rk3568 patches and your rk3588 rfc series.
I added a few fixup on top of that and a few additional patches, please see commit message
for a very brief note on why the change was needed.
Feel free to squash fixups and pick commits up to and possible including
"board: rockchip: Sync evb-rk3568_defconfig with evb-rk3588_defconfig"
for a v2 of this series.

The remaining sdhci patches needs a little bit more work,
I can send a separate series with emmc patches once they are fully ready.

The last commit adds a hack to mkimage to keep the data for atf-3 embedded in the FIT.
This ensures we do not run into problems trying to use dma from emmc into secure pmu sram.
I think this is a more appropriate way to work around this issue, instead of patching
u-boot spl_fit or sdhci core to use bounce buffers in a very special case.

[4] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3588-master-v2

Regards,
Jonas

> 
> [3] https://github.com/edgeble/u-boot/commit/1389822228ac3dfe8d3cd3513db6a32a5c898b7f
> 
> Jagan.