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 BCC68ECAAD8 for ; Thu, 22 Sep 2022 00:22:52 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 79FFF84A28; Thu, 22 Sep 2022 02:22:50 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="hMbOGAhJ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 5A5B6848CF; Thu, 22 Sep 2022 02:22:49 +0200 (CEST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 C1FDC840FB for ; Thu, 22 Sep 2022 02:22:46 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x829.google.com with SMTP id y2so5300287qtv.5 for ; Wed, 21 Sep 2022 17:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=1mNTYtphE/0nH/yySSwgGSI8xGEgBl1r69r9HL8Hq0M=; b=hMbOGAhJ4jXyLIAWFo5QQ1Uu/yPYyh6GRUhKc/m3QZ2s7+ZZ6O7EAC6yonW20FmSb8 fVLTKyiZOuqooKAaZXDMXCw067AAtD8ka6HmmVdCn0LTR6N+N3x8jcfgb5RYLuXVCSp+ fKsZzst8POnEztq2Z3bF8X5glQvbu9+k24Ro4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=1mNTYtphE/0nH/yySSwgGSI8xGEgBl1r69r9HL8Hq0M=; b=u0CDpPRVOgnvLB2/hF/dK18wE3bKHOPfLmbyzJiFEM3Whh0Zmu3/g2A6VUIBFVDAhI Pw8VlEaNRSn+t2M/dpZZQwyqdc5HFhZhUuY3yTh4TXGaJAyPb9Jbrju7qAwGTSM7Rd7s hsySjEfOH9K9Tj7kFtOyrh7PVG3DFKjGK+b3AOz0AIs5X9giBLmtt/ZRJf+0J7COUaWr Nly8vAXtSfgVQ8l9f1S6/cttsrK2Z8Ytdbv3tCMSO22c8FBurGkc3IaW/ofNo5NBjDA4 tbwefxLFHly2EEKuFmL3Hlr/CSmKanZPFvaF//kIudjZYbh1YGs8h42Ed2jFAwSU2UL2 sUSg== X-Gm-Message-State: ACrzQf2+Pz+mAUxirzaOCOWIUz1MVmbpIljl5Mb4dMNPqOdFgMyZDj7W I5E87tj/0c2BCVklBf3q/cAwpw== X-Google-Smtp-Source: AMsMyM6zhh+IhfSI8yzkTH0OFQxFNoniRJaHUswhliDh4pCHlweSAb1cBsWaZO1xf/S7NdIbSx1qTg== X-Received: by 2002:a05:622a:14c9:b0:35b:b744:a7c8 with SMTP id u9-20020a05622a14c900b0035bb744a7c8mr847667qtx.570.1663806165410; Wed, 21 Sep 2022 17:22:45 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b00-6400-7442-0e7b-49ca-6995.res6.spectrum.com. [2603:6081:7b00:6400:7442:e7b:49ca:6995]) by smtp.gmail.com with ESMTPSA id h11-20020a05620a284b00b006bbc3724affsm2792236qkp.45.2022.09.21.17.22.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Sep 2022 17:22:44 -0700 (PDT) Date: Wed, 21 Sep 2022 20:22:42 -0400 From: Tom Rini To: Andre Przywara Cc: David Feng , Simon Glass , Liviu Dudau , Linus Walleij , Ross Burton , Peter Hoyes , u-boot@lists.denx.de Subject: Re: [PATCH] vexpress64: also consider DTB pointer in x1 Message-ID: <20220922002242.GZ3044094@bill-the-cat> References: <20220921170946.1363372-1-andre.przywara@arm.com> <20220921175644.GW3044094@bill-the-cat> <20220922010225.03b4bc8a@slackpad.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="o/5eNASeIIpuMggS" Content-Disposition: inline In-Reply-To: <20220922010225.03b4bc8a@slackpad.lan> X-Clacks-Overhead: GNU Terry Pratchett 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.6 at phobos.denx.de X-Virus-Status: Clean --o/5eNASeIIpuMggS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 22, 2022 at 01:03:04AM +0100, Andre Przywara wrote: > On Wed, 21 Sep 2022 13:56:44 -0400 > Tom Rini wrote: >=20 > Hi Tom, >=20 > > On Wed, Sep 21, 2022 at 06:09:46PM +0100, Andre Przywara wrote: > > > Commit c0fce929564f("vexpress64: fvp: enable OF_CONTROL") added code = to > > > consider a potential DTB address being passed in the x0 register, or > > > revert to the built-in DTB otherwise. > > > The former case was used when using the boot-wrapper, to which we sell > > > U-Boot as a Linux kernel. The latter was meant for TF-A, for which we > > > couldn't find an easy way to use the DTB it uses itself. We have some > > > quirk to filter for a valid DTB, as TF-A happens to pass a pointer to > > > some special devicetree blob in x0 as well. > > >=20 > > > Now the TF-A case is broken, when enabling proper emulation of secure > > > memory (-C bp.secure_memory=3D1). TF-A carves out some memory at the = top > > > of the first DRAM bank for its own purposes, and configures the > > > TrustZone DRAM controller to make this region secure-only. U-Boot will > > > then hang when it tries to relocate itself exactly to the end of DRAM. > > > TF-A announces this by carving out that region of the /memory node, in > > > the DT it passes on to BL33 in x1, but we miss that so far. > > >=20 > > > Instead of repeating this carveout in our DT copy, let's try to look = for > > > a DTB at the address x1 points to as well. This will let U-Boot pick = up > > > the DTB provided by TF-A, which has the correct carveout in place, > > > avoiding the hang. > > > While we are at it, make the detection more robust: the length test (= is > > > the DT larger than 256 bytes?) is too fragile, in fact the TF-A port = for > > > a new FVP model already exceeds this. So we test x1 first, consider 0 > > > an invalid address, and also require a /memory node to detect a valid= DTB. > > >=20 > > > And for the records: > > > Some asking around revealed what is really going on with TF-A and that > > > ominous DTB pointer in x0: TF-A expects EDK-2 as its non-secure paylo= ad > > > (BL33), and there apparently was some long-standing ad-hoc boot proto= col > > > defined just between the two: x0 would carry the MPIDR register value= of > > > the boot CPU, and the hardware DTB address would be stored in x1. > > > Now the MPIDR of CPU 0 is typically 0, plus bit 31 set, which is defi= ned > > > as RES1 in the ARMv7 and ARMv8 architectures. This gives 0x80000000, > > > which is the same value as the address of the beginning of DRAM (2GB). > > > And coincidentally TF-A put some DTB structure exactly there, for its > > > own purposes (passing it between stages). So U-Boot was trying to use > > > this DTB, which requires the quirk to check for its validity. =20 > >=20 > > So, follow-up question. Why don't we just always look at x1 and never x0 > > for the DTB? That would seem to be a bugfix and should work on older > > TF-A releases too, yes? >=20 > There is a use case where the boot-wrapper[1] runs U-Boot, as a kind of > poor-man's TF-A replacement. As the boot-wrapper normally just runs > kernels, it follows the arm64 Linux kernel boot protocol, which puts > the DTB address in x0. So to stay flexible, we look at both registers. > The kernel boot protocol says x1 must be 0, so we check for that first, > to sort that out. Ah, thanks! --=20 Tom --o/5eNASeIIpuMggS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmMrqs8ACgkQFHw5/5Y0 tyxQbgv/VRG37jn6O+G75CaybpDB67NquDiznD84vldL+Dq9b2v3z7pqbNRQnEgE gii/9FAiJrbUm85HH1N3imXIEUSJNJvirBZcPKK/s1+ifj+Aktw5rqNru0j2qDc9 k5aGm9iZGtzYZ/o0QEUqLEwHTy2+GLJrukyf4SqB7yuw3NPxeJqT9f5kNEv43Jco DhjUf8uaf56HyTdQsa56j7isuiUKh7Y2v4rmidVTEvJfaL4hP2ZYcgq7QYlwfXs1 oVJfXJ/AyeUxxijF0bjX5YKXymoIgvuJcf0lliSyvg68M6joFT2NTsPail2+9o4y pI71YD9RTtufPOq9vpCA5xMGWamIFyx6g7m1SSBEauZSumZqwfIZBxf1vExnmkTG H6Tdo7xMe5hEUsi018+L25xB7X9X8Edjc+RpI9v/X7dfm6NKI1suYuB1y5GEbyfG n/mj5PeqNocXaKyZOb9bjtLQeX/KO9Rvu/8pxC9sutWHeyD373BGz9CPVMVtyxnU 24Voo4Dx =XgDq -----END PGP SIGNATURE----- --o/5eNASeIIpuMggS--