From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1C37BC61DA4 for ; Mon, 13 Mar 2023 15:34:14 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7425185D23; Mon, 13 Mar 2023 16:34:11 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; secure) header.d=xs4all.nl header.i=@xs4all.nl header.b="FAX2T1la"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 22A5A8616E; Mon, 13 Mar 2023 16:34:09 +0100 (CET) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.185]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id EFCB585982 for ; Mon, 13 Mar 2023 16:34:03 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=mark.kettenis@xs4all.nl X-KPN-MessageId: 7520f0b9-c1b4-11ed-884e-005056999439 Received: from smtp.kpnmail.nl (unknown [10.31.155.8]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 7520f0b9-c1b4-11ed-884e-005056999439; Mon, 13 Mar 2023 16:33:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=xs4all01; h=subject:to:from:message-id:date; bh=2JJDsBdQT7942OZGmrpGxRb+nOvgHMdYJSp4Z8DwWkU=; b=FAX2T1lastW8kibi04RWrmpzDNsfhDAuaArhqk6pegpidDhVqZ20oaaIDDlarLfg38fsmoSci96kb oWjy9TekgQoiQTRvfVBkJuz0EsaV7LLkJatM9L1p+b/H++9sf4/pkUMYbLGvPZv0SchvMkZWEpXYTC zMAnXcUhSSRNZCTpUs++7N0YRuZHyloOFU8y2mHxd+BW1tvUbrAvY9dNfcmR5zdLRtUIFMhFRuh92X gaMQgQN/jXJ3hlLVMFgwC76unXG119Qs62fN6ZhJrG+VmAbyufZzbq0AVU0HGn0N98spOpeU4Nyjq3 mrFWSorBdNDGl4wu5Yiz8ySJ5mttq+A== X-KPN-MID: 33|9sSCIaAgu/4WIK4GCtQ474LMCn2GDUyYpoovCF+QBTnWrdkrgWgiY4m4/A1HTuF MsjOimtsIjPdZGLJZXqd+UgZKciRuF5nUkSVcGTZO1mY= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|+u7+dBVn/24dlhk6F94U/2tIfKJMHkMa0P3VGXxznNyJsqkCzg5c3jYEFrhclHw 6i4w/K7BEQFIqyxRVwOznzQ== X-Originating-IP: 80.61.163.207 Received: from bloch.sibelius.xs4all.nl (80-61-163-207.fixed.kpn.net [80.61.163.207]) by smtp.xs4all.nl (Halon) with ESMTPSA id 7b3491e9-c1b4-11ed-9d31-00505699d6e5; Mon, 13 Mar 2023 16:34:03 +0100 (CET) Date: Mon, 13 Mar 2023 16:34:02 +0100 Message-Id: <87r0tsbr85.fsf@bloch.sibelius.xs4all.nl> From: Mark Kettenis To: Eugen Hristev Cc: jonas@kwiboo.se, jagan@edgeble.ai, sjg@chromium.org, kever.yang@rock-chips.com, philipp.tomsich@vrull.eu, fatorangecat@189.cn, u-boot@lists.denx.de In-Reply-To: <095df908-5e0b-06dd-6b2b-7f3821a48098@collabora.com> (message from Eugen Hristev on Mon, 13 Mar 2023 17:21:05 +0200) Subject: Re: [RFC PATCH 00/16] arm: Add Rockchip RK3588 support References: <20230125222741.303259-1-jagan@edgeble.ai> <64443c40-03b1-bfe2-23fe-ad61236d7dde@kwiboo.se> <516c84b9-4867-b2ea-46ad-30decc62194a@kwiboo.se> <1e370ab2-8407-b724-2afd-24ddb23c638c@kwiboo.se> <7f4bdd74-c2df-0c8e-2527-b192040d3977@kwiboo.se> <6fe7adc8-0b0d-70a1-5f13-d3205ad158ab@kwiboo.se> <8e806457-0220-443a-84e4-33cadf968c4f@collabora.com> <3a504ce2-0c82-d4c9-6b87-89b87d01c80c@collabora.com> <1d71198b-a187-a805-31ab-d3fe7221efa1@collabora.com> <87ttyobsfp.fsf@bloch.sibelius.xs4all.nl> <095df908-5e0b-06dd-6b2b-7f3821a48098@collabora.com> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean > Date: Mon, 13 Mar 2023 17:21:05 +0200 > From: Eugen Hristev > > On 3/13/23 17:07, Mark Kettenis wrote: > >> Date: Mon, 13 Mar 2023 16:21:36 +0200 > >> From: Eugen Hristev > >> > >> On 3/13/23 12:00, Jonas Karlman wrote: > >>> On 2023-03-13 09:42, Eugen Hristev wrote: > >>>> On 3/13/23 00:34, Jonas Karlman wrote: > >>>>> Hi Eugen, > >>>>> > >>>>> On 2023-03-08 09:57, Eugen Hristev wrote: > >>>>>> On 1/29/23 11:04, Jonas Karlman wrote: > >>>>>>> On 2023-01-27 14:21, Jagan Teki wrote: > >>>>>>>> On Fri, 27 Jan 2023 at 05:13, Jonas Karlman 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 wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> On 2023-01-26 19:26, Jagan Teki wrote: > >>>>>>>>>>>>> Hi Simon, > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Thu, 26 Jan 2023 at 23:34, Simon Glass wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Jagan, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Thu, 26 Jan 2023 at 10:42, Jagan Teki wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Thu, 26 Jan 2023 at 22:28, Jonas Karlman wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi Jagan, > >>>>>>>>>>>>>>>> On 2023-01-26 17:51, Jagan Teki wrote: > >>>>>>>>>>>>>>>>> Hi Jonas, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Thu, 26 Jan 2023 at 04:17, 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 > >>>>>>>>>>>>>>>>>>> > >>>>>>>> > >>>>>>>> < 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 > >>>>>>> > >>>>>> Hello Jagan, Jonas, > >>>>>> > >>>>>> I wanted to chip into this discussion, to ask whether you did anything > >>>>>> more on the SD clock matter ? > >>>>> > >>>>> I have been busy this past week but have now had time to take a new look > >>>>> at the sdmmc issue, along with completing some other fixes. > >>>>> > >>>>>> > >>>>>> I am currently using your workaround that creates dummy clocks in the DT > >>>>>> and then the SD node just uses those, and it works, in the SPL, if and > >>>>>> only if the bootrom also loads the SPL from SD. > >>>>>> I tried to have the SPL inside the SPI flash, or load it to DDR using > >>>>>> the rockusb protocol, and then, initializing the SD-Card from SPL fails > >>>>>> utterly, namely, it cannot communicate with the card. > >>>>>> I did some changes to have the pinctrl working at SPL level, which > >>>>>> appears to be fine, but I would like to see what can be done about the > >>>>>> clocks. > >>>>>> Having the cru and all the required drivers at SPL level is the way to > >>>>>> go ? The SPL should run before SCMI is required so it should be able to > >>>>>> change all the clocks at the clock controller level ? > >>>>> > >>>>> I fully agree that we should have some sort of scmi clk driver so that > >>>>> we can control the sdmmc clk in both SPL and U-Boot proper. > >>>>> > >>>>> As you have noticed the current workaround only works because bootrom > >>>>> leave the clocks in a working state after it has loaded TPL/SPL from > >>>>> the sdmmc device. When TPL/SPL is loaded from any other source it is > >>>>> not be possible to read from the sdmmc device in u-boot. > >>>>> > >>>>> After having played around with the scmi agent driver and being inspired > >>>>> by the dummy scmi clk driver in vendor u-boot I have managed to create > >>>>> something that could work. See top three commits from [5] for a working > >>>>> proof-of-concept. > >>>>> > >>>>> What I did was to enable the scmi agent driver for use in u-boot proper > >>>>> and keeping it disabled in SPL build. Then added a new scmi clk driver > >>>>> that is enabled in SPL build, the rk3588 clk driver hooks the new clk > >>>>> driver to the scmi_clk ofnode. I only implemented the get/set rate ops > >>>>> for the two sdmmc clocks. With this both SPL and U-Boot proper should > >>>>> be able to configure the sdmmc clocks. > >>>>> > >>>>> The initial fixes commits in that branch should hit the list soon. > >>>>> Will send the sdmmc related commits once I have had some time to do > >>>>> more testing. > >>>>> > >>>>> [5] https://github.com/Kwiboo/u-boot-rockchip/commits/rk35xx-fixes > >>>>> > >>>> Hi Jonas, > >>>> > >>>> I managed to get it working in SPL as well, with a similar code inspired > >>>> from the vendor tree. > >>>> About the solution, I am not sure whether it should be called a scmi > >>>> clock, and whether it should be part of clk_rk3588 > >>>> Honestly by looking at the DT node, I find the description of the clock > >>>> tree wrong to begin with. > >>>> The SD should not have the 2 clocks tied to the scmi agent, because this > >>>> is true only if it's running in normal world with a secure world agent > >>>> that will act as a middle man. So if we are running at a higher EL, as > >>>> in the SPL case, the clocks should be tied directly to the CRU. > >>>> So the node itself is described bad IMO. > >>>> > >>>> Anyway, if the node is set in stone from Linux, there isn;t much we can do. > >>>> I am also thinking whether we should have the SCMI enabled in SPL as > >>>> well, but the agent/clock should just access the CRU directly, meaning > >>>> to do something at the agent level : > >>>> #ifdef CONFIG_SPL_BUILD > >>>> -> access CRU > >>>> #else > >>>> -> send SCMI message > >>>> #endif > >>>> Does this make more sense ? > >>>> > >>>> Or have some kind of wrapper driver that would act as a dispatcher > >>>> depending on the SPL/proper build ? > >>> > >>> Looks like the sdmmc clock is controlled by the securecru registers and I > >>> expect that this can only be configured in secure world, not sure how this > >>> could have been modeled differently. > >> > >> Since it can work with a clock given by either scmi or securecru, I > >> would expect all clocks to be in the list, and the driver could start > >> the needed clock as per the EL level it's running into :) > >> > >> e.g. > >> clocks = <&scru CCLK_SD>, <&scru HCLK_SD>, <&scmi CCLK_SD>, <&scmi > >> HCLK_SD> , <&cru basic other clocks..> > >> > >> Just my vision of how it could be modeled > > > > That is a change to the device tree bindings. The goal is to have > > U-Boot use the same bindings and device tree as the official device > > tree (which currently is the one in mainline Linux). > > That's right. A change in the bindings (and Linux ) And OpenBSD, and NetBSD, and ... The device tree bindings are ABI. You can't change them unless they are really relly broken. > >>> With the approach that I took I think the normal clk framework will behave > >>> as such dispatcher and clock gets tied to cru in SPL. > >>> > >>> #ifdef CONFIG_SPL_BUILD > >>> -> bind protocol@14 to rk3588 securecru driver -> read/write securecru regs > >>> #else > >>> -> bind protocol@14 to scmi clk driver -> send SCMI message > >>> #endif > >> > >> This looks right, just that we would have to bring a lot of bloat to SPL > >> , firmware subsystem and things we may not want. > > > > I don't see why this would bring in a lot of bloat into SPL. The SPL > > device tree will grow a little bit since it will have to include the > > scmi nodes. And a little bit of additional code in the rk3588 clock > > driver. Navigating the Kconfig stuff is a bit hard, but I don't think > > this needs to pull in the firmware subsystem in SPL. > > When I tried this, I noticed that only the scmi agents look inside the > subnodes (e.g. protocol@14) which do not have a compatible, and then > they bind the subnodes to a driver found by a hardcoded search for > 'scmi_clock'. > So, to get there, an agent is required, and firmware node, probed > firmware, probed 'scmi clock' . Then, probing it requires additional > things, because the agent wants a shared memory 'shmem' node, and you > end up also probing a SRAM area, allocating it to the space... that's > what I mean when I say that there might be much more bloat added than > just an additional clock set/get for securecru clocks. No, Jonas added code to find the clock protocol node and bind the clock driver to it: https://github.com/Kwiboo/u-boot-rockchip/blob/3209167d7a518291f912964186ee90f10b555084/drivers/clk/rockchip/clk_rk3588.c#L1953 > >>> Naming and placement of the SPL securecru driver could be improved. > >>> Not sure if any other soc beside rk3588 will need this at this moment. > >> > >> securecru sounds better for me, I don't think we can have a scmi clock > >> fake driver like in vendor uboot, it has nothing 'scmi' about it. > >> > >>>> Meanwhile, I will test your patches to see how they work on my setup, I > >>>> also have some things in progress including pinctrl in SPL for the rock5b. > >>>> Thanks for your detailed description, > >>> > >>> Thanks for the hint at pinctrl, I made some updates to [5] and could verify > >>> that sdmmc works when booting from emmc thanks to your pinctrl commit. > >>> Also enabled SPI NOR and eMMC for rock5b in [6], and could do a sf probe > >>> and build a spi firmware image. > >>> > >>> There is an issue with non-DMA access in sdhci that requires the HACK commit > >>> for proper loading of atf, was hoping to disable SDMA in SPL like what is done > >>> using fifo-mode for sdmmc. But only first sector is read successfully then it > >>> fails, see below. Will take a closer look before I post eMMC series. > >> > >> In your patches, I see this : > >> https://github.com/Kwiboo/u-boot-rockchip/blob/rk35xx-fixes/arch/arm/dts/rk3588s-u-boot.dtsi#L61 > >> Perhaps the fifo-mode is intended for the sdhci(emmc) and not for > >> sdmmc(sd-card) ? My understanding was that sdhci cannot do DMA to SRAM, > >> but the sdmmc can ? > >> one possible workaround is to have DMA to DRAM and then relocate it to > >> SRAM using the CPU. Having DMA disabled for the whole IP may have > >> downsides, but this is U-boot, we don't expect to have anything else to > >> do with the CPU while the DMA master works its magic, and the CPU should > >> be faster. > >> > >> I tested your patches together with the series I sent now > >> ( https://marc.info/?l=u-boot&m=167871206530072&w=2 ) and it appears to > >> boot correctly from SD-Card > >> Once you send them to the ML I can retest them. > >> Thanks ! > >> > >>> > >>> Trying to boot from MMC2 > >>> 1 > >>> - 0 'mmc@fe2c0000' > >>> - 1 'mmc@fe2e0000' > >>> - found > >>> blk_find_device: uclass_id=67, devnum=1: mmc@fe2c0000.blk, 67, 0 > >>> blk_find_device: uclass_id=67, devnum=1: mmc@fe2e0000.blk, 67, 1 > >>> clock is disabled (0Hz) > >>> clock is enabled (400000Hz) > >>> clk_set_rate(clk=5000d8, rate=400000) > >>> size=200, ptr=3b8, limit=100000: 5001b8 > >>> clock is enabled (25000000Hz) > >>> clk_set_rate(clk=5000d8, rate=25000000) > >>> clk_set_rate(clk=5000d8, rate=25000000) > >>> clock is enabled (52000000Hz) > >>> clk_set_rate(clk=5000d8, rate=52000000) > >>> spl: mmc boot mode: raw > >>> blk_find_device: uclass_id=67, devnum=1: mmc@fe2c0000.blk, 67, 0 > >>> blk_find_device: uclass_id=67, devnum=1: mmc@fe2e0000.blk, 67, 1 > >>> hdr read sector 4000, count=1 > >>> Found FIT > >>> size=a00, ptr=dc0, limit=100000: aligned to 5003c0 > >>> blk_find_device: uclass_id=67, devnum=1: mmc@fe2c0000.blk, 67, 0 > >>> blk_find_device: uclass_id=67, devnum=1: mmc@fe2e0000.blk, 67, 1 > >>> fit read sector 4000, sectors=5, dst=5003c0, count=0, size=0xa00 > >>> mmc_load_image_raw_sector: mmc block read error > >>> spl: mmc boot mode: fs > >>> Trying to boot from MMC1 > >>> > >>> [6] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3588-emmc > >>> > >>> Regards, > >>> Jonas > >>> > >>> > >>>> Eugen > >>>> > >>>>> > >>>>> Regards, > >>>>> Jonas > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Eugen > >>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> Jonas > >>>>>>> > >>>>>>>> > >>>>>>>> [3] https://github.com/edgeble/u-boot/commit/1389822228ac3dfe8d3cd3513db6a32a5c898b7f > >>>>>>>> > >>>>>>>> Jagan. > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >> > >