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@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@nic.cz wrote:
On Wed, 3 Mar 2021 16:36:05 -0500 Tom Rini trini@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.