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

[Tom Rini]

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

Right.

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

OK, good.

> 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 next release, v2019.04, it's just MMC and SPI.
Everything else is v2019.07.  And in all of these cases, the subsystems
are converted and there's other SoC drivers to look at for conversion.
But yes, i.MX is in a bad spot here.  As a board maintainer, what you
should focus on first is enabling CONFIG_OF_CONTROL and setting (and
grabbing from Linux the file for) CONFIG_DEFAULT_DEVICE_TREE and in
those cases, there's lots of i.MX examples to look at.

> I can offer to help with testing for adapted mmc, usb, and sata drivers
> for the imx6qdl family. But I will not do the driver conversions myself.

That's fine and great, thanks!

-- 
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/20190109/481fea4f/attachment.sig>