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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
