| author | Chris Ring <cring@ti.com> | |
| Tue, 4 Mar 2014 21:23:16 +0000 (13:23 -0800) | ||
| committer | Chris Ring <cring@ti.com> | |
| Tue, 4 Mar 2014 21:30:25 +0000 (13:30 -0800) | ||
| commit | c18fece0c9f0dc76361dc1ee11b7ee2417479847 | |
| tree | 2518d6e170406930ba2fbb5005774815d1468d7c | tree | snapshot (tar.xz tar.gz zip) |
| parent | bff428e4a975d6a0881a14b4d98bf4bbc2eaab5e | commit | diff |
Test: Fix NameServerApp config
IpcMgr_ipcStartup() was being added twice to the BIOS startup
function - once in nameserverapp.cfg (which is removed in this
commit) and again in messageq_common.cfg.xs (which is included
by nameserverapp.cfg). In addition to just being wrong, this
resulted in an abort on Keystone 2 devices.
Also, the MessageQ.SetupTransportProxy was errantly not assigned
in the nameserverapp.cfg script. This resulted in MessageQ.xs
pulling in 'default' MessageQ configuration, which pulled in much
more content than was necessary for this test (for example,
TransportShm, which then pulled in GateMP, SharedRegion, etc). By
explicitly assigning MessageQ.SetupTransportProxy to the
ti.ipc.transports.TransportRpmsgSetup module, these extra [unused]
modules are no longer pulled in.
IpcMgr_ipcStartup() was being added twice to the BIOS startup
function - once in nameserverapp.cfg (which is removed in this
commit) and again in messageq_common.cfg.xs (which is included
by nameserverapp.cfg). In addition to just being wrong, this
resulted in an abort on Keystone 2 devices.
Also, the MessageQ.SetupTransportProxy was errantly not assigned
in the nameserverapp.cfg script. This resulted in MessageQ.xs
pulling in 'default' MessageQ configuration, which pulled in much
more content than was necessary for this test (for example,
TransportShm, which then pulled in GateMP, SharedRegion, etc). By
explicitly assigning MessageQ.SetupTransportProxy to the
ti.ipc.transports.TransportRpmsgSetup module, these extra [unused]
modules are no longer pulled in.
| packages/ti/ipc/tests/nameserverapp.cfg | diff | blob | history |