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/7e4fee945e725c0ec9ef3905c41...
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]
[3] https://github.com/edgeble/u-boot/commit/1389822228ac3dfe8d3cd3513db6a32a5c8...
Jagan.