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=-10.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NICE_REPLY_A,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 C3D74C07E99 for ; Mon, 12 Jul 2021 16:01:36 +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 07B0160238 for ; Mon, 12 Jul 2021 16:01:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 07B0160238 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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 3BD6582DEF; Mon, 12 Jul 2021 18:01:34 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="gHcEOaWz"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id DF5B482054; Mon, 12 Jul 2021 18:01:31 +0200 (CEST) Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (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 D141F82054 for ; Mon, 12 Jul 2021 18:01:28 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=mr.nuke.me@gmail.com Received: by mail-oo1-xc2e.google.com with SMTP id j27-20020a4a751b0000b029025fb3e97502so1026969ooc.12 for ; Mon, 12 Jul 2021 09:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Bw8078tb5hui9ERilRPiEO7f2lpX0Jytk8Iq+yqtUJk=; b=gHcEOaWz/SgmQ223y5OzbsRJnHLTxlfJ1Didd//F/rmO+lkTH3uaBl2wF4Z2r2Tkts k4aTiyQnOhOrAeB/alDnJ7h+jxhEbCushEzj/2u3IOEid8jQx+Aj7dIuf5TKYxx182EX YYZHlhja4EEUWaB7fdMQ9ZxhAZflniuX872OT4Oz3R3VR59SK0nEcwPNNQJAsKaqei5z U/psAf7ntyR+VLWSmkFn7qBiLKFpasJ4tTQ1Z/IUdWSNNemwM5sVdomo4/gkTlbnXnpv 8ekVh2YUB11ciBZ2uyOuehkQ84WIFeBArQvd8VZVVXJ/Xm8Y+cHebIROoaFOJ91WZ5IS YiQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Bw8078tb5hui9ERilRPiEO7f2lpX0Jytk8Iq+yqtUJk=; b=ongR/3oXTtWkzB1ruk4k/muOi9zsFYlrfYQNirmn6cmp6ICAMJHafwcUUR1R9hvbKz ffmrR2gOmPU7RunDmkxJn+82YaZeN4blKbAwN6Wx5azU8Uf3KyMyuM2c34s4oJnxh/v7 z4aTnMIAmYy+S5bKznLET8vCfEJs4yZ9U2j1jgYCjnLarCE0W3I7CVU7ULxetSYAEpiL wwOYjs/G+V907JDko18Q63JB5F98BAzoIUOoB8VaKp3/Vqn3F+ewLZBkOOtWxwpw4D/K LvUJZgDZMlrMj1qwwwMnvSKLpi0UHuuOxwYXtk6FYsHGM8yAghLQWvbb9gbdFZJJK9lt 5fsQ== X-Gm-Message-State: AOAM5327om5GGi3BJlERkk5l1Otol33BVXKmwbwQ+nDww6GSNfD/GYmt ue1F0Tdd6fFzN7cHcKpLKUWRNBvovDo= X-Google-Smtp-Source: ABdhPJyJKOO4FBHDDXWawGzGJ5IwkUsm1lxiQimN2oPJzagylew2t82QrTrbmM9CfqhVVZ9dhCZ6fA== X-Received: by 2002:a4a:be93:: with SMTP id o19mr38396474oop.61.1626105686752; Mon, 12 Jul 2021 09:01:26 -0700 (PDT) Received: from nuclearis3.gtech (c-98-195-139-126.hsd1.tx.comcast.net. [98.195.139.126]) by smtp.gmail.com with ESMTPSA id v203sm3261557oib.37.2021.07.12.09.01.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 09:01:25 -0700 (PDT) Subject: Re: [PATCH] spl: Align device tree blob address at 8-byte boundary To: Tom Rini , Bin Meng Cc: Reuben Dowle , Marek Vasut , Simon Glass , "u-boot@lists.denx.de" References: <20210712035231.26475-1-bmeng.cn@gmail.com> <58187afcb4aa481a8302777aca599fa7@4rf.com> <20210712151510.GT9516@bill-the-cat> From: "Alex G." Message-ID: <300cbb2d-a343-aff8-2c73-00a81ec05af3@gmail.com> Date: Mon, 12 Jul 2021 11:01:24 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210712151510.GT9516@bill-the-cat> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 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: >>> >>> 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-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114), because it was 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 platform aborts. >>> >>> I don't have time to investigate why this was happening, but you need to check this code won't just cause exactly the same faults. >> >> Thanks for your information. >> >> +Marek who did the revert >> >> The revert commit message says: >> >> "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." >> >> 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. 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. 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 In case (1) SPL must place the FDT at a location where u-boot will find it. The current logic is SPL: fdt = ALIGN_4(u_boot + u_boot_size) u-boot: fdt = ALIGN_4(u_boot + u_boot_size) 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 = ALIGN_4(u_boot + u_boot_size) 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. I had proposed in the revert discussion that SPL use r2 or similar mechanism to pass the location of the FDT to u-boot. Alex