[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

Wed Oct 25 11:58:44 UTC 2017

On Tue, 24 Oct 2017 18:21:43 +0100
Andre Przywara <andre.przywara at 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