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 <[email protected]> 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 <[email protected]> wrote: > > > > > > > > > > On Wed, 3 Mar 2021 16:36:05 -0500 > > > > > Tom Rini <[email protected]> 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.
