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 480B7C6FD1F for ; Sun, 12 Mar 2023 22:34:51 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id ECB1785480; Sun, 12 Mar 2023 23:34:48 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=kwiboo.se 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; unprotected) header.d=kwiboo.se header.i=@kwiboo.se header.b="kIzm3OPZ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7FF4B85841; Sun, 12 Mar 2023 23:34:46 +0100 (CET) Received: from wrqvtzvf.outbound-mail.sendgrid.net (wrqvtzvf.outbound-mail.sendgrid.net [149.72.126.143]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 9315683623 for ; Sun, 12 Mar 2023 23:34:42 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=kwiboo.se Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=bounces+31435339-7456-u-boot=lists.denx.de@em2124.kwiboo.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kwiboo.se; h=mime-version:subject:references:from:in-reply-to:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=wueRoKyaJZXJ4+iuRhLuM6wAZ2L0rSW7ALyqN9NwwV0=; b=kIzm3OPZcpi/0O02mPG1LGuo2UbOpcZHLBlRLL5s2sCn8/yODmoYYwKhr6lq/WVOMvme FvYAyWHXgCHfUG+KBfNzYN7h0S0tVQhmTOiFBrON2Cvx1VZ9W/ZbrPeTwYUbvJZYglMs+A HKdsOG1sAu+8MLBT98H0FhnEc5BV95SfmYhPqpheYq6hmUSePwc4m7SZSs3w7q6ga7pkXF fwgfKQlimjTidfvwxBnllEqDRruLwwdJmtsAhyR+D7Lljm4XdiHyzfiUNwJ+jHI0PlCTDj xltl+qmzELNLKJR06YykyIp/1pl4H4WZuz0cAobWDuXDoj/yYnrjSIM511hUrabA== Received: by filterdrecv-59cb65cf6d-ggn5h with SMTP id filterdrecv-59cb65cf6d-ggn5h-1-640E5380-1C 2023-03-12 22:34:40.717821365 +0000 UTC m=+1638081.746220067 Received: from [192.168.1.50] (unknown) by geopod-ismtpd-10 (SG) with ESMTP id TUy4NyPxT8WrrgkTDu24Kw Sun, 12 Mar 2023 22:34:40.345 +0000 (UTC) Message-ID: Date: Sun, 12 Mar 2023 22:34:40 +0000 (UTC) MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: [RFC PATCH 00/16] arm: Add Rockchip RK3588 support References: <20230125222741.303259-1-jagan@edgeble.ai> <2efd56b6-4dc9-cd77-3792-e60142faa6ae@kwiboo.se> <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> Content-Language: en-US From: Jonas Karlman In-Reply-To: <8e806457-0220-443a-84e4-33cadf968c4f@collabora.com> X-SG-EID: =?us-ascii?Q?TdbjyGynYnRZWhH+7lKUQJL+ZxmxpowvO2O9SQF5CwCVrYgcwUXgU5DKUU3QxA?= =?us-ascii?Q?fZekEeQsTe+RrMu3cja6a0h2FNGwbTD7zrb1pZN?= =?us-ascii?Q?c5=2Flplfowv3TcUdgRWrgX6fcDZr2mS4Szuekbgv?= =?us-ascii?Q?+te6Z8scAzcivny04PRdIyfaXcRHNecMqmMJPIE?= =?us-ascii?Q?mRzNBWd+Xw3Bflv0mIV6QuFg8Mti82ykDjc157h?= =?us-ascii?Q?J6HeBCQUTwqFT2RpuZcgt=2FBNSeozLlJ1Ey1XZT?= To: Eugen Hristev , Jagan Teki Cc: Simon Glass , Kever Yang , Philipp Tomsich , "fatorangecat@189.cn" , "u-boot@lists.denx.de" X-Entity-ID: P7KYpSJvGCELWjBME/J5tg== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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 Regards, Jonas > > Thanks, > Eugen > >> >> Regards, >> Jonas >> >>> >>> [3] https://github.com/edgeble/u-boot/commit/1389822228ac3dfe8d3cd3513db6a32a5c898b7f >>>> >>> Jagan. >> >