Hi Alexander
Welcome on board :-) Pls see my in lined answers
-----Original Message----- From: Alexander Holler [mailto:holler@ahsoftware.de] Sent: Friday, January 15, 2010 4:15 AM To: Prafulla Wadaskar Subject: Re: open u-boot on the DockStar
Hello again,
through painful debugging by reset (tm) ;) I have found the exact location where the problem seems to occur. The following diff explains it:
...snip...
Am 14.01.2010 20:45, schrieb Alexander Holler:
Hello,
I'm currently trying to build an u-boot from the sources at
denx.de and
I'm stuck. Because I currently only have a serial
connection an no JTAG,
Working on u-boot really needs some JTAG since it is risky game.
debugging isn't easy and I have only limited knowledge
about the hardware.
It is no problem if you don't want or could help me on that
topc, I'm
I will try to help you, You are most welcomed (as my first line)...
just thought mailing to you directly could be worth a try.
I would prefer to be u-boot mailing list so that other users can benefit from the discussion. I am copying to mailing list.
What I've done so far:
For all things, I'm using the precompiled gcc from the
sheevaplug sdk
I suggest to use latest gcc, (ref: www.codesourcery.com to work with latest u-boot
Currently I'm booting using an u-boot I've build from the
sources found
in pogoplug-u-boot-1.1.4.pp2.0.tar.bz2 pogoplug published
after I asked
for the GPL-sources used in the DockStar. This works but doesn't the load the kernel. I'm not really interested the pogoplug
kernel, but for
completness this is where the pogoplug u-boot I've build from their sources stops:
NAND read: device 0 offset 0x100000, size 0x300000
reading NAND page at offset 0x100000 failed 3145728 bytes read: ERROR ## Booting image at 00800000 ... Bad Magic Number
So nand read.e fails. I've build pogoplugs u-boot with the following commands:
PATH=$PATH:/home/aholler/gcc/bin make mrproper PATH=$PATH:/home/aholler/gcc/bin make redstone_config PATH=$PATH:/home/aholler/gcc/bin make
Anyway, that error currently isn't of interest for me, the resulted u-boot is enough for trying to load and execute an u-boot
build from the
sources at denx.de.
To build such an u-boot, I've modified board/Marvell/sheevaplug/config.mk to have a TEXT_BASE =
0x01600000 (for
testing by loading it to RAM).
This will not help much
Than I've modified the values kwbimage.cfg to be same as those I've found dramregs_pp128_A.txt in pogoplug-u-boot-1.1.4.pp2.0.tar.bz2.
Sounds good
Compilation was done with
PATH=$PATH:/home/aholler/gcc/bin make mrproper
USE_PRIVATE_LIBGCC=yes
CROSS_COMPILE=arm-none-linux-gnueabi- PATH=$PATH:/home/aholler/gcc/bin make sheevaplug_config USE_PRIVATE_LIBGCC=yes CROSS_COMPILE=arm-none-linux-gnueabi- PATH=$PATH:/home/aholler/gcc/bin make u-boot.kwb
USE_PRIVATE_LIBGCC=yes
CROSS_COMPILE=arm-none-linux-gnueabi-
After loading the resulting u-boot.bin with tftp 0x01600000 u-boot.bin and starting it with go 0x01600000
This will not work since this interface is used for application execution.
on Kirkwood, internal BootROM will start "boot from configured media" on Power on reset only to read kirkwood boot image header and that too from 0x0 address, so you must need to put uboot image at 0x0 in NAND Flash
Or use JTAG to download u-boot.bin to RAM and then start execution.
just nothing happens. No single char appears over the serial, just nothing. I've even tried it without CONFIG_CMD_NAND, but
the results are
the same: nothing visible happens. Even the led doesn't change (it's still blinking orange).
I would appreciate any help. ;)
This is new board with NEW DRAM and new configuration, Kwbimage.cfg file will be used to create target u-boot.kwb. I strongly recommend to use JTAG tool for ex. openOCD
The best approach should be- Use openocd, get some JTAG tool (ex. Amontec) Prepare script to configure DRAM and some other CPU register as provided in kwbimage.cfg Load u-boot elf through JTAG Debug with dgb/led/uart Prepare nice and clean patches if you want to mainline them
Good luck
Regards.. Prafulla . .
My next step will be to use the led for simplified
debugging (in absence
of a JTAG) for finding out, how far the initialization will come.
Kind regards,
Alexander Holler