On Thu, Jan 10, 2019 at 5:54 PM Tom Rini trini@konsulko.com 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 sbabic@denx.de 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. Mhmmhh....this 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?
We have CONFIG_BOARD_SIZE_LIMIT, which I would be unsurprised to learn also needs to be used in just a few more targets in the top-level Makefile.
Anyway, if new default y things aren't the problem, it's probably an increasement here and there, like Stefano said... :-(
Well, which part? There's the huge jump that I want to see what's going on with on Stefano's PowerPC board. Looking at SoCFPGA for that time-frame, wow, there's a lot of growth due to how we've fixed things in FAT write support. Then it's EFI fixes and UBI fixes. A lot of that growth could be returned by dropping LOGLEVEL. In fact, a quick test of going down to CONFIG_LOGLEVEL=2 shows a net reduction of 6KiB instead of 40KiB growth.
Luckily, I'm not having a huge jump like Stefano. Also, in my 200 KiB config, I don't have FAT support enabled. EFI and UBI are disabled, logging is disabled as well, so I don't expect that changing CONFIG_LOGLEVEL would change anything.
Seems like there's no easy way out and I have to keep monitoring the size. I'll try to add the automatic size check at least.
Thanks, Simon