On Thu, Jan 10, 2019 at 5:54 PM Tom Rini <tr...@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 <sba...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
