[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.
Tom Rini
trini at konsulko.com
Wed Oct 25 13:45:26 UTC 2017
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 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.
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>
More information about the U-Boot
mailing list