So what I am trying to do now, is to use CCSv5 to compile a simple program: [...]
Your code accesses the mailbox, have you powered it on ?
I'd suggest to remove the mailbox code (for now), and replace the 'return 0;' with an infinite loop (
main() is not supposed to return).
The entry_point is aligned with 1KB as TRM said
Actually the TRM says it has to be aligned to a 4k page. Should not be an issue, though, since you shouldn't set
BOOTADDR to the entry point but to some short (assembly) program that jumps to the actual entry point. For example, c64_tools sets
BOOTADDR to
0x86000000 (reset_vector), then generates a short boot code, depending on the actual entry point, before releasing the DSP from reset.
i'm thinking that maybe it's my kernel module memory issue. I do ioremap_nocache on L2RAM (according to L3 address, global view), and use the return pointer as the base. Extract section address from the bootTable.h, OFFSET = section address - L2RAM_base(address is according to DSP view, different from L3 view) and copy data to the ioremap_return_address + OFFSET.
I assume this is the correct physical location and continuous?
That sounds OK. I assume you have verified that the target addresses are correct ?
1. I assume I copied the correct binary data to the correct memory location and set the correct entry_point to BOOTADDR(BOOTMOD=0).
Why does the Linux hang and die ? I think two cores are operating independently, why DSP can kill Linux?
I presume you meant that you copied the data, set the entry point (
resp. generated the boot code, see above), released the DSP from reset, then it crashes ?
Why the DSP can kill the entire system cannot be answered easily but I've seen it _a lot_ of times even when I totally did not expect it (usually the system simply resets).
2. When I write the DSP test code and compile with ccs, did I use DSPBIOS or SYSBIOS library? If any lib is used, it should be static linking right? So it should execute without any pre-stored library data.
Well, you don't have to use DSPBIOS but it contains a couple of useful routines that you'd have to re-invent otherwise (e.g. HWI dispatching, cache control).
For a simple DSP test program you don't need these so you should be able to work w/o DSPBIOS.
And yeah, it's all linked statically. As for pre-stored library data, the "Dspboot assist tool" you're using (
which I'm totally unfamiliar with) hopefully takes care of cinit, otherwise you cannot use global variable initializers. Not relevant to your test-program, though (for now).
3. When I "return 0", where does the PC of DSP go? DSP is actually bare-metal with no OS...What would happen if the program is executed correctly? (Mailbox should not work, I saw TI guys said DSP was blind to global address if MMU is disabled. I expect to see value changes in those RAM locations though.)
See above. Replace the "return 0;" with an infinite loop to be on the safe side.
If you haven't configured the MMU, you can only access memory within the local interconnect (
i.e. DSP internal regs, L1/L2).
4. I want to configure DSP internal memory using XMC registers, however, it gives me error:
root@overo:~/dspdd/transfer# ../../devmem2/devmem2 0x5e840000
/dev/mem opened.[10665.960113] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6f43000
[10665.969329] In-band Error seen by MPU at address 0
Memory mapped at address 0xb6f43000.
Bus error
Maybe the MMU power/clock is not on?? ...I'm kinda tired on opening 4 copies of TRM and look around for registers....
Hmm.. hard to say why that happens. You did not post the ARM side code. My guess is that the DSP is not powered on when you try to access its regs using your "devmem2" tool ?!
Sorry for this lengthy post...Just like Bastian, I don't have JTAG,.And I can totally feel the pain when he was developing the c64_tool.
yep, w/o JTAG this was a real PITA. You really picked a "fun" topic to learn kernel/embedded development and if you want to see this through, be ready to lose a hair or two over this one..
On the upside, you can always look into the c64_tools source code. Some of the code lines in there took me hours, sometimes days to figure out.
Still, if I were you I'd pick a more accessible platform (
with a proper debugger!) to learn about embedded development (
e.g. how to develop your own RTOS, how to use interrupts handlers, DMA, ADC/DAC, GPIOs, ..).
Last but not least, your questions are clearly TI forum material but I have seen that, unfortunately, many questions there simply do not get answered (
it's usually the high level questions about codec engine etc. that are), and there are hardly any alternatives, so feel free to keep on posting
Next time you'd post your entire source, though. You can "tar"/"zip" it and attach it to your posts in this forum (
if you have javascript enabled), or you can upload it to one of the many one-click hosters and post the link.