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

Fri Jan 11 14:44:03 UTC 2019

On Fri, Jan 11, 2019 at 08:22:45AM +0100, Simon Goldschmidt wrote:
> 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

Thanks.  This is another one of those great features that's not used /
plumbed in widely enough.  It's a bug that it's not in use in the areas
where we have DTB + image header.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190111/5a4acc85/attachment.sig>