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,URIBL_BLOCKED,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 BDB60C07E99 for ; Mon, 12 Jul 2021 15:15:24 +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 B799861008 for ; Mon, 12 Jul 2021 15:15:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B799861008 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 D5F9282C6B; Mon, 12 Jul 2021 17:15:20 +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="gwjGauH+"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 97E5582D22; Mon, 12 Jul 2021 17:15:19 +0200 (CEST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 A46F782C3C for ; Mon, 12 Jul 2021 17:15:14 +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-qk1-x72d.google.com with SMTP id 77so16511498qkk.11 for ; Mon, 12 Jul 2021 08:15:14 -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=r/rHxpv+w5VrScuy/eceQJKsHyrYsf2MDgRqC3CrXts=; b=gwjGauH+4+PGycYJVapOQHXQdo1yGduTCyDpy4DPAfu2UmcmahUc0Y3i17z78emP+S m1WrdUKhkRXve6axvP4LgBncXIIh7gSiRKhEHpQ+zTpeRvak6ydXm5f1smfDjGntxPEy ITt9mDu1ej1mYIiT1NNdv6NTafg7tWgMv8skQ= 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=r/rHxpv+w5VrScuy/eceQJKsHyrYsf2MDgRqC3CrXts=; b=P2eH35zLtigKH2tyzxs8XJDbfJA43U/72gF+dTeGu/kG3qoi9xiIHTPOTPdtc4vcS8 wj4MdrgzCjNpL1LigQ6eEOyNLOWyDpPKZ8fLF89/Xmj+I6fD2tjRbfqUx8XAh1xwe7Sz bg5PnLy2rdYeE2HGQpHh6d88jqfgVt1cimgZnH2xrNEXIu0PM7Lus99Ddo6rf/IkfQ5I f6c+JuDtemrXyaLBVqMplfHb/zVCV4sRfa3H8g8L8EBSjzOrQFZK5k6uqObqvnjsJ6mD kqrqQV+rmDFYL5xit+AxPRF9IA3pI4yBOEh8xwoWDaQ62KHsZtzRX4ZRtqTon5ezKU2a 0f+Q== X-Gm-Message-State: AOAM531k5icmwPP0X9lbLn6lu0idA1I6ciDxPxMtkFiC6fnmMHLZEyJP KV+TCfn885TSK4V0PSFbqTndUg== X-Google-Smtp-Source: ABdhPJzMbbuxmO9ySoGaUYnYHi/vrxPdnXOqUH147KcEejeyXY63ElVeg4gv2BVCmGFN9bVR2GUCYw== X-Received: by 2002:a37:b983:: with SMTP id j125mr38353699qkf.482.1626102913430; Mon, 12 Jul 2021 08:15:13 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-8124-e22d-adbc-1eeb.res6.spectrum.com. [2603:6081:7b01:cbda:8124:e22d:adbc:1eeb]) by smtp.gmail.com with ESMTPSA id e6sm6604732qkg.12.2021.07.12.08.15.11 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 12 Jul 2021 08:15:12 -0700 (PDT) Date: Mon, 12 Jul 2021 11:15:10 -0400 From: Tom Rini To: Bin Meng Cc: 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: <20210712151510.GT9516@bill-the-cat> References: <20210712035231.26475-1-bmeng.cn@gmail.com> <58187afcb4aa481a8302777aca599fa7@4rf.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QMgXNoGITKY5bwcE" Content-Disposition: inline In-Reply-To: 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 --QMgXNoGITKY5bwcE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > > > I submitted an almost identical patch. See https://github.com/u-boot/u-= boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76 > > > > This patch eventually had to be reverted (https://github.com/u-boot/u-b= oot/commit/5675ed7cb645f5ec13958726992daeeed16fd114), because it was causin= g issues on some platforms that had FIT on 32 bit boundary. However I conti= nue to use it in production code, as without it the boot on my platform abo= rts. > > > > I don't have time to investigate why this was happening, but you need t= o 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? 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. > Note, as I indicated in this patch, now with libfdt 1.6.1, the > alignment to 8 byte is a must-have. So we have to do such alignment > anyway. >=20 > @Tom may fill in why libfdt commit commit 5e735860c478 ("libfdt: Check > for 8-byte address alignment in fdt_ro_probe_()") was made to have the > 8-byte alignment requirement. Note that it's not so much since libfdt 1.6.1 but that since always the device tree has required 8 byte alignment. It's just that on 32bit platforms 4-but-not-8 byte alignment tends to not be fatal but on 64bit platforms it is. --=20 Tom --QMgXNoGITKY5bwcE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmDsXHcACgkQFHw5/5Y0 tyxfFwwAp/g7ruS3lAO0p1G3uhHaAr5H9b5a0Y0gnqJ+Ph7Oms2mSTR7vYZ3f3Nk uWK4ENRy107lRH4MPBwPRLBKi2pKNd4lzD1dJPBTKrnqAPY44jeU6GVhKUdWYgMY AWu7xznz5I20GG1Y5d9ACh3CuuLVO7OuQdjtL+Cul+qrDWlLSbbLcc0PZ8X+kwS4 8trvvPGzkYK6joeAPO8M6vjBtHMWemJvBFJkE+F5d7yIJQgNwigQAUXi2QdCSRts 7xK8Lc7ikIYxekJqYnLaiNd083I7i164uTr+Qqsk5AfFM+pr5tHUqn9Rdeq4/q9d X/nqvAiMW6jBE++oyeX/DgGf0MsDzxAimZGxTXpBEfDUz4Wk+OFOT16y32mXawEO U1RyROYPU9rfK3Wijy2PE3CA5eTlotVcbyPBaY5P6Rzepdb+MwNip7G+aWMUPLKo zhtE+9vzXfE46OkR0De2l24lECE1stozZsSFEfb0wS7Ayi8+5tCpoR7wbf8Z6qVF yiynPOwO =+ycf -----END PGP SIGNATURE----- --QMgXNoGITKY5bwcE--