On 2023-01-27 14:21, Jagan Teki wrote: > On Fri, 27 Jan 2023 at 05:13, Jonas Karlman <jo...@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 <jo...@kwiboo.se> wrote: >>>>> >>>>> On 2023-01-26 19:26, Jagan Teki wrote: >>>>>> Hi Simon, >>>>>> >>>>>> On Thu, 26 Jan 2023 at 23:34, Simon Glass <s...@chromium.org> wrote: >>>>>>> >>>>>>> Hi Jagan, >>>>>>> >>>>>>> On Thu, 26 Jan 2023 at 10:42, Jagan Teki <ja...@edgeble.ai> wrote: >>>>>>>> >>>>>>>> On Thu, 26 Jan 2023 at 22:28, Jonas Karlman <jo...@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 <jo...@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.
