Build and test mtd0 Uboot from SDRAM

Is seems only Jeff's "uboot.mtd0.kwb" and "uboot-original-mtd0.kwb" can be tested by using:

tftpboot 0x800000 uboot.mtd0.kwb
go 0x800200

Several people have followed http://jeff.doozan.com/debian/uboot/build_uboot.htm but were not able to boot from SDRAM.

I was able to boot mtd3 uboot from SDRAM, but mtd0 uboot always hang after "go 0x800200".

Does anyone have a hint why Jeff's mtd0 uboots can boot from SDRAM but others can't?

After changing "mkDockstar.mtd0"
from "sed -i 's/^TEXT_BASE = 0x00.00000/TEXT_BASE = 0x00600000/' board/Marvell/sheevaplug/config.mk"
to "sed -i 's/^TEXT_BASE = 0x00.00000/TEXT_BASE = 0x00c00000/' board/Marvell/sheevaplug/config.mk"

I was able to build mtd0 uboot, tested it on SDRAM and flashed it to NAND.

I'm not sure why Jeff set TEXT_BASE to 0x00600000 in his patches and mkDockstar.mtd0.

DockstarPBX Wrote:
-------------------------------------------------------
> Is seems only Jeff's "uboot.mtd0.kwb" and
> "uboot-original-mtd0.kwb" can be tested by using:
>
>
> Several people have followed
> http://jeff.doozan.com/debian/uboot/build_uboot.ht
> m but were not able to boot from SDRAM.
>
> I was able to boot mtd3 uboot from SDRAM, but
> mtd0 uboot always hang after "go 0x800200".
>



It works, but one condition is that it seems you should minimize the changes between your actual in-NAND bootloader, and the version you are loading into SDRAM to execute.

I built a u-boot.kwb yesterday - and flashed it - after several days of trying to get it to load (and having the same results as PBX above). Since I knew that an acquaintance had flashed his to NAND and it was OK, I made the leap of faith and went ahead and flashed it... all was well.

But after discovering that

#define CONFIG_ENV_ADDR			0xc0000

had been changed to

#define CONFIG_ENV_ADDR			0x60000

when support for Dockstar had been added to mainline u-boot, I tried changin ENV_ADDR back and recompiled it... also changed the prompt... and it does load and execute:

Filename 'uboot.mtd0.kwb-marvell02192012-doozanvars-fs-origenv'.
Load address: 0x800000
Loading: ####################################
done
Bytes transferred = 524288 (80000 hex)
DockStar> go 0x800200 
## Starting application at 0x00800200 ...


U-Boot 2011.12-06918-gf33b06f-dirty (Feb 11 2012 - 01:50:51)
Seagate FreeAgent DockStar

SoC:   Kirkwood 88F6281_A0
DRAM:  WARNING: Caches not enabled
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0 
u-boot>>

I do not know what the "threshhold" or tolerance is exactly. But after experimenting for an hour or so (building uboot on my quad core takes less than 60 seconds), I can say for sure that it is replicable - it wasn't a one-time fluke.

=====================================================

• davy's Github Repo's rescue-dg

Edited 2 time(s). Last edit at 02/12/2012 10:49AM by davygravy.

It is weird cause new headers size = 516 bytes (204 in hexadecimal).

@davygravy: could you test 'go 0x800204' in uboot's prompt

@ pazos: can you find the commit of the new header size?

=====================================================

• davy's Github Repo's rescue-dg

Sorry, It was a mistake! I can confirm that there are some changes in kwbimage.kwb from jeff's patch to ecc's patch, but forget about diferences in sizes, my fault ;)



Edited 1 time(s). Last edit at 02/12/2012 07:32PM by pazos.

OK, some fine-tuning now on when it seems that testing in SDRAM works...
Same source code (ie. same version, eg 2011.12), minor changes only (ie. only minor edits to the include/configs/<machine>.h.

=====================================================

• davy's Github Repo's rescue-dg