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 F2E26C433EF for ; Fri, 11 Feb 2022 16:12:19 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 58CE983AA3; Fri, 11 Feb 2022 17:12:17 +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="WZNsA23C"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 61FEC83AA7; Fri, 11 Feb 2022 17:12:15 +0100 (CET) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 BFDB783A97 for ; Fri, 11 Feb 2022 17:12:11 +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-x729.google.com with SMTP id bs32so8697394qkb.1 for ; Fri, 11 Feb 2022 08:12:11 -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=92+IOatrLMZc+47RxW+nh0Rcvd9+m35OmmN+QLC4j1Y=; b=WZNsA23ChOp1GN0tVIkRo/QeynXuafpORKnN2XjWPhMHLY1g4BbmxdNhdrwD8CnuhF nMPXqH+GhbehL65G2eNIiE82ljcbjeqn0XavDAYaovUV5/Xms9tcWiFaN74t4du0sb6A GbKTclTZ7dONECsywkITo4SsCZbK/8R9obnTI= 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=92+IOatrLMZc+47RxW+nh0Rcvd9+m35OmmN+QLC4j1Y=; b=YHfqQGNi3/TNKd0y/Ex+Z0ZoOzgJc65tKqgkp8QHGOuNteSbIT+gK2obyMQ4BbBoI6 AghUFWni9Ebyu86zDik3gyIUvrATHIeRYfd5kVGc0qXp13dsU6EqNrK7Hmt9y826y006 56KxjqWif/ahWzjYguzoxQZ8/eb1DdLRdxaU5VnT4jUs7KaAfmTAS8ONANEgYLzQCzqm pNzpKh0kk3f0DO43Js8kv+y/V1YPl7pXZ41o1ci5mHNxWgB17NS540FA80cyEFLuoZjH Sb9PWnQWxDyrRnmuLv7CDMMGouG5EN4pSGsTZeDP3v5an0SFGPTuywj7L+/sE6kRR2cD Enuw== X-Gm-Message-State: AOAM531dC5mHpRCM0tZ4PgBaU7wrDBad9CcUzal/qkvm5eNufOpchPy6 2p7/h4hdHy2M0jW7JaILI6eltg== X-Google-Smtp-Source: ABdhPJwPLfXvDi0MZB9KTBUzB+efB8OrRnc13nfjSOJ3RSwONnhZVhaz4TsApZduP8veaKJNPGyoEA== X-Received: by 2002:a05:620a:4445:: with SMTP id w5mr1099909qkp.459.1644595930488; Fri, 11 Feb 2022 08:12:10 -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 g24sm11541001qkk.76.2022.02.11.08.12.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Feb 2022 08:12:09 -0800 (PST) Date: Fri, 11 Feb 2022 11:12:08 -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: <20220211161208.GF2697206@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HjNkcEWJ4DMx36DP" 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 --HjNkcEWJ4DMx36DP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 wrote: > > > > > > > > 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 c= an 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 patch= breaks > > > > > > my omap3_logic board (DM3730) by making it wrongly think there = is 4GB > > > > > > of RAM, when in reality there is only 256MB. We have both 256M= B 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:42 -0= 600) > > > > > > > > > > > > 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 -0= 600) > > > > > > > > > > > > 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_SYSBOOT= all > > > > > > defined, so I am having a hard time understanding why this would > > > > > > change behavior or stomp on the the structure that knows the me= mory > > > > > > size. > > > > > > > > > > > > If I jump ahead to the current 'master' 531c0089457:("Merge bra= nch > > > > > > '2022-02-08-TI-platform-updates') and revert this patch, my bo= ard > > > > > > boots correctly again, but I am struggling to understand why. > > > + Marek Beh=FAn > > > > > > > > > > > > > > > Do you have any suggestions for me to try? > > > > > > > > > > I would suggest objdump disassemble U-Boot before/after and see w= hat > > > > > 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 issue > > > 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 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 feeling >=20 > I will be the first to admit thatI am not very good with the assembly > side of things, but this is what I did: >=20 > 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 >=20 > diff --side-by-side --suppress-common-lines broken.dump working.dump > > broken-working.diff > cat -n broken-working.diff >=20 > The broken-working.diff file with common lines suppressed is 236256 lines= 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. > 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. >=20 > 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: >=20 > 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 >=20 > When I grepped for mon_len, both sets of dumps looked nearly identical: >=20 > 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]; >=20 >=20 > 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$ >=20 > 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. >=20 > With LTO building pxe_utils.o, the dump looks empty: >=20 > arm-linux-gnueabihf-objdump -S boot/pxe_utils.o > pxe-notworking.dump > cat pxe-notworking.dump >=20 > boot/pxe_utils.o: file format elf32-littlearm >=20 > ^-- 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. >=20 > 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 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 Tom --HjNkcEWJ4DMx36DP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmIGitcACgkQFHw5/5Y0 tyxYRAv/XIQd2FDfGy6dZD1VhbfcV6EnDlbEMcRTP7A9jLVToP6dgC3wARC+WSu3 iwQ6uI5EFyvXZ6l7xmYcjDg+zG4/YFWi2u8+i02jLy747Vurj4UAYOhyKG+tJ2wP /sQL5GKlV60DCC5W7KuYD+4uL9DpKupJEdvgFPZia38eURHLr161baGF3Ve3ex2d utxJMjx6uJpnglliMB9rszhtbqYZuiKA3oVjgR21jAg5MqA2nzbEl2Ui7l95tntL 4sGYY/CPoGUC8l8dGnJC6Kf7o3pnF6N8IPOnvTUGVcxOuS9T3o0GOy427HuH8V+H PHBzY7GEqX6uiiDBh0PTWYM/N+1iuq9yCD6AIbl6183cDjAjTSgPyE6fQ2ivAqsE LA223oeN5i8Nfi/p3BO8rTzZvQdUMFPJblHDjV40++XqfiIjGS574lrhfyGu5RF/ i1b6YZR9+sKAxBAwtOS6duZWw30DwEDfMptHHBTaDsoBxEXKyENzY6VLzRBOsypa lCh6ySyv =PzTm -----END PGP SIGNATURE----- --HjNkcEWJ4DMx36DP--