On 23.04.19 01:19, Tom Rini wrote: > On Sun, Apr 14, 2019 at 12:46:25PM +0200, Soeren Moch wrote: >> Hi Stefano, >> >> On 14.04.19 11:52, stefano babic wrote: >>> Hallo Soeren, >>> >>> after pulling from Tom and merging u-boot-imx, - next, your board is not >>> buildable anymore. Better: it is buildable, but size exceeds: >>> >>> arm: + tbs2910 >>> +u-boot.imx exceeds file size limit: >>> + limit: 392192 bytes >>> + actual: 396288 bytes >>> + excess: 4096 bytes >>> >>> Just dropping CONFIG_EFI_PARTITION (I supposed EFI is not used on this >>> board), solves the issue. I can do myself in this way or let me know >>> what is your preferred way. >>> >> Hm, the full name of this board is "TBS2910 Matrix ARM mini PC", so it >> is supposed to provide a full PC environment. It supports booting from >> SATA, and such disk may as well be partitioned with EFI. It is really >> terrible to drop user visible features, just to support a new "driver >> model" that is supposed to ease life for developers, but in fact is much >> work and a real pain for maintainers of existing boards, and brings >> exactly nothing for the board's users. >> >> So much for that. Now to your question. >> >> Would be OK for me to drop CONFIG_EFI_PARTITION for now since it is more >> important to get this series merged, because other boards also depend on >> the SATA patches. We can readd EFI_PARTITION support later. For sure >> there will be more patches in this development cycle. >> But if you can wait a few hours, I will look for a better solution, or >> send a formal patch for this CONFIG_EFI_PARTITION removal. > Now that I'm back from vacation, I do want to chime in here. So, yes, > this presents a difficult challenge. I don't want to encourage people > to take out functionality just to make the binary fit. And I assume the > binary size limit is so that we don't overwrite something else, so we > can't just grow it either. So what options do we have? Taking out > CONFIG_DM_WARN and CONFIG_MMC_VERBOSE gives us about 2KB. Changing the > loglevel from 4 to 3 saves another 2KB. Dropping the memtest command > (which is not helpful and discouraged) gives another 1KB. > > But these are also, well, stopgaps. Is it all going to be worth it? > Well, I hope so. We can for example gain another 1KB back by disabling > block cache, which does improve read speed from filesystems and thus > something end users see. But it could have been written without DM, > it's just a new feature and "carrot" to move to DM. > > I don't even see any obvious-to-me cases of including big hunks of data > that should be dropped, so that brings us to maybe-not-used > functionality like bootelf/bootvx/nfs and so on. Which I don't like. > > So, I'm trying to keep a harder still eye on size growth when pulling in > functionality. And I kinda wish LTO was easier to bring in as that > might really save us some space. > Thanks, Tom, for your additional suggestions. Disabling CMD_FDT in tbs2910_defconfig did the trick for this round, see [1].
Regards, Soeren [1] http://git.denx.de/?p=u-boot.git;a=commit;h=e0627f77f55ea8d606cd4b0902bc47ffaad220d0 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
