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

[Andre Przywara]

Hi,

On 25/10/17 10:42, Maxime Ripard wrote:
> On Tue, Oct 24, 2017 at 06:21:43PM +0100, Andre Przywara wrote:
>> 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.
> 
> I started to look into the latter as well, because that's really what
> I'd like to see (for some time at least).
> 
> I guess having a custom environment handling method would be the best,
> and it doesn't seem that hard.
> 
> The behaviour I had in mind would be, when reading:
>   - Look for an environment in a FAT partition
>   - If not:
>     - Load the raw environment
>     - Print a warning
> 
> When writing:
>   - Try to write the environment to a FAT partition
>   - If it fails:
>     - Write to the raw environment
>     - Print a warning
> 
> That way, we can slowly migrate users in a transparent manner as soon
> as they would use saveenv, and we also provide a warning that things
> might (and actually will) break in the future if the setup isn't
> changed.

That was exactly what I had in mind as well!

Do you have some spare cycles to implement this? If not, I can give it a
try.

> We could even just rely on the existing methods from both standards
> environment code, we just need to make the functions !static.

There is even a Delphic comment in env/Kconfig:
"At *present* the environment can be stored in only one place."
;-)


Cheers,
Andre.

P.S. I will arrive tonight in Prague, for the DT workshop tomorrow.