2008-07-18 11:09:33     call a function on core B, which is implemented in an application on Core A

Document created by Aaronwu Employee on Aug 7, 2013
Version 1Show Document
  • View in full screen mode

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

Outcomes