Re: [U-Boot] Bug#897671: u-boot does not work on sheevaplug
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=4dfb0e4d3e75763d6fbe8788316bea9b...
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
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=4dfb0e4d3e75763d6fbe8788316bea9b...
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!
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=4dfb0e4d3e75763d6fbe8788316bea9b...
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/f21cd9640052a733e1759519e3d7ca0f9453... 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
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=4dfb0e4d3e75763d6fbe8788316bea9b...
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
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
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).
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
Am 09.05.2018 um 14:33 schrieb klaus.goger@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!
On 2018-05-09, Markus Krebs wrote:
Am 09.05.2018 um 14:33 schrieb klaus.goger@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
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@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)!
participants (5)
-
drEagle -
klaus.goger＠theobroma-systems.com -
Markus Krebs -
Tom Rini -
Vagrant Cascadian