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

Thu Jan 10 15:06:40 UTC 2019

On Thu, Jan 10, 2019 at 03:03:27PM +0100, Soeren Moch wrote:
> 
> 
> On 10.01.19 03:30, Tom Rini wrote:
> > 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.
> So default y might be OK if this feature is desired for new platforms.
> But I would prefer that the same patch series that introduces the
> default y also inserts all the "# CONFIG_WHATEVER is not set" in old
> board's defconfigs.

But that's close to the opposite of why you make something default y,
which I really do try and not do so often, but maybe I'm also not doing
a great job there.

But, digging into specifics for just a moment,
https://www.tbsdtv.com/launch/tbs-2910-matrix-arm-mini-pc.html is what
we're talking about here and that you can install $whatever on it as
$whatever expects to be able to have its EFI-application installer just
run (and be passed a device tree for the kernel) is part of why
EFI_LOADER is default enabled.

That's not saying you shouldn't still disable it if you need the space.

[snip]
> >> 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
> Setting CONFIG_OF_CONTROL and CONFIG_DEFAULT_DEVICE_TREE is the easy
> part (I also wrote the dts for this board in linux). But this only gives
> me a u-boot-dtb.imx, which is too large for the available flash space.
> And the newly introduced size check does not catch this, because the
> final image name changed.

Sounds like a bug that u-boot-dtb.imx isn't getting the size check done,
and we should fix that.

> But OK, when I disable CONFIG_EFI_LOADER, the size fits. I can boot this
> image and it works, other users probably are not aware of the new image
> name and boot the wrong one.

I think we've got a place where once again, sadly, iMX is a bit behind
the curve.  On other SoCs when we make the switch broadly, we go from
"u-boot-dtb.foo and u-boot.foo" to "u-boot-nodtb.foo and u-boot.foo".

> But OK, let's go ahead. When I enable DM_MMC as mandatory for v2019.04,
> the build fails in the dwc_ahsata driver. So I have to disable sata for
> this board, what I really not like to do, especially as sata conversion
> is due for v2019.07.

Yes, sadly you might need to turn off SATA support for a release.

> But OK, let's try without sata. The build runs through now, I can start
> this image, but it immediately hangs at Loading Environment from MMC...
> 
> So there is much more to do than the simple board config conversion. The
> DM core and drivers are not ready for the requested board conversions,
> at least it looks like this for me. And I have no idea how this
> conversion can be done transparently for users due to the new boot image
> name.

You might need to look at some of the other i.MX boards which do enable
DM_MMC and see what you're possibly missing.
configs/imx6qdl_icore_mipi_defconfig is another i.MX6Q/DL platform with
DM_MMC and ENV_IS_IN_MMC.

-- 
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/20190110/342a4d63/attachment.sig>