[U-Boot-Users] U-boot 1.1.1

Hello,
I am new to U-boot and the mailing list. I recently downloaded U-boot version 1.1.1 and made some adjustments to the code so I could run it on a proprietary board containing a PPC 750Cxe processor with 64 meg of SDRAM, 64 meg of norflash, 64 meg of nand flash, 32k of NVM and a Galileo 64260 memory controller + and onboard FPGA. I now have the code executing at the command line, but appear to have some stack corruption problems which require me to use our BDI 2000 JTAG debugger which we recently purchased.
My Problem: GDB does not function correctly after the code has been loaded into SDRAM because the code is linked at address 0xFFF00000. I want to take the steps neccessary to allow GDB to function.
What I have tried:
-------------------------------------------------------------------------- 10.1.2. Debugging of U-Boot After Relocation
For debugging U-Boot after relocation we need to know the address to which U-Boot relocates itself to. When no exotic features like PRAM are used, this address usually is <MAXMEM> - CFG_MONITOR_LEN. In our example with 16MB RAM and CFG_MONITOR_LEN = 192KB this yields the address 0x1000000 - 0x30000 = 0xFD0000. With this knowledge, we can instruct gdb to forget the old symbol table and reload the symbols with our calculated offset:
(gdb) symbol-file Discard symbol table from `/home/dzu/denx/cvs-trees/u-boot/u-boot'? (y or n) y No symbol file now. (gdb) add-symbol-file u-boot 0xfd0000 add symbol table from file "u-boot" at .text_addr = 0xfd0000 (y or n) y Reading symbols from u-boot...done. (gdb) b board_init_r Breakpoint 2 at 0xfd99ac: file board.c, line 533. (gdb) c Continuing.
Breakpoint 2, board_init_r (id=0xfbb1f0, dest_addr=16495088) at board.c:533 533 { (gdb)
board_init_f is the first C routine running in the newly relocated C friendly RAM environment.
---------------------------------------------------------------------------
On my board, u-boot is relocating to SDRAM address 0x03fd7000. Note that this address is not as suggested in 10.1.2. which states that the address is usually MAXMEM (64meg) - CFG_MONITOR_LEN (256k).
Any suggestiions would be great.
Jason

Dear Jason,
in message OFA4702A80.10FA9680-ON86256F3F.0076FEE2-86256F3F.00781039@crnotes.rockwellcollins.com you wrote:
My Problem: GDB does not function correctly after the code has been loaded into SDRAM because the code is linked at address 0xFFF00000. I want to
I bet it does work correctly, you just don't use it correctly.
What I have tried:
10.1.2. Debugging of U-Boot After Relocation
Good, you've read the docs. 5 points.
On my board, u-boot is relocating to SDRAM address 0x03fd7000. Note that this address is not as suggested in 10.1.2. which states that the address is usually MAXMEM (64meg) - CFG_MONITOR_LEN (256k).
My fault - the documentation is older than the code.
Any suggestiions would be great.
The relevant code changes ware introduced with this patch set:
--------------------- PatchSet 655 Date: 2003/05/30 13:48:29 Author: wdenk Branch: HEAD Tag: LABEL_2003_05_30_1450 Log: * Get (mostly) rid of CFG_MONITOR_LEN definition; compute real length instead CFG_MONITOR_LEN is now only used to determine _at_compile_ _time_ (!) if the environment is embedded within the U-Boot image, or in a separate flash sector.
* Cleanup CFG_DER #defines in config files (wd maintained only)
---------------------
Best regards,
Wolfgang Denk
participants (2)
-
jtbrower@rockwellcollins.com
-
Wolfgang Denk