[U-Boot] Bug#897671: u-boot does not work on sheevaplug

[drEagle]

Hello all,

Take my apologies for the late activity and also for the mailer I am using, which may disturb the following reading.

> Le 6 mai 2018 à 02:13, Tom Rini <trini at konsulko.com> a écrit :
> 
> On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
> 
>> Hello U-Boot.
>> 
>> Markus Krebs discovered that the sheevaplug target has again grown and
>> installation overlaps where the u-boot env is saved since u-boot
>> ~2017.09. Running saveenv overwrites u-boot, and installing u-boot
>> overwrites any prior environment settings.
>> 
>> More detail on the bug report in Debian:
>> 
>>  https://bugs.debian.org/897671
>> 
>> We don't carry any patches for the sheevaplug u-boot target in Debian,
>> so this is likely also an issue upstream. Who are the current
>> maintainers for sheevaplug in u-boot upstream?
>> 
>> A brief summary of the current findings:
>> 
>> On 2018-05-05, Markus Krebs wrote:
>>> Am 05.05.2018 um 20:36 schrieb Markus Krebs:
>>>> Am 05.05.2018 um 20:35 schrieb Martin Michlmayr:
>>>>> * Markus Krebs <Markus.Krebs at web.de> [2018-05-05 20:32]:
>>>>>> I got it. Indeed it has to to with the size of u-boot.
>>>>> 
>>>>> Does it boot?
>>>>> 
>>>> 
>>>> Yes it does.
>>> 
>>> ... and no longer so, when I "saveenv" :-(
>>> 
>>> I downloaded u-boot via git; I guess that the config for u-boot for 
>>> sheevaplug is already broken upstream (in sheevaplug.h):
>>> 
>>>   #define CONFIG_ENV_SIZE                 0x20000 /* 128k */
>>>   #define CONFIG_ENV_ADDR                 0x80000
>>>   #define CONFIG_ENV_OFFSET               0x80000 /* env starts here */
>>> 
>>> but the environment shouldn't start at 0x80000 when u-boot.kwb > 524 KB; 
>>> in this case 'saveenv' overwrites u-boot (?).
>>> Changing 0x80000 to 0xa0000 helps ; I compiled a u-boot.kwb from the 
>>> so-modified sources, and now I can start Debian fine.
>> 
>> It looks like it was bumped from 0x60000 to 0x80000 in 2014:
>> 
>>  http://git.denx.de/?p=u-boot.git;a=commit;h=4dfb0e4d3e75763d6fbe8788316bea9ba23e8e01
>> 
>> If 0x80000 isn't enough, there might be some features in the config to
>> experiment with removing, or it may need to be bumped again.
> 
> I've added the maintainer to the list as well.  I would suggest looking
> for things to trim out, perhaps CMD_MEMTEST ?  Also, a patch to make it
> a link error when we exceed the size allowed would be great, so that in
> the future we catch this when it happens.  Thanks!
> 
> 

Take a look to the proposal of patching the env config files to MTD1 and not offsetting from MTD0, which may take a quick fix.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781874 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781874>

> UBOOT ENV offset can be defined in sheevaplug.config in two ways.
> With a global offset as usual defined, but gets read errors if ENV move :
> +/dev/mtd0           0x80000         0x20000     0x20000
> Or, my prefered proposition, which will not need change with future modification of uboot size :
> +/dev/mtd1           0x0             0x20000     0x20000

Take also a look to openwork patches where the size is offset to 0xE0000 on Kirkwood supported boards.

https://github.com/openwrt/openwrt/blob/f21cd9640052a733e1759519e3d7ca0f9453653b/package/boot/uboot-kirkwood/patches/110-dockstar.patch <https://github.com/openwrt/openwrt/blob/f21cd9640052a733e1759519e3d7ca0f9453653b/package/boot/uboot-kirkwood/patches/110-dockstar.patch>


-#define CONFIG_ENV_ADDR			0x80000
-#define CONFIG_ENV_OFFSET		0x80000	/* env starts here */
+#define CONFIG_ENV_OFFSET		0xe0000	/* env starts here */


I remember having a lot of troubles with this and I proposed the two solutions.
Better way will add also a test to get no write at all if overlapping binary, and we will get a robust solution.

GK2