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.go...@theobroma-systems.com:

On 09.05.2018, at 10:19, Markus Krebs  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)!

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.go...@theobroma-systems.com:
>>> On 09.05.2018, at 10:19, Markus Krebs  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


signature.asc
Description: PGP signature

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

[Markus Krebs]

Am 09.05.2018 um 14:33 schrieb klaus.go...@theobroma-systems.com:




On 09.05.2018, at 10:19, Markus Krebs  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!

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

[klaus . goger]

> On 09.05.2018, at 10:19, Markus Krebs  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

Bug#897671: [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).

Bug#897671: [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


signature.asc
Description: PGP signature

Bug#897671: [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 0x8 when u-boot.kwb > 524 KB; 
>> > in this case 'saveenv' overwrites u-boot (?).
>> > Changing 0x8 to 0xa 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 0x6 to 0x8 in 2014:
>> 
>>   
>> http://git.denx.de/?p=u-boot.git;a=commit;h=4dfb0e4d3e75763d6fbe8788316bea9ba23e8e01
>> 
>> If 0x8 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


signature.asc
Description: PGP signature

Bug#897671: [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  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  [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 0x2 /* 128k */
>>>   #define CONFIG_ENV_ADDR 0x8
>>>   #define CONFIG_ENV_OFFSET   0x8 /* env starts here */
>>> 
>>> but the environment shouldn't start at 0x8 when u-boot.kwb > 524 KB; 
>>> in this case 'saveenv' overwrites u-boot (?).
>>> Changing 0x8 to 0xa 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 0x6 to 0x8 in 2014:
>> 
>>  
>> http://git.denx.de/?p=u-boot.git;a=commit;h=4dfb0e4d3e75763d6fbe8788316bea9ba23e8e01
>> 
>> If 0x8 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 


> 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   0x8 0x2 0x2
> Or, my prefered proposition, which will not need change with future 
> modification of uboot size :
> +/dev/mtd1   0x0 0x2 0x2

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

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



-#define CONFIG_ENV_ADDR0x8
-#define CONFIG_ENV_OFFSET  0x8 /* env starts here */
+#define CONFIG_ENV_OFFSET  0xe /* 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

Bug#897671: [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  [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 0x2 /* 128k */
> >#define CONFIG_ENV_ADDR 0x8
> >#define CONFIG_ENV_OFFSET   0x8 /* env starts here */
> >
> > but the environment shouldn't start at 0x8 when u-boot.kwb > 524 KB; 
> > in this case 'saveenv' overwrites u-boot (?).
> > Changing 0x8 to 0xa 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 0x6 to 0x8 in 2014:
> 
>   
> http://git.denx.de/?p=u-boot.git;a=commit;h=4dfb0e4d3e75763d6fbe8788316bea9ba23e8e01
> 
> If 0x8 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


signature.asc
Description: PGP signature

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  [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 0x2 /* 128k */
>#define CONFIG_ENV_ADDR 0x8
>#define CONFIG_ENV_OFFSET   0x8 /* env starts here */
>
> but the environment shouldn't start at 0x8 when u-boot.kwb > 524 KB; 
> in this case 'saveenv' overwrites u-boot (?).
> Changing 0x8 to 0xa 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 0x6 to 0x8 in 2014:

  
http://git.denx.de/?p=u-boot.git;a=commit;h=4dfb0e4d3e75763d6fbe8788316bea9ba23e8e01

If 0x8 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


signature.asc
Description: PGP signature

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Am 05.05.2018 um 20:36 schrieb Markus Krebs:

Am 05.05.2018 um 20:35 schrieb Martin Michlmayr:

* Markus Krebs  [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 0x2 /* 128k */
  #define CONFIG_ENV_ADDR 0x8
  #define CONFIG_ENV_OFFSET   0x8 /* env starts here */

but the environment shouldn't start at 0x8 when u-boot.kwb > 524 KB; 
in this case 'saveenv' overwrites u-boot (?).
Changing 0x8 to 0xa helps ; I compiled a u-boot.kwb from the 
so-modified sources, and now I can start Debian fine.


Markus

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Am 05.05.2018 um 20:35 schrieb Martin Michlmayr:

* Markus Krebs  [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.

Bug#897671: u-boot does not work on sheevaplug

[Martin Michlmayr]

* Markus Krebs  [2018-05-05 20:32]:
> I got it. Indeed it has to to with the size of u-boot.

Does it boot?
-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

I got it. Indeed it has to to with the size of u-boot.
The space in the command in your instructions "nand erase 0x0 0x8" 
is too small now for u-boot.kwb. I tried "nand erase 0x0 0xc0" 
(which should still be ok, as mtd0 is 1 Megabyte) and everything works 
fine (flashing with ${filesize} afterwards of course).


This works when flashing from u-boot. For flashing from Debian maybe 
"/etc/fw_env.config" must be changed? Or the commands/values in 
/usr/share/doc/u-boot/README.Debian which are


  sudo flash_erase /dev/mtd0 0 0
  sudo nandwrite -p /dev/mtd0 /usr/lib/u-boot/sheevaplug/u-boot.kwb

I don't know how, though. Maybe you can direct me?

Am 05.05.2018 um 14:41 schrieb Markus Krebs:

It gives the same type of error when flashing:

  NAND write: device 0 offset 0x0, size 0x934cc
  nand_write_ecc: Attempt to write not page aligned data
   0 bytes written: ERROR


Am 05.05.2018 um 11:13 schrieb Martin Michlmayr:

Can you try:
http://ftp.debian.org/debian/pool/main/u/u-boot/u-boot_2018.05~rc3+dfsg-1_armel.deb 

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

It gives the same type of error when flashing:

 NAND write: device 0 offset 0x0, size 0x934cc
 nand_write_ecc: Attempt to write not page aligned data
  0 bytes written: ERROR


Am 05.05.2018 um 11:13 schrieb Martin Michlmayr:

Can you try:
http://ftp.debian.org/debian/pool/main/u/u-boot/u-boot_2018.05~rc3+dfsg-1_armel.deb

Bug#897671: u-boot does not work on sheevaplug

[Martin Michlmayr]

Can you try:
http://ftp.debian.org/debian/pool/main/u/u-boot/u-boot_2018.05~rc3+dfsg-1_armel.deb

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

I can report now:

- u-boot up to 2017.07+dfsg1-3 works fine.

- 2017.09+dfsg1-3: can be flashed, but after reset usb doesn't work 
properly:

 => usb start
 starting USB...
 USB0:   USB EHCI 1.00
 scanning bus 0 for devices...
 [and no more reaction]

-  2017.11+dfsg1-3: cannot even be flashed:
 => nand write 0x080 0x0 ${filesize}
 NAND write: device 0 offset 0x0, size 0x8f924
 NAND write to offset 0 failed -5
   0 bytes written: ERROR

Markus


Am 04.05.2018 um 21:02 schrieb Markus Krebs:
Just thinking: Maybe it does indeed have something to do with the size 
of u-boot. The one from bodhi is 524 KB, whereas the Debian one is 599 KB.



Am 04.05.2018 um 20:40 schrieb Markus Krebs:
Interesting thoughts, but: I tried again flashing both from within 
Debian and from u-boot (using ${filesize}). $filesize is accepted and 
flashing works, but the plug doesn't boot.
Flashing (again with $filesize, just to confirm it works) the u-boot 
from bodhi-linux (the one I was referring to) works, so it must be the 
u-boot.kwb in Debian which is broken.



Am 04.05.2018 um 19:11 schrieb Martin Michlmayr:

* Vagrant Cascadian  [2018-05-04 08:40]:

I do recall that there was some incompatible change regarding the
environment size on some of the marvell platforms, as u-boot.kwb grew
large enough to overwrite the environment section.

Uh, this might not be an u-boot issue then but a problem with my
upgrade instructions (although Markus said he tried to do the update
from within Debian too, so maybe not).

https://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/ says:
nand write 0x080 0x0 0x8

0x8 = 524288

but:
-rw-r--r-- 1 tbm tbm 599684 Apr  2 03:20 
usr/lib/u-boot/sheevaplug/u-boot.kwb


so we're not writing the whole binary to flash.

The reason I used 0x8 instead of ${filesize} is because very old
u-boot versions (as originally shipped on the SheevaPlug) have
problems with ${filesize}:

 NAND write: device 0 offset 0x0, size 0x68ab0
 nand_write_ecc: Attempt to write not page aligned data
  0 bytes written: ERROR

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Just thinking: Maybe it does indeed have something to do with the size 
of u-boot. The one from bodhi is 524 KB, whereas the Debian one is 599 KB.



Am 04.05.2018 um 20:40 schrieb Markus Krebs:
Interesting thoughts, but: I tried again flashing both from within 
Debian and from u-boot (using ${filesize}). $filesize is accepted and 
flashing works, but the plug doesn't boot.
Flashing (again with $filesize, just to confirm it works) the u-boot 
from bodhi-linux (the one I was referring to) works, so it must be the 
u-boot.kwb in Debian which is broken.



Am 04.05.2018 um 19:11 schrieb Martin Michlmayr:

* Vagrant Cascadian  [2018-05-04 08:40]:

I do recall that there was some incompatible change regarding the
environment size on some of the marvell platforms, as u-boot.kwb grew
large enough to overwrite the environment section.

Uh, this might not be an u-boot issue then but a problem with my
upgrade instructions (although Markus said he tried to do the update
from within Debian too, so maybe not).

https://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/ says:
nand write 0x080 0x0 0x8

0x8 = 524288

but:
-rw-r--r-- 1 tbm tbm 599684 Apr  2 03:20 
usr/lib/u-boot/sheevaplug/u-boot.kwb


so we're not writing the whole binary to flash.

The reason I used 0x8 instead of ${filesize} is because very old
u-boot versions (as originally shipped on the SheevaPlug) have
problems with ${filesize}:

 NAND write: device 0 offset 0x0, size 0x68ab0
 nand_write_ecc: Attempt to write not page aligned data
  0 bytes written: ERROR

Bug#897671: u-boot does not work on sheevaplug

[Martin Michlmayr]

* Markus Krebs  [2018-05-04 20:40]:
> Interesting thoughts, but: I tried again flashing both from within Debian
> and from u-boot (using ${filesize}). $filesize is accepted and flashing
> works, but the plug doesn't boot.
> Flashing (again with $filesize, just to confirm it works) the u-boot from
> bodhi-linux (the one I was referring to) works, so it must be the u-boot.kwb
> in Debian which is broken.

In this case, I guess the u-boot binary plus my instructions are
broken. ;)

Maybe you can find out which versions work / do not work.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Interesting thoughts, but: I tried again flashing both from within 
Debian and from u-boot (using ${filesize}). $filesize is accepted and 
flashing works, but the plug doesn't boot.
Flashing (again with $filesize, just to confirm it works) the u-boot 
from bodhi-linux (the one I was referring to) works, so it must be the 
u-boot.kwb in Debian which is broken.



Am 04.05.2018 um 19:11 schrieb Martin Michlmayr:

* Vagrant Cascadian  [2018-05-04 08:40]:

I do recall that there was some incompatible change regarding the
environment size on some of the marvell platforms, as u-boot.kwb grew
large enough to overwrite the environment section.

Uh, this might not be an u-boot issue then but a problem with my
upgrade instructions (although Markus said he tried to do the update
from within Debian too, so maybe not).

https://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/ says:
nand write 0x080 0x0 0x8

0x8 = 524288

but:
-rw-r--r-- 1 tbm tbm 599684 Apr  2 03:20 usr/lib/u-boot/sheevaplug/u-boot.kwb

so we're not writing the whole binary to flash.

The reason I used 0x8 instead of ${filesize} is because very old
u-boot versions (as originally shipped on the SheevaPlug) have
problems with ${filesize}:

 NAND write: device 0 offset 0x0, size 0x68ab0
 nand_write_ecc: Attempt to write not page aligned data
  0 bytes written: ERROR

Bug#897671: u-boot does not work on sheevaplug

[Martin Michlmayr]

* Vagrant Cascadian  [2018-05-04 08:40]:
> I do recall that there was some incompatible change regarding the
> environment size on some of the marvell platforms, as u-boot.kwb grew
> large enough to overwrite the environment section.

Uh, this might not be an u-boot issue then but a problem with my
upgrade instructions (although Markus said he tried to do the update
from within Debian too, so maybe not).

https://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/ says:
nand write 0x080 0x0 0x8

0x8 = 524288

but:
-rw-r--r-- 1 tbm tbm 599684 Apr  2 03:20 usr/lib/u-boot/sheevaplug/u-boot.kwb

so we're not writing the whole binary to flash.

The reason I used 0x8 instead of ${filesize} is because very old
u-boot versions (as originally shipped on the SheevaPlug) have
problems with ${filesize}:

NAND write: device 0 offset 0x0, size 0x68ab0
nand_write_ecc: Attempt to write not page aligned data
 0 bytes written: ERROR

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#897671: u-boot does not work on sheevaplug

[Vagrant Cascadian]

On 2018-05-04, Martin Michlmayr  wrote:
> * Markus Krebs  [2018-05-04 06:33]:
>> Version: 2018.03+dfsg1-2
>> 
>> The u-boot.kwb provided at https://forum.doozan.com/read.php?3,12381 works.
>
> That is version 2017.07.  If you have time, could you try some
> versions from http://snapshot.debian.org/package/u-boot/  Not all of
> them but maybe
>
> 2018.01+dfsg1-2
> 2017.11+dfsg1-3
> 2017.09+dfsg1-3
> 2017.07+dfsg1-3

And also 2018.05-rc3+dfsg-1, currently in debian experimental; maybe
it's fixed in the newest version.

I do recall that there was some incompatible change regarding the
environment size on some of the marvell platforms, as u-boot.kwb grew
large enough to overwrite the environment section.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#897671: u-boot does not work on sheevaplug

[Martin Michlmayr]

* Markus Krebs  [2018-05-04 06:33]:
> Version: 2018.03+dfsg1-2
> 
> The u-boot.kwb provided at https://forum.doozan.com/read.php?3,12381 works.

That is version 2017.07.  If you have time, could you try some
versions from http://snapshot.debian.org/package/u-boot/  Not all of
them but maybe

2018.01+dfsg1-2
2017.11+dfsg1-3
2017.09+dfsg1-3
2017.07+dfsg1-3

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Package: u-boot
Version: 2018.03+dfsg1-2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

flashing the newest u-boot.kwb on sheevaplug makes the system unbootable. I 
tried flashing out of Debian as well as from u-boot - no difference. One must 
flash a different u-boot via OpenOCD to bring the system back to life again.
The u-boot.kwb provided at https://forum.doozan.com/read.php?3,12381 works.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armel (armv5tel)

Kernel: Linux 4.15.0-3-marvell
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Markus