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

Fri Jan 11 14:32:07 UTC 2019

On Fri, Jan 11, 2019 at 02:11:38PM +0100, Soeren Moch wrote:
> 
> 
> On 10.01.19 16:06, Tom Rini wrote:
> > 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.
> You say we should intentionally break user systems which are configured
> to boot over SATA? And the only reason for this is your arbitrary
> deadline for enforcing DM_MMC without DM_SCSI ? Really?

After the number of years we're at with lack of action here, yes.
Because it's not unlikely that the driver will be removed in the
following release due to lack of maintainer.

> >> 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.
> >
> Will look at this if I find time to do so.

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/20190111/fdbb3ee7/attachment.sig>