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 6043EC433F5 for ; Thu, 19 May 2022 14:56:52 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 835FA80F7B; Thu, 19 May 2022 16:56:49 +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="aRFLYF8i"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id CA85880FC8; Thu, 19 May 2022 16:56:47 +0200 (CEST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 70B6E80F52 for ; Thu, 19 May 2022 16:56:44 +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-wr1-x429.google.com with SMTP id j25so7527904wrc.9 for ; Thu, 19 May 2022 07:56:44 -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=ISOD/iOKAclCtwdMM3vHb2RLq5kMYU15+WUUo5PmRkY=; b=aRFLYF8im2UJauIw+M3XDEaVIqu4s+D3bM8F+kuxdKMYALzDjrjz5c3q9mHyung5Z4 4vqJinDiLzxL9HhDCabldxtFGZmov7ScXe1epX9h/+fszrIihrvEofasO9PALsx9eL+N rqZPk4UTCtgFI477afLdCgOxXjTUfCzUGRaUWKUJKKnHQQpYGD30g6ZI4DLD6YNHdWh1 stZxx3MyzpJkvcSAF6HAXaymLOVtdryp/a4/6deK+gSyQ+bi1yZvAWMRNHSz9dDOlfk6 +SvXvYUPG+iDCKprIyhSASPCLqWW+gL8NnhKe4jQRLE1F9S+mlBote7xQCcQ/KSfn1vj LS9A== 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=ISOD/iOKAclCtwdMM3vHb2RLq5kMYU15+WUUo5PmRkY=; b=C7WbhQ0yYcHy8TqyuHmhOFU7pHtACcxH6SbfbyFo3DVYeD9BPzqOgzkCRQCb0iz8bm +e64EMK5omxajPxRLtoApeCFr9W+UcmX+s65CMen+uelGEwOidUIf6qdiOTHqmOuT37R puuxWEy5YWu0wzfprpCSboUcf5qqM+QeSzo48D0UUevLJ67brY3b+4+hJuOMMjVLeEwW wrqwCkwbNTAc3ZqOM0B9iEAX20AumoX+i9uh0dLL7WJY0AQf2bc5n/y31SxnAUsQOmed tcRZLuqyLM6TmKt+Y7c0Irp4hI7zWt/cegow2RQ9NGyjsI/xjpOgx88OFQiHuFCslWCm IyEw== X-Gm-Message-State: AOAM531OI3vjvN8yHvPWtdJLkFqffG2FR0qhLWK8aPPVtUD3YAKhxScQ AkeHSWT0zJyWCyJe4X9pBi7okA== X-Google-Smtp-Source: ABdhPJzMhUAdMlupNmGxdoHnWFBGW1dFlprM8B+x4BKJigotU1z6k2KLJ8TJhtJ4mxW2IKsvoWEXOg== X-Received: by 2002:adf:eec9:0:b0:20d:5f7:f54a with SMTP id a9-20020adfeec9000000b0020d05f7f54amr4384973wrp.714.1652972203824; Thu, 19 May 2022 07:56:43 -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 r2-20020adfa142000000b0020d0c37b350sm6216175wrr.27.2022.05.19.07.56.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 May 2022 07:56:43 -0700 (PDT) Date: Thu, 19 May 2022 15:56:41 +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: <20191128061433.1952869-2-anarsoul@gmail.com> <1ab40490-a232-b5fd-6180-17867aa6a053@rock-chips.com> <6C83A835-37D3-4E48-BB08-024BB2703FB8@gmail.com> 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 > > > > 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/ > > 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"): https://pastebin.ubuntu.com/p/hwmBzxDBgc/ Thanks again for your insight. Kind regards, Lee -- Lee Jones [李琼斯] Principal Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog