[U-Boot-Users] u-boot for Vertex4-based board.

[Leonid]

Behalf Of Grant Likely
On Wednesday, February 14, 2007 6:28 AM Grant Likely:
> > Are you aware that this setup is strongly discouraged? Have you read

> That's not necessarily relevant when using the virtex parts.  His only
> option might be to boot from SDRAM.  I've got a number of Virtex
> designs where the SystemACE (FPGA loader hardware) loads code into
> SDRAM after the FPGA is configured.
[Leonid] It's also not relevant for many ARM platforms as I wrote in my answer on Marcus' posting. In any rate I don't see anything specifically evil in such setup, quite opposite, it's much more convenient for debug since allows to reload code very quickly. I think I could resort to traditional for PPC (and probably for u-boot, being in the past PPCboot) loading algorithm in future if will see it fit.

> That being said; I actually use a 3 stage loading process.  I have an
> early boot loader which fits into Block RAM (BRAM, on chip memory) in
> the fpga.  Earlyboot loads a u-boot image off of the CF card which is
> attached to the system ace.  When u-boot starts, it is already in RAM.
[Leonid] I do precisely the same on many platforms. U-boot doesn't work on this particular board yet, but that to be expected - the board is new.

> In the past, I have bypassed the relocation code so I can run u-boot
> from where it was linked; 

[Leonid] You just commented out relocation function? Can you send me your change if you have saved one to try?

> but now I link u-boot to the base of ram and
> let the standard relocation code move it to the top of ram.  It's kind
> of an unnecessary copy; but I don't need to fiddle with the code as
> much.

[Leonid] Agree.

> BTW, Leonid;  You want to use ppc_4xx, not ppc_4xxFP.  I don't know
> about the uartlite driver.

[Leonid] I use ppc_4xx, now I'm running Kegel cross tool - all the same.

BTW, could you manage source level debug for you target? I download elf file via XMD and then try to connect GDB remotely, but addresses GDB show have nothing to do with real address (u-boot is located on 0x01f00000):

leonid at mylinux u-boot-1.1.4]$ ~/gdb-ppc/gdb/gdb -symbols=u-boot.map u-boot
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-linux"...
(gdb) target remote 192.168.0.70:1234
Remote debugging using 192.168.0.70:1234
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
#1  0x01f0c8fc in env_init () at env_flash.c:270
#2  0x01f0c8fc in env_init () at env_flash.c:270
#3  0x01f0c8fc in env_init () at env_flash.c:270
#4  0x01f0c8fc in env_init () at env_flash.c:270
#5  0x01f0c8fc in env_init () at env_flash.c:270
Previous frame inner to this frame (corrupt stack?)
(gdb)  

Thanks,

Leonid.