* [U-Boot] tbs2910 not buildable
@ 2019-04-14 9:52 stefano babic
2019-04-14 10:46 ` Soeren Moch
0 siblings, 1 reply; 6+ messages in thread
From: stefano babic @ 2019-04-14 9:52 UTC (permalink / raw)
To: u-boot
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.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 6+ messages in thread* [U-Boot] tbs2910 not buildable 2019-04-14 9:52 [U-Boot] tbs2910 not buildable stefano babic @ 2019-04-14 10:46 ` Soeren Moch 2019-04-14 11:24 ` Stefano Babic 2019-04-22 23:19 ` Tom Rini 0 siblings, 2 replies; 6+ messages in thread From: Soeren Moch @ 2019-04-14 10:46 UTC (permalink / raw) To: u-boot 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. Thanks, Soeren ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] tbs2910 not buildable 2019-04-14 10:46 ` Soeren Moch @ 2019-04-14 11:24 ` Stefano Babic 2019-04-14 11:29 ` Sören Moch 2019-04-22 23:19 ` Tom Rini 1 sibling, 1 reply; 6+ messages in thread From: Stefano Babic @ 2019-04-14 11:24 UTC (permalink / raw) To: u-boot Hi Soeren, On 14/04/19 12:46, 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. I have explained my concerns in the past about footprint, too, but there is nothing I can do. This is the way we have to go on and we have to find solutions. > > 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. Today is Sunday, I have also not expected you was fast to answer.... ;-) It is also fine for me to wait until tomorrow. I just want to sent PR to Tom as soon as possible, because there are many developers waiting for the merge from -next. tbs2910 is the only board with issues from Travis, and I can confirm that it is still ok on u-boot-imx, next. Something new is slipped down between 2019.rc4 and 2019.04 and at the end had increased again the footprint. Thanks for checking this, Stefano Babic -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de ===================================================================== ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] tbs2910 not buildable 2019-04-14 11:24 ` Stefano Babic @ 2019-04-14 11:29 ` Sören Moch 0 siblings, 0 replies; 6+ messages in thread From: Sören Moch @ 2019-04-14 11:29 UTC (permalink / raw) To: u-boot Hi Stefano, On 14.04.19 13:24, Stefano Babic wrote: > Hi Soeren, > > On 14/04/19 12:46, 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. > I have explained my concerns in the past about footprint, too, but there > is nothing I can do. I know, therefore I cc'd Tom. > This is the way we have to go on and we have to > find solutions. > >> 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. > Today is Sunday, I have also not expected you was fast to answer.... ;-) > > It is also fine for me to wait until tomorrow. OK, I will send a patch for that. Regards, Soeren > I just want to sent PR to > Tom as soon as possible, because there are many developers waiting for > the merge from -next. tbs2910 is the only board with issues from Travis, > and I can confirm that it is still ok on u-boot-imx, next. Something new > is slipped down between 2019.rc4 and 2019.04 and at the end had > increased again the footprint. > > Thanks for checking this, > > Stefano Babic > ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] tbs2910 not buildable 2019-04-14 10:46 ` Soeren Moch 2019-04-14 11:24 ` Stefano Babic @ 2019-04-22 23:19 ` Tom Rini 2019-04-24 14:56 ` Soeren Moch 1 sibling, 1 reply; 6+ messages in thread From: Tom Rini @ 2019-04-22 23:19 UTC (permalink / raw) To: u-boot 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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190422/59fa80df/attachment.sig> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] tbs2910 not buildable 2019-04-22 23:19 ` Tom Rini @ 2019-04-24 14:56 ` Soeren Moch 0 siblings, 0 replies; 6+ messages in thread From: Soeren Moch @ 2019-04-24 14:56 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-04-24 14:56 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-14 9:52 [U-Boot] tbs2910 not buildable stefano babic 2019-04-14 10:46 ` Soeren Moch 2019-04-14 11:24 ` Stefano Babic 2019-04-14 11:29 ` Sören Moch 2019-04-22 23:19 ` Tom Rini 2019-04-24 14:56 ` Soeren Moch
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.