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

[Tom Rini <trini@konsulko.com>]

On Wed, Oct 25, 2017 at 02:58:44PM +0300, Siarhei Siamashka wrote:
> On Tue, 24 Oct 2017 18:21:43 +0100
> Andre Przywara <andre.przywara@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.

Would you mind posting the runtime decompression part?  We have other
platforms that are already stuck due to small size limits and something
like this might finally un-block them.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171025/f4e82364/attachment.sig>