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 89ABEC64EC4 for ; Wed, 8 Mar 2023 08:57:24 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1E85B85C93; Wed, 8 Mar 2023 09:57:22 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=collabora.com 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=collabora.com header.i=@collabora.com header.b="IC2mJZ8K"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C13EE85CA8; Wed, 8 Mar 2023 09:57:19 +0100 (CET) Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) (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 7DFE785C8A for ; Wed, 8 Mar 2023 09:57:15 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=eugen.hristev@collabora.com Received: from [192.168.0.125] (unknown [82.76.24.202]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: ehristev) by madras.collabora.co.uk (Postfix) with ESMTPSA id 7CE936602FE7; Wed, 8 Mar 2023 08:57:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1678265834; bh=t11H3NNDZgCYfvCr7CnANd8O4T6lGTXXDyxeBwV+wS8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=IC2mJZ8KywVdLbrorQWWlbOrCVLnXi6zXJMiXKzl57gHHPG9iDg9/7rIjQt9hZ1gL 5UZVNX4r8ccmwei4pcdffMQRTcxik8BJ1SNq6Tdpavy4wTFEBAdEKJDHK4JkU2xmYA zQ7bwvXcK7OxhXgQjFXsEuXESr+ALpwP6x0QhqKByyeCwNvTIekDT8pgiXZXeSrcIS fciEHMEvOekHprasXtBtbQJEl6wEtGmYFU3H3thAykWB3l6F/ZAAm8GB9EOpVoVMMz kR7j2riOeAphvEYEAye0Qf8Eqei+fiOI/YGYGN935Uv0fGF9q6qKb89Fw0ZAr712hC Qez8OZ+E/MvtA== Message-ID: <8e806457-0220-443a-84e4-33cadf968c4f@collabora.com> Date: Wed, 8 Mar 2023 10:57:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [RFC PATCH 00/16] arm: Add Rockchip RK3588 support To: Jonas Karlman , Jagan Teki Cc: Simon Glass , Kever Yang , Philipp Tomsich , fatorangecat@189.cn, u-boot@lists.denx.de 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> Content-Language: en-US From: Eugen Hristev In-Reply-To: <6fe7adc8-0b0d-70a1-5f13-d3205ad158ab@kwiboo.se> Content-Type: text/plain; charset=UTF-8; format=flowed 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 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 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 ? Thanks, Eugen > > Regards, > Jonas > >> >> [3] https://github.com/edgeble/u-boot/commit/1389822228ac3dfe8d3cd3513db6a32a5c898b7f >> >> Jagan. >