IPC Notify - minimizing the footprint

Clement,

Wow...lots of questions.  I will try to answer the best I can.

#1. In the _pe66.c why these modules are there:
 ti.sdo.ipc.ListMP
ti.sdo.ipc.MessageQ
ti.sdo.utils.List
ti.sdo.utils.NameServer
ti.sysbios.hal.Timer
ti.sysbios.hal.Timer_TimerProxy
ti.sysbios.knl.Clock
ti.sysbios.knl.Queue
ti.sysbios.knl.Swi
ti.sysbios.timers.timer64.Timer

These are there because they are being by some module.  Now it is possible to disable to disable the Clock which uses Timer.  Also you could disable Swis.  I think LIstMP can be removeable.  Now some of the modules might be brought in but only the state objects and not any of the code.  Unfortunately you cannot get rid of some of the state modules.  I believe this would include MessageQ, List and NameServer.  For minizing a BIOS application checkout the BIOS_User_Guide.  There is a chapter on this

#2.  What are these things used for exactly:
GateHWSem
ti.sysbios.gates.GateAll
ti.sysbios.gates.GateHwi (I guess for handling the notify interrupt)
ti.sysbios.gates.GateMutex (I guess for shared memory modification protection)
ti.sysbios.gates.GateMutexPri
ti.sysbios.gates.GateSwi
ti.sysbios.syncs.SyncSem
ti.sysbios.xdcruntime.GateThreadSupport
xdc.runtime.System_Module_GateProxy
xdc.runtime.knl.GateThread_Proxy
xdc.runtime.knl.GateThread
xdc.runtime.Main_Module_GateProxy

These are used for protection when modifying shared memory that is used by more than 1 processor.  I do not think you can get rid of these for IPC.

#3.  is it possible to change NameServerRemotenotify event and transportShm notify event without loading these modules ?

As I stated above

#4.  why does the SharedRegion needs a HeapMemMP instance? For IPC_start ?

SharedRegion will not create/open a HeapMemMP instance if you specify it to not create a heap.  It does not require a HeapMemMP instance.

#5.  Are the four instances of NameServer (ipc sdo utils) for GateMP, MessageQ, ListMP, HeapMemMP really necessary ?

Well, it depends who you ask.  Most people would say yes because that is how they use IPC, but in your case you don't need it.  Unfortunately there's no way to configure this out.

#6.  Why do I have 5 different gates used totalling 8 instances of gates ?

Those gates are pre-created to be used with GateMP as local protection.  There's no way to remove them without hacking changes into the IPC files.

Sorry, might not be the answers you wanted but its the way things are currently.

Judah

Judah,

Thank you for your answers.

If you look at the cfg file you'll see that I already applied SYS/BIOS footprint recommandations.

What I don't get is that I explicitly disable the clock and yet it's still there.

I'll have to try again disabling the SWIs (last time I did it broke the execution).
Same thing for disabling the SharedRegion heap. My initial attempt broke the execution of the application. I'll try again.

By the way, do you know if there'll be major updates for the IPC package coming someday ? Or is it considered stable and only subject to minor corrections ?

Thanks, I'll keep you posted about the Clock/timer/swi thing and for the SharedRegion heap.

Clement

Clement,

I see the line to disable Clock.  It should go away.

Sounds to me like you are not using Swis anywhere so you should be able to remove it.  Same with SharedRegion heaps.

I don't forsee any major change to IPC at the moment, just minor changes.

In all honesty, IPC was not designed with an optimized foot print in mind because many of the systems which support IPC have large amount of memory and it was more important to get something that functionally was working.  I could see some cleanup in the future to make the foot print smaller because some "Features" that increased footprint are never used.

Judah

Judah,

Thanks for the info about IPC in general.

Here's the error I'm getting when I have this in my configuration :

var SHAREDMEM           = 0x0C000000;
var SHAREDMEMSIZE       = 0x00100000;
var CACHESIZE                 = 64;

/* Shared region configuration (used by IPC module) */
SharedRegion.setEntryMeta(0,
    { base: SHAREDMEM,
      len:  SHAREDMEMSIZE,
      ownerProcId: 0,
      isValid: true,
      cacheEnable: true,
      cacheLineSize: CACHESIZE,
      createHeap: false,
      name: "IPC_SHAREDMEM",
    });

[C66xx_0] ti.sdo.ipc.SharedRegion: line 353: assertion failure: A_addrOutOfRange: Address is out of region id's range

which corresponds to this in the source code :

/*
         *  Note: The very last byte on the very last id cannot be mapped
         *        because ti_sdo_ipc_SharedRegion_INVALIDSRPTR which is ~0 denotes an
         *        error. Since pointers should be word aligned, we don't
         *        expect this to be a problem.
         *
         *        ie: numEntries = 4,
         *            id = 3, base = 0x00000000, len = 0x40000000
         *            ==> address 0x3fffffff would be invalid because the
         *                SRPtr for this address is 0xffffffff
         */
        if (((UInt32)addr >= (UInt32)region->entry.base) &&
            ((UInt32)addr < ((UInt32)region->entry.base + region->entry.len))) {
            retPtr = (SharedRegion_SRPtr)((id << ti_sdo_ipc_SharedRegion_numOffsetBits)
                     | ((UInt32)addr - (UInt32)region->entry.base));
        }
        else {
            Assert_isTrue(FALSE, ti_sdo_ipc_SharedRegion_A_addrOutOfRange);
            retPtr = ti_sdo_ipc_SharedRegion_INVALIDSRPTR;
        }

I'll try with other sizes for the SharedRegion it may fix the issue.

Clement

EDIT1 : I can avoid this issue with translate = false but then I get

ti.sdo.ipc.notifyDrivers.NotifyDriverCirc: line 117: assertion failure: A_addrNotCacheAligned: Address is not cache aligned

with corresponds to
    /* Check if shared memory base addr is aligned to cache line boundary.*/
    Assert_isTrue ((UInt32)params->sharedAddr % minAlign == 0,
        ti_sdo_ipc_Ipc_A_addrNotCacheAligned);

I'll try other settings.

EDIT2 :

With
var SHAREDMEM           = 0x0C000000;
var SHAREDMEMSIZE   = 0x00200000;
var CACHESIZE               = 128;

I don't have any asserts error. However the application doesn't work.

Notify events are sent successfully (status ==0) but it's like the slaves doesn't process the cbk function.
I'll investigate more.

Judah,

Thanks for the follow up on this.

I haven't insisted much on the asserts as I found a sweet spot in terms of shared region size that doesn't trigger the asserts. I'll keep your suggestion in mind if I run into these errors later.

I don't see how " the app is simply using too much shared memory" as I gave it a LARGE size in L3.

To put things simply : with the heap it works, without it behaves like the other cores never receive their interrupts.

Good suggestion on stepping through the code.

I'll be on vacation the next 3 weeks starting tonight, so I won't be able to do any test on the EVM. However I'll still be able to reply on this thread.

If you have a working sample notify application could you try to disable the heap (set it to false in the cfg) and see if it still works ?

Clement

Judah,

It seems to me that I have found a bug in IPC. Looking at the sources I found GateHWSem module allows to reserve HW semaphores using setReserved() function in XDC. This feature is the MUST-Have because OSAL layer typically uses ~3-6 HW semaphores but unfortunately it (the feature) does not work. I have spent some time investigating it here are the results:

In (generated) app_pe66.c we have the following definitions:

...

const __T1_ti_sdo_ipc_gates_GateHWSem_reservedMaskArr ti_sdo_ipc_gates_GateHWSem_reservedMaskArr__A[1];

...

__FAR__ const CT__ti_sdo_ipc_gates_GateHWSem_reservedMaskArr ti_sdo_ipc_gates_GateHWSem_reservedMaskArr__C = ((CT__ti_sdo_ipc_gates_GateHWSem_reservedMaskArr)ti_sdo_ipc_gates_GateHWSem_reservedMaskArr__A);

...

In GateHWSem.h we have:

...

#define ti_sdo_ipc_gates_GateHWSem_reservedMaskArr (ti_sdo_ipc_gates_GateHWSem_reservedMaskArr__C)
...
#define GateHWSem_reservedMaskArr ti_sdo_ipc_gates_GateHWSem_reservedMaskArr

...

Finally, in GateHWSem.c we have

...

Bits32 *GateHWSem_getReservedMask()
{
    return ((Bits32 *)&GateHWSem_reservedMaskArr);
}

...

It's easy to see that GateHWSem_getReservedMask()'s returned value is not a pointer to a Bits32[] array but a pointer to a pointer to such array.

Could you please give me an advice on how to fix this in an easiest way?

Thanks in advance,

Dmitry

It seems to be fixed in IPC 1.25 (SDOCM00096667)... Thanks