2009-01-15 05:48:43     Shared memory issue with the BF561

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

2009-01-15 05:48:43     Shared memory issue with the BF561

John Redford (UNITED KINGDOM)

Message: 67978   

 

Hi, we have a few questions regarding the shared external memory (64Meg SD RAM) on the BF561 EZKIT LITE.

 

uClinux is being launched using uboot. uBoot has been setup to 'limit' the linux kernel to use only 55 meg of the 64 available. The remaining 9 meg is used to hold several data buffers which are needed in order to pass information between the two cores.

 

The intermittent problem we are having seems to have symptoms similar to memory being trampled on by 'something' else. The messages being passed either from core a to b or core b to a work flawlessy for a while then, randomly, contain garbage and so cannot be ready correctly.

 

Could this be due to some sort of memory caching being carried out by the uClinux kernel on core a? Or could it be the bare metal app running on core b randomly using the same section of SD RAM?

 

If this is the case, then we must track down exactly how the memory management is being carried out on both cores.

 

 

 

If anyone could throw some light on the subject that would be great.

 

Thanks in advance,

 

John Redford.

QuoteReplyEditDelete

 

 

2009-01-15 07:21:05     Re: Shared memory issue with the BF561

Robin Getz (UNITED STATES)

Message: 67980   

 

John:

 

Is your bare metal app build with VDSP or with gcc?

QuoteReplyEditDelete

 

 

2009-01-15 07:43:53     Re: Shared memory issue with the BF561

John Redford (UNITED KINGDOM)

Message: 67981   

 

We are using the gcc to compile the coreb bare metal app.

 

 

QuoteReplyEditDelete

 

 

2009-01-15 07:58:55     Re: Shared memory issue with the BF561

Robin Getz (UNITED STATES)

Message: 67983   

 

John:

 

Thanks - just eliminating the possibilities.

 

>The messages being passed either from core a to b or core b to a work flawlessy for a while then,

 

>randomly, contain garbage and so cannot be ready correctly.

 

 

 

What kind of mailbox/semaphore is set up? to make sure that both cores don't try to write at the same time? Are caches turned on for both cores? (are you flushing at the necessary times?)

 

What kind of memory protection do you have on the areas? Is it possible to run the app with four different areas (Core A read, Core A write, Core B read, Core B write) - to see in what area things are failing? (or do you have enough memory to do that?)

 

-Robin

QuoteReplyEditDelete

 

 

2009-01-15 08:20:03     Re: Shared memory issue with the BF561

John Redford (UNITED KINGDOM)

Message: 67984   

 

We are using 2x circular buffers... one for message going to core b, the other for going the other way. Each circular buffer has an associated 'head' and 'tail' integer (placed immediately before the circular buffers in memory) used to turn the buffers into a simple queuing system.

 

As for caches - I'm fairly certain I have turned caching off for core a, using the environment variables of uBoot:

 

(bootargs root=/dev/mtdblock2 rw rootfstype=jffs2 mem=55M max_mem=64M$#)

 

But I don't know how to turn it on/off for the bare metal app. Maybe this is the problem?

 

So far testing has proved that:

 

Parts of the message are garbage when they should have valid payloads / messageType (messageType is just an enumeration) Also, occasionaly the head / tail variables themselves are not set correctly. (core a driver initially sets them to 0 and sometimes even this isn't happening.

 

The buffers are only small at the moment - 64 elements of 64bytes.

 

 

 

I hope that is helpful

 

John.

QuoteReplyEditDelete

 

 

2009-01-15 09:33:28     Re: Shared memory issue with the BF561

Robin Getz (UNITED STATES)

Message: 67985   

 

John:

 

You have cache turned on for the Linux 55 -> 64 Meg.

 

http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:memory_allocation&s[]=max_mem#nommu_systems

 

$ means enable data cache on this reserved memory, and # means enable instruction cache on this memory. I think what you want is "max_mem=64M". Then check /proc/cplbinfo/cpu0/dcplb to be sure.

 

-Robin

QuoteReplyEditDelete

 

 

2009-02-03 09:23:25     Re: Shared memory issue with the BF561

John Redford (UNITED KINGDOM)

Message: 68770   

 

Thanks for that, I guess I had gotten mixed up.

 

Unfortunately there were other contributors to the issues we were having... having re-written the inter core comms driver and organised shared memory management better it works flawlessly now.

 

Cheers

Attachments

    Outcomes