On Tue, 24 Oct 2017 18:21:43 +0100 Andre Przywara <andre.przyw...@arm.com> wrote:
> Hi, > > On 24/10/17 18:05, Dennis Gilmore wrote: > > El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió: > >> On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote: > >>> El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió: > >>>> On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: > >>>>> Hi, > >>>>> > >>>>> On 19/10/17 14:24, Maxime Ripard wrote: > >>>>>> On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara > >>>>>> wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> On 19/10/17 09:26, Maxime Ripard wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Most featureful boards, such as the Cubietruck, have been > >>>>>>>> broken since > >>>>>>>> the release 2017.09. > >>>>>>>> > >>>>>>>> This is due to a size increase of the binary that will > >>>>>>>> trip > >>>>>>>> us across > >>>>>>>> the size we've been using in the u-boot-sunxi-with- > >>>>>>>> spl.bin > >>>>>>>> file. > >>>>>>>> > >>>>>>>> We would have two ways to work around it. The first one > >>>>>>>> would > >>>>>>>> be to > >>>>>>>> just increase the offset of the environment. However, > >>>>>>>> since > >>>>>>>> it would > >>>>>>>> break all the environments of our users and possibly the > >>>>>>>> custom > >>>>>>>> partition scheme that they would have created, it doesn't > >>>>>>>> really seem > >>>>>>>> like a smart move. > >>>>>>> > >>>>>>> Is that really such a problem? How many people rely on > >>>>>>> having > >>>>>>> their > >>>>>>> custom environment preserved over an update? (That's an > >>>>>>> honest > >>>>>>> question) > >>>>>> > >>>>>> All of them, I guess. In your U-boot upgrade script, do you > >>>>>> do a > >>>>>> 'env > >>>>>> default -a; saveenv' all the time ? > >>>>>> > >>>>>> I know I don't. > >>>>> > >>>>> Well, I never use the saved environment and always expected > >>>>> some > >>>>> user or > >>>>> board specific environment to come from some file (boot.scr or > >>>>> something > >>>>> loaded via TFTP). But that's just my personal use, hence I was > >>>>> asking. > >>>> > >>>> Well, even if you want to boot to tftp, you'll need to have some > >>>> setup > >>>> to do, even just to use a different server IP, and that will be > >>>> in > >>>> the > >>>> environment. > >>> > >>> I personally just use pxe boot > >> > >> It's not really about what personally you use, but what any user can > >> use. > > Not saying that it is. but how I use it is really simple for the user > > to use without needing to have a ton of specific knowledge about how u- > > boot works > > > >>> dhcp > >>> pxe get > >>> pxe boot > >>> and pick the right option. nothing needed on the client side. > >> > >> It has the assumption that the DHCP server is setup properly, which > >> might or might not be the case, especially when it comes to the > >> server > >> option being there and valid. > >> > >> Maxime > > Anyone doing something like this on X86 has to have the same setup. its > > not that hard of a ask to assume that a pxe environment is available. > > you can skip the dhcp part and set the serrver ip and system ip > > manually, its just simpler to use dhcp > > I agree to both of you ;-) > As Maxime already pointed out, it's a bit of a pointless discussion, as > x U-Boot users have possibly x different usage scenarios. > Some very actively do work on the U-Boot prompt and rely on a customized > and preserved environment, while others merely rely on some standardized > boot paths, using config_distro_bootcmd.h and PXE, DHCP and/or EFI. > > That being said I have prepared a patch to switch sunxi ARM64 boards > over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there > and have no Thumb2 to get off lightly. Even without Thumb2 we still can reduce footprint by taking advantage of compression for the main U-Boot binary. For this purpose we can use at least LZO because the decompressor code is really small (was it 200-300 bytes?) and still can fit in SPL. A more sophisticated approach can involve attaching the decompressor code to the main U-Boot binary itself. To be honest, I actually expected the size overflow problem to eventually happen for the SPL, resulting in a proposal of a similar radical feature chopping "solution". And when shit actually hits the fan, I will submit an LZO/UCL runtime decompression patch for the SPL, which can save the day :-) I have already mentioned this a few times in the past and it is our strategic reserve. The size overflow for the main U-Boot binary was a bit of surprise to me, but we still have it under control. Also as already discussed in this thread, we can just move the location of the environment to reserve more space for the main U-Boot binary (yes, handling the smooth environment location move during U-Boot upgrade will be a bit tricky, but still doable if anyone is really up to it). > And I believe that the arm64 boards mostly use a standardized way of > booting, also are much less wide spread, so the number of affected > users is probably less there. I don't think that we have any significant number of U-Boot env users on 32-bit sunxi hardware either. For example, we can do a search in the linux-sunxi wiki to compare the usage of environment vs. boot.scr and uEnv.txt: https://linux-sunxi.org/index.php?search=saveenv https://linux-sunxi.org/index.php?search=boot.scr https://linux-sunxi.org/index.php?search=uenv.txt Using saveenv is justified only in very rare exceptional cases. They do exist, otherwise Maxime would not have encountered the problem in the first place. But I think that we should encourage Maxime to migrate away from it. I would really like to know a bit more about his use case. The Linux distributions don't seem to rely on the U-Boot environment (if I understood their feedback correctly). Our tutorials at the linux-sunxi wiki encourage the use of boot.scr since a very long time ago. Anyone is free to deviate from good practices, but they should really know what they are doing and understand that they are expected to take care of their problems themselves. > I am just thinking of whether it's worthwhile to have some transition > code, which tries multiple environment locations (first FAT, then MMC, > for instance), or even contains code to migrate from one to another. Ugh. I think that this is a very bad idea. It makes the U-Boot environment handling even more convoluted and dangerous than it is now. I would prefer to keep the U-Boot environment (when its use is justified) tightly coupled with the bootloader itself and always stored on the same boot media. We do have the boot media id passed to us from the boot ROM, so this is pretty much straightforward. Allowing to move the environment to a different media is a recipe for disaster. Currently boot.scr or uEnv.txt is loaded from FAT or other partitions as part of distro boot. Is this really not enough? -- Best regards, Siarhei Siamashka _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
