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

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

[Vagrant Cascadian]

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

Not sure what the best coarse of action is.


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180505/ce18391a/attachment.sig>

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

[Tom Rini]

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@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!

-- 
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/20180505/351c390f/attachment.sig>

[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@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@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

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

[Vagrant Cascadian]

On 2018-05-05, Tom Rini wrote:
> On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
>> 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:
...
>> > 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 ?

Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling
EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a
*lot* left to disable in the config, but that's a significant start...

On a related note, I'm wondering if EFI_LOADER should only be enabled
with SYS_ARM_ARCH >= 7 by default, as many of the earlier arm systems
tend to be space-constrained, and those that aren't could enable it on a
case-by-case basis.


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

Will look into it, although would be happy if someone beats me to it. :)


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180508/a5636d6f/attachment.sig>

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

[Vagrant Cascadian]

On 2018-05-08, Vagrant Cascadian wrote:
> On 2018-05-05, Tom Rini wrote:
>> On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
>>> 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.
...
>> I've added the maintainer to the list as well.  I would suggest looking
>> for things to trim out, perhaps CMD_MEMTEST ?
>
> Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling
> EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a
> *lot* left to disable in the config, but that's a significant start...

And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
down to 432k! Thanks to beeble for the suggestion.

Anyone who has a sheevaplug can test that it actually boots with
CONFIG_SYS_THUMB_BUILD=y enabled?


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180508/61de2fb4/attachment.sig>

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

[Markus Krebs]

Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian:
> On 2018-05-08, Vagrant Cascadian wrote:
>> On 2018-05-05, Tom Rini wrote:
>>> On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
>>>> 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.
> ...
>>> I've added the maintainer to the list as well.  I would suggest looking
>>> for things to trim out, perhaps CMD_MEMTEST ?
>>
>> Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling
>> EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a
>> *lot* left to disable in the config, but that's a significant start...
> 
> And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
> down to 432k! Thanks to beeble for the suggestion.
> 
> Anyone who has a sheevaplug can test that it actually boots with
> CONFIG_SYS_THUMB_BUILD=y enabled?

I could test it, but I don't know the config-file where I can change 
those options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD).

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

[klaus.goger at theobroma-systems.com]

> On 09.05.2018, at 10:19, Markus Krebs <Markus.Krebs@web.de> wrote:
> 
> Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian:
>> On 2018-05-08, Vagrant Cascadian wrote:
>>> On 2018-05-05, Tom Rini wrote:
>>>> On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
>>>>> 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.
>> ...
>>>> I've added the maintainer to the list as well.  I would suggest looking
>>>> for things to trim out, perhaps CMD_MEMTEST ?
>>> 
>>> Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling
>>> EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a
>>> *lot* left to disable in the config, but that's a significant start...
>> And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
>> down to 432k! Thanks to beeble for the suggestion.
>> Anyone who has a sheevaplug can test that it actually boots with
>> CONFIG_SYS_THUMB_BUILD=y enabled?
> 
> I could test it, but I don't know the config-file where I can change those options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD).

Both are Kconfig options. So just disable it via menuconfig or in your .config file

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

[Markus Krebs]

Am 09.05.2018 um 14:33 schrieb klaus.goger at theobroma-systems.com:
> 
> 
>> On 09.05.2018, at 10:19, Markus Krebs <Markus.Krebs@web.de> wrote:
>>
>> Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian:
>>> On 2018-05-08, Vagrant Cascadian wrote:
>>>> On 2018-05-05, Tom Rini wrote:
>>>>> On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
>>>>>> 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.
>>> ...
>>>>> I've added the maintainer to the list as well.  I would suggest looking
>>>>> for things to trim out, perhaps CMD_MEMTEST ?
>>>>
>>>> Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling
>>>> EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a
>>>> *lot* left to disable in the config, but that's a significant start...
>>> And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
>>> down to 432k! Thanks to beeble for the suggestion.
>>> Anyone who has a sheevaplug can test that it actually boots with
>>> CONFIG_SYS_THUMB_BUILD=y enabled?
>>
>> I could test it, but I don't know the config-file where I can change those options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD).
> 
> Both are Kconfig options. So just disable it via menuconfig or in your .config file
> 

Thanks. The modified u-boot (size indeed 441592 bytes only) boots!

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

[Vagrant Cascadian]

On 2018-05-09, Markus Krebs wrote:
> Am 09.05.2018 um 14:33 schrieb klaus.goger at theobroma-systems.com:
>>> On 09.05.2018, at 10:19, Markus Krebs <Markus.Krebs@web.de> wrote:
>>> Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian:
>>>> On 2018-05-08, Vagrant Cascadian wrote:
>>>>> On 2018-05-05, Tom Rini wrote:
>>>>>> On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
>>>>>>> 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.
...
>>>> And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
>>>> down to 432k! Thanks to beeble for the suggestion.
>>>> Anyone who has a sheevaplug can test that it actually boots with
>>>> CONFIG_SYS_THUMB_BUILD=y enabled?
>>>
>>> I could test it, but I don't know the config-file where I can change
>>> those options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD).
>> 
>> Both are Kconfig options. So just disable it via menuconfig or in your .config file
>
> Thanks. The modified u-boot (size indeed 441592 bytes only) boots!

Can you try with CONFIG_SYS_THUMB_BUILD=y only (e.g. leave EFI_LOADER at
the default).


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180510/ed04d562/attachment.sig>

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

[Markus Krebs]

Am 10.05.2018 um 20:10 schrieb Vagrant Cascadian:
> On 2018-05-09, Markus Krebs wrote:
>> Am 09.05.2018 um 14:33 schrieb klaus.goger at theobroma-systems.com:
>>>> On 09.05.2018, at 10:19, Markus Krebs <Markus.Krebs@web.de> wrote:
>>>> Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian:
>>>>> On 2018-05-08, Vagrant Cascadian wrote:
>>>>>> On 2018-05-05, Tom Rini wrote:
>>>>>>> On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
>>>>>>>> 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.
> ...
>>>>> And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
>>>>> down to 432k! Thanks to beeble for the suggestion.
>>>>> Anyone who has a sheevaplug can test that it actually boots with
>>>>> CONFIG_SYS_THUMB_BUILD=y enabled?
>>>>
>>>> I could test it, but I don't know the config-file where I can change
>>>> those options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD).
>>>
>>> Both are Kconfig options. So just disable it via menuconfig or in your .config file
>>
>> Thanks. The modified u-boot (size indeed 441592 bytes only) boots!
> 
> Can you try with CONFIG_SYS_THUMB_BUILD=y only (e.g. leave EFI_LOADER at
> the default).

Yes, it works (size now 473740 bytes)!