2010-02-22 06:41:25 Problems with gdb loading files into internal SRAM/CACHE area
David Brown (NORWAY)
For background, I have very little experiance with Blackfins, but plenty of practice with gdb and jtag proxies on lots of other architectures. I am working with bfin-gdb and bfin-gdbproxy and a gnICE to help our test department burn software onto a customer's Blackfin BF532 card. I'm using the latest windows binary build of the tools at <http://blackfin.uclinux.org/gf/download/frsrelease/470/7420/blackfin-toolchain-win32-2009R1.1.exe>.
The test software the customer has written is a little over 32K in size, and linked at 0xffa08000, which is the start of the internal instruction SRAM in the BF532. It extends slightly beyong the "Instruction SRAM" area and into the 16K block at 0xffa10000 "Instruction SRAM/CACHE". When I attempt to load the code (either the customer's elf-format DXE file, or an SREC copy) with gdb+gdbproxy+gnICE, only the first 32K loads correctly - the second section "Instruction SRAM/CACHE" is not loaded. However, if I use an SREC file that only contains data in the 0xffa10000 area, it loads fine. It seems to me there is some problem occurring just at the boundary here.
I have a perfectly good work-around - I have split the code into two parts, and load the 0xffa08000 - 0xffa0ffff part first, then the 0xffa10000 part. I also have very limited opportunity to work on this issue - the Blackfin is not a part I normally use. However, I am curious to know if anyone else has come across this issue, or knows of any reason for it. And perhaps this post may aid others who have similar problems.
2010-02-22 11:18:00 Re: Problems with gdb loading files into internal SRAM/CACHE area
Robin Getz (UNITED STATES)
It's likely that gdbproxy assumes the cache might be configured as cache (not isram). Someone will have a look.
2010-02-23 04:40:13 Re: Problems with gdb loading files into internal SRAM/CACHE area
David Brown (NORWAY)
That sounds like it might be the problem. I had checked the Blackfin's register setup, so I know the BF532 has the area configured as isram rather than cache. But perhaps gdb has other ideas...
2010-04-26 18:04:33 Re: Problems with gdb loading files into internal SRAM/CACHE area
Mike Frysinger (UNITED STATES)
i tried to reproduce this issue, but it seems to work fine for me. i can load from 0xffa00000 to 0xffa14000 with a simple app, and then disassemble/view it just fine. i tried this with a BF533, but i can read/write BF537 just fine as well.
do you have an example app to load in ? and can you show the tool output you're running ?