2008-07-18 11:09:33 call a function on core B, which is implemented in an application on Core A
Stephen Sheldon (GERMANY)
Message: 59096
Hi,
I am trying to call a function on a core B application. This function is implemented in an application which runs under uClinux on core A. So the instructions of this function are located in L3 SDRAM. The core B application gets the functionpointer via L2 SRAM.
This doesn't work at the moment and I don't now why. Each time I call the function on core B, core B is stuck. When I call the function the same way on core A it works. Perhaps the MMU is the reason for the problem. But the memory protection unit is disabled.
I use uClinux-dist-2008R1-RC8 with default config.
I attached the hole sources of this project. So I hope you can help me to solve this problem.
1. core B driver
It's a slightly modified version of the coreb driver from this Thread http://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?action=ForumBrowse&forum_id=39&thread_id=24832&_forum_action=ForumMessageBrowse
I just added an interrupt handler, so core B can signal core A.
2. CorebLoader
It's a slightly modified version of corebld.c from the above Thread. Now its a static lib which I include in my core A appl.
I built it with these compiler flags: -mcpu=bf561 -mmulticore -mcorea
3. CorebTest
This is the core A application. I hope its well enough commented. If you don't understand something, ask me please.
I built it with these compiler flags: -mcpu=bf561 -mmulticore -mcorea
4. CorebBootLoader
This is the application which runs on core B. The CorebStartStop.S is a slightly modified version of the one from the Thread above. The only difference is, that I call the _main from my C source.
The C source is commented. So I hope i understand what it does. If not, ask. :-)
I built it with bfin-elf-gcc and these compiler flags: -mcpu=bf561 -mmulticore -mcoreb -c
I linked it with these linker flags: -N -T coreb.lds
CorebTest and CorebBootLoader include the CorebTest.h both. So both know the struct. The pointer to this struct is located at 0xFEB00000 in L2 SRAM.
Thank you very much for your help in advance.
Best regards
Stephen
CorebBootLoader.zip
CorebLoader.zip
coreb.c
CorebTest.zip
TranslateQuoteReplyEditDelete
2008-07-21 23:40:56 Re: call a function on core B, which is implemented in an application on Core A
Mike Frysinger (UNITED STATES)
Message: 59171
the Blackfin doesnt have a MMU.
the flags "-mcpu=bf561 -mmulticore -mcorea" are intended for bare metal applications, not applications that run under Linux.
any function you call from core b has to be guaranteed to not rely on any external environment. if your function tries to use the operating system (like doing an open() or printf() or anything even remotely like that) or probably even just the C library, it isnt going to work.
ignoring all of that, FDPIC will not practically work. if you jump through enough hoops, you might be able to, but really it isnt worth wasting your time attempting to do so.
QuoteReplyEditDelete
2008-07-22 07:54:09 Re: call a function on core B, which is implemented in an application on Core A
Stephen Sheldon (GERMANY)
Message: 59224
Hi Mike,
> the Blackfin doesnt have a MMU.
According to the "ADSP-BF53x/BF561 Blackfin Prosessor Programming Reference" at page 6-52 and 6-53:
"Upon reset, all CPLBs are disables, and the Memory Management Unit (MMU) is not used. ... Before caches are enabled, the MMU and its supporting data structures must be set up and enabled."
So I think the Blackfin has a MMU and because the cache is enabled under uClinux on core A, the MMU have to be enabled also.
Regards
Stephen
TranslateQuoteReplyEditDelete
2008-07-22 10:56:47 Re: call a function on core B, which is implemented in an application on Core A
Robin Getz (UNITED STATES)
Message: 59229
Stephen:
What ADI calls a MMU in their documentation is not a MMU like the rest of the world defines it. It only provides protection, no virtualization (what everyone would call a MPU - memory protection unit).
Mike's feedback still is correct - you need to rethink the way you are doing things, or run with the SMP branch.
QuoteReplyEditDelete
2008-07-22 12:17:47 Re: call a function on core B, which is implemented in an application on Core A
Stephen Sheldon (GERMANY)
Message: 59239
Does SMP work now? The last time I have asked, no SMP was supported by uClinux.
I would love to use SMP. But now my thesis is getting near completion. :-(
But I found a solution. I call the function with some Inline-Assembly. And it works. :-) It's not a very nice solution, but it serves its purpose for now.
Thanks a lot again for your help!
Best regards
Stephen
TranslateQuoteReplyEditDelete
2008-07-22 13:45:44 Re: call a function on core B, which is implemented in an application on Core A
Robin Getz (UNITED STATES)
Message: 59240
Stephen:
What we have would be a lie to call SMP - you can run different processes on different cores, but a single process which includes multiple threads all run on the same core.
-Robin
QuoteReplyEditDelete
2008-07-22 22:02:38 Re: call a function on core B, which is implemented in an application on Core A
Mike Frysinger (UNITED STATES)
Message: 59251
SMP will be part of the 2008R1.5 release as an addon patch ... but the SMP limitations like Robin pointed out still apply