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=-9.6 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 EB37DC07E95 for ; Tue, 13 Jul 2021 21:06:42 +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 EA9FF61152 for ; Tue, 13 Jul 2021 21:06:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA9FF61152 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 6E35282C53; Tue, 13 Jul 2021 23:06:40 +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="e4r0HD2r"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C343382E0B; Tue, 13 Jul 2021 23:06:38 +0200 (CEST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 DC6C380293 for ; Tue, 13 Jul 2021 23:06: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=mr.nuke.me@gmail.com Received: by mail-ot1-x336.google.com with SMTP id v32-20020a0568300920b02904b90fde9029so258700ott.7 for ; Tue, 13 Jul 2021 14:06:34 -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=vRQR8IGQ+rivPQgMplCQc7y7R5ksffyXWbrTYE7iVPg=; b=e4r0HD2rwui2mWbd6PID9T7kWfOYskyqSLio5NbiTGAzjUeTNdnsIKWqGMjx6a6MvL whi7KMCFNs6fmp2jfjEGMNxApRjH4Y2OaLH58gsunCRcZIn8Xs9yCi+wFiIaKuLR42PG jDPYPvf1iXeMtFAZgcIvXJ5tTQFIO8K6KORGjQM/gQStaqmUsPehr7agUzV7jYyWqwcg PmBkpCqzaVovuX/EBBAD1jqVEyyYjy4PHdC2qGLzcMJHlw/wROJbEbw8u8TK4LF9NBOT Nnx1M1Suyxw6lIw/jGZvNhqnyNwn1AuCZ6dUrDT+U0IMqT4Y0PaiAfXmRExzXAi9axMf BH9Q== 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=vRQR8IGQ+rivPQgMplCQc7y7R5ksffyXWbrTYE7iVPg=; b=iVLoDhpNvUiqMzVK2ig7Z3hFen66qnDa7dP3YritcMiVD9sXVHZFLKwwDbFh9rHXBb fncS6yKcRL0Ouk7ZXBLEf9EfkHHCmoNigwiEWumLhhC+H1ZcvtxIDfTcLwGY9L9P+rdq RVYw4gg7LGROSkbTLrv2804DyOzbNKeEuoji9ZmirU72hmz88fKppP2Aa1FmNpvyU6RV yrVjmUO4IDua6d5ALiVPwiBrYZg8rwk7LSGQJJgvpOox1+3ruaxqjsGRwPpqSyz/QGGS co3+q1N1QpUSDYxPUPe1tRP/wFroT9inF3T6bsGPnPVM9GI3g7nm6Z7Z8YUcSHrxnvk0 qDwQ== X-Gm-Message-State: AOAM533mCgWFVXE9MoV2Groo0TnsLLZXGgBZV/xoEJopbLlWRMrGFEh5 nBpdUgM0XuZvmKlH9jjSf3M= X-Google-Smtp-Source: ABdhPJyALsvIUm9t24Ry3yx1o/oPKgWIswUVm05MdzqpWOiG2YskqJjYLPSq+oKzuDnfzbUgw+8pjw== X-Received: by 2002:a05:6830:2107:: with SMTP id i7mr2046333otc.44.1626210393454; Tue, 13 Jul 2021 14:06:33 -0700 (PDT) Received: from nukespec.gtech (rrcs-67-78-34-122.sw.biz.rr.com. [67.78.34.122]) by smtp.gmail.com with ESMTPSA id v4sm2675216ooa.2.2021.07.13.14.06.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 14:06:32 -0700 (PDT) Subject: Re: [PATCH] spl: Align device tree blob address at 8-byte boundary To: Tom Rini , Marek Vasut Cc: Simon Glass , Bin Meng , Reuben Dowle , "u-boot@lists.denx.de" , Wolfgang Denk References: <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> <20210713144151.GH9516@bill-the-cat> <357b8f2e-4aa5-acf7-96aa-a4d0f7d1fbde@denx.de> <20210713181105.GK9516@bill-the-cat> From: Alex G Message-ID: Date: Tue, 13 Jul 2021 16:06:31 -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: <20210713181105.GK9516@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 1:11 PM, Tom Rini wrote: > On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote: >> On 7/13/21 6:47 PM, Simon Glass wrote: >>> Hi Marek, >>> >>> On Tue, 13 Jul 2021 at 08:53, Marek Vasut wrote: >>>> >>>> On 7/13/21 4:41 PM, Tom Rini wrote: >>>>> 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: >>>>>>>>>>> >>>>>>>>>>> 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. >>>>> >>>>> 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. >>>> >>>> I don't follow you, sorry. I believe the revert did the right thing and >>>> new systems should use mkimage -E when generating fitImages, to avoid >>>> the string alignment problem. That is all. >>> >>> Using -E should be optional and things really should work without it. >> >> See the DTSpec, I don't think that is possible unless you relocate fitImage >> components, and if you want fast boot time esp. in SPL, that is not good. > > This is why I've asked you to make up some patch to perhaps highlight > the problem. Ensuring that the device tree, which is small, is also > 8-byte aligned, shouldn't be a big problem nor performance hit. I'm not > sure where the problem case is that isn't "user put things they control > in a bad spot, fail and tell them why" but I could just be missing a > case. > As far as highlighting the problem, here's an excerpt from the previous discussion [1]. ## SPL: image_info.load_addr = ALIGN(spl_image->load_addr + spl_image->size, 8); (gdb) print/x (spl_image->load_addr + spl_image->size) $19 = 0xc01cf85c (gdb) print/x image_info->load_addr $20 = 0xc01cf860 FDT is installed at 0xc01cf860 ## u-boot: __weak void *board_fdt_blob_setup(void) { /* FDT is at end of image */ fdt_blob = (ulong *)&_end; (gdb) print &_end $22 = (char (*)[]) 0xc01cf85c FDT is expected at 0xc01cf85c Alex [1] https://lists.denx.de/pipermail/u-boot/2020-October/430066.html