[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: d-i for wheezy on a Dreamplug, docs/recommended practice?



Coming to this a bit late because I've been travelling

On Fri, 2013-03-22 at 19:42 +0100, Martin Lucina wrote:
> Hi,
> 
> having found some time to play with a Dreamplug I've given a go at
> installing wheezy using the d-i RC1 images. Got hit by #703146, but that is
> a separate problem (presumably d-i nightlies in the next few days will pick
> up the fixed debootstrap?).
> 
> Anyhow, my question / offer to help is: AFAICS at the moment there is no
> real documentation on how joe user can install wheezy on their Dreamplug
> using d-i, or if there is I haven't found it.
> 
> In my case, being vaguely familiar with U-boot (and having just flashed
> U-boot 2013.01.01 on the plug), I followed these steps:
> 
>     1. Download uImage and uInitrd from [1].
>     http://ftp.nl.debian.org/debian/dists/testing/main/installer-armel/current/images/.
>     2. Copy both to a (FAT-formatted) USB stick.
>     3. Boot into U-boot, stop the autoboot and run the following commands:
> 
>         usb start
>         usb tree
>         [determine, using "fatls" etc, which device is the usb stick]
>         setenv bootargs console=ttyS0,115200
>         fatload usb 2:1 0x6400000 uImage
>         fatload usb 2:1 0x8000000 uInitrd
>         bootm 0x6400000 0x8000000

This matches my notes. You can also use tftp etc if you prefer

> Who can I contact about getting these steps into the wheezy installation
> guide in some prominent place?

As has been pointed out already a bug against the"installation-guide"
package would be goods. Martin (who maintains some useful webpages at
http://www.cyrius.com/debian/kirkwood) might also be interested in some
content?

> Futher: What is a user w/o a JTAG device to do? How is he/she supposed to
> run the installer?

On the dreamplug the JTAG device is part of the serial console dongle,
which since you are interacting with the serial console you appear to
have?

We could in principal provide a network-console version of the
installer, as used on e.g. the QNAP devices
http://www.cyrius.com/debian/kirkwood/qnap/ts-41x/install.html
(obviously some of the specifics would differ with the dreamplug).
However I'm not sure how worthwhile this is -- how many people get a
dreamplug but don't shell out the little bit extra for the serial
console?

> Further #2: All of the instructions I've found on the net about upgrading
> U-boot discuss either using OpenOCD (which is unreliable as hell, I never
> managed to make it work due to timing problems),

FWIW OpenOCD works for me. My NOTES file says I use something like:

        sudo openocd -f /usr/share/openocd/scripts/board/sheevapl.cfg -s /usr/share/openocd/scripts

Then "telnet localhost 4444":
        reset;sheevaplug_init;load_image /tmp/u-boot;resume 0x00600000

Then at the resulting u-boot prompt:
        Marvell>> tftp 0x6400000 u-boot.kwb
        Marvell>> sf probe 0
        Marvell>> sf erase 0x0 0x100000
        Marvell>> sf write 0x6400000 0x0 0x${filesize}

IIRC I typically use this method to boot a working u-boot and then use
that to reflash a fixed u-boot, rather than trying to flash directly
with OpenOCD (although I think I've done that too in the past but
apparently not made any notes). If you've not bricked u-boot then only
the last section is needed.

>  or using an existing
> U-boot to load the new image and flash it.
> 
> There is another method which is not mentioned anywhere(!!) which I use and
> is 100% reliable, namely booting over UART using kwuartboot [2], loading
> the new image also over UART using e.g. kermit and then flashing it. Would
> it be worthwhile to document this somewhere? If so, where? Obviously this
> only works for people with the JTAG unit/some other compatible UART level
> converter.

That is pretty neat, is it "just" driving the u-boot command line in an
expect(1) like manner to start a kermit transfer or is it doing
something clever?

Ian.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: