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

Fri Jan 11 13:11:38 UTC 2019


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

Regards,
Soeren