On Thu, Feb 10, 2022 at 8:32 AM Simon Glass <s...@chromium.org> wrote:
>
> Hi Adam,
>
> On Thu, 10 Feb 2022 at 06:57, Adam Ford <aford...@gmail.com> wrote:
> >
> > On Thu, Feb 10, 2022 at 7:56 AM Adam Ford <aford...@gmail.com> wrote:
> > >
> > > On Wed, Feb 9, 2022 at 11:16 AM Simon Glass <s...@chromium.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Wed, 9 Feb 2022 at 05:32, Tom Rini <tr...@konsulko.com> 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 <s...@chromium.org>
> > > > > > 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 lokeshvu...@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 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: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
> > > > > > <hang>
> > > > > >
> > > > > > 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_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 memory
> > > > > > size.
> > > > > >
> > > > > > If I jump ahead to the current 'master' 531c0089457:("Merge branch
> > > > > > '2022-02-08-TI-platform-updates') and revert this patch, my board
> > > > > > boots correctly again, but I am struggling to understand why.
> > > + Marek Behún
> > >
> > > > > >
> > > > > > 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 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.
>
> Another thing that might help is to put your revert in a branch and then:
>
> buildman -b <branch> <board>
>
> then
>
> buildman -b <branch> <board> -sB
>
> which will show function changes.
>
> But more directly, the DRAM calculation should be something you can
> print out and debug (perhaps with DEBUG_UART) and see where it is
> going wrong.
I have some meetings, but I'll try that this weekend. I was able to
narrow the specific file to pxe_utils.o. If I add 1 line to the
Makefile, the issue goes away:
CFLAGS_REMOVE_pxe_utils.o := $(LTO_CFLAGS)
Would this be acceptable? I haven't tested this, but I am guessing
any OMAP3 board with LTO would be affected (maybe others), and I have
5. :-(
adam
>
> Regards,
> Simon
