On Sat, 6 Mar 2021 05:12:12 -0600 Adam Ford aford173@gmail.com wrote:
On Fri, Mar 5, 2021 at 9:03 PM Adam Ford aford173@gmail.com wrote:
On Fri, Mar 5, 2021 at 11:10 AM Adam Ford aford173@gmail.com wrote:
On Fri, Mar 5, 2021 at 6:31 AM Stefan Roese sr@denx.de wrote:
On 05.03.21 12:25, Adam Ford wrote:
On Thu, Mar 4, 2021 at 4:33 PM Marek Behun marek.behun@nic.cz wrote:
On Thu, 4 Mar 2021 16:18:03 -0600 Adam Ford aford173@gmail.com wrote:
> diff --git a/arch/arm/mach-omap2/omap3/Makefile > b/arch/arm/mach-omap2/omap3/Makefile > index 91ed8ebc9f..a2cc21c6d2 100644 > --- a/arch/arm/mach-omap2/omap3/Makefile > +++ b/arch/arm/mach-omap2/omap3/Makefile > @@ -6,6 +6,8 @@ > # If clock.c is compiled for Thumb2, then it fails on OMAP3530 > CFLAGS_clock.o += -marm > > +CFLAGS_REMOVE_file.o := $(LTO_CFLAGS)
Eh? There is no file.c in arch/arm/mach-omap2/omap3/ directory.
It must be from something else that had changed when I did a git pull pull on your repo. I guess that's better news.
It might be a misunderstanding. Marek means that you need to replace "file" with your real filename, like:
driver_spi.c ->
+CFLAGS_REMOVE_driver_spi.o := $(LTO_CFLAGS)
I first did a git pull from his git repo, and then blindly copy-pasted the suggested link to that above directly. I don't play with Makefiles often, so I didn't really notice that I needed to match the line to an actual file. When I rebuilt, my initial issue with showing too much DDR and hanging went away, so I wrongly assumed that this fixed it. In reality, I think it was a patch that had been applied to his git repo that got pulled in at the same time.
On the testing front, I started testing the da850evm (ARM9) this morning. I ran into an issue that I apparently caused some time ago, and I'm trying to resolve that now. I have it working, but I need to clean it up. I'll push the clean-up to the ML then try the LTO on that board to see if U-Boot and/or SPL work with LTO enabled.
As of now, I have one board that seems to fully boot (imx6q_logic) and a family of boards that work in U-Boot but not SPL (omap3_logic).
After the da850em, I'll test a 64-bit Renesas board without SPL and a 64-bit NXP board with SPL to test.
On the build-testing I have done, I am seeing an average of a 10-20% reduction in size for SPL, and a ~ 3% reduction in size in U-Boot.
With a patch that I've already sent to the mailing list for the da850evm, it's booting both SPL and U-Boot
With the compiler I have, the code went from: SPL 24305 U-Boot 381930
To: SPL 20937 U-Boot 358780
For a Reduction of: SPL -3368 (-13.86%) U-Boot -23150 (-6.06%)
I didn't test the NOR or NAND booting versions of the da850evm, but I will try to do that when the time comes.
I ran the same tests on the imx8mn_beacon board, and this board boots.
Without LTO SPL 82487 U-Boot 704477
With LTO: SPL 74526 U-Boot 670859
For a reduction of: SPL -7961 (-9.65%) U-Boot -33618 (-4.77%)
Thank you Adam for these tests. I think you are right in that we should not enable LTO for all ARM boards, but only those that are tested, at least until for example about 80% of them are tested.
Marek