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 <tr...@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.kr...@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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
