Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Fri, Jan 11, 2019 at 08:22:45AM +0100, Simon Goldschmidt wrote: > On Thu, Jan 10, 2019 at 5:54 PM Tom Rini wrote: > > > > On Thu, Jan 10, 2019 at 05:36:11PM +0100, Simon Goldschmidt wrote: > > > Am 10.01.2019 um 16:56 schrieb Tom Rini: > > > >On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote: > > > >>On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic wrote: > > > >>> > > > >>>Hi Tom, Soeren, > > > >>> > > > >>>On 09/01/19 23:39, Tom Rini wrote: > > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > > > >Hi Soeren, > > > > > > > >On 08/01/19 12:03, Soeren Moch wrote: > > > >>Hi Stefano, > > > >> > > > >>On 08.01.19 11:24, Stefano Babic wrote: > > > >>>Hi Soeren, > > > >>> > > > >>>On 08/01/19 11:14, Soeren Moch wrote: > > > Stefano, > > > > > > can you apply this for v2019.01? This is really a important fix > > > to avoid > > > environment and u-boot binary overwriting each other. > > > It is also a small local fix which cannot hurt anybody else. > > > >>>I will apply and I send a new PR. This is not the first fix in this > > > >>>direction, u-boot becomes pretty large, it is becoming a common > > > >>>problem. > > > >>> > > > >>Thank you very much. > > > >> > > > >>Yes, "in the good old days (tm)" there was much effort put into not > > > >>increasing the binary size for existing boards when adding new > > > >>features. > > > > > > > >Right, fully agree. > > > > > > > >>Unfortunately this is not true anymore. > > > > > > > >I get in the same trouble with more as one project. A previous rule > > > >of > > > >thumb was to reserve 512KB to the bootloader because it was pretty > > > >unthinkable that bootloader could be larger. Mhmmhhthis remember > > > >me > > > >someone else who said that 640Kb is enough for everything. > > > > > > > >Anyway, as you noted, this is a big problem in field and it makes > > > >difficult an upgrade without returning back the device to factory, > > > >what > > > >nobody wants. > > > > > > So, this is more on me, so I should probably explain a little, and > > > point > > > at the biggest culprit too. The biggest at times culprit and > > > sometimes > > > controversial thing is that we default to the EFI subsystem being on > > > by > > > default. This is 50KiB on tbs2910. > > > >>> > > > >>>I am not sure if we should point to EFI as responsible for the > > > >>>increased > > > >>>footprint or it is due to the sum of several components / factors. I > > > >>>just report my experience in last month : I had to port U-Boot for a > > > >>>customer from a not very old release (2017.01) to the current. 2017.01 > > > >>>had already (apart of FIT support) all features the customer needed, > > > >>>but > > > >>>there are issues(NAND, UBI) and I kew that they were solved later. > > > >>>Processor was an old PowerPC 8308, a quite dead SOC. I have not changed > > > >>>a lot in board code, but of course I had to reconfigure a lot. At the > > > >>>end, everything worked but I was quite astonished about footprint. I > > > >>>had: > > > >>> > > > >>>2017.01 u-boot.bin 443452 > > > >>>2018.11 u-boot.bin 654684 > > > >>> > > > >>> But the new footprint overwrote the space for the env, and I had to > > > >>>change the layout.It was not something that I could not manage and in > > > >>>this specific case, customer could handle it. I cannot say I did > > > >>>something pretty wrong to bloat the bootloader, so my feeling was that > > > >>>there is not a specific part responsible for the increased size, but > > > >>>each component is slightly bigger and they sizes sum at the end. > > > >>> > > > >>> > > > Why default? Well, "everyone" > > > agrees that defaulting to EFI application support means the widest > > > choice of out of the box software support. > > > >>> > > > >>>I am unsure about this - just my two cents. > > > >>> > > > >>>I agree with you if we are talking about evaluation boards and / or > > > >>>boards supposed to run different distros (or in any case, more flavour > > > >>>of software). > > > >>> > > > >>>But there are a lot of "custom" boards (maintained in U-Boot) that runs > > > >>>for a specific project and won't run any other kind of software. If a > > > >>>device is a navigation system, a network controller, or whatever, it > > > >>>will just do this job until its EOL. > > > >>> > > > >>>Specially for older boards, a new feature should not be activated as > > > >>>default. At the beginning, police in U-Boot was to set just what should > > > >>>be required in the bootloader, without setting what is not needed as > > > >>>default. So default was off instead of on. > > > >> > > > >>I aslo think that would suit U-Boot better. For example, I have one > > > >>configuration where I need to squeeze U-Boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Fri, Jan 11, 2019 at 02:11:38PM +0100, Soeren Moch wrote: > > > On 10.01.19 16:06, Tom Rini wrote: > > On Thu, Jan 10, 2019 at 03:03:27PM +0100, Soeren Moch wrote: > >> > >> On 10.01.19 03:30, Tom Rini wrote: > >>> On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote: > On 09.01.19 23:39, Tom Rini wrote: > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > >> Hi Soeren, > >> > >> On 08/01/19 12:03, Soeren Moch wrote: > >>> Hi Stefano, > >>> > >>> On 08.01.19 11:24, Stefano Babic wrote: > Hi Soeren, > > On 08/01/19 11:14, Soeren Moch wrote: > > Stefano, > > > > can you apply this for v2019.01? This is really a important fix to > > avoid > > environment and u-boot binary overwriting each other. > > It is also a small local fix which cannot hurt anybody else. > I will apply and I send a new PR. This is not the first fix in this > direction, u-boot becomes pretty large, it is becoming a common > problem. > > >>> Thank you very much. > >>> > >>> Yes, "in the good old days (tm)" there was much effort put into not > >>> increasing the binary size for existing boards when adding new > >>> features. > >> Right, fully agree. > >> > >>> Unfortunately this is not true anymore. > >> I get in the same trouble with more as one project. A previous rule of > >> thumb was to reserve 512KB to the bootloader because it was pretty > >> unthinkable that bootloader could be larger. Mhmmhhthis remember me > >> someone else who said that 640Kb is enough for everything. > >> > >> Anyway, as you noted, this is a big problem in field and it makes > >> difficult an upgrade without returning back the device to factory, what > >> nobody wants. > > So, this is more on me, so I should probably explain a little, and point > > at the biggest culprit too. The biggest at times culprit and sometimes > > controversial thing is that we default to the EFI subsystem being on by > > default. This is 50KiB on tbs2910. Why default? Well, "everyone" > > agrees that defaulting to EFI application support means the widest > > choice of out of the box software support. > > > Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64 > boards. The usual way for firmware updates was to load a special > >>> Yes, there's some amount of chicken-and-egg but it's there and growing. > >>> > UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or > more convenient these days to support EFI, maybe a good idea to > default=y, but why this is not disabled in old board's defconfigs then? > >>> While it's default y and means we're even enabling it on pre-v7 > >>> processors, the general answer is that defaults matter especially when > >>> things get forked off for a custom project or for a new reference > >>> platform, and it's something that can always be turned off. i.MX is in > >>> fact where a number of platforms have gone for opt-out. > >> So default y might be OK if this feature is desired for new platforms. > >> But I would prefer that the same patch series that introduces the > >> default y also inserts all the "# CONFIG_WHATEVER is not set" in old > >> board's defconfigs. > > But that's close to the opposite of why you make something default y, > > which I really do try and not do so often, but maybe I'm also not doing > > a great job there. > > > > But, digging into specifics for just a moment, > > https://www.tbsdtv.com/launch/tbs-2910-matrix-arm-mini-pc.html is what > > we're talking about here and that you can install $whatever on it as > > $whatever expects to be able to have its EFI-application installer just > > run (and be passed a device tree for the kernel) is part of why > > EFI_LOADER is default enabled. > > > > That's not saying you shouldn't still disable it if you need the space. > > > > [snip] > The bigger challenge are the BLK and DM conversions for the next u-boot > version. I absolutely cannot understand how somebody can insist on these > changes, while letting the board maintainers completely alone with > required driver adaptations. Board maintainers are not familiar with > driver code, a lot of board maintainers would need to work in parallel > on this (when no person is designated for this work, all maintainers are > equally responsible), while the author of the BLK/DM core code is very > familiar with the required changes. The necessary API adaptations in > drivers would be a no-brainer for him, since nothing of the actual > hardware access code needs to be adapted. At least that is my > understanding. > But someone (who actually?) decided to simply offload the second > conversion step (drivers) to somebody else, with no help offered for >
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On 10.01.19 16:53, Tom Rini wrote: > On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote: >> Hi Tom, Soeren, >> >> On 09/01/19 23:39, Tom Rini wrote: > [snip] >>> Why default? Well, "everyone" >>> agrees that defaulting to EFI application support means the widest >>> choice of out of the box software support. >> I am unsure about this - just my two cents. >> >> I agree with you if we are talking about evaluation boards and / or >> boards supposed to run different distros (or in any case, more flavour >> of software). >> >> But there are a lot of "custom" boards (maintained in U-Boot) that runs >> for a specific project and won't run any other kind of software. If a >> device is a navigation system, a network controller, or whatever, it >> will just do this job until its EOL. >> >> Specially for older boards, a new feature should not be activated as >> default. At the beginning, police in U-Boot was to set just what should >> be required in the bootloader, without setting what is not needed as >> default. So default was off instead of on. > So, part of what I'm taking away from all of this is that I really do > need to see how many people I can bcc at once before gmail gets really > mad at me, Yes, there's a number of end-user devices we have support > for in mainline that are intended to be re-used as the manufacturer > intended. Part of the Kconfig migration means that they can more easily > remove stuff they don't want/need than before. But there's also the > repurposed boards, and lots of not really clear cut cases, such as the > tbs2910 where while it's not my call, does fall into the "enable EFI > loader support for your end users maybe?" category. And in the end, I > should have emailed off everyone with a gentle reminder to inspect and > trim their configs. > My view on this: The overwhelming majority of users use u-boot as _bootloader_, not as their favorite toy to play around with every two month. Users want stable software with bugfixes, not fancy new untested features. For a lot of users it is a real pain if linux does not boot anymore. Often u-boot updates are done from a running linux system. Often users don't have access to serial adapters to re-animate bricked boards (e.g. they are sold separately for tbs2910). So I really prefer new features disabled on old boards. 'default y' may be good to include modern features for new platforms. But for old boards then include "# CONFIG_WHATEVER is not set" in defconfigs. Let board maintainers do their job in testing new features and activate them when properly tested on their platform and found useful. Recently a lot of code is committed to u-boot by the original author without any reviewed-by or tested-by tags. We should not force the testing effort on ordinary users by activation of new features by default. Otherwise for me the risk is too high to rendering user systems un-bootable just by updating "stable" u-boot releases. For me the real advantage of Kconfig is that interested users can _enable_ new features easily, test this and maybe propose as new defconfig to board maintainers. So there is no disadvantage for experienced users, and no harm for users that only follow available howtos and are not able to handle sudden changes in behavior. Regards, Soeren ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On 10.01.19 16:06, Tom Rini wrote: > On Thu, Jan 10, 2019 at 03:03:27PM +0100, Soeren Moch wrote: >> >> On 10.01.19 03:30, Tom Rini wrote: >>> On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote: On 09.01.19 23:39, Tom Rini wrote: > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: >> Hi Soeren, >> >> On 08/01/19 12:03, Soeren Moch wrote: >>> Hi Stefano, >>> >>> On 08.01.19 11:24, Stefano Babic wrote: Hi Soeren, On 08/01/19 11:14, Soeren Moch wrote: > Stefano, > > can you apply this for v2019.01? This is really a important fix to > avoid > environment and u-boot binary overwriting each other. > It is also a small local fix which cannot hurt anybody else. I will apply and I send a new PR. This is not the first fix in this direction, u-boot becomes pretty large, it is becoming a common problem. >>> Thank you very much. >>> >>> Yes, "in the good old days (tm)" there was much effort put into not >>> increasing the binary size for existing boards when adding new features. >> Right, fully agree. >> >>> Unfortunately this is not true anymore. >> I get in the same trouble with more as one project. A previous rule of >> thumb was to reserve 512KB to the bootloader because it was pretty >> unthinkable that bootloader could be larger. Mhmmhhthis remember me >> someone else who said that 640Kb is enough for everything. >> >> Anyway, as you noted, this is a big problem in field and it makes >> difficult an upgrade without returning back the device to factory, what >> nobody wants. > So, this is more on me, so I should probably explain a little, and point > at the biggest culprit too. The biggest at times culprit and sometimes > controversial thing is that we default to the EFI subsystem being on by > default. This is 50KiB on tbs2910. Why default? Well, "everyone" > agrees that defaulting to EFI application support means the widest > choice of out of the box software support. > Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64 boards. The usual way for firmware updates was to load a special >>> Yes, there's some amount of chicken-and-egg but it's there and growing. >>> UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or more convenient these days to support EFI, maybe a good idea to default=y, but why this is not disabled in old board's defconfigs then? >>> While it's default y and means we're even enabling it on pre-v7 >>> processors, the general answer is that defaults matter especially when >>> things get forked off for a custom project or for a new reference >>> platform, and it's something that can always be turned off. i.MX is in >>> fact where a number of platforms have gone for opt-out. >> So default y might be OK if this feature is desired for new platforms. >> But I would prefer that the same patch series that introduces the >> default y also inserts all the "# CONFIG_WHATEVER is not set" in old >> board's defconfigs. > But that's close to the opposite of why you make something default y, > which I really do try and not do so often, but maybe I'm also not doing > a great job there. > > But, digging into specifics for just a moment, > https://www.tbsdtv.com/launch/tbs-2910-matrix-arm-mini-pc.html is what > we're talking about here and that you can install $whatever on it as > $whatever expects to be able to have its EFI-application installer just > run (and be passed a device tree for the kernel) is part of why > EFI_LOADER is default enabled. > > That's not saying you shouldn't still disable it if you need the space. > > [snip] The bigger challenge are the BLK and DM conversions for the next u-boot version. I absolutely cannot understand how somebody can insist on these changes, while letting the board maintainers completely alone with required driver adaptations. Board maintainers are not familiar with driver code, a lot of board maintainers would need to work in parallel on this (when no person is designated for this work, all maintainers are equally responsible), while the author of the BLK/DM core code is very familiar with the required changes. The necessary API adaptations in drivers would be a no-brainer for him, since nothing of the actual hardware access code needs to be adapted. At least that is my understanding. But someone (who actually?) decided to simply offload the second conversion step (drivers) to somebody else, with no help offered for this, but with short deadlines. I never heard that this can work in community projects. If the driver adaptations are done for a single board from each family, then the third step (adapting board configurations) is a job for board
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Thu, Jan 10, 2019 at 5:54 PM Tom Rini wrote: > > On Thu, Jan 10, 2019 at 05:36:11PM +0100, Simon Goldschmidt wrote: > > Am 10.01.2019 um 16:56 schrieb Tom Rini: > > >On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote: > > >>On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic wrote: > > >>> > > >>>Hi Tom, Soeren, > > >>> > > >>>On 09/01/19 23:39, Tom Rini wrote: > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > > >Hi Soeren, > > > > > >On 08/01/19 12:03, Soeren Moch wrote: > > >>Hi Stefano, > > >> > > >>On 08.01.19 11:24, Stefano Babic wrote: > > >>>Hi Soeren, > > >>> > > >>>On 08/01/19 11:14, Soeren Moch wrote: > > Stefano, > > > > can you apply this for v2019.01? This is really a important fix to > > avoid > > environment and u-boot binary overwriting each other. > > It is also a small local fix which cannot hurt anybody else. > > >>>I will apply and I send a new PR. This is not the first fix in this > > >>>direction, u-boot becomes pretty large, it is becoming a common > > >>>problem. > > >>> > > >>Thank you very much. > > >> > > >>Yes, "in the good old days (tm)" there was much effort put into not > > >>increasing the binary size for existing boards when adding new > > >>features. > > > > > >Right, fully agree. > > > > > >>Unfortunately this is not true anymore. > > > > > >I get in the same trouble with more as one project. A previous rule of > > >thumb was to reserve 512KB to the bootloader because it was pretty > > >unthinkable that bootloader could be larger. Mhmmhhthis remember me > > >someone else who said that 640Kb is enough for everything. > > > > > >Anyway, as you noted, this is a big problem in field and it makes > > >difficult an upgrade without returning back the device to factory, what > > >nobody wants. > > > > So, this is more on me, so I should probably explain a little, and point > > at the biggest culprit too. The biggest at times culprit and sometimes > > controversial thing is that we default to the EFI subsystem being on by > > default. This is 50KiB on tbs2910. > > >>> > > >>>I am not sure if we should point to EFI as responsible for the increased > > >>>footprint or it is due to the sum of several components / factors. I > > >>>just report my experience in last month : I had to port U-Boot for a > > >>>customer from a not very old release (2017.01) to the current. 2017.01 > > >>>had already (apart of FIT support) all features the customer needed, but > > >>>there are issues(NAND, UBI) and I kew that they were solved later. > > >>>Processor was an old PowerPC 8308, a quite dead SOC. I have not changed > > >>>a lot in board code, but of course I had to reconfigure a lot. At the > > >>>end, everything worked but I was quite astonished about footprint. I had: > > >>> > > >>>2017.01 u-boot.bin 443452 > > >>>2018.11 u-boot.bin 654684 > > >>> > > >>> But the new footprint overwrote the space for the env, and I had to > > >>>change the layout.It was not something that I could not manage and in > > >>>this specific case, customer could handle it. I cannot say I did > > >>>something pretty wrong to bloat the bootloader, so my feeling was that > > >>>there is not a specific part responsible for the increased size, but > > >>>each component is slightly bigger and they sizes sum at the end. > > >>> > > >>> > > Why default? Well, "everyone" > > agrees that defaulting to EFI application support means the widest > > choice of out of the box software support. > > >>> > > >>>I am unsure about this - just my two cents. > > >>> > > >>>I agree with you if we are talking about evaluation boards and / or > > >>>boards supposed to run different distros (or in any case, more flavour > > >>>of software). > > >>> > > >>>But there are a lot of "custom" boards (maintained in U-Boot) that runs > > >>>for a specific project and won't run any other kind of software. If a > > >>>device is a navigation system, a network controller, or whatever, it > > >>>will just do this job until its EOL. > > >>> > > >>>Specially for older boards, a new feature should not be activated as > > >>>default. At the beginning, police in U-Boot was to set just what should > > >>>be required in the bootloader, without setting what is not needed as > > >>>default. So default was off instead of on. > > >> > > >>I aslo think that would suit U-Boot better. For example, I have one > > >>configuration where I need to squeeze U-Boot into 204 KiB. For me this > > >>currently means I have to re-check the defconfig for every update to > > >>disable new features that are now on by default. I think having those > > >>default to off and enabling them via defconfig if required would be > > >>better. > > > > > >Can SoCFPGA not set the option to make a link failure if you grow beyond > > >204KiB?
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Thu, Jan 10, 2019 at 5:54 PM Tom Rini wrote: > > On Thu, Jan 10, 2019 at 05:36:11PM +0100, Simon Goldschmidt wrote: > > Am 10.01.2019 um 16:56 schrieb Tom Rini: > > >On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote: > > >>On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic wrote: > > >>> > > >>>Hi Tom, Soeren, > > >>> > > >>>On 09/01/19 23:39, Tom Rini wrote: > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > > >Hi Soeren, > > > > > >On 08/01/19 12:03, Soeren Moch wrote: > > >>Hi Stefano, > > >> > > >>On 08.01.19 11:24, Stefano Babic wrote: > > >>>Hi Soeren, > > >>> > > >>>On 08/01/19 11:14, Soeren Moch wrote: > > Stefano, > > > > can you apply this for v2019.01? This is really a important fix to > > avoid > > environment and u-boot binary overwriting each other. > > It is also a small local fix which cannot hurt anybody else. > > >>>I will apply and I send a new PR. This is not the first fix in this > > >>>direction, u-boot becomes pretty large, it is becoming a common > > >>>problem. > > >>> > > >>Thank you very much. > > >> > > >>Yes, "in the good old days (tm)" there was much effort put into not > > >>increasing the binary size for existing boards when adding new > > >>features. > > > > > >Right, fully agree. > > > > > >>Unfortunately this is not true anymore. > > > > > >I get in the same trouble with more as one project. A previous rule of > > >thumb was to reserve 512KB to the bootloader because it was pretty > > >unthinkable that bootloader could be larger. Mhmmhhthis remember me > > >someone else who said that 640Kb is enough for everything. > > > > > >Anyway, as you noted, this is a big problem in field and it makes > > >difficult an upgrade without returning back the device to factory, what > > >nobody wants. > > > > So, this is more on me, so I should probably explain a little, and point > > at the biggest culprit too. The biggest at times culprit and sometimes > > controversial thing is that we default to the EFI subsystem being on by > > default. This is 50KiB on tbs2910. > > >>> > > >>>I am not sure if we should point to EFI as responsible for the increased > > >>>footprint or it is due to the sum of several components / factors. I > > >>>just report my experience in last month : I had to port U-Boot for a > > >>>customer from a not very old release (2017.01) to the current. 2017.01 > > >>>had already (apart of FIT support) all features the customer needed, but > > >>>there are issues(NAND, UBI) and I kew that they were solved later. > > >>>Processor was an old PowerPC 8308, a quite dead SOC. I have not changed > > >>>a lot in board code, but of course I had to reconfigure a lot. At the > > >>>end, everything worked but I was quite astonished about footprint. I had: > > >>> > > >>>2017.01 u-boot.bin 443452 > > >>>2018.11 u-boot.bin 654684 > > >>> > > >>> But the new footprint overwrote the space for the env, and I had to > > >>>change the layout.It was not something that I could not manage and in > > >>>this specific case, customer could handle it. I cannot say I did > > >>>something pretty wrong to bloat the bootloader, so my feeling was that > > >>>there is not a specific part responsible for the increased size, but > > >>>each component is slightly bigger and they sizes sum at the end. > > >>> > > >>> > > Why default? Well, "everyone" > > agrees that defaulting to EFI application support means the widest > > choice of out of the box software support. > > >>> > > >>>I am unsure about this - just my two cents. > > >>> > > >>>I agree with you if we are talking about evaluation boards and / or > > >>>boards supposed to run different distros (or in any case, more flavour > > >>>of software). > > >>> > > >>>But there are a lot of "custom" boards (maintained in U-Boot) that runs > > >>>for a specific project and won't run any other kind of software. If a > > >>>device is a navigation system, a network controller, or whatever, it > > >>>will just do this job until its EOL. > > >>> > > >>>Specially for older boards, a new feature should not be activated as > > >>>default. At the beginning, police in U-Boot was to set just what should > > >>>be required in the bootloader, without setting what is not needed as > > >>>default. So default was off instead of on. > > >> > > >>I aslo think that would suit U-Boot better. For example, I have one > > >>configuration where I need to squeeze U-Boot into 204 KiB. For me this > > >>currently means I have to re-check the defconfig for every update to > > >>disable new features that are now on by default. I think having those > > >>default to off and enabling them via defconfig if required would be > > >>better. > > > > > >Can SoCFPGA not set the option to make a link failure if you grow beyond > > >204KiB?
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Thu, Jan 10, 2019 at 11:47 PM Stefano Babic wrote: > > Hi Tom, > > On 10/01/19 16:12, Tom Rini wrote: > > On Thu, Jan 10, 2019 at 03:51:51PM +0100, Stefano Babic wrote: > >> Hi Tom, > >> > >> On 10/01/19 15:44, Tom Rini wrote: > >>> On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote: > Hi Tom, Soeren, > > On 09/01/19 23:39, Tom Rini wrote: > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > >> Hi Soeren, > >> > >> On 08/01/19 12:03, Soeren Moch wrote: > >>> Hi Stefano, > >>> > >>> On 08.01.19 11:24, Stefano Babic wrote: > Hi Soeren, > > On 08/01/19 11:14, Soeren Moch wrote: > > Stefano, > > > > can you apply this for v2019.01? This is really a important fix to > > avoid > > environment and u-boot binary overwriting each other. > > It is also a small local fix which cannot hurt anybody else. > I will apply and I send a new PR. This is not the first fix in this > direction, u-boot becomes pretty large, it is becoming a common > problem. > > >>> Thank you very much. > >>> > >>> Yes, "in the good old days (tm)" there was much effort put into not > >>> increasing the binary size for existing boards when adding new > >>> features. > >> > >> Right, fully agree. > >> > >>> Unfortunately this is not true anymore. > >> > >> I get in the same trouble with more as one project. A previous rule of > >> thumb was to reserve 512KB to the bootloader because it was pretty > >> unthinkable that bootloader could be larger. Mhmmhhthis remember me > >> someone else who said that 640Kb is enough for everything. > >> > >> Anyway, as you noted, this is a big problem in field and it makes > >> difficult an upgrade without returning back the device to factory, what > >> nobody wants. > > > > So, this is more on me, so I should probably explain a little, and point > > at the biggest culprit too. The biggest at times culprit and sometimes > > controversial thing is that we default to the EFI subsystem being on by > > default. This is 50KiB on tbs2910. > > I am not sure if we should point to EFI as responsible for the increased > footprint or it is due to the sum of several components / factors. I > just report my experience in last month : I had to port U-Boot for a > customer from a not very old release (2017.01) to the current. 2017.01 > had already (apart of FIT support) all features the customer needed, but > there are issues(NAND, UBI) and I kew that they were solved later. > Processor was an old PowerPC 8308, a quite dead SOC. I have not changed > a lot in board code, but of course I had to reconfigure a lot. At the > end, everything worked but I was quite astonished about footprint. I had: > > 2017.01u-boot.bin 443452 > 2018.11 u-boot.bin 654684 > I'm splitting my reply here into two emails. This here concerns the > >>> heck out of me. But I don't see it on MPC8308RDB. There I see: > >>>powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text > >>> +6847.0 > >>> MPC8308RDB : all -124241 bss -131040 data -48 text +6847 > >>>u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 > >>> (-125646) > >> > >> Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but > >> it is not MPC8308RDB. But nevertheless, I could not understand the > >> difference is sitze. > > > > Right, I understand, that's just the first MPC83xx board I spotted, and > > I wanted to see if all platforms had such unreasonable growth. You're > > showing your custom platform went up by _200_ kilobytes. > > I have found that one of the major reason is the different toolchain. > 2018.11 was built with the toolchain requested by customer, it was gcc > 6.4. I built 2017.01 with buildman and fetching the toolchain, that > means 7.3. The same U-Boot versione produces very different footprint, > much better with the newer toolchain. At least 50-60KB are due to the > toolchain. LibFDT + FIT image (new features I added) produces ~70Kb more > code. But then, yes, I want to have them. So at the end, one big > responsible is the toolchain. So partially I am responsible for new > footprint (new features), the rest is done by toolchain. That looked promising, so I gave it a try as well: I'm normally using gcc 6.3 from Debian 9. Comparing the sizes of this and buildman-provided 7.3, I got a reduction of 100-200 Bytes only (both for SPL and U-Boot) with 7.3. So your 50 KiB reduction must have been a corner case I guess... Regards, Simon > > > > > >>> And in terms of .bins: > >>> -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 > >>> /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin >
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
Hi Tom, On 10/01/19 16:12, Tom Rini wrote: > On Thu, Jan 10, 2019 at 03:51:51PM +0100, Stefano Babic wrote: >> Hi Tom, >> >> On 10/01/19 15:44, Tom Rini wrote: >>> On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote: Hi Tom, Soeren, On 09/01/19 23:39, Tom Rini wrote: > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: >> Hi Soeren, >> >> On 08/01/19 12:03, Soeren Moch wrote: >>> Hi Stefano, >>> >>> On 08.01.19 11:24, Stefano Babic wrote: Hi Soeren, On 08/01/19 11:14, Soeren Moch wrote: > Stefano, > > can you apply this for v2019.01? This is really a important fix to > avoid > environment and u-boot binary overwriting each other. > It is also a small local fix which cannot hurt anybody else. I will apply and I send a new PR. This is not the first fix in this direction, u-boot becomes pretty large, it is becoming a common problem. >>> Thank you very much. >>> >>> Yes, "in the good old days (tm)" there was much effort put into not >>> increasing the binary size for existing boards when adding new features. >> >> Right, fully agree. >> >>> Unfortunately this is not true anymore. >> >> I get in the same trouble with more as one project. A previous rule of >> thumb was to reserve 512KB to the bootloader because it was pretty >> unthinkable that bootloader could be larger. Mhmmhhthis remember me >> someone else who said that 640Kb is enough for everything. >> >> Anyway, as you noted, this is a big problem in field and it makes >> difficult an upgrade without returning back the device to factory, what >> nobody wants. > > So, this is more on me, so I should probably explain a little, and point > at the biggest culprit too. The biggest at times culprit and sometimes > controversial thing is that we default to the EFI subsystem being on by > default. This is 50KiB on tbs2910. I am not sure if we should point to EFI as responsible for the increased footprint or it is due to the sum of several components / factors. I just report my experience in last month : I had to port U-Boot for a customer from a not very old release (2017.01) to the current. 2017.01 had already (apart of FIT support) all features the customer needed, but there are issues(NAND, UBI) and I kew that they were solved later. Processor was an old PowerPC 8308, a quite dead SOC. I have not changed a lot in board code, but of course I had to reconfigure a lot. At the end, everything worked but I was quite astonished about footprint. I had: 2017.01u-boot.bin 443452 2018.11 u-boot.bin 654684 I'm splitting my reply here into two emails. This here concerns the >>> heck out of me. But I don't see it on MPC8308RDB. There I see: >>>powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text >>> +6847.0 >>> MPC8308RDB : all -124241 bss -131040 data -48 text +6847 >>>u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 >>> (-125646) >> >> Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but >> it is not MPC8308RDB. But nevertheless, I could not understand the >> difference is sitze. > > Right, I understand, that's just the first MPC83xx board I spotted, and > I wanted to see if all platforms had such unreasonable growth. You're > showing your custom platform went up by _200_ kilobytes. I have found that one of the major reason is the different toolchain. 2018.11 was built with the toolchain requested by customer, it was gcc 6.4. I built 2017.01 with buildman and fetching the toolchain, that means 7.3. The same U-Boot versione produces very different footprint, much better with the newer toolchain. At least 50-60KB are due to the toolchain. LibFDT + FIT image (new features I added) produces ~70Kb more code. But then, yes, I want to have them. So at the end, one big responsible is the toolchain. So partially I am responsible for new footprint (new features), the rest is done by toolchain. > >>> And in terms of .bins: >>> -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 >>> /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin >>> -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 >>> /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin >>> >>> I am doing all of mpc83xx now to see if something else trips such a >>> large growth. >>> >> >> I will do the same here on this board and try to understand where the >> difference is coming from. I will report to you, then. > > Thanks! > Regards, Stefano ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Thu, Jan 10, 2019 at 05:36:11PM +0100, Simon Goldschmidt wrote: > Am 10.01.2019 um 16:56 schrieb Tom Rini: > >On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote: > >>On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic wrote: > >>> > >>>Hi Tom, Soeren, > >>> > >>>On 09/01/19 23:39, Tom Rini wrote: > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > >Hi Soeren, > > > >On 08/01/19 12:03, Soeren Moch wrote: > >>Hi Stefano, > >> > >>On 08.01.19 11:24, Stefano Babic wrote: > >>>Hi Soeren, > >>> > >>>On 08/01/19 11:14, Soeren Moch wrote: > Stefano, > > can you apply this for v2019.01? This is really a important fix to > avoid > environment and u-boot binary overwriting each other. > It is also a small local fix which cannot hurt anybody else. > >>>I will apply and I send a new PR. This is not the first fix in this > >>>direction, u-boot becomes pretty large, it is becoming a common > >>>problem. > >>> > >>Thank you very much. > >> > >>Yes, "in the good old days (tm)" there was much effort put into not > >>increasing the binary size for existing boards when adding new features. > > > >Right, fully agree. > > > >>Unfortunately this is not true anymore. > > > >I get in the same trouble with more as one project. A previous rule of > >thumb was to reserve 512KB to the bootloader because it was pretty > >unthinkable that bootloader could be larger. Mhmmhhthis remember me > >someone else who said that 640Kb is enough for everything. > > > >Anyway, as you noted, this is a big problem in field and it makes > >difficult an upgrade without returning back the device to factory, what > >nobody wants. > > So, this is more on me, so I should probably explain a little, and point > at the biggest culprit too. The biggest at times culprit and sometimes > controversial thing is that we default to the EFI subsystem being on by > default. This is 50KiB on tbs2910. > >>> > >>>I am not sure if we should point to EFI as responsible for the increased > >>>footprint or it is due to the sum of several components / factors. I > >>>just report my experience in last month : I had to port U-Boot for a > >>>customer from a not very old release (2017.01) to the current. 2017.01 > >>>had already (apart of FIT support) all features the customer needed, but > >>>there are issues(NAND, UBI) and I kew that they were solved later. > >>>Processor was an old PowerPC 8308, a quite dead SOC. I have not changed > >>>a lot in board code, but of course I had to reconfigure a lot. At the > >>>end, everything worked but I was quite astonished about footprint. I had: > >>> > >>>2017.01 u-boot.bin 443452 > >>>2018.11 u-boot.bin 654684 > >>> > >>> But the new footprint overwrote the space for the env, and I had to > >>>change the layout.It was not something that I could not manage and in > >>>this specific case, customer could handle it. I cannot say I did > >>>something pretty wrong to bloat the bootloader, so my feeling was that > >>>there is not a specific part responsible for the increased size, but > >>>each component is slightly bigger and they sizes sum at the end. > >>> > >>> > Why default? Well, "everyone" > agrees that defaulting to EFI application support means the widest > choice of out of the box software support. > >>> > >>>I am unsure about this - just my two cents. > >>> > >>>I agree with you if we are talking about evaluation boards and / or > >>>boards supposed to run different distros (or in any case, more flavour > >>>of software). > >>> > >>>But there are a lot of "custom" boards (maintained in U-Boot) that runs > >>>for a specific project and won't run any other kind of software. If a > >>>device is a navigation system, a network controller, or whatever, it > >>>will just do this job until its EOL. > >>> > >>>Specially for older boards, a new feature should not be activated as > >>>default. At the beginning, police in U-Boot was to set just what should > >>>be required in the bootloader, without setting what is not needed as > >>>default. So default was off instead of on. > >> > >>I aslo think that would suit U-Boot better. For example, I have one > >>configuration where I need to squeeze U-Boot into 204 KiB. For me this > >>currently means I have to re-check the defconfig for every update to > >>disable new features that are now on by default. I think having those > >>default to off and enabling them via defconfig if required would be better. > > > >Can SoCFPGA not set the option to make a link failure if you grow beyond > >204KiB? As part of this thread, the only new default y thing since > >v2018.01 at least is CRC16-CCITT support in "hash". > > Well, this is a non-mainline config. Plus I keep having problems with the > size check in that it does not account for the DTB. Wait, that was for
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
Am 10.01.2019 um 16:56 schrieb Tom Rini: On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote: On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic wrote: Hi Tom, Soeren, On 09/01/19 23:39, Tom Rini wrote: On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: Hi Soeren, On 08/01/19 12:03, Soeren Moch wrote: Hi Stefano, On 08.01.19 11:24, Stefano Babic wrote: Hi Soeren, On 08/01/19 11:14, Soeren Moch wrote: Stefano, can you apply this for v2019.01? This is really a important fix to avoid environment and u-boot binary overwriting each other. It is also a small local fix which cannot hurt anybody else. I will apply and I send a new PR. This is not the first fix in this direction, u-boot becomes pretty large, it is becoming a common problem. Thank you very much. Yes, "in the good old days (tm)" there was much effort put into not increasing the binary size for existing boards when adding new features. Right, fully agree. Unfortunately this is not true anymore. I get in the same trouble with more as one project. A previous rule of thumb was to reserve 512KB to the bootloader because it was pretty unthinkable that bootloader could be larger. Mhmmhhthis remember me someone else who said that 640Kb is enough for everything. Anyway, as you noted, this is a big problem in field and it makes difficult an upgrade without returning back the device to factory, what nobody wants. So, this is more on me, so I should probably explain a little, and point at the biggest culprit too. The biggest at times culprit and sometimes controversial thing is that we default to the EFI subsystem being on by default. This is 50KiB on tbs2910. I am not sure if we should point to EFI as responsible for the increased footprint or it is due to the sum of several components / factors. I just report my experience in last month : I had to port U-Boot for a customer from a not very old release (2017.01) to the current. 2017.01 had already (apart of FIT support) all features the customer needed, but there are issues(NAND, UBI) and I kew that they were solved later. Processor was an old PowerPC 8308, a quite dead SOC. I have not changed a lot in board code, but of course I had to reconfigure a lot. At the end, everything worked but I was quite astonished about footprint. I had: 2017.01 u-boot.bin 443452 2018.11 u-boot.bin 654684 But the new footprint overwrote the space for the env, and I had to change the layout.It was not something that I could not manage and in this specific case, customer could handle it. I cannot say I did something pretty wrong to bloat the bootloader, so my feeling was that there is not a specific part responsible for the increased size, but each component is slightly bigger and they sizes sum at the end. Why default? Well, "everyone" agrees that defaulting to EFI application support means the widest choice of out of the box software support. I am unsure about this - just my two cents. I agree with you if we are talking about evaluation boards and / or boards supposed to run different distros (or in any case, more flavour of software). But there are a lot of "custom" boards (maintained in U-Boot) that runs for a specific project and won't run any other kind of software. If a device is a navigation system, a network controller, or whatever, it will just do this job until its EOL. Specially for older boards, a new feature should not be activated as default. At the beginning, police in U-Boot was to set just what should be required in the bootloader, without setting what is not needed as default. So default was off instead of on. I aslo think that would suit U-Boot better. For example, I have one configuration where I need to squeeze U-Boot into 204 KiB. For me this currently means I have to re-check the defconfig for every update to disable new features that are now on by default. I think having those default to off and enabling them via defconfig if required would be better. Can SoCFPGA not set the option to make a link failure if you grow beyond 204KiB? As part of this thread, the only new default y thing since v2018.01 at least is CRC16-CCITT support in "hash". Well, this is a non-mainline config. Plus I keep having problems with the size check in that it does not account for the DTB. Wait, that was for SPL, how do you enable a size check for U-Boot? Anyway, if new default y things aren't the problem, it's probably an increasement here and there, like Stefano said... :-( Thanks, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote: > On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic wrote: > > > > Hi Tom, Soeren, > > > > On 09/01/19 23:39, Tom Rini wrote: > > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > > >> Hi Soeren, > > >> > > >> On 08/01/19 12:03, Soeren Moch wrote: > > >>> Hi Stefano, > > >>> > > >>> On 08.01.19 11:24, Stefano Babic wrote: > > Hi Soeren, > > > > On 08/01/19 11:14, Soeren Moch wrote: > > > Stefano, > > > > > > can you apply this for v2019.01? This is really a important fix to > > > avoid > > > environment and u-boot binary overwriting each other. > > > It is also a small local fix which cannot hurt anybody else. > > I will apply and I send a new PR. This is not the first fix in this > > direction, u-boot becomes pretty large, it is becoming a common > > problem. > > > > >>> Thank you very much. > > >>> > > >>> Yes, "in the good old days (tm)" there was much effort put into not > > >>> increasing the binary size for existing boards when adding new features. > > >> > > >> Right, fully agree. > > >> > > >>> Unfortunately this is not true anymore. > > >> > > >> I get in the same trouble with more as one project. A previous rule of > > >> thumb was to reserve 512KB to the bootloader because it was pretty > > >> unthinkable that bootloader could be larger. Mhmmhhthis remember me > > >> someone else who said that 640Kb is enough for everything. > > >> > > >> Anyway, as you noted, this is a big problem in field and it makes > > >> difficult an upgrade without returning back the device to factory, what > > >> nobody wants. > > > > > > So, this is more on me, so I should probably explain a little, and point > > > at the biggest culprit too. The biggest at times culprit and sometimes > > > controversial thing is that we default to the EFI subsystem being on by > > > default. This is 50KiB on tbs2910. > > > > I am not sure if we should point to EFI as responsible for the increased > > footprint or it is due to the sum of several components / factors. I > > just report my experience in last month : I had to port U-Boot for a > > customer from a not very old release (2017.01) to the current. 2017.01 > > had already (apart of FIT support) all features the customer needed, but > > there are issues(NAND, UBI) and I kew that they were solved later. > > Processor was an old PowerPC 8308, a quite dead SOC. I have not changed > > a lot in board code, but of course I had to reconfigure a lot. At the > > end, everything worked but I was quite astonished about footprint. I had: > > > > 2017.01 u-boot.bin 443452 > > 2018.11 u-boot.bin 654684 > > > > But the new footprint overwrote the space for the env, and I had to > > change the layout.It was not something that I could not manage and in > > this specific case, customer could handle it. I cannot say I did > > something pretty wrong to bloat the bootloader, so my feeling was that > > there is not a specific part responsible for the increased size, but > > each component is slightly bigger and they sizes sum at the end. > > > > > > > Why default? Well, "everyone" > > > agrees that defaulting to EFI application support means the widest > > > choice of out of the box software support. > > > > I am unsure about this - just my two cents. > > > > I agree with you if we are talking about evaluation boards and / or > > boards supposed to run different distros (or in any case, more flavour > > of software). > > > > But there are a lot of "custom" boards (maintained in U-Boot) that runs > > for a specific project and won't run any other kind of software. If a > > device is a navigation system, a network controller, or whatever, it > > will just do this job until its EOL. > > > > Specially for older boards, a new feature should not be activated as > > default. At the beginning, police in U-Boot was to set just what should > > be required in the bootloader, without setting what is not needed as > > default. So default was off instead of on. > > I aslo think that would suit U-Boot better. For example, I have one > configuration where I need to squeeze U-Boot into 204 KiB. For me this > currently means I have to re-check the defconfig for every update to > disable new features that are now on by default. I think having those > default to off and enabling them via defconfig if required would be better. Can SoCFPGA not set the option to make a link failure if you grow beyond 204KiB? As part of this thread, the only new default y thing since v2018.01 at least is CRC16-CCITT support in "hash". -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote: > Hi Tom, Soeren, > > On 09/01/19 23:39, Tom Rini wrote: [snip] > > Why default? Well, "everyone" > > agrees that defaulting to EFI application support means the widest > > choice of out of the box software support. > > I am unsure about this - just my two cents. > > I agree with you if we are talking about evaluation boards and / or > boards supposed to run different distros (or in any case, more flavour > of software). > > But there are a lot of "custom" boards (maintained in U-Boot) that runs > for a specific project and won't run any other kind of software. If a > device is a navigation system, a network controller, or whatever, it > will just do this job until its EOL. > > Specially for older boards, a new feature should not be activated as > default. At the beginning, police in U-Boot was to set just what should > be required in the bootloader, without setting what is not needed as > default. So default was off instead of on. So, part of what I'm taking away from all of this is that I really do need to see how many people I can bcc at once before gmail gets really mad at me, Yes, there's a number of end-user devices we have support for in mainline that are intended to be re-used as the manufacturer intended. Part of the Kconfig migration means that they can more easily remove stuff they don't want/need than before. But there's also the repurposed boards, and lots of not really clear cut cases, such as the tbs2910 where while it's not my call, does fall into the "enable EFI loader support for your end users maybe?" category. And in the end, I should have emailed off everyone with a gentle reminder to inspect and trim their configs. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Thu, Jan 10, 2019 at 03:51:51PM +0100, Stefano Babic wrote: > Hi Tom, > > On 10/01/19 15:44, Tom Rini wrote: > > On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote: > >> Hi Tom, Soeren, > >> > >> On 09/01/19 23:39, Tom Rini wrote: > >>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > Hi Soeren, > > On 08/01/19 12:03, Soeren Moch wrote: > > Hi Stefano, > > > > On 08.01.19 11:24, Stefano Babic wrote: > >> Hi Soeren, > >> > >> On 08/01/19 11:14, Soeren Moch wrote: > >>> Stefano, > >>> > >>> can you apply this for v2019.01? This is really a important fix to > >>> avoid > >>> environment and u-boot binary overwriting each other. > >>> It is also a small local fix which cannot hurt anybody else. > >> I will apply and I send a new PR. This is not the first fix in this > >> direction, u-boot becomes pretty large, it is becoming a common > >> problem. > >> > > Thank you very much. > > > > Yes, "in the good old days (tm)" there was much effort put into not > > increasing the binary size for existing boards when adding new features. > > Right, fully agree. > > > Unfortunately this is not true anymore. > > I get in the same trouble with more as one project. A previous rule of > thumb was to reserve 512KB to the bootloader because it was pretty > unthinkable that bootloader could be larger. Mhmmhhthis remember me > someone else who said that 640Kb is enough for everything. > > Anyway, as you noted, this is a big problem in field and it makes > difficult an upgrade without returning back the device to factory, what > nobody wants. > >>> > >>> So, this is more on me, so I should probably explain a little, and point > >>> at the biggest culprit too. The biggest at times culprit and sometimes > >>> controversial thing is that we default to the EFI subsystem being on by > >>> default. This is 50KiB on tbs2910. > >> > >> I am not sure if we should point to EFI as responsible for the increased > >> footprint or it is due to the sum of several components / factors. I > >> just report my experience in last month : I had to port U-Boot for a > >> customer from a not very old release (2017.01) to the current. 2017.01 > >> had already (apart of FIT support) all features the customer needed, but > >> there are issues(NAND, UBI) and I kew that they were solved later. > >> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed > >> a lot in board code, but of course I had to reconfigure a lot. At the > >> end, everything worked but I was quite astonished about footprint. I had: > >> > >> 2017.01u-boot.bin 443452 > >> 2018.11 u-boot.bin 654684 > >> I'm splitting my reply here into two emails. This here concerns the > > heck out of me. But I don't see it on MPC8308RDB. There I see: > >powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text > > +6847.0 > > MPC8308RDB : all -124241 bss -131040 data -48 text +6847 > >u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 > > (-125646) > > Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but > it is not MPC8308RDB. But nevertheless, I could not understand the > difference is sitze. Right, I understand, that's just the first MPC83xx board I spotted, and I wanted to see if all platforms had such unreasonable growth. You're showing your custom platform went up by _200_ kilobytes. > > And in terms of .bins: > > -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 > > /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin > > -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 > > /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin > > > > I am doing all of mpc83xx now to see if something else trips such a > > large growth. > > > > I will do the same here on this board and try to understand where the > difference is coming from. I will report to you, then. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Thu, Jan 10, 2019 at 03:03:27PM +0100, Soeren Moch wrote: > > > On 10.01.19 03:30, Tom Rini wrote: > > On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote: > >> > >> On 09.01.19 23:39, Tom Rini wrote: > >>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > Hi Soeren, > > On 08/01/19 12:03, Soeren Moch wrote: > > Hi Stefano, > > > > On 08.01.19 11:24, Stefano Babic wrote: > >> Hi Soeren, > >> > >> On 08/01/19 11:14, Soeren Moch wrote: > >>> Stefano, > >>> > >>> can you apply this for v2019.01? This is really a important fix to > >>> avoid > >>> environment and u-boot binary overwriting each other. > >>> It is also a small local fix which cannot hurt anybody else. > >> I will apply and I send a new PR. This is not the first fix in this > >> direction, u-boot becomes pretty large, it is becoming a common > >> problem. > >> > > Thank you very much. > > > > Yes, "in the good old days (tm)" there was much effort put into not > > increasing the binary size for existing boards when adding new features. > Right, fully agree. > > > Unfortunately this is not true anymore. > I get in the same trouble with more as one project. A previous rule of > thumb was to reserve 512KB to the bootloader because it was pretty > unthinkable that bootloader could be larger. Mhmmhhthis remember me > someone else who said that 640Kb is enough for everything. > > Anyway, as you noted, this is a big problem in field and it makes > difficult an upgrade without returning back the device to factory, what > nobody wants. > >>> So, this is more on me, so I should probably explain a little, and point > >>> at the biggest culprit too. The biggest at times culprit and sometimes > >>> controversial thing is that we default to the EFI subsystem being on by > >>> default. This is 50KiB on tbs2910. Why default? Well, "everyone" > >>> agrees that defaulting to EFI application support means the widest > >>> choice of out of the box software support. > >>> > >> Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64 > >> boards. The usual way for firmware updates was to load a special > > Yes, there's some amount of chicken-and-egg but it's there and growing. > > > >> UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or > >> more convenient these days to support EFI, maybe a good idea to > >> default=y, but why this is not disabled in old board's defconfigs then? > > While it's default y and means we're even enabling it on pre-v7 > > processors, the general answer is that defaults matter especially when > > things get forked off for a custom project or for a new reference > > platform, and it's something that can always be turned off. i.MX is in > > fact where a number of platforms have gone for opt-out. > So default y might be OK if this feature is desired for new platforms. > But I would prefer that the same patch series that introduces the > default y also inserts all the "# CONFIG_WHATEVER is not set" in old > board's defconfigs. But that's close to the opposite of why you make something default y, which I really do try and not do so often, but maybe I'm also not doing a great job there. But, digging into specifics for just a moment, https://www.tbsdtv.com/launch/tbs-2910-matrix-arm-mini-pc.html is what we're talking about here and that you can install $whatever on it as $whatever expects to be able to have its EFI-application installer just run (and be passed a device tree for the kernel) is part of why EFI_LOADER is default enabled. That's not saying you shouldn't still disable it if you need the space. [snip] > >> The bigger challenge are the BLK and DM conversions for the next u-boot > >> version. I absolutely cannot understand how somebody can insist on these > >> changes, while letting the board maintainers completely alone with > >> required driver adaptations. Board maintainers are not familiar with > >> driver code, a lot of board maintainers would need to work in parallel > >> on this (when no person is designated for this work, all maintainers are > >> equally responsible), while the author of the BLK/DM core code is very > >> familiar with the required changes. The necessary API adaptations in > >> drivers would be a no-brainer for him, since nothing of the actual > >> hardware access code needs to be adapted. At least that is my > >> understanding. > >> But someone (who actually?) decided to simply offload the second > >> conversion step (drivers) to somebody else, with no help offered for > >> this, but with short deadlines. I never heard that this can work in > >> community projects. > >> If the driver adaptations are done for a single board from each family, > >> then the third step (adapting board configurations) is a job for board > >> maintainers. But we're not at his point. > > Keep in mind that for the
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
Hi Tom, On 10/01/19 15:44, Tom Rini wrote: > On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote: >> Hi Tom, Soeren, >> >> On 09/01/19 23:39, Tom Rini wrote: >>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: Hi Soeren, On 08/01/19 12:03, Soeren Moch wrote: > Hi Stefano, > > On 08.01.19 11:24, Stefano Babic wrote: >> Hi Soeren, >> >> On 08/01/19 11:14, Soeren Moch wrote: >>> Stefano, >>> >>> can you apply this for v2019.01? This is really a important fix to avoid >>> environment and u-boot binary overwriting each other. >>> It is also a small local fix which cannot hurt anybody else. >> I will apply and I send a new PR. This is not the first fix in this >> direction, u-boot becomes pretty large, it is becoming a common problem. >> > Thank you very much. > > Yes, "in the good old days (tm)" there was much effort put into not > increasing the binary size for existing boards when adding new features. Right, fully agree. > Unfortunately this is not true anymore. I get in the same trouble with more as one project. A previous rule of thumb was to reserve 512KB to the bootloader because it was pretty unthinkable that bootloader could be larger. Mhmmhhthis remember me someone else who said that 640Kb is enough for everything. Anyway, as you noted, this is a big problem in field and it makes difficult an upgrade without returning back the device to factory, what nobody wants. >>> >>> So, this is more on me, so I should probably explain a little, and point >>> at the biggest culprit too. The biggest at times culprit and sometimes >>> controversial thing is that we default to the EFI subsystem being on by >>> default. This is 50KiB on tbs2910. >> >> I am not sure if we should point to EFI as responsible for the increased >> footprint or it is due to the sum of several components / factors. I >> just report my experience in last month : I had to port U-Boot for a >> customer from a not very old release (2017.01) to the current. 2017.01 >> had already (apart of FIT support) all features the customer needed, but >> there are issues(NAND, UBI) and I kew that they were solved later. >> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed >> a lot in board code, but of course I had to reconfigure a lot. At the >> end, everything worked but I was quite astonished about footprint. I had: >> >> 2017.01 u-boot.bin 443452 >> 2018.11 u-boot.bin 654684 >> I'm splitting my reply here into two emails. This here concerns the > heck out of me. But I don't see it on MPC8308RDB. There I see: >powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text > +6847.0 > MPC8308RDB : all -124241 bss -131040 data -48 text +6847 >u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 > (-125646) Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but it is not MPC8308RDB. But nevertheless, I could not understand the difference is sitze. > > And in terms of .bins: > -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 > /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin > -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 > /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin > > I am doing all of mpc83xx now to see if something else trips such a > large growth. > I will do the same here on this board and try to understand where the difference is coming from. I will report to you, then. Regards, Stefano -- = 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: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote: > Hi Tom, Soeren, > > On 09/01/19 23:39, Tom Rini wrote: > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > >> Hi Soeren, > >> > >> On 08/01/19 12:03, Soeren Moch wrote: > >>> Hi Stefano, > >>> > >>> On 08.01.19 11:24, Stefano Babic wrote: > Hi Soeren, > > On 08/01/19 11:14, Soeren Moch wrote: > > Stefano, > > > > can you apply this for v2019.01? This is really a important fix to avoid > > environment and u-boot binary overwriting each other. > > It is also a small local fix which cannot hurt anybody else. > I will apply and I send a new PR. This is not the first fix in this > direction, u-boot becomes pretty large, it is becoming a common problem. > > >>> Thank you very much. > >>> > >>> Yes, "in the good old days (tm)" there was much effort put into not > >>> increasing the binary size for existing boards when adding new features. > >> > >> Right, fully agree. > >> > >>> Unfortunately this is not true anymore. > >> > >> I get in the same trouble with more as one project. A previous rule of > >> thumb was to reserve 512KB to the bootloader because it was pretty > >> unthinkable that bootloader could be larger. Mhmmhhthis remember me > >> someone else who said that 640Kb is enough for everything. > >> > >> Anyway, as you noted, this is a big problem in field and it makes > >> difficult an upgrade without returning back the device to factory, what > >> nobody wants. > > > > So, this is more on me, so I should probably explain a little, and point > > at the biggest culprit too. The biggest at times culprit and sometimes > > controversial thing is that we default to the EFI subsystem being on by > > default. This is 50KiB on tbs2910. > > I am not sure if we should point to EFI as responsible for the increased > footprint or it is due to the sum of several components / factors. I > just report my experience in last month : I had to port U-Boot for a > customer from a not very old release (2017.01) to the current. 2017.01 > had already (apart of FIT support) all features the customer needed, but > there are issues(NAND, UBI) and I kew that they were solved later. > Processor was an old PowerPC 8308, a quite dead SOC. I have not changed > a lot in board code, but of course I had to reconfigure a lot. At the > end, everything worked but I was quite astonished about footprint. I had: > > 2017.01 u-boot.bin 443452 > 2018.11 u-boot.bin 654684 I'm splitting my reply here into two emails. This here concerns the heck out of me. But I don't see it on MPC8308RDB. There I see: powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text +6847.0 MPC8308RDB : all -124241 bss -131040 data -48 text +6847 u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 (-125646) And in terms of .bins: -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin I am doing all of mpc83xx now to see if something else trips such a large growth. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On 10.01.19 03:30, Tom Rini wrote: > On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote: >> >> On 09.01.19 23:39, Tom Rini wrote: >>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: Hi Soeren, On 08/01/19 12:03, Soeren Moch wrote: > Hi Stefano, > > On 08.01.19 11:24, Stefano Babic wrote: >> Hi Soeren, >> >> On 08/01/19 11:14, Soeren Moch wrote: >>> Stefano, >>> >>> can you apply this for v2019.01? This is really a important fix to avoid >>> environment and u-boot binary overwriting each other. >>> It is also a small local fix which cannot hurt anybody else. >> I will apply and I send a new PR. This is not the first fix in this >> direction, u-boot becomes pretty large, it is becoming a common problem. >> > Thank you very much. > > Yes, "in the good old days (tm)" there was much effort put into not > increasing the binary size for existing boards when adding new features. Right, fully agree. > Unfortunately this is not true anymore. I get in the same trouble with more as one project. A previous rule of thumb was to reserve 512KB to the bootloader because it was pretty unthinkable that bootloader could be larger. Mhmmhhthis remember me someone else who said that 640Kb is enough for everything. Anyway, as you noted, this is a big problem in field and it makes difficult an upgrade without returning back the device to factory, what nobody wants. >>> So, this is more on me, so I should probably explain a little, and point >>> at the biggest culprit too. The biggest at times culprit and sometimes >>> controversial thing is that we default to the EFI subsystem being on by >>> default. This is 50KiB on tbs2910. Why default? Well, "everyone" >>> agrees that defaulting to EFI application support means the widest >>> choice of out of the box software support. >>> >> Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64 >> boards. The usual way for firmware updates was to load a special > Yes, there's some amount of chicken-and-egg but it's there and growing. > >> UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or >> more convenient these days to support EFI, maybe a good idea to >> default=y, but why this is not disabled in old board's defconfigs then? > While it's default y and means we're even enabling it on pre-v7 > processors, the general answer is that defaults matter especially when > things get forked off for a custom project or for a new reference > platform, and it's something that can always be turned off. i.MX is in > fact where a number of platforms have gone for opt-out. So default y might be OK if this feature is desired for new platforms. But I would prefer that the same patch series that introduces the default y also inserts all the "# CONFIG_WHATEVER is not set" in old board's defconfigs. >> Either "automatically" like in the Kconfig conversions, or via a short >> notice to the relevant board maintainers? > I've been bad about communicating stuff to board maintainers, so that's > on me. I have been, more of late at least, mentioning them in the > release emails, and now that we have build-time warnings (which are long > over-due, sorry!) I hope it will be more visible. But I haven't come up > with a good way to not too painfully email the 300 or so people listed > as a maintainer for something under boards/. I need to 'tho. > >> I also noticed this EFI support as big, but disabling it is more >> complicated than disabling FIT, and we are at -rc3. Maybe I will send a >> corresponding patch for the next merge window. > It shouldn't be more than just disabling CONFIG_EFI_LOADER. This works, thanks. I must have done something when I tried this 2 weeks ago. > >>> And I do look at size changes, at least per push to master. So most of >>> the time it comes in "drips and drabs". Right now I'm going to grow >>> tbs2910 by 60 bytes[1]. Most of that is section re-alignment and 8 of it >>> is the regression fix to mmc_startup() or non-DM MMC drivers. But >>> that's not super interesting, so lets look at v2018.09 to now. That's >>> 1800 bytes. That's not too bad and looks like it's maybe half bug >>> fixes, half working on various frameworks (sure, DM/DT stuff but also >>> hash algos. If we jump back to v2018.01, so more or less a year worth >>> of changes, that's 19KiB. Without trying to break down _everything_ >>> that's a good bit of EFI and a little bit everywhere else. >> I fully understand that this is not a easy job for you. And usually a >> few kiB are not a big deal. But the one kiB that overwrites the >> environment on eMMC (and therefore often bricks the board) is very very >> inconvenient for users. > Right, it's bad, I agree. Which is part of my further lament about the > build-time size check. > > And all the shiny new driver model / OF features only bring >
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Wed, 2019-01-09 at 17:39 -0500, Tom Rini wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > > Hi Soeren, > > > > On 08/01/19 12:03, Soeren Moch wrote: > > > Hi Stefano, > > > > > > On 08.01.19 11:24, Stefano Babic wrote: > > > > Hi Soeren, > > > > > > > > On 08/01/19 11:14, Soeren Moch wrote: > > > > > Stefano, > > > > > > > > > > can you apply this for v2019.01? This is really a important fix to > > > > > avoid > > > > > environment and u-boot binary overwriting each other. > > > > > It is also a small local fix which cannot hurt anybody else. > > > > I will apply and I send a new PR. This is not the first fix in this > > > > direction, u-boot becomes pretty large, it is becoming a common problem. > > > > > > > Thank you very much. > > > > > > Yes, "in the good old days (tm)" there was much effort put into not > > > increasing the binary size for existing boards when adding new features. > > > > Right, fully agree. > > > > > Unfortunately this is not true anymore. > > > > I get in the same trouble with more as one project. A previous rule of > > thumb was to reserve 512KB to the bootloader because it was pretty > > unthinkable that bootloader could be larger. Mhmmhhthis remember me > > someone else who said that 640Kb is enough for everything. > > > > Anyway, as you noted, this is a big problem in field and it makes > > difficult an upgrade without returning back the device to factory, what > > nobody wants. > > So, this is more on me, so I should probably explain a little, and point > at the biggest culprit too. The biggest at times culprit and sometimes > controversial thing is that we default to the EFI subsystem being on by > default. This is 50KiB on tbs2910. Why default? Well, "everyone" > agrees that defaulting to EFI application support means the widest > choice of out of the box software support. > > And I do look at size changes, at least per push to master. So most of > the time it comes in "drips and drabs". Right now I'm going to grow > tbs2910 by 60 bytes[1]. Most of that is section re-alignment and 8 of it > is the regression fix to mmc_startup() or non-DM MMC drivers. But > that's not super interesting, so lets look at v2018.09 to now. That's > 1800 bytes. That's not too bad and looks like it's maybe half bug > fixes, half working on various frameworks (sure, DM/DT stuff but also > hash algos. If we jump back to v2018.01, so more or less a year worth > of changes, that's 19KiB. Without trying to break down _everything_ > that's a good bit of EFI and a little bit everywhere else. If you looking to save a few more bytes you could take a look at my old patch for handling the env. without a lot of static variables: https://patchwork.ozlabs.org/patch/746419/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic wrote: > > Hi Tom, Soeren, > > On 09/01/19 23:39, Tom Rini wrote: > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > >> Hi Soeren, > >> > >> On 08/01/19 12:03, Soeren Moch wrote: > >>> Hi Stefano, > >>> > >>> On 08.01.19 11:24, Stefano Babic wrote: > Hi Soeren, > > On 08/01/19 11:14, Soeren Moch wrote: > > Stefano, > > > > can you apply this for v2019.01? This is really a important fix to avoid > > environment and u-boot binary overwriting each other. > > It is also a small local fix which cannot hurt anybody else. > I will apply and I send a new PR. This is not the first fix in this > direction, u-boot becomes pretty large, it is becoming a common problem. > > >>> Thank you very much. > >>> > >>> Yes, "in the good old days (tm)" there was much effort put into not > >>> increasing the binary size for existing boards when adding new features. > >> > >> Right, fully agree. > >> > >>> Unfortunately this is not true anymore. > >> > >> I get in the same trouble with more as one project. A previous rule of > >> thumb was to reserve 512KB to the bootloader because it was pretty > >> unthinkable that bootloader could be larger. Mhmmhhthis remember me > >> someone else who said that 640Kb is enough for everything. > >> > >> Anyway, as you noted, this is a big problem in field and it makes > >> difficult an upgrade without returning back the device to factory, what > >> nobody wants. > > > > So, this is more on me, so I should probably explain a little, and point > > at the biggest culprit too. The biggest at times culprit and sometimes > > controversial thing is that we default to the EFI subsystem being on by > > default. This is 50KiB on tbs2910. > > I am not sure if we should point to EFI as responsible for the increased > footprint or it is due to the sum of several components / factors. I > just report my experience in last month : I had to port U-Boot for a > customer from a not very old release (2017.01) to the current. 2017.01 > had already (apart of FIT support) all features the customer needed, but > there are issues(NAND, UBI) and I kew that they were solved later. > Processor was an old PowerPC 8308, a quite dead SOC. I have not changed > a lot in board code, but of course I had to reconfigure a lot. At the > end, everything worked but I was quite astonished about footprint. I had: > > 2017.01 u-boot.bin 443452 > 2018.11 u-boot.bin 654684 > > But the new footprint overwrote the space for the env, and I had to > change the layout.It was not something that I could not manage and in > this specific case, customer could handle it. I cannot say I did > something pretty wrong to bloat the bootloader, so my feeling was that > there is not a specific part responsible for the increased size, but > each component is slightly bigger and they sizes sum at the end. > > > > Why default? Well, "everyone" > > agrees that defaulting to EFI application support means the widest > > choice of out of the box software support. > > I am unsure about this - just my two cents. > > I agree with you if we are talking about evaluation boards and / or > boards supposed to run different distros (or in any case, more flavour > of software). > > But there are a lot of "custom" boards (maintained in U-Boot) that runs > for a specific project and won't run any other kind of software. If a > device is a navigation system, a network controller, or whatever, it > will just do this job until its EOL. > > Specially for older boards, a new feature should not be activated as > default. At the beginning, police in U-Boot was to set just what should > be required in the bootloader, without setting what is not needed as > default. So default was off instead of on. I aslo think that would suit U-Boot better. For example, I have one configuration where I need to squeeze U-Boot into 204 KiB. For me this currently means I have to re-check the defconfig for every update to disable new features that are now on by default. I think having those default to off and enabling them via defconfig if required would be better. Regards, Simon > > > > > And I do look at size changes, at least per push to master. So most of > > the time it comes in "drips and drabs". Right now I'm going to grow > > tbs2910 by 60 bytes[1]. Most of that is section re-alignment and 8 of it > > is the regression fix to mmc_startup() or non-DM MMC drivers. But > > that's not super interesting, so lets look at v2018.09 to now. That's > > 1800 bytes. That's not too bad and looks like it's maybe half bug > > fixes, half working on various frameworks (sure, DM/DT stuff but also > > hash algos. If we jump back to v2018.01, so more or less a year worth > > of changes, that's 19KiB. Without trying to break down _everything_ > > that's a good bit of EFI and a little bit everywhere else. > > > >>> And all the shiny new driver model / OF features only bring >
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
Hi Tom, Soeren, On 09/01/19 23:39, Tom Rini wrote: > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: >> Hi Soeren, >> >> On 08/01/19 12:03, Soeren Moch wrote: >>> Hi Stefano, >>> >>> On 08.01.19 11:24, Stefano Babic wrote: Hi Soeren, On 08/01/19 11:14, Soeren Moch wrote: > Stefano, > > can you apply this for v2019.01? This is really a important fix to avoid > environment and u-boot binary overwriting each other. > It is also a small local fix which cannot hurt anybody else. I will apply and I send a new PR. This is not the first fix in this direction, u-boot becomes pretty large, it is becoming a common problem. >>> Thank you very much. >>> >>> Yes, "in the good old days (tm)" there was much effort put into not >>> increasing the binary size for existing boards when adding new features. >> >> Right, fully agree. >> >>> Unfortunately this is not true anymore. >> >> I get in the same trouble with more as one project. A previous rule of >> thumb was to reserve 512KB to the bootloader because it was pretty >> unthinkable that bootloader could be larger. Mhmmhhthis remember me >> someone else who said that 640Kb is enough for everything. >> >> Anyway, as you noted, this is a big problem in field and it makes >> difficult an upgrade without returning back the device to factory, what >> nobody wants. > > So, this is more on me, so I should probably explain a little, and point > at the biggest culprit too. The biggest at times culprit and sometimes > controversial thing is that we default to the EFI subsystem being on by > default. This is 50KiB on tbs2910. I am not sure if we should point to EFI as responsible for the increased footprint or it is due to the sum of several components / factors. I just report my experience in last month : I had to port U-Boot for a customer from a not very old release (2017.01) to the current. 2017.01 had already (apart of FIT support) all features the customer needed, but there are issues(NAND, UBI) and I kew that they were solved later. Processor was an old PowerPC 8308, a quite dead SOC. I have not changed a lot in board code, but of course I had to reconfigure a lot. At the end, everything worked but I was quite astonished about footprint. I had: 2017.01 u-boot.bin 443452 2018.11 u-boot.bin 654684 But the new footprint overwrote the space for the env, and I had to change the layout.It was not something that I could not manage and in this specific case, customer could handle it. I cannot say I did something pretty wrong to bloat the bootloader, so my feeling was that there is not a specific part responsible for the increased size, but each component is slightly bigger and they sizes sum at the end. > Why default? Well, "everyone" > agrees that defaulting to EFI application support means the widest > choice of out of the box software support. I am unsure about this - just my two cents. I agree with you if we are talking about evaluation boards and / or boards supposed to run different distros (or in any case, more flavour of software). But there are a lot of "custom" boards (maintained in U-Boot) that runs for a specific project and won't run any other kind of software. If a device is a navigation system, a network controller, or whatever, it will just do this job until its EOL. Specially for older boards, a new feature should not be activated as default. At the beginning, police in U-Boot was to set just what should be required in the bootloader, without setting what is not needed as default. So default was off instead of on. > > And I do look at size changes, at least per push to master. So most of > the time it comes in "drips and drabs". Right now I'm going to grow > tbs2910 by 60 bytes[1]. Most of that is section re-alignment and 8 of it > is the regression fix to mmc_startup() or non-DM MMC drivers. But > that's not super interesting, so lets look at v2018.09 to now. That's > 1800 bytes. That's not too bad and looks like it's maybe half bug > fixes, half working on various frameworks (sure, DM/DT stuff but also > hash algos. If we jump back to v2018.01, so more or less a year worth > of changes, that's 19KiB. Without trying to break down _everything_ > that's a good bit of EFI and a little bit everywhere else. > >>> And all the shiny new driver model / OF features only bring >>> disadvantages for maintainers and users of existing boards. >>> >>> I totally understand the desire to convert the driver code to "something >>> better", which is easier to maintain long-term. But apparently new code >>> is only tested on a single platform, while constantly breaking support >>> for others without notice. But 'm complaining to the wrong person... >> >> Yes, I am not the right person ;-) >> >> I picked up your patches, I will run build tests and if everything is >> fine I will sent PR for 2019.01. > > In retrospect, I wish more people knew about enforcing a link time hard > limit on the
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote: > > > On 09.01.19 23:39, Tom Rini wrote: > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > >> Hi Soeren, > >> > >> On 08/01/19 12:03, Soeren Moch wrote: > >>> Hi Stefano, > >>> > >>> On 08.01.19 11:24, Stefano Babic wrote: > Hi Soeren, > > On 08/01/19 11:14, Soeren Moch wrote: > > Stefano, > > > > can you apply this for v2019.01? This is really a important fix to avoid > > environment and u-boot binary overwriting each other. > > It is also a small local fix which cannot hurt anybody else. > I will apply and I send a new PR. This is not the first fix in this > direction, u-boot becomes pretty large, it is becoming a common problem. > > >>> Thank you very much. > >>> > >>> Yes, "in the good old days (tm)" there was much effort put into not > >>> increasing the binary size for existing boards when adding new features. > >> Right, fully agree. > >> > >>> Unfortunately this is not true anymore. > >> I get in the same trouble with more as one project. A previous rule of > >> thumb was to reserve 512KB to the bootloader because it was pretty > >> unthinkable that bootloader could be larger. Mhmmhhthis remember me > >> someone else who said that 640Kb is enough for everything. > >> > >> Anyway, as you noted, this is a big problem in field and it makes > >> difficult an upgrade without returning back the device to factory, what > >> nobody wants. > > So, this is more on me, so I should probably explain a little, and point > > at the biggest culprit too. The biggest at times culprit and sometimes > > controversial thing is that we default to the EFI subsystem being on by > > default. This is 50KiB on tbs2910. Why default? Well, "everyone" > > agrees that defaulting to EFI application support means the widest > > choice of out of the box software support. > > > Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64 > boards. The usual way for firmware updates was to load a special Yes, there's some amount of chicken-and-egg but it's there and growing. > UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or > more convenient these days to support EFI, maybe a good idea to > default=y, but why this is not disabled in old board's defconfigs then? While it's default y and means we're even enabling it on pre-v7 processors, the general answer is that defaults matter especially when things get forked off for a custom project or for a new reference platform, and it's something that can always be turned off. i.MX is in fact where a number of platforms have gone for opt-out. > Either "automatically" like in the Kconfig conversions, or via a short > notice to the relevant board maintainers? I've been bad about communicating stuff to board maintainers, so that's on me. I have been, more of late at least, mentioning them in the release emails, and now that we have build-time warnings (which are long over-due, sorry!) I hope it will be more visible. But I haven't come up with a good way to not too painfully email the 300 or so people listed as a maintainer for something under boards/. I need to 'tho. > I also noticed this EFI support as big, but disabling it is more > complicated than disabling FIT, and we are at -rc3. Maybe I will send a > corresponding patch for the next merge window. It shouldn't be more than just disabling CONFIG_EFI_LOADER. > > And I do look at size changes, at least per push to master. So most of > > the time it comes in "drips and drabs". Right now I'm going to grow > > tbs2910 by 60 bytes[1]. Most of that is section re-alignment and 8 of it > > is the regression fix to mmc_startup() or non-DM MMC drivers. But > > that's not super interesting, so lets look at v2018.09 to now. That's > > 1800 bytes. That's not too bad and looks like it's maybe half bug > > fixes, half working on various frameworks (sure, DM/DT stuff but also > > hash algos. If we jump back to v2018.01, so more or less a year worth > > of changes, that's 19KiB. Without trying to break down _everything_ > > that's a good bit of EFI and a little bit everywhere else. > I fully understand that this is not a easy job for you. And usually a > few kiB are not a big deal. But the one kiB that overwrites the > environment on eMMC (and therefore often bricks the board) is very very > inconvenient for users. Right, it's bad, I agree. Which is part of my further lament about the build-time size check. > >>> And all the shiny new driver model / OF features only bring > >>> disadvantages for maintainers and users of existing boards. > >>> > >>> I totally understand the desire to convert the driver code to "something > >>> better", which is easier to maintain long-term. But apparently new code > >>> is only tested on a single platform, while constantly breaking support > >>> for others without notice. But 'm complaining to the wrong person... > >> Yes, I am
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On 09.01.19 23:39, Tom Rini wrote: > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: >> Hi Soeren, >> >> On 08/01/19 12:03, Soeren Moch wrote: >>> Hi Stefano, >>> >>> On 08.01.19 11:24, Stefano Babic wrote: Hi Soeren, On 08/01/19 11:14, Soeren Moch wrote: > Stefano, > > can you apply this for v2019.01? This is really a important fix to avoid > environment and u-boot binary overwriting each other. > It is also a small local fix which cannot hurt anybody else. I will apply and I send a new PR. This is not the first fix in this direction, u-boot becomes pretty large, it is becoming a common problem. >>> Thank you very much. >>> >>> Yes, "in the good old days (tm)" there was much effort put into not >>> increasing the binary size for existing boards when adding new features. >> Right, fully agree. >> >>> Unfortunately this is not true anymore. >> I get in the same trouble with more as one project. A previous rule of >> thumb was to reserve 512KB to the bootloader because it was pretty >> unthinkable that bootloader could be larger. Mhmmhhthis remember me >> someone else who said that 640Kb is enough for everything. >> >> Anyway, as you noted, this is a big problem in field and it makes >> difficult an upgrade without returning back the device to factory, what >> nobody wants. > So, this is more on me, so I should probably explain a little, and point > at the biggest culprit too. The biggest at times culprit and sometimes > controversial thing is that we default to the EFI subsystem being on by > default. This is 50KiB on tbs2910. Why default? Well, "everyone" > agrees that defaulting to EFI application support means the widest > choice of out of the box software support. > Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64 boards. The usual way for firmware updates was to load a special UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or more convenient these days to support EFI, maybe a good idea to default=y, but why this is not disabled in old board's defconfigs then? Either "automatically" like in the Kconfig conversions, or via a short notice to the relevant board maintainers? I also noticed this EFI support as big, but disabling it is more complicated than disabling FIT, and we are at -rc3. Maybe I will send a corresponding patch for the next merge window. > And I do look at size changes, at least per push to master. So most of > the time it comes in "drips and drabs". Right now I'm going to grow > tbs2910 by 60 bytes[1]. Most of that is section re-alignment and 8 of it > is the regression fix to mmc_startup() or non-DM MMC drivers. But > that's not super interesting, so lets look at v2018.09 to now. That's > 1800 bytes. That's not too bad and looks like it's maybe half bug > fixes, half working on various frameworks (sure, DM/DT stuff but also > hash algos. If we jump back to v2018.01, so more or less a year worth > of changes, that's 19KiB. Without trying to break down _everything_ > that's a good bit of EFI and a little bit everywhere else. I fully understand that this is not a easy job for you. And usually a few kiB are not a big deal. But the one kiB that overwrites the environment on eMMC (and therefore often bricks the board) is very very inconvenient for users. >>> And all the shiny new driver model / OF features only bring >>> disadvantages for maintainers and users of existing boards. >>> >>> I totally understand the desire to convert the driver code to "something >>> better", which is easier to maintain long-term. But apparently new code >>> is only tested on a single platform, while constantly breaking support >>> for others without notice. But 'm complaining to the wrong person... >> Yes, I am not the right person ;-) >> >> I picked up your patches, I will run build tests and if everything is >> fine I will sent PR for 2019.01. > In retrospect, I wish more people knew about enforcing a link time hard > limit on the binary and knew about it a lot longer ago. Because when > those failures pop up, I don't apply the new PR and I start talking to > the relevant parties to see what we can do. Unfortunately I learned about the availability of this check only recently. As hobbyist maintainer I usually rely on the reference board settings. But for v2019.01 all the problems (MMC partitions and u-boot size) have been solved (when the relevant patches are applied), so I think we are in good shape for now. The bigger challenge are the BLK and DM conversions for the next u-boot version. I absolutely cannot understand how somebody can insist on these changes, while letting the board maintainers completely alone with required driver adaptations. Board maintainers are not familiar with driver code, a lot of board maintainers would need to work in parallel on this (when no person is designated for this work, all maintainers are equally responsible), while the author of the BLK/DM
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote: > Hi Soeren, > > On 08/01/19 12:03, Soeren Moch wrote: > > Hi Stefano, > > > > On 08.01.19 11:24, Stefano Babic wrote: > >> Hi Soeren, > >> > >> On 08/01/19 11:14, Soeren Moch wrote: > >>> Stefano, > >>> > >>> can you apply this for v2019.01? This is really a important fix to avoid > >>> environment and u-boot binary overwriting each other. > >>> It is also a small local fix which cannot hurt anybody else. > >> I will apply and I send a new PR. This is not the first fix in this > >> direction, u-boot becomes pretty large, it is becoming a common problem. > >> > > Thank you very much. > > > > Yes, "in the good old days (tm)" there was much effort put into not > > increasing the binary size for existing boards when adding new features. > > Right, fully agree. > > > Unfortunately this is not true anymore. > > I get in the same trouble with more as one project. A previous rule of > thumb was to reserve 512KB to the bootloader because it was pretty > unthinkable that bootloader could be larger. Mhmmhhthis remember me > someone else who said that 640Kb is enough for everything. > > Anyway, as you noted, this is a big problem in field and it makes > difficult an upgrade without returning back the device to factory, what > nobody wants. So, this is more on me, so I should probably explain a little, and point at the biggest culprit too. The biggest at times culprit and sometimes controversial thing is that we default to the EFI subsystem being on by default. This is 50KiB on tbs2910. Why default? Well, "everyone" agrees that defaulting to EFI application support means the widest choice of out of the box software support. And I do look at size changes, at least per push to master. So most of the time it comes in "drips and drabs". Right now I'm going to grow tbs2910 by 60 bytes[1]. Most of that is section re-alignment and 8 of it is the regression fix to mmc_startup() or non-DM MMC drivers. But that's not super interesting, so lets look at v2018.09 to now. That's 1800 bytes. That's not too bad and looks like it's maybe half bug fixes, half working on various frameworks (sure, DM/DT stuff but also hash algos. If we jump back to v2018.01, so more or less a year worth of changes, that's 19KiB. Without trying to break down _everything_ that's a good bit of EFI and a little bit everywhere else. > > And all the shiny new driver model / OF features only bring > > disadvantages for maintainers and users of existing boards. > > > > I totally understand the desire to convert the driver code to "something > > better", which is easier to maintain long-term. But apparently new code > > is only tested on a single platform, while constantly breaking support > > for others without notice. But 'm complaining to the wrong person... > > Yes, I am not the right person ;-) > > I picked up your patches, I will run build tests and if everything is > fine I will sent PR for 2019.01. In retrospect, I wish more people knew about enforcing a link time hard limit on the binary and knew about it a lot longer ago. Because when those failures pop up, I don't apply the new PR and I start talking to the relevant parties to see what we can do. [1]: buildman --step 0 -SBCdevlk followed by --step 0 -SsBdevlk to see how much and where, and yes, that's a few more flags than I _need_ for that, and since it's in a script I never go and optimize it down. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
Hi Soeren, On 08/01/19 12:03, Soeren Moch wrote: > Hi Stefano, > > On 08.01.19 11:24, Stefano Babic wrote: >> Hi Soeren, >> >> On 08/01/19 11:14, Soeren Moch wrote: >>> Stefano, >>> >>> can you apply this for v2019.01? This is really a important fix to avoid >>> environment and u-boot binary overwriting each other. >>> It is also a small local fix which cannot hurt anybody else. >> I will apply and I send a new PR. This is not the first fix in this >> direction, u-boot becomes pretty large, it is becoming a common problem. >> > Thank you very much. > > Yes, "in the good old days (tm)" there was much effort put into not > increasing the binary size for existing boards when adding new features. Right, fully agree. > Unfortunately this is not true anymore. I get in the same trouble with more as one project. A previous rule of thumb was to reserve 512KB to the bootloader because it was pretty unthinkable that bootloader could be larger. Mhmmhhthis remember me someone else who said that 640Kb is enough for everything. Anyway, as you noted, this is a big problem in field and it makes difficult an upgrade without returning back the device to factory, what nobody wants. > And all the shiny new driver model / OF features only bring > disadvantages for maintainers and users of existing boards. > > I totally understand the desire to convert the driver code to "something > better", which is easier to maintain long-term. But apparently new code > is only tested on a single platform, while constantly breaking support > for others without notice. But 'm complaining to the wrong person... Yes, I am not the right person ;-) I picked up your patches, I will run build tests and if everything is fine I will sent PR for 2019.01. Best regards, Stefano -- = 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: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
Hi Stefano, On 08.01.19 11:24, Stefano Babic wrote: > Hi Soeren, > > On 08/01/19 11:14, Soeren Moch wrote: >> Stefano, >> >> can you apply this for v2019.01? This is really a important fix to avoid >> environment and u-boot binary overwriting each other. >> It is also a small local fix which cannot hurt anybody else. > I will apply and I send a new PR. This is not the first fix in this > direction, u-boot becomes pretty large, it is becoming a common problem. > Thank you very much. Yes, "in the good old days (tm)" there was much effort put into not increasing the binary size for existing boards when adding new features. Unfortunately this is not true anymore. And all the shiny new driver model / OF features only bring disadvantages for maintainers and users of existing boards. I totally understand the desire to convert the driver code to "something better", which is easier to maintain long-term. But apparently new code is only tested on a single platform, while constantly breaking support for others without notice. But 'm complaining to the wrong person... Thanks again, Soeren ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
Hi Soeren, On 08/01/19 11:14, Soeren Moch wrote: > Stefano, > > can you apply this for v2019.01? This is really a important fix to avoid > environment and u-boot binary overwriting each other. > It is also a small local fix which cannot hurt anybody else. I will apply and I send a new PR. This is not the first fix in this direction, u-boot becomes pretty large, it is becoming a common problem. Regards, Stefano -- = 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: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
Stefano, can you apply this for v2019.01? This is really a important fix to avoid environment and u-boot binary overwriting each other. It is also a small local fix which cannot hurt anybody else. Thanks, Soeren On 05.01.19 09:31, Soeren Moch wrote: > The current defconfig build generates a u-boot.imx file that is too large > for the available space on a eMMC/SD card. Installing this file overwrites > the u-boot environment. So disable the unused FIT support to reduce the > size of the u-boot binary. > > Signed-off-by: Soeren Moch > --- > Cc: Stefano Babic > Cc: Fabio Estevam > Cc: u-boot@lists.denx.de > --- > configs/tbs2910_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig > index 55cd9bd998..fc15dcf013 100644 > --- a/configs/tbs2910_defconfig > +++ b/configs/tbs2910_defconfig > @@ -5,7 +5,6 @@ CONFIG_SYS_TEXT_BASE=0x1780 > CONFIG_TARGET_TBS2910=y > CONFIG_CMD_HDMIDETECT=y > CONFIG_NR_DRAM_BANKS=1 > -CONFIG_FIT=y > CONFIG_BOOTDELAY=3 > CONFIG_PRE_CONSOLE_BUFFER=y > CONFIG_PRE_CON_BUF_ADDR=0x7c00 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
The current defconfig build generates a u-boot.imx file that is too large for the available space on a eMMC/SD card. Installing this file overwrites the u-boot environment. So disable the unused FIT support to reduce the size of the u-boot binary. Signed-off-by: Soeren Moch --- Cc: Stefano Babic Cc: Fabio Estevam Cc: u-boot@lists.denx.de --- configs/tbs2910_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig index 55cd9bd998..fc15dcf013 100644 --- a/configs/tbs2910_defconfig +++ b/configs/tbs2910_defconfig @@ -5,7 +5,6 @@ CONFIG_SYS_TEXT_BASE=0x1780 CONFIG_TARGET_TBS2910=y CONFIG_CMD_HDMIDETECT=y CONFIG_NR_DRAM_BANKS=1 -CONFIG_FIT=y CONFIG_BOOTDELAY=3 CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_PRE_CON_BUF_ADDR=0x7c00 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
