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