How do you compile uboot on the dockstar?

I did the commands below which are what was posted to do with the exception of two things.
1. Did a make -f Makefile_doimage in the tools directory of the pogo uboot source and used it
2. Did not run codesourcery-arm-2009q3.sh since I am compiling natively

What I get locks up the dockstar when I tftp it and try to run it.

The image that is produced does not equal the image posted either. I would think they should be the same except for the time it was compiled and the checksum.

Can someone let me know what I am doing wrong and how to compile uboot on the Dockstar.

Thanks,

ygator



git clone git://git.denx.de/u-boot.git u-boot
cd u-boot

wget http://jeff.doozan.com/debian/uboot/dramregs_pp128_A.txt
#wget http://jeff.doozan.com/debian/uboot/doimage
#chmod +x doimage
# I did a make -f Makefile_doimage in the tools directory of the pogo uboot source and copied doimage over

wget http://jeff.doozan.com/debian/uboot/uboot.mtd0.patch
patch -p1 < uboot.mtd0.patch

wget http://jeff.doozan.com/debian/uboot/mkDockstar.mtd0
chmod +x mkDockstar.mtd0

# Switch to the cross compiler environment
#codesourcery-arm-2009q3.sh

./mkDockstar.mtd0

ygator Wrote:
-------------------------------------------------------
> I did the commands below which are what was posted to do with the exception of two things.
> 1. Did a make -f Makefile_doimage in the tools directory of the pogo uboot source and used it
> 2. Did not run codesourcery-arm-2009q3.sh since I am compiling natively
>
> What I get locks up the dockstar when I tftp it and try to run it.

I think this is because it is trying to relocate itself to the same location as the "real" u-boot (in mtd0). If you want to test it by chainloading, you need to change the 0x600000 TEXT_BASE in config.mk to something else (I use 0xC00000) and also in the doimage command.

If you want to flash it to mtd0, you can build it with 0x600000.

I was just following the steps on this page.

I thought it was strange that it had a TEXT_BASE at 0x600000, but it says to load it at 0x800000.
So I tried changing the TEXT_BASE to 0x800000 as you suggested. Looks like to change the TEXT_BASE it justs needs to be changed in two places in mkDockstar.mtd0. This then changes it in board/Marvell/sheevaplug/config.mk. However, this did not work either. The output is below:

Marvell>> setenv ipaddr 10.0.0.200
Marvell>> setenv serverip 10.0.0.2
Marvell>> tftp 0x800000 uboot.mtd0.kwb
Using egiga0 device
TFTP from server 10.0.0.2; our IP address is 10.0.0.200
Filename 'uboot.mtd0.kwb'.
Load address: 0x800000
Loading: ####################################
done
Bytes transferred = 524288 (80000 hex)
Marvell>> go 0x800200
## Starting application at 0x00800200 ...

I then looked at the posted good uboot and it shows that it is based at 0x600000, but it loads and runs fine from 0x800000.
So I guess I am doing something else wrong then.

Forgot to add that when I do issue the go command the led changes from flashing green to flashing yellow.



Edited 1 time(s). Last edit at 09/15/2010 09:33PM by ygator.

With kwimage.cfg fixed here is what I do now.

git clone git://git.denx.de/u-boot.git u-boot
cd u-boot

wget http://jeff.doozan.com/debian/uboot/uboot.mtd0.patch
patch -p1 < uboot.mtd0.patch

I use my copy of kwimage.cfg

make mrproper
make sheevaplug_config
make u-boot.kwb
perl -e 'for ($i=0;$i<512;$i++){printf("\xFF" x 1024)}' > /tmp/ff.512k
cat u-boot.kwb /tmp/ff.512k | dd of=u-boot.kwb.512k bs=1 count=512k

setenv ipaddr 192.168.0.200
setenv server 192.168.0.100
tftp 0x800000 uboot.kwb.512k
go 0x800200

If I do this from stopping Jeff's u-boot it locks up and the LED blinks fast yellow.

If I do this after letting Jeff's u-boot run cloud engines u-boot and stopping it I get some print outs, but then it locks up.
What gets printed out is not consistent though.

Filename 'u-boot.kwb.512k'.
Load address: 0x800000
Loading: #################################################################
######################################
done
Bytes transferred = 524288 (80000 hex)
CE>> go 0x800200
## Starting application at 0x00800200 ...


U-Boot 2010.09-rc1-00010-ga12555c-dirty (Sep 17 2010 - 17:03:05)
Marvell-Dockstar/Pogoplug by Jeff Doozan

SoC: Kirkwood 88F6281_A0
DRAM: 128 MiB
NAND:

You were right ecc. Since I have jtag capability I just went ahead and flashed the u-boot I produced and it worked.
I am going to do some more testing.

I'm in the same boat as you, ygator. I'm trying to compile a version of uBoot for a Pogoplug V2 (pink) so I can use all 256MB of RAM (as discussed here). However, I want to test it before flashing it to mtd0. I tried following Jeff's instructions as you did but got the same results - device hung at:

## Starting application at 0x00800200 ...

I think I've compiled everything correctly, however, I'm reluctant to just go ahead and flash it as you did since I have neither a JTAG or a serial cable (I'm using netconsole). If you determine a reliable set of steps for tftp'ing a uBoot image for testing I would appreciate hearing them.

aperson Wrote:
-------------------------------------------------------
> I'm in the same boat as you, ygator. I'm trying to
> compile a version of uBoot for a Pogoplug V2
> (pink) so I can use all 256MB of RAM (as discussed
> here). However, I want to test it before flashing
> it to mtd0. I tried following Jeff's instructions
> as you did but got the same results - device hung
> at:
>
> ## Starting application at 0x00800200 ...
>
> I think I've compiled everything correctly,
> however, I'm reluctant to just go ahead and flash
> it as you did since I have neither a JTAG or a
> serial cable (I'm using netconsole). If you
> determine a reliable set of steps for tftp'ing a
> uBoot image for testing I would appreciate hearing
> them.

I would urge you not to try re-flashing your mtd0 partition with an experimental u-boot unless you have at least a serial cable, and be prepared for JTAG as a fallback. You can't test the memory initialization by chainloading, because that code is only executed when it is booted (not transferred to from another running u-boot). I found this out when debugging my own version, because it mistakenly detected 256M on my dockstar instead of 128M, but that didn't show up until I flashed it. Luckily it wasn't fatal and I could recover with just my serial cable access.