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

[Andre Przywara <andre.przywara@arm.com>]

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. 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 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.

Cheers,
Andre.