There have been quite a few customer inquiries on this. I have done some searches and found these following past emails. I list them here with some modifications. In general this is not normally something that you would need to do. So before proceeding further, you should step back and consider if you are approaching this problem from the right angle. The most possible culprit at this stage is that some hardware initialization in romInit.s is wrong. To debug that, you don�t need to include symbol information, because it is an assembly file.

 

---

If you still want to do this, #3 and #4 provide 2 solutions. If you choose #3 (building a bootrom_res.hex image), then you should re-program the flash with the new code, because the image is different.

#1

Debugging ROM based images can be quite tricky; as you know the bootrom_uncmp image, copies itself from ROM to RAM for execution. This makes things tuff since the symbol information is generated on where the image will be as compared to where it currently is.

#2

It is also important to note that the bootrom_uncmp build initially executes out of flash, then after it copies the bootrom into RAM it transfers control to RAM. A typical WR BSP for an EST board will link accordingly to the starting RAM address and then will be converted into a bin file. Here's the end of the output for the 8240 BSP (using make bootrom_uncmp.bin):

ldppc -X -N -e _romInit -Ttext 01F00000 \ -o bootrom_uncmp romInit.o bootInit_uncmp.o version.o bootConfig.o \ sysALib.o sysLib.o fei82557End.obj d:\t2ppc\target/lib/libPPC603gnuvx.a
d:\t2ppc\host\x86-win32\bin\romsize PPC -b 00080000 bootrom_uncmp
bootrom_uncmp: 366156(t) + 23596(d) = 389752 (134536 unused) d:\t2ppc\host\x86-win32\bin\elfHex -a fff00100 bootrom_uncmp \
> bootrom_uncmp.hex
d:\t2ppc/host/x86-win32/bin/convert -s bootrom_uncmp.hex -a bootrom_uncmp.bin \  

-l 0xfff00100
convert v7.6A Copyright (c) 1996-2000 Wind River HSI convert S-Record file bootrom_uncmp.hex to Flat Binary file bootrom_uncmp.bin Extracting image from 'bootrom_uncmp.hex'
Writing flat binary image to 'bootrom_uncmp.bin'
Lower address: 0xfff00100
Upper address: 0xffffffff
Execution address: 0x00000000
Image written
Processing time: 0.250 seconds

From the above you can see that generating symbols from bootrom_uncmp will generate symbols for the RAM area. I guess you could try linking the bootrom using the flash address and generate symbols from there, if the linker makes all the same decisions (I would be surprised if it didn't) you would have symbols for the code running out of flash.


#3

These are difficult ones to debug since the addresses for a section of code are the addresses where the ROM image will be copied into(RAM). The is only a small section of code where this takes places.

The way I have done this in the past is to build a ROM resident image and use hardware breakpoints. Alternatively you can remap the ROM addresses into RAM and debug it with software breakpoints.

Depending on the target processor type, I typically build a bootrom_res.hex image and then use the internal hardware breakpoint feature of the processor (IHBC). You typically only get one or a few hardware breakpoints.

Chances are if they are trying to debug at romStart level, they are doing something wrong. My sanity check is to set a breakpoint on sysHwInit(). If I can hit it, great, if not then there is something wrong in either romInit.s or sysAlib.s depending on the type of image.  

#4

Being able to trace execution in ROM with C source is a matter of preparing the proper symbol file. Symbol files generated from bootrom images such as bootrom_uncmp contain symbols with addresses starting at RAM_HIGH_ADDRESS. So we need to obtain a symbol file in which symbols start at ROM_BASE_ADRS. This is accomplished by temporarily changing the value of RAM_HIGH_ADRS in both Makefile and config.h to the value of ROM_BASE_ADRS. Here are the steps:

a.    Build a bootrom image as usual.  
b.    Program it into the flash.
c.    Rename this bootrom image to save it.
d.    Change the value of RAM_HIGH_ADRS in both Makefile and config.h to the value of ROM_BASE_ADRS.
e.    Rebuild the bootrom image.
f.    Use the Convert utility to convert this bootrom image to generate a symbol file.
g.    Change the value of RAM_LOW_ADRS in both Makefile and config.h back to the original value for the next build cycle.
h.    In a visionCLICK project, specify this symbol file, and no download file (since the code to be debugged is already in the flash).

Once this approach has been confirmed, a post-build rule can be added in the normal build procedure. This avoids building the image twice each time the code is modified. And the files Makefile and config.h need not be changed. The rule contains the linker command to perform linking again except to point the text address to ROM_BASE_ADRS. The easiest way to do this is to copy the linker command from the normal build output and change the address following �Ttext to ROM_BASE_ADRS. An example is as below:

ldmips -EB -X -N -Map bootrom_symbols.map  -e romInit -Ttext BFC00000 �