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 X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A7E1C07E95 for ; Tue, 13 Jul 2021 14:42:05 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id CF23B6115B for ; Tue, 13 Jul 2021 14:42:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF23B6115B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 0540082BD2; Tue, 13 Jul 2021 16:42:03 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (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="pPQEiLjY"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 16AB482CC1; Tue, 13 Jul 2021 16:42:01 +0200 (CEST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 2596A82BBC for ; Tue, 13 Jul 2021 16:41:56 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x82d.google.com with SMTP id g12so16782815qtb.2 for ; Tue, 13 Jul 2021 07:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=netgc8hu7FRVUo3XfH12s90qpk+3Wwqro1wHdEdH4Yk=; b=pPQEiLjYra/c5IDU/Ei8ZQHaT9uG7EYRnhCeV+/Usl+WxwU2DoG5zALhCXhcMX4hye FVHEWoEZMLAlSHS2HKFFbw2GppcO60dNsl1pMLiz8UDlp9pscSSPG/HxLq3Wks+Vizd9 xxbpd+k2SZsmzU5i3QWVz2rmug8Z2QJpwaQ74= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=netgc8hu7FRVUo3XfH12s90qpk+3Wwqro1wHdEdH4Yk=; b=LwIhHK4XXGGeApflRNuwUTR/DtQUyx1n+wwwwSI9f/zKBmkRFtoh5OcMgfBJcZk7Lr vqxUCnomaSsnu4xgcqrw9HgO1pVH7w5A6XJxjZSewIVqxz5pvFnsG4576QlUoRO+pHcN yrORrvEbPIxV7ZMczoY9KVWkGxfO9Cacw2aZed36uvXl1HBDrr2w7JH0dTG3RVIwPElO s2DI396Fr3U+/QvNS6TCT0HvrFsDeuKi3xqcr8CtBQ9g5vkdhj+L5CCxnlpqmyaKKgXt H7EKsnkacLsv+QN7tEj+c2Z4YikybxusTwSqFb8T/7GcrfqTW6lyqcNVHHM3jAjrmJag qzEg== X-Gm-Message-State: AOAM531pwh4oqUtT9qLb69qxWy92oBnCc4cw4BTlfrmrxC8E8WoJym4I FCZ833z/0DQaP5Vdfoa3Deyf9g== X-Google-Smtp-Source: ABdhPJytIJ5vM19L4ojLaWKulvtjova/7JS5iNt49HpZ4qG0Jt7uucqKheUzbb4rnHmTjBdvZUN0mA== X-Received: by 2002:ac8:5657:: with SMTP id 23mr4446066qtt.98.1626187314948; Tue, 13 Jul 2021 07:41:54 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-1c72-8d2e-073a-3455.res6.spectrum.com. [2603:6081:7b01:cbda:1c72:8d2e:73a:3455]) by smtp.gmail.com with ESMTPSA id p64sm8070602qka.114.2021.07.13.07.41.53 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Jul 2021 07:41:53 -0700 (PDT) Date: Tue, 13 Jul 2021 10:41:51 -0400 From: Tom Rini To: Marek Vasut Cc: "Alex G." , Bin Meng , Reuben Dowle , Simon Glass , "u-boot@lists.denx.de" , Wolfgang Denk Subject: Re: [PATCH] spl: Align device tree blob address at 8-byte boundary Message-ID: <20210713144151.GH9516@bill-the-cat> References: <20210712035231.26475-1-bmeng.cn@gmail.com> <58187afcb4aa481a8302777aca599fa7@4rf.com> <20210712151510.GT9516@bill-the-cat> <300cbb2d-a343-aff8-2c73-00a81ec05af3@gmail.com> <20210713134703.GF9516@bill-the-cat> <940b2a89-c332-c534-102e-5fa25b5b14b4@denx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kPH5P37VjogrgabI" Content-Disposition: inline In-Reply-To: <940b2a89-c332-c534-102e-5fa25b5b14b4@denx.de> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.2 at phobos.denx.de X-Virus-Status: Clean --kPH5P37VjogrgabI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote: > On 7/13/21 3:47 PM, Tom Rini wrote: > > On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote: > > > On 7/12/21 10:15 AM, Tom Rini wrote: > > > > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote: > > > > > On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle wrote: > > > > > >=20 > > > > > > I submitted an almost identical patch. See https://github.com/u= -boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76 > > > > > >=20 > > > > > > This patch eventually had to be reverted (https://github.com/u-= boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114), because it wa= s causing issues on some platforms that had FIT on 32 bit boundary. However= I continue to use it in production code, as without it the boot on my plat= form aborts. > > > > > >=20 > > > > > > I don't have time to investigate why this was happening, but yo= u need to check this code won't just cause exactly the same faults. > > > > >=20 > > > > > Thanks for your information. > > > > >=20 > > > > > +Marek who did the revert > > > > >=20 > > > > > The revert commit message says: > > > > >=20 > > > > > "The commit breaks booting of fitImage by SPL, the system s= imply > > > > > hangs. This is because on arm32, the fitImage and all of its cont= ent > > > > > can be aligned to 4 bytes and U-Boot expects just that." > > > > >=20 > > > > > I don't understand this. If an address is aligned to 8, it is alr= eady > > > > > aligned to 4, so how did this commit make the system hang on arm3= 2? > > > >=20 > > > > I think this had something to do with embedding contents somewhere = in > > > > the image? There is a thread on the ML from then but I don't know = how > > > > informative it will end up being. > > >=20 > > > It's true that the flat devicetree spec requires an 8-byte alignment,= even > > > on 32-bit. The issues here are specific to u-boot. > > >=20 > > > SPL and u-boot have to agree where u-boot's FDT is located. We'll loo= k at > > > two cases: > > > 1) u-boot as a FIT (binary and FDT separately loaded) > > > 2) u-boot with embedded FDT > > >=20 > > > In case (1) SPL must place the FDT at a location where u-boot will fi= nd it. > > > The current logic is > > > SPL: fdt =3D ALIGN_4(u_boot + u_boot_size) > > > u-boot: fdt =3D ALIGN_4(u_boot + u_boot_size) > > >=20 > > > In case (2), SPL's view of the FDT is not relevant, but instead the b= uild > > > system must place the FDT correctly: > > > build: fdt >> u-boot.bin > > > u-boot: fdt =3D ALIGN_4(u_boot + u_boot_size) > > >=20 > > > We have 3 places that must agree. A correct and complete patch could = change > > > all three, but one has to consider compatibility issues when crossing= u-boot > > > and SPL versions. > > >=20 > > > I had proposed in the revert discussion that SPL use r2 or similar me= chanism > > > to pass the location of the FDT to u-boot. > >=20 > > I'm not sure that we need to worry too much about mix-and-match > > SPL/U-Boot, but documenting what to go change if you must do it > > somewhere under doc/ would be good. I think we can just switch to > > ALIGN(8) not ALIGN(4) and be done with it? >=20 > Remember, there is also falcon boot. And we definitely have to be able to > have old u-boot (SPL) boot new fitImage and vice versa. I don't follow you, sorry. But since you seem to have the best understanding of where all of the cases something could go wrong here, can you perhaps post an RFC patch? That is likely to be clearer than another long thread here. --=20 Tom --kPH5P37VjogrgabI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmDtpiwACgkQFHw5/5Y0 tyygzwv/TR4TY9GrNW823d19Zdgf67udWTzKYF+4YXMNQA8JS1h57hyYHDg5txdP mNAL7CnG3tdRU87wLBNfO6EfA5FnxESdvcdeQuYMhmTR+i0Q5Tt/6m+3ZXng1pIM 1hh5192fsEmjbMBFNoDVj6QWZU2Wfcc2Z/2zEZgjwRzmz0zGZOXU24h6eBPVYRF7 ul9yqvub61agD8ajOioCjcU9IkPSAw/84kR2WpWZGCKQ5cO2D3WZ79FH6l0TfFu5 PhAONQSj3nVrJ41HaLhZjFoMiZ1bcLYp0wobLB1MwsvcK8BCF/cjwmUvLnyPkiCU CLkcpWuYkKEXkuRdfcEtkZo5+jO8IP1VYRw6dlBBNrxqb5HxZLM0CSE0XjMfeBYJ 4Fs6qntlTuu99hvYiSzkflCFM9JGMYmhTN7Y/e0oqCQTweQLGRwnDYTU03lC4TXt uKwe08SIQQbbuX9ohW+0my6XXo9H21bedtzl/UKNIgRuAoAil4f40prNyZ4xfic7 HtCcJyRa =10oN -----END PGP SIGNATURE----- --kPH5P37VjogrgabI--