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.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 9F746C11F66 for ; Tue, 13 Jul 2021 14:35:45 +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 7FBC4610CB for ; Tue, 13 Jul 2021 14:35:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7FBC4610CB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=denx.de 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 3371882CC1; Tue, 13 Jul 2021 16:35:42 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1626186942; bh=2sDvevjyPVKr7nGhSFtyGosqa1hcwJKtLSXJhJFD2CI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=NWadQBCXEp7mnigUl07cS83ZIyyKrGtbHfx0K1NjHWdyyEZPr1pW/pFzFB0Jc3nDT 54vqS2BX0TSURVVWUJm+cPrVgPKbWirTIiMhklsVj6fvEoRrbf2PUjDnqPHeW2JK5C ZCQtXzPRZ324bejKP1g8bhnVO231WCpc65ymUoAppZpxFd6RAWLDWeHU2kNP3BUBuP TPJoFDlEBJn/Eu5x6h5BJgsPzrL+dOX2PQDXKHkY5gV3Jb6+oD4BvCQxSDnoD2z3Zt 5f5/UmY7xZX9qRbtFa+swWG6cjKWyUAwb3ysWJ95nS+Un1RYFgtC6Di8bcDrIx0LoR oKiuO30Dv48pA== Received: from [IPv6:::1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 02AA982BFF; Tue, 13 Jul 2021 16:35:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1626186939; bh=2sDvevjyPVKr7nGhSFtyGosqa1hcwJKtLSXJhJFD2CI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=H2jQ7WF/zSaBBwSrCNszhn0UPACDLxgoDGhwpnMt4BqqpD/YAF/Aqf1QVx6/WIocx URH61RC4yaOAkE69z8//l9RQvXIy0aNjmOaUC8D1o2jB6GRLzOsbhbrB82Y3cfXThx Zwq6GjzL0FsemzK9xnnRy/wmidMVrF24VJqnG3CrOIZMo0RdfJLe2PT+o77u84KxnH XjFWQPq7L66Qqh5GByFZ1KB1x8+yHALNeCXfEciU9tQ6F7Md90Y8opxxWc2+Y+oOMj jTd/dow8/f5gD/X6xamMYPw0gPLb5zskCDj2QwttwIES6T+cXNeIRLdfEsB8QnQdXi JYimQpjTur+WA== Subject: Re: [PATCH] spl: Align device tree blob address at 8-byte boundary To: Tom Rini , "Alex G." Cc: Bin Meng , Reuben Dowle , Simon Glass , "u-boot@lists.denx.de" , Wolfgang Denk 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> From: Marek Vasut Message-ID: <940b2a89-c332-c534-102e-5fa25b5b14b4@denx.de> Date: Tue, 13 Jul 2021 16:35:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210713134703.GF9516@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/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: >>>>> >>>>> 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. > > 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? 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.