Hi Tixy,
On Fri, 2013-05-17 at 09:24 +0100, Tixy wrote:
> Does anyone know of any foolproof method of getting Wheezy running on a
> Dreamplug?
>
> I believe this requires upgrading U-Boot (to get device-tree support/fix
> L2 cache issue?) but when I tried upgrading U-Boot by flashing it from
> U-Boot I ended up with an expensive brick. Now this may have been user
> error, but I don't want to risk bricking the new DreamPlug I bought
> without instructions which are known to work. Or, perhaps the safest
> thing is to load a new U-Boot from the old one if that's possible? And
> in desperation I may even resort to writing a shim to make the Wheezy
> kernel load with the stock U-Boot.
You can do this with devio. My NOTES file says (I've not tried this
recently, but I'm reasonably sure it worked when I made the notes):
$ (
# disable l2 caches
devio "wl 0xee3f3f11,4" # mrc 15, 1, r3, cr15, cr1, {0}
devio "wl 0xe3c33501,4" # bic r3, r3, #4194304 ; 0x400000
devio "wl 0xee2f3f11,4" # mcr 15, 1, r3, cr15, cr1, {0}
# flush caches
devio "wl 0xe3a03000,4" # mov r3, #0
devio "wl 0xee073f17,4" # mcr 15, 0, r3, cr7, cr7, {0}
cat vmlinuz-3.2.0-3-kirkwood
)> vmlinuz.devio
$ mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 \
-n "kernel 3.2.0-3-kirkwood" -d vmlinuz.devio myuImage
This ought to work equally well with the kernel file provided by the
installer.
> The method I was following which created a brick was to use the U-Boot
> binary linked from Martin Michlmayr's page [1] and flash it using the
> the sf probe/erase/write commands from the FreedomBox site [2].
FWIW what works for me is:
Marvell>> tftp 0x6400000 u-boot.kwb
Marvell>> sf probe 0
Marvell>> sf erase 0x0 0x100000
Marvell>> sf write 0x6400000 0x0 0x${filesize}
or if you have the u-boot package installed:
Marvell>> usb start
Marvell>> ext2load usb 1:2 0x6400000 /usr/lib/u-boot/dreamplug/u-boot.kwb
Marvell>> sf probe 0
Marvell>> sf erase 0x0 0x80000
Marvell>> sf write 0x6400000 0x0 0x${filesize}
> My attempts to debrick using openocd and the JTAG module were the same
> as another user [3] even when I scripted power cycling and openocd to
> run in a loop a to try and get the timing right (which was one of the
> suggested remedies). I gave up after 1000's of cycles in a overnight
> run.
It does seem to be a bit of a dice roll if it works. FWIW I use:
sudo openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg -s /usr/share/openocd/scripts
Then telnet to localhost port 4444 and:
reset;sheevaplug_init;load_image [path]/u-boot;resume 0x00600000
The openocd version is the Debian package 0.5.0-1, running on amd64.
Sadly based on that forum thread I don't expect that will help you.
I do remember having problems with loose cables between the DP and the
UART/JTAG module early on, but a firm reseating helped there.
Ian.
Attachment:
signature.asc
Description: This is a digitally signed message part