From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 25 Oct 2017 09:45:26 -0400 Subject: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al. In-Reply-To: <20171025145844.3fe7077a@i7> References: <20171019082649.27819-1-maxime.ripard@free-electrons.com> <829444bb-fa9e-40a4-3b58-f5506557f89b@arm.com> <20171019132457.dcsamtfncimf53af@flea> <20171019145855.iwzw4q24zmkq6t7z@flea> <1508535237.2990.4.camel@ausil.us> <20171023073532.4s72bvsg532gjvxf@flea> <1508864702.5075.9.camel@ausil.us> <20171025145844.3fe7077a@i7> Message-ID: <20171025134526.GV22919@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On Wed, Oct 25, 2017 at 02:58:44PM +0300, Siarhei Siamashka wrote: > On Tue, 24 Oct 2017 18:21:43 +0100 > Andre Przywara 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: