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 39448C433FE for ; Thu, 29 Sep 2022 20:08:28 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7C1F584CCB; Thu, 29 Sep 2022 22:08:26 +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="WybNUse3"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 26BFD84CB9; Thu, 29 Sep 2022 22:07:42 +0200 (CEST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 911BC84CA9 for ; Thu, 29 Sep 2022 22:07:38 +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-x834.google.com with SMTP id y2so1482343qtv.5 for ; Thu, 29 Sep 2022 13:07:38 -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=1l9xdNgz6Pqv3T3suMw+0Ah2+Id721oTr58vAe189Io=; b=WybNUse32HeSzBEDa3s7LkxZg1vUlsBBHkDWe+jw9OmtvauoiXzFFQ5AO9a+kFxj6U G6jHERPcGv+5Mi9o8Qh21fUhL/TyOGoktfvHQtU+c7MB0zo9VAUlB8oyCsl34IojidLx eBiD/HcNvNsL2ZO5jMO6j2iSRxQM2f/LaTVhg= 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=1l9xdNgz6Pqv3T3suMw+0Ah2+Id721oTr58vAe189Io=; b=pN23s8KxF/FlNMFvA9frzPnbfngHik9XSBSxzVeUzhgpiYTSoqNg4ALa1VroUxA0sp yPGtq3VKEHObaTgBm/QXCbCs2kIo44dzwvlOM2Sj1Q4bjYAxWx1OX1WHywP1M0QzG1Me ceOrbT0ih/V7PXcIvoisWIDK9XQSdGJwWU72DoGKbmZWKRIlEnr0G+pqqJQUbp2e0FVi B1nceKsHOJI4JdgUjUbq9zJFOTEZzRaI188rUCWu84Srfb5GKuGQy6sWKu1hAQawnGMj z7pBWOu/MwPNakdidsxtHoBFKQGWGG5lAsYPC/O2sdZGS85YJDrKE/EQxHueeBn9L3dI 40KA== X-Gm-Message-State: ACrzQf3VEyyQPDc+39L174Jqqq3mu9RvMM/O1iAhqoWgwKM9Zz3NJCW7 zNQS7AedudLZrLSK8z4pGTJIJqDtFWn/nlD3 X-Google-Smtp-Source: AMsMyM7d95+zXCK7WFrwMjHCOUB+3pxNC/ZH6hV4GSqY8dmds+GLfnSxTxZfVen2BuGATWrrAvwAaQ== X-Received: by 2002:ac8:5f46:0:b0:35b:b279:1d76 with SMTP id y6-20020ac85f46000000b0035bb2791d76mr4065377qta.98.1664482058173; Thu, 29 Sep 2022 13:07:38 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b00-6400-0186-ea3a-a82b-3964.res6.spectrum.com. [2603:6081:7b00:6400:186:ea3a:a82b:3964]) by smtp.gmail.com with ESMTPSA id k6-20020ac86046000000b0035ba3cae6basm122101qtm.34.2022.09.29.13.07.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Sep 2022 13:07:37 -0700 (PDT) Date: Thu, 29 Sep 2022 16:07:35 -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: <20220929200735.GL3044094@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="9nLP/ACA6Hz7sAOz" 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 --9nLP/ACA6Hz7sAOz 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. >=20 > Signed-off-by: Andre Przywara > Tested-by: Peter Hoyes Applied to u-boot/master, thanks! --=20 Tom --9nLP/ACA6Hz7sAOz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmM1+wcACgkQFHw5/5Y0 tyz2hQwAhygt0ZKltw/YUMkY0Ws+l2rVsn1R2NjYgym8UbOnLmAbGni38xZxkill 73fQ5HvIsfzxzGGl2kKbsyIWrnqRY8lxuu339hyGV63jNlpzAGz7nNKgI5ixi0Fv jPgF/Lm9tjGJokdlDlv4Gx9f6/q0BjBuYm5DnwUBjOO/wheVa4Q7SIslhuxSiOmN XMUsrcPQTjggHWlZRIrfEUeYiAUkI3muluQwP6JHPMsmIPmtCIy7RNv8sC58Fi2x 8Gv2xj0DMCGGsvDjbN4PwMFIvC1tmIyAWwGovAQjb5X/9S9/cVv3zrJqDxhjqYo/ 0mSipXI7e7PRvU7/NTgoFV4rsgRYoeYy2ArThIVmqWdcJzubpfEzdf34eXjaoe6+ d1V6zuhR/26j9gZZKhzqGmtLoLerWbzaUnh79G0c/8xorAwWBUjVSpyU42D1iQZ/ F058rcwevPN9dkOUnIaKyZQ/qiB6TroI3aA/Af4zrvq8Ne6QIwVf9POxSgQI1xqp 5vU38cz6 =bbKC -----END PGP SIGNATURE----- --9nLP/ACA6Hz7sAOz--