Review your favorite Linux distribution.
Go Back > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer
User Name
Linux - Embedded & Single-board computer This forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.


  Search this Thread
Old 11-20-2013, 04:15 PM   #1
Registered: Aug 2001
Location: ChristChurch New Zealand
Distribution: Ubuntu
Posts: 343

Rep: Reputation: 75
Question Inter Processor Communications Mechanisms in linux.

So I'm soon to have a Cyclone V based SoftCore + Arm Hardcore based device on my desk.

The Arm side will be running OpenEmbedded Linux.

The SoftCore will be running Something Else (Ecos).

They will share a region of RAM and hopefully be able to interrupt each other.

What is the simplest mechanism for Inter _Processor_ communication that exists within the Linux Kernel?

Note the subtlety, not inter process (usual IPC) but Inter Processor, (between independent CPU's running different operating systems).

Old 11-21-2013, 09:16 AM   #2
Registered: Mar 2011
Location: Sutton, MA. USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu
Posts: 6,403
Blog Entries: 12

Rep: Reputation: 2203Reputation: 2203Reputation: 2203Reputation: 2203Reputation: 2203Reputation: 2203Reputation: 2203Reputation: 2203Reputation: 2203Reputation: 2203Reputation: 2203
The RAM is shared, therefore the method of access and communications is up to your specifications.

What you can do is find a way to protect that memory from other use by making sure that the heap and stack are never placed in that region; really by defining that region in your build process as a DATA segment which is not usable for heap, stack, or program memory.

Next as far as communications go. Having interrupts is helpful you just need to agree on the terms, which interrupt overrules, and so forth. I've never used interrupts. Instead that region was memory mapped where both sides built their software using the same reference file. Actually in my case it's typically always been a bank of DSP's having shared memory and Linux or other OS on the other side. However the concepts are still the same. The mapping of the region was generally driven by the technology side which was closest to the requirements, however it was a negotiated mapping in that either side could request that a set of bytes be declared in a certain way.

The main parts of these concepts are the following:
  1. Each side had a section it could only write too
  2. Each side had a section it could on read from
  3. The Read section for one side corresponds to the write section for the other side, and vice versa
  4. ADVANCED: If there was a section where both sides could read and write too, ownership of that segment was done via a set of rules involving the write-only and read-only sections
By that last point I mean that there was a set of rules. If one side wished to attain ownership of the common read-write section; it would assert a location in it's write-only section; which in turn would be a read-only section for the other side. The side receiving the request would acknowledge, or not that request. One of the two sides would be considered the master, and both sides would time-out on requests and either have to retry or cause a fault because they'd been forced to wait too long.

Say the following exists:
Side A WRONLY region is 0x4000-0x7FFF and this is RDONLY for Side B
Side B WRONLY region is 0x8000-0xBFFF and this is RDONLY for Side A
Common RW region starts at 0xC000.

First byte is "other region common write request"
Second byte is "grant request to other region"

Side A writes 1 to first byte @WRONLY=0x4000
Side B reads 1 at first byte @RDONLY=0x4000
Side B write 1 to second byte @WRONLY=0x8001
Side A reads 1 at second byte @RDONLY=0x8001

Side A now can write to the common RW region freely. Once A is done it should de-assert the first byte to close it's request.

I actually recommend that you stay away from common RW segments if you can. The implementations I've done have always been defined such that one segment is WRONLY for Side A and RDONLY for Side B and another segment is the reverse. The segments don't have to be the same size; they just have to be defined commonly for both code implementations. And then one can always only write to one segment and always only read from another segment. Many times one location is used to indicate "new data".

Last edited by rtmistler; 11-21-2013 at 09:22 AM.
1 members found this post helpful.


embedded, inter processor, shared memory

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Inter process and inter computer communication jthjth Linux - Newbie 1 12-27-2011 03:53 PM
linux locking mechanisms psrs Linux - General 2 04-08-2005 01:19 PM > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer

All times are GMT -5. The time now is 06:14 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration