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 AE9DCC6FA82 for ; Wed, 21 Sep 2022 17:56:55 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3AD3D84C9D; Wed, 21 Sep 2022 19:56:53 +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="dhe/394g"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 875FA84C9F; Wed, 21 Sep 2022 19:56:51 +0200 (CEST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 E54DF84BD0 for ; Wed, 21 Sep 2022 19:56:48 +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-qk1-x72c.google.com with SMTP id q11so4508479qkc.12 for ; Wed, 21 Sep 2022 10:56:48 -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=uYCtFyRhak+yoRm/9J21qLvdHy6uVxOzkQ4oOtrrz58=; b=dhe/394gh45skFX6hqyZtHKo9Ci/bnUHNcmfc4ytAOKmIZkM68XGxIJv/aa/J7pCre N07RW8yO5TN50DljACrDTQORxtgLS5zOvEnQ77aSRYYyxOMY/pbslct31HtcqGEYG2u4 frNTrjJQ3e9h3YXuAPIR8NoNfp6M9S79ir91Y= 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=uYCtFyRhak+yoRm/9J21qLvdHy6uVxOzkQ4oOtrrz58=; b=fYvpJ7OhF8+vRToUQTuSqNA1ATUV41PHzbVU0PHyFZLTfUhpJuIzET7mzmXQuGGLZO g4jkpxHM7jaN4hC0H+HYD67D8T46ncahQvPa4oF6xYlorufYPwlShEVzlev7UeOiTCRH vRM1LmOCJJndgh8UYljr6UvSXtx8gjIJqqXLO7thpyaKmoOGRVp9Z8McFUV77qbEALzQ BT2wSX08jr13L/FWVSTU/ecMR6CEK+W5WTFAov8YC9Uvg6R8czkXzJW9YLciDPDGIti1 4cgW47OYWo8xlbFJczi9Hq6XUR9SKf46pKL7TEBBa1nVfBg0KrdcqcWM+SUkrHKr3PcD aFoQ== X-Gm-Message-State: ACrzQf3Ry+Eatbx8qdvA74GnD8xV1zmSHoN8tLdKgmpiNY7yM+7qGqPC ayCRM6dgun9+1OpeLlFnKPm+iw== X-Google-Smtp-Source: AMsMyM7J7TZ1cSLZB7bC7/zU0xwLaN8PlkWJtqEB+wQCYr8hG5sqFBk8NoRT7by5TClYSFcWeL+sMA== X-Received: by 2002:a05:620a:2989:b0:6ce:1360:33b4 with SMTP id r9-20020a05620a298900b006ce136033b4mr21191556qkp.755.1663783007380; Wed, 21 Sep 2022 10:56:47 -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 u15-20020a05620a0c4f00b006cf19068261sm2372467qki.116.2022.09.21.10.56.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Sep 2022 10:56:46 -0700 (PDT) Date: Wed, 21 Sep 2022 13:56:44 -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: <20220921175644.GW3044094@bill-the-cat> References: <20220921170946.1363372-1-andre.przywara@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gMqNd2jlyJQcupG/" Content-Disposition: inline In-Reply-To: <20220921170946.1363372-1-andre.przywara@arm.com> 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 --gMqNd2jlyJQcupG/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 payload > (BL33), and there apparently was some long-standing ad-hoc boot protocol > 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 defined > 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. 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 Tom --gMqNd2jlyJQcupG/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmMrUFkACgkQFHw5/5Y0 tywAZwv+MklmyFfblOuwygJlYFVE198MlP55/EOciIvQwuTRMMsx+pdI6qCsvB+/ pt3hlFRVHTZLEQowD4kozrXmjs+zhv4cj4dSkwWLgZcOjsrg2hi3tdn3jV4y5u/X rMrOqgj+cfFJ++vnofzc7CMiePGIwuil9GNBer7g+UKkf1sHRElD2qASFlPOI+Ea EJsQMoCX0yZtzm8imGFI5tDcY3b+6Q4DFMFjxeHmryLQ+QQh6VhfWqO9sHKM629v zNAFdlf4YRPGnKo2hVwpm05RosybzHX0qfIvJpRRxqBFM1CsEiARH0ENG/bxco6h MshXumoaYB8vju0B0g0lOtk29SBEyWJwFkAQJlRJWwNiOKCwSkowtT7cDMnw+h4z jgcRyrKg6Vl4aBbWEJeworwdsbcdNB0TW5YJEM/kI4nRzatB3DBdDX7EF1BFlDV1 xCBiZkEWMZkVM0CfNpEsuKIEw+uzxRzgpiPcsW4lz76OaTCCLUUgR94xuFuYPFd8 7D03lhlW =QiSG -----END PGP SIGNATURE----- --gMqNd2jlyJQcupG/--