[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

Fri Jan 11 07:22:45 UTC 2019

On Thu, Jan 10, 2019 at 5:54 PM Tom Rini <trini at 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 at 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.

So I just tried that and it doesn't really work as the size checked is without
DTB and without image header. These two add up to nearly 20 KiB on my board,
so a size check without them is not really worth anything.

I'll send a patch to check the size of u-boot.img

Regards,
Simon

>
> > 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.
>
> --
> Tom