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 714F2C07E95 for ; Tue, 13 Jul 2021 17:20:15 +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 74F76610D1 for ; Tue, 13 Jul 2021 17:20:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 74F76610D1 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 332F082CC1; Tue, 13 Jul 2021 19:20:11 +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="qQwPMm9Z"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id CDE1382DD2; Tue, 13 Jul 2021 19:20:09 +0200 (CEST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 8A90082CC1 for ; Tue, 13 Jul 2021 19:20:05 +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-x82a.google.com with SMTP id w13so17257753qtc.0 for ; Tue, 13 Jul 2021 10:20:05 -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=14+qjDvKez1IbEwh2yBR+lPXAz6N/s7MqVCV4JMAMrM=; b=qQwPMm9ZbNzaMNPzHXAdD75shYCpMD0jam4F3uNVBCw4hwVso5ua/cequaWj9mBiPj /SDbV6sI8VvFlCyW09APvPSBwc1n9paMR87iPQDGBTCqLWqbv7koN5MQYs4j5PxVi7q4 GlUNRgb86ZZKMTuPIZx74IhxDi4EkApDTKzIg= 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=14+qjDvKez1IbEwh2yBR+lPXAz6N/s7MqVCV4JMAMrM=; b=nkWUWG3Paw15xqak4KbnRaiwrKBxHIY97GjM7HYv1rj0hy/ARpPX8mXJKUs5Ywjh2f 4kilzxJQRq5rEbDfFSJJA01lJdQwvhtt1elv5StMWVuZ7t+rK+bEPxpid3ZFtYgTrmik 81A8QMQOw6kyP9bfo1ec17ZZ7+VXOLlhrnSDJIbM2jIJaObGFg4Kf128/w5dHqqz5UI9 TGrMSCBjZVl9h/vm2L0s5JeQsWBqMbgqjFI+n6PIqx2tbiP6/rROzuXZSUOYg/2PdwlI 1atuyyDbB+zHsSPfsMxOeSwzkV4B+Qvr+LtCtGK47zL3auuixQ/9I/YIUGMHVs2EKULo QvJw== X-Gm-Message-State: AOAM533ZXDi6L+b3CVk0A+LqSSR1/Sk8r77m59bdAQfVkj8maXAPiOju QAO2+5/nuWN0K2yA/dRYL39SNQ== X-Google-Smtp-Source: ABdhPJyJ9H+ytwpXm93NhbtirP9f0bw9Fr6PWmbHS+L+dBA6A1Y3q0DZhq2cMkJI3sfNSz50uTUJ+Q== X-Received: by 2002:a05:622a:1349:: with SMTP id w9mr5054736qtk.73.1626196804218; Tue, 13 Jul 2021 10:20:04 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-4cf5-6df7-4b7d-752e.res6.spectrum.com. [2603:6081:7b01:cbda:4cf5:6df7:4b7d:752e]) by smtp.gmail.com with ESMTPSA id t62sm8187075qkc.26.2021.07.13.10.20.02 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Jul 2021 10:20:03 -0700 (PDT) Date: Tue, 13 Jul 2021 13:20:00 -0400 From: Tom Rini To: "Alex G." Cc: Bin Meng , Reuben Dowle , Marek Vasut , Simon Glass , "u-boot@lists.denx.de" Subject: Re: [PATCH] spl: Align device tree blob address at 8-byte boundary Message-ID: <20210713172000.GJ9516@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r0jaPmPINdo+Q5Ia" Content-Disposition: inline In-Reply-To: <300cbb2d-a343-aff8-2c73-00a81ec05af3@gmail.com> 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 --r0jaPmPINdo+Q5Ia Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 w= rote: > > > >=20 > > > > I submitted an almost identical patch. See https://github.com/u-boo= t/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76 > > > >=20 > > > > This patch eventually had to be reverted (https://github.com/u-boot= /u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114), because it was ca= using issues on some platforms that had FIT on 32 bit boundary. However I c= ontinue to use it in production code, as without it the boot on my platform= aborts. > > > >=20 > > > > I don't have time to investigate why this was happening, but you ne= ed 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 simply > > > hangs. This is because on arm32, the fitImage and all of its content > > > 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 already > > > aligned to 4, so how did this commit make the system hang on arm32? > >=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 look 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 find i= t. > 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 build > 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 chan= ge > all three, but one has to consider compatibility issues when crossing u-b= oot > and SPL versions. >=20 > I had proposed in the revert discussion that SPL use r2 or similar mechan= ism > to pass the location of the FDT to u-boot. Looking at this again, and trying to figure out what we can do here most easily, I think we need to have spl_fit_append_fdt() perhaps be split in to "find the fdt" and then either a new function, or more logic within the function for "ensure fdt is aligned properly". We had made the assumption that we can use the fdt in place in memory but that's not always true. --=20 Tom --r0jaPmPINdo+Q5Ia Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmDtyzwACgkQFHw5/5Y0 tyxSVQv+IP2eU2y7ZilMjD5lJtbiCkegg3EoNRQnjuoDkQO581oOnb7cNFhdSMKV XNn2gLz4+2KLWVydIJLMvBkD13F7KjXAhRtYgyuQNVUJE7fdKvlu3p26jNQACNpY ziDDmz5fScDxJJSANt6Ie5bMihTm83rGpYt1/De/BaqfzPvBr4Ecn0fkY5l+y445 uXXNg2It502MwTWMNQ1CMpX2BxC6gyZLfdkespkmC1nCTvurTlDBsFqdWjsVoQQN FP7czOcqED7lc+EB20rHSWKIQMvzZuIPB/dyM3qzua2Dynfwsr027yIqHi477CNH /+4BkCXjBC7wRtWE9yE11eGJUR4FH0S+KEVdWdvEkEVIvJ7DuXcvOlacsme0K3ic fQlQScNlEMURyoQxSQF9ic0gQcI5tNYuOcPNxGxax70tNSfSJYaSPRHC5Rdzbv4f NRvld7u45Gx0pE6IE6P7pdLRM7xTOjgVSXhksYCkoiONh/y5Fs8yAOh5vBRntnWI mKWTiNUn =CV4c -----END PGP SIGNATURE----- --r0jaPmPINdo+Q5Ia--