[RFC PATCH u-boot 00/12] U-Boot LTO (Sandbox + ARM Nokia RX-51)

[Pali Rohár]

On Thursday 04 March 2021 11:17:01 Tom Rini wrote:
> On Thu, Mar 04, 2021 at 09:07:33AM -0600, Adam Ford wrote:
> > On Thu, Mar 4, 2021 at 8:58 AM Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Thu, Mar 04, 2021 at 07:46:18AM -0600, Adam Ford wrote:
> > > > On Thu, Mar 4, 2021 at 4:43 AM Marek Behun <marek.behun at nic.cz> wrote:
> > > > >
> > > > > On Wed, 3 Mar 2021 16:36:05 -0500
> > > > > Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > > So, as I start testing things locally with two additional changes (1.
> > > > > > LTO by default 2. No ffunction/data-sections with LTO) we see:
> > > > > > https://gist.github.com/trini/350ab850c42293563228b8d68a1bb89a
> > > > > > as the detailed size reduction.  This also shows that with LTO we want
> > > > > > to turn off -ffunction-sections/etc as it's not useful now.
> > > > >
> > > > > Tom, I have pushed another version to github PR to trigger CI, and am
> > > > > still working on clang. You can look at the github PR if you want to
> > > > > try yourself. I have also added patch that disables
> > > > > -ffunction-section/fdata-section on arm.
> > > > >
> > > > > After I manage to make it all work in CI I will send v2 to mailing list.
> > > >
> > > > I tested this with the imx6q_logic board.  I only tested the U-Boot
> > > > portion, but it appeared to work and it booted the kernel.  The U-Boot
> > > > size reduced -7182 bytes (about 3% smaller).
> > > >
> > > > I haven't been able to successfully boot the OMAP3 boards I have yet.
> > > > I'm still looking into this.
> > >
> > > It boots (and pytest runs) on my Beagleboard xM, fwiw.
> > 
> > Interesting.  with LTO enabled, the DRAM reports 7.2 GB and hangs.
> > Without LTO, U-Boot boots fine.
> > 
> > LTO:
> > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
> > Model: LogicPD Zoom DM3730 Torpedo + Wireless Development Kit
> > Logic DM37x/OMAP35x reference board + LPDDR/NAND
> > DRAM:  7.2 GiB
> > <hang>
> > 
> > Without LTO:
> > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
> > Model: LogicPD Zoom DM3730 Torpedo + Wireless Development Kit
> > Logic DM37x/OMAP35x reference board + LPDDR/NAND
> > DRAM:  256 MiB
> > NAND:  512 MiB
> > MMC:   OMAP SD/MMC: 0
> > Loading Environment from NAND... OK
> > OMAP die ID: 619e00029ff800000168300f1502501f
> > Net:   smc911x-0
> > Hit any key to stop autoboot:  0
> > OMAP Logic #
> 
> I take it back, I had my bbxm disabled in the loop and indeed it doesn't
> boot either.  What's odd there is that N900 is omap3.

Marek and Azure tested it only in qemu-system.

We already know that real HW can do different things as emulated qemu.

Also N900 U-Boot port is somehow special compared to other OMAP3 boards,
as on N900 is U-Boot loaded by NOLO bootloader. On other OMAP3 boards
U-Boot is loaded either by SPL or X-Load. NOLO is doing basically whole
HW initialization (there are just few exceptions like eMMC...) so
started U-Boot just skips lot of initialization code. And therefore
behave differently as on other OMAP3 boards. And due to this fact,
U-Boot can chainload to U-Boot itself without any issues (IIRC this is
not possible for most boards).

During weekend I will try to test all patches on real N900 HW and say if
they are working or not. Note if U-Boot hangs prior entering into
monitor code it would be very hard / impossible to debug. It take some
time for U-Boot to start musb subsystem to export usbtty console for
debugging. So early hangs cannot be debugged via usbtty.