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 55A1CC433F5 for ; Thu, 19 May 2022 18:01:48 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8960883B25; Thu, 19 May 2022 20:01:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org 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=linaro.org header.i=@linaro.org header.b="zNwnD8HG"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E8EEC83C7B; Thu, 19 May 2022 20:01:43 +0200 (CEST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 77B55839CC for ; Thu, 19 May 2022 20:01:39 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=lee.jones@linaro.org Received: by mail-wm1-x32f.google.com with SMTP id bd25-20020a05600c1f1900b0039485220e16so4116222wmb.0 for ; Thu, 19 May 2022 11:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=fVe3M9tqslwY4x7NOY++ZuqXi/JwODP0AzP24EXTsFU=; b=zNwnD8HGEX4dMW2o83rvLTn7AoZEcx1sSR4p4yjn9QVAK5h1dVtGWZVEiPqgsMQ4fC FR4vTxK/gTLl2/te9WksEJEGLkn2bq1r/T4Oxf29++6M/sWEy0SEK+b2zg+gpI4A+iHo +EmeaSR60xdrt/FxX0ojmalJ1HRHJDT/MJMybnUKbzff1PaXXg7T4mMY0M9Ot9pkqXdA 6uQIX8VO6xni9jWjHMjkzgsgvi+HusgSv1QCTCiH0DhzpXeUbM8LlnEdwPZycqwjNKxp zOiVH0jPUBWHMqU9wcUWK3DHvkT70gubrsWDtyNATfaeNj2C/ucpTbc1s+0aDcagdguf 7GeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=fVe3M9tqslwY4x7NOY++ZuqXi/JwODP0AzP24EXTsFU=; b=GPBrRObEOWV96DoEU6c0MmQMfiAT6bQkUCJ97LC9bzljYt0G/s/lvLBAhb1dqDfbEv rluE4b+w2ZC4ZYzJdleJT8R3AxXBXkVUeFmFSqunnaohYFc+iS4SXpc8dLtYyd6a6DQH XydYwNSaYMBCwIAx+ann4twNNasqu2XNVNS4rqCSHGH4DrddfbJ36SQyZDS0YiiPv9OU DWFzmj8v6LxG0FpKtPj45cw7M3wdp3Qz2x56W0WanOnovBhAvX0B59AV7fM6xa7rRTaX 5jLdgiBOlstl/Gh/4xebbajluYnLEYtGT8RJWGMmn+mNfESlRb5qywPgH9fwUBnzfKU5 4wQQ== X-Gm-Message-State: AOAM533yH+e0kc+LYrdd7jzRD9iSGCw9FBuin/GQabB7MWSCPf8fXTMm sLeja9lw0rt0zpHTqj2BtzkwjQ== X-Google-Smtp-Source: ABdhPJw8cfkp+TT1jQnbGLtDqbmyP7lf64imV8URHllNUeLqCnBGznJ1wWVEYzCwsc27qviUHiMqbw== X-Received: by 2002:a05:600c:35c1:b0:394:8621:a1d5 with SMTP id r1-20020a05600c35c100b003948621a1d5mr5370463wmq.196.1652983298729; Thu, 19 May 2022 11:01:38 -0700 (PDT) Received: from google.com (cpc155339-bagu17-2-0-cust87.1-3.cable.virginm.net. [86.27.177.88]) by smtp.gmail.com with ESMTPSA id i24-20020adfa518000000b0020e5d8dbbb8sm223537wrb.56.2022.05.19.11.01.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 May 2022 11:01:38 -0700 (PDT) Date: Thu, 19 May 2022 19:01:36 +0100 From: Lee Jones To: Peter Geis Cc: Hugh Cole-Baker , U-Boot Mailing List , Caesar Wang , Vasily Khoruzhick , Kever Yang , Heiko Stuebner , Elaine Zhang , Brian Norris , "open list:ARM/Rockchip SoC..." , arm-mail-list Subject: Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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.5 at phobos.denx.de X-Virus-Status: Clean On Thu, 19 May 2022, Peter Geis wrote: > On Thu, May 19, 2022 at 1:36 PM Peter Geis wrote: > > > > On Thu, May 19, 2022 at 1:23 PM Lee Jones wrote: > > > > > > On Thu, 19 May 2022, Lee Jones wrote: > > > > > > > On Thu, 19 May 2022, Peter Geis wrote: > > > > > > > > > On Thu, May 19, 2022 at 11:47 AM Lee Jones wrote: > > > > > > > > > > > > On Thu, 19 May 2022, Lee Jones wrote: > > > > > > > > > > > > > On Thu, 19 May 2022, Peter Geis wrote: > > > > > > > > > > > > > > > On Thu, May 19, 2022 at 10:56 AM Lee Jones wrote: > > > > > > > > > > > > > > > > > > > > > > It's not clear how this issue (present 3 years ago) was finally > > > > > > > > > > > > > resolved. From the thread, it looks as if the fix might have made its > > > > > > > > > > > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform > > > > > > > > > > > > > (yet). > > > > > > > > > > > > > > > > > > > > > > > > The rk3399 SoC has a hardware bug where the power domains are not > > > > > > > > > > > > reset upon a soft reset. This leads to situations like this one where > > > > > > > > > > > > power domains are shut down during shutdown but aren't restored on > > > > > > > > > > > > reboot. > > > > > > > > > > > > > > > > > > > > > > I assume this isn't something we can patch in the kernel driver? > > > > > > > > > > > > > > > > > > > > As far as I know it's being worked on by others, I have some ideas for > > > > > > > > > > this as well but I've been focused on rk356x lately. > > > > > > > > > > > > > > > > > > Thanks for the update. > > > > > > > > > > > > > > > > > > > > > Mainline TF-A was patched to force all power domains online > > > > > > > > > > > > when a soft reboot is triggered, which solved that issue. > > > > > > > > > > > > > > > > > > > > > > Okay, this is what I figured. > > > > > > > > > > > > > > > > > > > > > > > What particular issues are you having initializing modern u-boot on > > > > > > > > > > > > this device? > > > > > > > > > > > > > > > > > > > > > > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/ > > > > > > > > > > > > > > > > > > > > > > Speaking with one of the guys who supports RockPi 4 in AOSP, he > > > > > > > > > > > suspects the DDR settings. Apparently settings for older SoCs > > > > > > > > > > > sometimes get clobbered when support for newer SoCs is added. > > > > > > > > > > > > > > > > > > > > The rk3399 TPL code is specific to the rk3399 and it really hasn't > > > > > > > > > > been touched much recently. I'm using the latest Mainline U-Boot on > > > > > > > > > > both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded, > > > > > > > > > > which should happen between: > > > > > > > > > > > > > > > > > > > > Trying to boot from BOOTROM > > > > > > > > > > Returning to boot ROM... > > > > > > > > > > > > > > > > > > > > Otherwise it just looks like the TPL code doesn't like being in a > > > > > > > > > > single channel configuration. Does the 2GB model just forgo the second > > > > > > > > > > ram chip? Or is this actually a 4GB model and it isn't detecting the > > > > > > > > > > second chip in both downstream and mainline? Could you include the > > > > > > > > > > TPL/SPL portion of downstream's output? > > > > > > > > > > > > > > > > > > TPL/SPL are mostly silent on the downstream build: > > > > > > > > > > > > > > > > > > https://pastebin.ubuntu.com/p/m2bBdjF8Wq/ > > > > > > > > > > > > > > > > > > Not sure if it helps at all, but ArmBian is pretty noisy: > > > > > > > > > > > > > > > > > > https://pastebin.ubuntu.com/p/fdPjmmqBDM/ > > > > > > > > > > > > > > > > Weird that downstream and mainline are being built with none of the > > > > > > > > debug stuff enabled. Armbian clearly shows the initial setup occuring > > > > > > > > correctly, and that it's a 4GB board. It's using both the Rockchip > > > > > > > > miniloader with a Rockchip TF-A blob as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am yet to investigate the u-boot story in any detail. > > > > > > > > > > > > > > > > > > > > > > It's on my TODO list for today. > > > > > > > > > > > > > > > > > > > > > > > Is there a particular reason it isn't using Mainline TF-A? > > > > > > > > > > > > > > > > > > > > > > We're not using Trusted Firmware yet. > > > > > > > > > > > > > > > > > > > > This platform does not work at all without TF-A. Optee is optional. > > > > > > > > > > Either you are using the downstream blob from Rockchip or Mainline > > > > > > > > > > built yourself. Personally I prefer using Mainline everything. If you > > > > > > > > > > build Mainline U-Boot without TF-A it will throw a warning at the end > > > > > > > > > > that says the created binary is non-functional. > > > > > > > > > > > > > > > > > > Right. Played a lot with this today. > > > > > > > > > > > > > > > > > > Our build was using TF-A which was built-in to the primary loader. > > > > > > > > > > > > > > > > > > I had 2 interesting results today. No idea how to explain them. > > > > > > > > > > > > > > > > > > First one was with Mainline u-boot and Mainline TF-A, which found, but > > > > > > > > > was seemingly unable to boot the kernel: > > > > > > > > > > > > > > > > > > https://pastebin.ubuntu.com/p/9HRhPyfjYK/ > > > > > > > > > > > > > > > > > > The second interesting result I had was using our downstream u-boot > > > > > > > > > with Mainline TF-A. It booted perfectly from cold, but managed to get > > > > > > > > > stuck in the TPL on soft reboot in a very similar way to the one I > > > > > > > > > reported earlier when not booting with TF-A ("Channel 1: col error"): > > > > > > > > > > > > > > > > > > > > > > > > Mainline TF-A defaults to 115200 for its uart messages, so you need to > > > > > > > > either A. pass the uart config from U-Boot to TF-A with a platform > > > > > > > > config option (unreliable in my experience), B. change U-Boot to > > > > > > > > 115200, or C. change TF-A to 1.5M (the path I take). Your mainline > > > > > > > > > > > > > > Hopefully this is enough: > > > > > > > > > > > > > > diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h > > > > > > > index ba83242eb..24ad94ae7 100644 > > > > > > > --- a/plat/rockchip/rk3399/rk3399_def.h > > > > > > > +++ b/plat/rockchip/rk3399/rk3399_def.h > > > > > > > @@ -17,7 +17,8 @@ > > > > > > > /************************************************************************** > > > > > > > * UART related constants > > > > > > > **************************************************************************/ > > > > > > > -#define RK3399_BAUDRATE 115200 > > > > > > > +//#define RK3399_BAUDRATE 115200 > > > > > > > +#define RK3399_BAUDRATE 1500000 > > > > > > > #define RK3399_UART_CLOCK 24000000 > > > > > > > > > > > > > > /****************************************************************************** > > > > > > > > > > Yes, that is sufficient. > > > > > > That's interesting. Would this change result in me now being able to > > > see the console output from this (apparently) failed attempt: > > > > > > https://pastebin.ubuntu.com/p/9HRhPyfjYK/ > > > > > > However the result is the same as the downstream kernel where it > > > fails in the TPL on soft reboot: > > > > > > https://pastebin.ubuntu.com/p/TZBYqTMCnN/ > > > > > > No TF-A messages seen though still. > > > > > > Is it possible that u-boot only runs TF-A on cold boot? Seems odd. > > > > I'm convinced that TF-A is not functional on your mainline config. No, > > TF-A will execute on any reset that triggers SPL, as SPL loads TF-A > > and jumps to it as part of the FIT load. > > > > > > > > What was the extra logging you mentioned before? > > > > This is what my rockpro64 looks like with TF-A executing. Note I've > > enabled a bit of extra TF-A debugging, normally it just prints out the > > TF-A version number. TF-A reports itself as BL31. > > > > U-Boot TPL 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55) > > Channel 0: LPDDR4, 50MHz > > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB > > Channel 1: LPDDR4, 50MHz > > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB > > 256B stride > > lpddr4_set_rate: change freq to 400000000 mhz 0, 1 > > lpddr4_set_rate: change freq to 800000000 mhz 1, 0 > > Trying to boot from BOOTROM > > Returning to boot ROM... > > rockchip_sdram_size ff320308 32c1f2c1 > > rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0 > > rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0 > > SDRAM base=0, size=100000000 > > > > U-Boot SPL 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55 -0500) > > Trying to boot from MMC2 > > NOTICE: BL31: v2.6(release):v2.6-138-g929f064f69d0-dirty > > NOTICE: BL31: Built : 11:27:48, Feb 2 2022 > > INFO: GICv3 with legacy support detected. > > INFO: ARM GICv3 driver initialized in EL3 > > INFO: Maximum SPI INTID supported: 287 > > INFO: plat_rockchip_pmu_init(1710): pd status 3e > > INFO: BL31: Initializing runtime services > > INFO: BL31: Preparing for EL3 exit to normal world > > INFO: Entry point address = 0x200000 > > INFO: SPSR = 0x3c9 > > > > > > U-Boot 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55 -0500) > > > > SoC: Rockchip rk3399 > > Reset cause: POR > > Model: Pine64 RockPro64 v2.1 > > DRAM: rockchip_sdram_size ff320308 32c1f2c1 > > rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0 > > rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0 > > SDRAM base=0, size=100000000 > > 3.9 GiB > > PMIC: RK808 > > Core: 292 devices, 29 uclasses, devicetree: separate > > MMC: mmc@fe310000: 3, mmc@fe320000: 1, mmc@fe330000: 0 > > Loading Environment from SPIFlash... SF: Detected gd25q128 with page > > size 256 Bytes, erase size 4 KiB, total 16 MiB > > *** Warning - bad CRC, using default environment > > > > I'm currently pulling the rk3399-rock-pi-4b.dts that's in mainline > > linux to build a quick image for you, if you're interested. Yes, very interested, thank you. > I see that mainline U-Boot has support already for this device. So I'm > building a debug image for you with that. Yes, that's what I'm using. Just the default config with BL31 exported. BL31=/rockpi/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf -- Lee Jones [李琼斯] Principal Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog