From mboxrd@z Thu Jan 1 00:00:00 1970 From: Soeren Moch Date: Fri, 11 Jan 2019 14:11:38 +0100 Subject: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size In-Reply-To: <20190110150640.GT5463@bill-the-cat> References: <20190105083118.13491-1-smoch@web.de> <20190105083118.13491-2-smoch@web.de> <63e7db53-dcaa-35cf-0d0e-f7bf5483c5c8@web.de> <20190109223917.GA5463@bill-the-cat> <20190110023029.GB5463@bill-the-cat> <20190110150640.GT5463@bill-the-cat> Message-ID: <5e97b3d6-2baf-de43-3bb2-0a17696f4f79@web.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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