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 B150EC433F5 for ; Fri, 11 Feb 2022 16:45:09 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id CFB5983071; Fri, 11 Feb 2022 17:45:06 +0100 (CET) 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="qFr1Yqr6"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C720183A37; Fri, 11 Feb 2022 17:45:02 +0100 (CET) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 A6596816AB for ; Fri, 11 Feb 2022 17:44:57 +0100 (CET) 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-x736.google.com with SMTP id o25so8732940qkj.7 for ; Fri, 11 Feb 2022 08:44:57 -0800 (PST) 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; bh=7mmhHTdYIauhQLav9LOEFT/jZzYl6oph+YspgWlv96Q=; b=qFr1Yqr6PvW+gD0Z1iLgOSHXU0hi5h/OeT4q055oy7iK61bHxPXtHJQ0cS/AEkSJ/y N45sc2/BKxUhM2SFVO4XRQ2OGnIa2Es1zKLFXsWqpBFjMw0kuY7V1Bqfi0tl6LL5c0FQ P4JXD8IoxJdnN74Cun+MBXa3RS8dlGdR0ENzA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=7mmhHTdYIauhQLav9LOEFT/jZzYl6oph+YspgWlv96Q=; b=FTIoCypuNLFio5MTmcyRg2aP/mJcJ+FKJsNAlan6YHbwhz+x0DrlOKa9pAwJzURgPN 315Q2/nD7YER71zQDaDzSRbwOZJfEGqJkPZt/NOIb3B3C84EVyq+HYvKzoCGzaqE/plV w+4Hav+JIW/l479HpU6zp+I/d2EanecKGZaRqJAx18eXY2ZdJ7ABjaFCZtnxfJDeFlWP TazvFZCQ64as1rUImN3VweETTGG7zJpt0LfK7Ry8onpFdj4UrEC6ZbLSwsCvFVKYeoq7 FuiMOByy61Yp6ezo8UqPGRBHVbUPudL0QJ24J/xMrgempK6QQoL4aCmk4PiXXXaoH6iq +IMg== X-Gm-Message-State: AOAM5307YgrHQ6AvoMXQj3YNsM5VVGPlGIf0YBNmxhL3mRiLkAPCtsKi UVtZD5wq8Ob+Z9gnycZIIk+cVQ== X-Google-Smtp-Source: ABdhPJwpUCMCu6VOj7oCtJwNKOibnAkyWwmvNwyLxcKpln7aIsf+pb7LzlHLY+Klm8mA+/x44cS1Bg== X-Received: by 2002:a05:620a:198f:: with SMTP id bm15mr1190509qkb.359.1644597896328; Fri, 11 Feb 2022 08:44:56 -0800 (PST) Received: from bill-the-cat (2603-6081-7b01-cbda-2ef0-5dff-fedb-a8ba.res6.spectrum.com. [2603:6081:7b01:cbda:2ef0:5dff:fedb:a8ba]) by smtp.gmail.com with ESMTPSA id h20sm5530387qtk.21.2022.02.11.08.44.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Feb 2022 08:44:55 -0800 (PST) Date: Fri, 11 Feb 2022 11:44:53 -0500 From: Tom Rini To: Adam Ford Cc: Simon Glass , U-Boot Mailing List , Patrice Chotard , Artem Lapkin , Joe Hershberger , Heinrich Schuchardt , Peter Hoyes Subject: Re: [PATCH v3 07/18] pxe: Move pxe_utils files Message-ID: <20220211164453.GG2697206@bill-the-cat> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gqO6s7S91gFL8ZIQ" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett 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 --gqO6s7S91gFL8ZIQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 11, 2022 at 10:39:30AM -0600, Adam Ford wrote: > 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 wr= ote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Wed, 9 Feb 2022 at 05:32, Tom Rini wrot= e: > > > > > > > > > > > > > > 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/ sinc= e it relates to > > > > > > > > > booting. > > > > > > > > > > > > > > > > > +cc lokeshvutla@ti.com > > > > > > > > > > > > > > > > Simon, > > > > > > > > > > > > > > > > I can't explain why, but with git bisect, it appears this p= atch breaks > > > > > > > > my omap3_logic board (DM3730) by making it wrongly think th= ere is 4GB > > > > > > > > of RAM, when in reality there is only 256MB. We have both = 256MB and > > > > > > > > 512MB parts, and the automatic memory detection has always = 'just > > > > > > > > worked' in the past. > > > > > > > > > > > > > > > > With this patch now, I see: > > > > > > > > U-Boot 2022.01-rc1-00185-g262cfb5b15 (Feb 09 2022 - 05:23:4= 2 -0600) > > > > > > > > > > > > > > > > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock = 1 GHz > > > > > > > > Model: LogicPD Zoom DM3730 Torpedo + Wireless Development K= it > > > > > > > > DRAM: 4 GiB > > > > > > > > > > > > > > > > > > > > > > > > With the previous commit, 8018b9af57b5 ("pxe: Tidy up the i= s_pxe > > > > > > > > global"), it properly detects the RAM and fully boots. > > > > > > > > > > > > > > > > U-Boot 2022.01-rc1-00184-g8018b9af57 (Feb 09 2022 - 05:21:3= 9 -0600) > > > > > > > > > > > > > > > > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock = 1 GHz > > > > > > > > Model: LogicPD Zoom DM3730 Torpedo + Wireless Development K= it > > > > > > > > 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_SYS= BOOT all > > > > > > > > defined, so I am having a hard time understanding why this = would > > > > > > > > change behavior or stomp on the the structure that knows th= e memory > > > > > > > > size. > > > > > > > > > > > > > > > > If I jump ahead to the current 'master' 531c0089457:("Merge= branch > > > > > > > > '2022-02-08-TI-platform-updates') and revert this patch, m= y board > > > > > > > > boots correctly again, but I am struggling to understand wh= y. > > > > > + Marek Beh=FAn > > > > > > > > > > > > > > > > > > > > > Do you have any suggestions for me to try? > > > > > > > > > > > > > > I would suggest objdump disassemble U-Boot before/after and s= ee what > > > > > > > functions have changed. > > > > > > > > > > > > Keep an eye out for a BSS variable that is used before relocati= on, perhaps? > > > > > > > > > > I am still investigating, but disabling LTO appears to fix the is= sue > > > > > for me. I'd like to keep LTO, so I'm going to attempt to focus o= n 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 bi= t of > > > > > time to investigate. If someone has any LTO-related suggestions = that > > > > > 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 feeli= ng > > > > > > 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 l= ines 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. >=20 > 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. >=20 > > > > > 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 identica= l: > > > > > > 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 >=20 > That's what I was thinking too. >=20 > > 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. >=20 > I am using GCC 11, but I'm using the version that come with Ubuntu 21.10: >=20 > Thread model: posix > Supported LTO compression algorithms: zlib zstd > gcc version 11.2.0 (Ubuntu 11.2.0-5ubuntu1) OK. FWIW, if it's easier to build and test, I would suggest also trying CFLAGS_REMOVE_xxx.o :=3D $(LTO_CFLAGS) for all of the obj files under arch/arm/ and board/ and then if that also works correctly, re-adding the flags a directory, then file, at a time until you've narrowed it down. --=20 Tom --gqO6s7S91gFL8ZIQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmIGkoIACgkQFHw5/5Y0 tyyL6wwAqNGz2hphDIRXi0lRc8Dd2P0rIKHee6m5WcuoL+4pa9K7mbzDj67X3qJG dxrFBgBNvQZ6edov2AOkOOnKOn0B1NRLltd4QN2ySEWPmybufKlRM9TfRmXcMONc uRejAlz2r6mNDBxn6HMdsqiE8ldxRyDKzVACVgnqm9Mi2Yl4DCgRMQ+0GUDpA4Qu GOoIL6EyUpRVgFvFMiAtBwIUUVrd163ZegO+4M9oLfzrPmSS7Q7c9z9UdN3EXIgS QYsPjWHkpyo8MDHh8CDNdFVTcDHW2EB+OMyZ4U/xt8wScYHHsiAxTeIea0GKsR2h +YGbXtayrQMGwxX3rV+1XdSmAtNkK/evVQAfdDACFeNAyYFH6CCpyIqaiwstPanA Mm+w7Xly/DfCKBMajSQszVVVIenRqqI5hSz+KvGWvBD2bxBjdgHLBVJ6bJ2Xws8y oeLwSH4iV3R/zWWNRTRurYPvNIT+SHzsPg6SROihecbk6x1ztRqVwN7/dd1uDYRs 6+5LzFhg =4Ofu -----END PGP SIGNATURE----- --gqO6s7S91gFL8ZIQ--