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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 33E9BC433F5 for ; Fri, 11 Feb 2022 16:39:54 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id ED66983A97; Fri, 11 Feb 2022 17:39:51 +0100 (CET) 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="cLuQ+d1E"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 25A8283B4B; Fri, 11 Feb 2022 17:39:50 +0100 (CET) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 9875083A3D for ; Fri, 11 Feb 2022 17:39:44 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=aford173@gmail.com Received: by mail-ed1-x52a.google.com with SMTP id g7so1325497edb.5 for ; Fri, 11 Feb 2022 08:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nbEWacqdpILnrqTqpfBl+NwqbCtoys8TAdLEebig8uk=; b=cLuQ+d1ERyznLd/nXHt91VARen2MVEzwTJHgWhbUAZFzp0xhzu72XLd/3xr5wAjMkO 5jRR2ZAp+F6e+qQ9/X5CHwIClspcF9ixigBiw/KZECdsRKOmTYrQ/BfJ0/xv+R31DsE3 fOZ7HAUQWWniGE/GdDirndDYwVFA5ftWSsiyd2MRKgbjnVAljRo3zlDBK1r9hCLstO/2 qRow7NLATrqDFJqMD1CSfwHJ8CIOUqGwXPWUps/YXgVcbuHM9YYnZqXOPs6tPo26ZYeQ 1Rb1VxQek1qPNzxdOg7TeZaqnP1AAz+Sscw6voLE2bTudEaIC9xxOe77b9iGl8Pz4lBd FPOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nbEWacqdpILnrqTqpfBl+NwqbCtoys8TAdLEebig8uk=; b=dsw3x20fgPzgfcMbMk0wKotb+H19D9qWrOFTJ5DFGoEnKlv2BhiScUTFHtSlmovG3k 9h5/5qPc8D70VjrVMJc45UclNCcVzM1ygsNLQCa35hpTXLgstwVDpGcdbc3SvIxt3Mo/ QiqDZEU07j+xpeUtYKQxh8aaZc0rX4lY+A9EVnZr+VlTm/obPN0jwsnVgotwVM7G07y8 7bP7FbQBP7Uz8kfu+SwF2yg8jecmLpJJsNhnKSIeuPMkhmOVwqVMu84+y6/kcyPQXGwn e+qwjIE2LQWSSGkElYO9zi3ud93FPK6EkIAba3k6kqznXt4tsScv3Q+l76R6jjWqAkin VPrA== X-Gm-Message-State: AOAM531FKvg3a8CQFIYs3lGOZyW8O3BCezBlFmytHDDXaFjOUJDFKH5T AQBcY9FjUMSEWDMwAcQ/RMJBzpK/3G/z7K1rrfY= X-Google-Smtp-Source: ABdhPJy0c4qSHgFotEuwXmQDu54s0MXd2Rx51rxpo8e8d9dO1wJvwAA8kIGa2pOQn/RbEeW/6ziEkfWA4mXtjhuiy6A= X-Received: by 2002:a05:6402:2895:: with SMTP id eg21mr2830166edb.439.1644597581520; Fri, 11 Feb 2022 08:39:41 -0800 (PST) MIME-Version: 1.0 References: <20211014184811.482560-1-sjg@chromium.org> <20211014124803.v3.7.Id5595981cd99201c6a2d8b714254d775436a3483@changeid> <20220209123219.GZ7515@bill-the-cat> <20220210145750.GH2697206@bill-the-cat> <20220211161208.GF2697206@bill-the-cat> In-Reply-To: <20220211161208.GF2697206@bill-the-cat> From: Adam Ford Date: Fri, 11 Feb 2022 10:39:30 -0600 Message-ID: Subject: Re: [PATCH v3 07/18] pxe: Move pxe_utils files To: Tom Rini Cc: Simon Glass , U-Boot Mailing List , Patrice Chotard , Artem Lapkin , Joe Hershberger , Heinrich Schuchardt , Peter Hoyes Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.5 at phobos.denx.de X-Virus-Status: Clean On Fri, Feb 11, 2022 at 10:12 AM Tom Rini wrote: > > On Fri, Feb 11, 2022 at 09:50:32AM -0600, Adam Ford wrote: > > On Thu, Feb 10, 2022 at 8:57 AM Tom Rini wrote: > > > > > > On Thu, Feb 10, 2022 at 07:56:52AM -0600, Adam Ford wrote: > > > > On Wed, Feb 9, 2022 at 11:16 AM Simon Glass wrot= e: > > > > > > > > > > Hi, > > > > > > > > > > On Wed, 9 Feb 2022 at 05:32, Tom Rini wrote: > > > > > > > > > > > > On Wed, Feb 09, 2022 at 05:40:03AM -0600, Adam Ford wrote: > > > > > > > On Thu, Oct 14, 2021 at 1:50 PM Simon Glass wrote: > > > > > > > > > > > > > > > > Move the header file into the main include/ directory so we= can use it > > > > > > > > from the bootmethod code. Move the C file into boot/ since = it relates to > > > > > > > > booting. > > > > > > > > > > > > > > > +cc lokeshvutla@ti.com > > > > > > > > > > > > > > Simon, > > > > > > > > > > > > > > I can't explain why, but with git bisect, it appears this pat= ch breaks > > > > > > > my omap3_logic board (DM3730) by making it wrongly think ther= e is 4GB > > > > > > > of RAM, when in reality there is only 256MB. We have both 25= 6MB and > > > > > > > 512MB parts, and the automatic memory detection has always 'j= ust > > > > > > > worked' in the past. > > > > > > > > > > > > > > With this patch now, I see: > > > > > > > U-Boot 2022.01-rc1-00185-g262cfb5b15 (Feb 09 2022 - 05:23:42 = -0600) > > > > > > > > > > > > > > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 = GHz > > > > > > > Model: LogicPD Zoom DM3730 Torpedo + Wireless Development Kit > > > > > > > DRAM: 4 GiB > > > > > > > > > > > > > > > > > > > > > With the previous commit, 8018b9af57b5 ("pxe: Tidy up the is_= pxe > > > > > > > global"), it properly detects the RAM and fully boots. > > > > > > > > > > > > > > U-Boot 2022.01-rc1-00184-g8018b9af57 (Feb 09 2022 - 05:21:39 = -0600) > > > > > > > > > > > > > > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 = GHz > > > > > > > Model: LogicPD Zoom DM3730 Torpedo + Wireless Development Kit > > > > > > > DRAM: 256 MiB > > > > > > > NAND: 512 MiB > > > > > > > MMC: OMAP SD/MMC: 0 > > > > > > > Loading Environment from NAND... OK > > > > > > > OMAP die ID: 619e00029ff800000168300f1502501f > > > > > > > Net: eth0: ethernet@08000000 > > > > > > > Hit any key to stop autoboot: 0 > > > > > > > OMAP Logic # > > > > > > > > > > > > > > I have CONFIG_CMD_BOOTM, CONFIG_CMD_PXE and CONFIG_CMD_SYSBO= OT all > > > > > > > defined, so I am having a hard time understanding why this wo= uld > > > > > > > change behavior or stomp on the the structure that knows the = memory > > > > > > > size. > > > > > > > > > > > > > > If I jump ahead to the current 'master' 531c0089457:("Merge b= ranch > > > > > > > '2022-02-08-TI-platform-updates') and revert this patch, my = board > > > > > > > boots correctly again, but I am struggling to understand why. > > > > + Marek Beh=C3=BAn > > > > > > > > > > > > > > > > > > Do you have any suggestions for me to try? > > > > > > > > > > > > I would suggest objdump disassemble U-Boot before/after and see= what > > > > > > functions have changed. > > > > > > > > > > Keep an eye out for a BSS variable that is used before relocation= , perhaps? > > > > > > > > I am still investigating, but disabling LTO appears to fix the issu= e > > > > for me. I'd like to keep LTO, so I'm going to attempt to focus on = the > > > > differences in the affected functions and how this patch makes LTO > > > > behave differently. > > > > > > > > The disassembly of U-Boot is large, so it's going to take me a bit = of > > > > time to investigate. If someone has any LTO-related suggestions th= at > > > > I could try, I'd be open to try them too. > > > > > > Wait, the disassembly is large, or the differences between the > > > disassembly, before/after this change alone, are large? It's feeling > > > > I will be the first to admit thatI am not very good with the assembly > > side of things, but this is what I did: > > > > git checkout master > > make CROSS_COMPILE=3Darm-linux-gnueabihf- -j8 > > arm-linux-gnueabihf-objdump -S u-boot > broken.dump > > git revert 262cfb5b15420a1aea465745a821e684b3dfa153 > > make CROSS_COMPILE=3Darm-linux-gnueabihf- -j8 > > arm-linux-gnueabihf-objdump -S u-boot > working.dump > > > > diff --side-by-side --suppress-common-lines broken.dump working.dump > > > broken-working.diff > > cat -n broken-working.diff > > > > The broken-working.diff file with common lines suppressed is 236256 lin= es long. > > OK, I just use '-d' and not '-S', which might help a little bit. But > you're probably going to still need to edit the dumps and just globally > change all of the addresses to 'XXXXXXXX' so that you'll end up > hopefully only seeing where functions were optimized differently. But > it might well end up being a bit trickier than that. It looks like none of the object files are showing any content with objdump when LTO is enabled. With a little google search, it appears we need lto-dump. I have some more meetings, but I'll try to spend some more time on it this weekend. > > > When I disable LTO for just pxe_utils.o and redo the same exercise, > > the diff file with common-lines removed is 266573 lines long. > > > > Maybe I am not using objdump correctly. I am not all that familiar > > with this code either, so I am not sure which variables should be in > > BSS. I did a search in both working and non-working dumps to look for > > keyworks like BSS, but from what I can tell, both have similar > > functions: > > > > gd->mon_len =3D (ulong)&__bss_end - (ulong)_start; > > /* TODO: use (ulong)&__bss_end - (ulong)&__text_start; ? */ > > gd->mon_len =3D (ulong)&__bss_end - CONFIG_SYS_MONITOR_BASE; > > gd->mon_len =3D (ulong)&__bss_end - (ulong)_start; > > * reserve memory for U-Boot code, data & bss > > 8011051a : > > #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_EARLY_BSS) > > CLEAR_BSS > > #if !defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SPL_EARLY_BSS) > > CLEAR_BSS > > CLEAR_BSS > > > > When I grepped for mon_len, both sets of dumps looked nearly identical: > > > > aford@aford-OptiPlex-7050:~/src/u-boot$ grep mon_len working.dump > > lmb_reserve(lmb, (phys_addr_t)(uintptr_t)_start, gd->mon_len); > > 80112724 : > > static int setup_mon_len(void) > > gd->mon_len =3D (ulong)&__bss_end - (ulong)_start; > > 80112726: 4903 ldr r1, [pc, #12] ; (80112734 ) > > 80112728: 4b03 ldr r3, [pc, #12] ; (80112738 ) > > gd->mon_len =3D (ulong)&__bss_end - CONFIG_SYS_MONITOR_BASE; > > gd->mon_len =3D (ulong)&__bss_end - (ulong)_start; > > gd->ram_top =3D board_get_usable_ram_top(gd->mon_len); > > gd->relocaddr -=3D gd->mon_len; > > gd->mon_len >> 10, gd->relocaddr); > > ip =3D mon_lengths[yleap]; > > > > > > aford@aford-OptiPlex-7050:~/src/u-boot$ grep mon_len broken.dump > > lmb_reserve(lmb, (phys_addr_t)(uintptr_t)_start, gd->mon_len); > > 80110398 : > > static int setup_mon_len(void) > > gd->mon_len =3D (ulong)&__bss_end - (ulong)_start; > > 8011039a: 4903 ldr r1, [pc, #12] ; (801103a8 ) > > 8011039c: 4b03 ldr r3, [pc, #12] ; (801103ac ) > > gd->mon_len =3D (ulong)&__bss_end - CONFIG_SYS_MONITOR_BASE; > > gd->mon_len =3D (ulong)&__bss_end - (ulong)_start; > > gd->ram_top =3D board_get_usable_ram_top(gd->mon_len); > > gd->relocaddr -=3D gd->mon_len; > > gd->mon_len >> 10, gd->relocaddr); > > ip =3D mon_lengths[yleap]; > > aford@aford-OptiPlex-7050:~/src/u-boot$ > > > > Since I think I narrowed it down to the pxe_utils.o file, I thought > > I'd do an objdump of both the working and non-working versions of > > pxe_utils.o and this is where it got interesting. > > > > With LTO building pxe_utils.o, the dump looks empty: > > > > arm-linux-gnueabihf-objdump -S boot/pxe_utils.o > pxe-notworking.dump > > cat pxe-notworking.dump > > > > boot/pxe_utils.o: file format elf32-littlearm > > > > ^-- no actual code dump > > If I take the working version of this same file without LTO enabled > > and do a dump, and it's 2291 lines long and full of functions. > > > > I tried adding some __used to the non-static function names, but that > > didn't appear to make any difference to the objdump of pxe_utils.o > > I feel like it can't be pxe_utils.o itself but rather how LTO is > behaving before/after that change and sorting the object files > differently. If modifying the dumps like I suggested above doesn't lead That's what I was thinking too. > to more clues, and it doesn't seem to matter what toolchain is used (are > you using the gcc-11 from kernel.org that we use in docker and > buildman?), I'll try and look as well. I am using GCC 11, but I'm using the version that come with Ubuntu 21.10: Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (Ubuntu 11.2.0-5ubuntu1) > > -- > Tom