The following changes have been made to the VirtQueue API used by
the slave:
1. Add a vqId parameter to VirtQueue_create to make the index of
the vq explicit and not depending on the invocation order.
2. Add a len param to VirtQueue_addUsedBuf so users can control it.
3. Add a *len param to VirtQueue_getAvailBuf so users are notified
with the amount of received data

The MessageQCopy module which currently uses the VirtQueue API has
also been modified to adapt the new API

A review of VirtQueue revealed the index to the available ring
buffer was being calculated differently than lguest from which
it was modelled. It worked given the current usage model, but
to be more correct, it should be updated to match what Linux
side does.

This change was verified to work by asserting that head index
was the same in both cases under sample tests. A minor trace
change to display the ring.avail addr is also added.

Resmgr Sample is modified to check for proper return status for
each of the resource request and release function calls. The sample
now prints an easy-to-read succeeded or failed status with the
corresponding status codes for various combinations of the resource
and constraints requests.

The sample has also been updated properly to support the different
resource request variations for OMAP5.

Executables have to specifically invoke ServiceMgr_start to
start all the service tasks registered with the ServiceMgr
module. This change is needed to support the new enhancements
implemented in the ServiceMgr module - necessary to start the
the decoupled OMX Service task.

The Service Manager module has been enhanced to allow different
services to use its infrastructure. This is done to allow other
IPC protocols to use the VirtQueue transport infrastructure
in tandem.

The OMX Service that is inherently tied into Service Manager
is now decoupled and moved out of the Service Manager code
and is built as an independent library.

This is achieved through the following:
1. The internal functions to create and delete different
instances of a service are made public through the API,
ServiceMgr_createService and ServiceMgr_deleteService.
The signature of these functions remain identical to the
previous internal functions:
UInt32 ServiceMgr_createService(Char * name, UInt32 * endpt);
UInt32 ServiceMgr_deleteService(UInt32 addr);

2. A new API, ServiceMgr_registerSrvTask, is added that allows
an external library to register its service task function
with the ServiceMgr module. The registration is expected to
be fairly early during the base image execution. All the task
parameters are to be initialized before registering with
ServiceMgr.
Bool ServiceMgr_registerSrvTask(UInt16 reserved,
Task_FuncPtr func,
Task_Params *taskParams)

3. A new API, ServiceMgr_start, is added that allows all the
registered services to be started. All service registrations
has to be done before a call to this function. The reserved
argument is to be used for future scalability for starting
services with different processors, and is currently
ignored.
UInt ServiceMgr_start(UInt16 reserved);

OMX Service is registered and included in the executable at
configuration time.

Simultaneous support for non-SMP and SMP-mode libraries has
also been added.

The BUILD_SMP variable has to be defined and have a value of
1 to define a SMP build. This has to be passed for both the
build and clean commands. The xdc clean invocation is missing
this and has been fixed.

SysMin has a line buffer for each core and a module-wide
shared buffer, common to both the cores and used to flush
out line buffers one at a time. The tracing functionality
depends on locking of these buffers properly. The line buffer
is protected by disabling local core interrupts, and the
shared buffer is protected by acquiring a system lock.

The current code is re-enabling the local core interrupts
before checking whether the line buffer needs flushing. This
opens up a small window for the line buffer to be overwritten
by a different task or interrupt while the current thread is
waiting for the system lock to flush the core line buffer.
This is fixed by enabling the local core interrupts properly
after checking on the flush condition. Releasing the system
gate re-enables the core interrupts automatically, so there
is no need for enabling local interrupts specifically when
flushing the line buffer.

The build for SMP-mode IPU target is enabled for both OMAP4
and OMAP5 platforms by configuring the build system to an
exclusive SMP build mode:
bash$ make smp_config

The proper BIOS and XDC versions that support SMP-mode are
selected automatically when the above configuration is chosen
overriding the non-SMP versions. Only the IPU SMP targets are
built upon issuing the usual build command:
bash$ make

For going back to the default non-smp configuration
next command should be used:
bash$ make unconfig

The SMP and regular mode binaries can be built by invoking
the build twice without doing a clean build, but only
changing the config.

Idle module interface is different for SMP platform. SMP requires
that Idle functions be added to each of the cores, and if it is the
same Idle function, then it should be a thread-safe function. The
inclusion of the module is therefore moved from the generic
IpcCommon.cfg.xs file to each one of the specific core configuration
files.

Two different hdmiwa libraries are built for both non-SMP and SMP
modes at build time based on configuration, and the appropriate
library is picked up during the linking stage in the final
executable based on the platform name.

The conditional build allows the build configuration to change
without overwriting the other mode's library.

Two different DEH libraries are built for both non-SMP and SMP
modes at build time based on configuration, and the appropriate
library is picked up during the linking stage in the final
executable based on the platform name.

The conditional build allows the build configuration to change
without overwriting the other mode's library.

The SMP support is added to the core PM module for IPU,
IpcPower. The Power Management functionality is adjusted
for the lack of two independent processor cores in the
IPU. The simultaneous support for non-SMP and SMP modes
are provided through a compiler preprocessor macro.

Libraries for SMP and non-SMP mode are built simultaneously
during build time, and the appropriate library is picked up
during the linking stage in the final executable based on
the platform name.

Depending on the BIOS version used, the Power Suspend API for IPU
could be executed as an asynchronous non-blocking call in just one
core (in a SMP environment) or as a synchronous blocking call in
both cores (non-SMP environment). This patch ensures that each
core sets/recovers its deepsleep configuration irrespective of the
mode and the core where the Power_suspend function is actually
executed.

Two different hwspinlock libraries are built for both non-SMP
and SMP modes at build time based on configuration, and the
appropriate library is picked up during the linking stage in
the final executable based on the platform name.

The conditional build allows the build configuration to change
without overwriting the other mode's library.

Two different ResMgr libraries are built for both non-SMP and SMP
modes at build time based on configuration, and the appropriate
library is picked up during the linking stage in the final
executable based on the platform name.

The conditional build allows the build configuration to change
without overwriting the other mode's library.

Two different grcm libraries are built for both non-SMP and SMP
modes at build time based on configuration, and the appropriate
library is picked up during the linking stage in the final
executable based on the platform name.

The conditional build allows the build configuration to change
without overwriting the other mode's library.

The tracing code has been enhanced to support the SMP-mode.
In SMP-mode, each processor core will have its own line
buffer and the traces are output into this linebuffer until
a new line is output or the line buffer has been filled up.
The respective line buffer is flushed out into the shared
output buffer with the processor core id prepended to the
respective line buffer trace.

Libraries for SMP and non-SMP mode are built simultaneously
during build time, and the appropriate library is picked up
during the linking stage in the final executable based on
the platform name.

Add a 'SMP' macro based on the platform information to support
SMP-mode on the IPU sub-system. This will list just one trace
buffer, one crash dump buffer and just one entry point as the
two IPU processors are treated as a single processor system
in SMP mode.

Libraries for SMP and non-SMP mode are built simultaneously
during build time, and the appropriate library is picked up
during the link stage in the final executable.

The IPU subsystem will create only one rpmsg channel in SMP
mode. The name 'rpmsg-omx1' is used to publish the channel
name in SMP mode. This helps to keep backward compatibility
with the corresponding driver and userspace applications.

Simultaneous support is provided for both non-SMP and SMP
modes through a compiler preprocessor macro. Libraries for
both the modes are built simultaneously during build time,
and the appropriate library is picked up during the linking
stage in the final executable based on the platform name.

The SMP support in IPU is added to the core IPC transport
layer - the VirtQueue module. For SMP, we only need one
pair of VirtQueues as if they were only one core. Support
for non-SMP and SMP is simultaneously provided by using a
compiler preprocessor macro.

Libraries for SMP and non-SMP mode are built simultaneously
during build time, and the appropriate library is picked up
during the link stage in the final executable.

Add separate IPU target platform modules that define the
default memory maps for the dual-core M3/M4 subsystems
in OMAP4/OMAP5 running a Symmetric Multi-Processing (SMP)
BIOS. These regions will be used by the build process to
place the ELF sections appropriately.

The Task.deleteTerminatedTasks option provides cleanup within
BIOS code for deleting dynamically created tasks that complete
their execution by returning from their Task function or calling
a Task_exit. The user applications should not be deleting the
terminated tasks by themselves when this option is set. The
behavior in such a case is undefined or can result in an
exception.

This option is therefore set back to the default 'false', since
the current users do use BIOS threading significantly and do
invoke Task termination functions.

The IPC package library linkage is fixed up to return the
library based on the current build profile of the final
executable. The 'debug' profile library was being linked
into executables previously irrespective of the profile.

The PM package build style has been cleaned up to allow
flexibility. The new build style allows different library
specific attributes to be passed by using the XDC global
build objects directly. This also removes a direct
dependency on the IPC product for build.

The PM package library linkage is also fixed up to return
the library based on profile. The 'debug' profile library
was being linked into executables irrespective of the
profile previously.

The HdmiWa package build style has been cleaned up to allow
flexibility. The new build style allows different library
specific attributes to be passed by using the XDC global
build objects directly. This also removes a direct
dependency on the IPC product for build.

The HwSpinlock package build style has been cleaned up to allow
flexibility. The new build style allows different library
specific attributes to be passed by using the XDC global
build objects directly. This also removes a direct
dependency on the IPC product for build.

The ResMgr package build style has been cleaned up to allow
flexibility. The new build style allows different library
specific attributes to be passed by using the XDC global
build objects directly. This also removes a direct
dependency on the IPC product for build.

The SrvMgr package build style has been cleaned up to allow
flexibility. The new build style allows different library
specific attributes to be passed by using the XDC global
build objects directly. This also removes a direct
dependency on the IPC product for build.

Introduce a local line buffer to which the characters are output.
The line buffer is flushed to the external shared buffer only
when the line is filled up or when a new line is encountered.

This change re-introduces back the actual flush functionality
(without a new line) present in the baseline SysMin module.
It also allows the future scalability for a SMP system wherein
the individual cores can write to their own line buffers without
mangling the actual output buffer.

Critical section protection within the IpcPower code is currently
performed by disabling both Hwi(s) and Swi(s). The code being
protected is fairly simple and does not invoke any calls (like
Swi_post or Semaphore_pend or Task_yield) that would invoke the
SYS/BIOS scheduler. The Hwi_disable and Hwi_restore combination
by itself is good enough to provide the required atomicity, so
the Swi calls have been cleaned up.

Cleanup the config.bld to remove all the target build profiles
other than 'release' and 'debug'. The build currently also builds
some other profiles such as 'whole_program_debug', 'coverage',
'whole_program', 'profile' etc for couple of libraries.

Add the folder where different build files will be generated
to the package.bld in packages missing it. This will allow the
generated folder to be deleted automatically deleted upon a
'clean' build command.

When a task called MessageQCopy_init function, it immediately
set the curInit variable to true before starting the actual
initialization. If another task called the same function, the
curInit was true already, and proceeded as if the initialization
was already done, while the module is still being initialized.

A semaphore initialized with its count to 1 is used as a mutual
exclusion protection between the competing tasks.

The max IPU clock rate in OMAP5 is actually 212.8 MHz. This
patch fixes the OMAP5's core0 and core1 platform files to
use the correct clock rate so that SYS/BIOS code calculate
any internal clock frequencies correctly.

This also eliminates the need for applications to manually
configure the following in their config files:
BIOS.cpuFreq.hi = 0;
BIOS.cpuFreq.lo = 212800000;

The sizes for different carveout resource type entries in the
IPU and DSP Resource Table have been replaced with macros. This
should minimize the the need to repeat platform specific
pre-compiler flags at multiple places.

In some situations, it is good to let the host know when the
boot has completed a certain basic initialiazation.

Add a function VirtQueue_postInitDone() and the message
RP_MSG_BOOTINIT_DONE to let the host know that the processor
core has finished the initialization during the boot process.
This can be used by the host processor to use some constraints
to speed up the loading and booting of the slave processors.

Added new API to allow applications/tasks on IPU or DSP to
control the suspend ability on the processors they are
executing on. The slave processors ignore the SUSPEND message
if user has disabled suspend.

These API compliment the existing IpcPower_wakeLock and
IpcPower_wakeUnlock API, but also allow the clocks to be cut
for better power savings.

The InterruptProxy functions are converted into macros expanding
to equivalent target-specific interrupt functions to reduce the
overhead of one extra function call. The macros are expanded
appropriately by using target-specific preprocessor compiler
flags.

When Idle functions are taken away or commented out from the common
configuration, the compiler is throwing a linker error (not finding
PM symbols) as it does not see any explicit dependency due to linker
optimizations.

An explicit dependency is added in the rpmsg package towards the pm
package to alleviate this problem.

Publish the OMX service using a different channel name
for each processor. This helps the host identify the exact
remote processor requesting the omx channel creation, and
allows it to create the corresponding driver.

The opaque RcmServer_Struct does not match the internal
working structure RcmServer_Object when USE_MESSAGEQCOPY is
defined. The missing fields are added to make the structure
definitions the same. This fixes an assert in RcmServer_init()
when the struct sizes do not match.

Symbol address of ti_sysbios_family_c64p_Hwi0 is assigned
as the entry point for DSP in genrprc utility, when no entry
point information is passed to genrprc utility. This symbol
branches off to the c_int00, and also satifies the 1K alignment
requirement for the DSP boot address.

This change is done in genrprc so that base images built outside
of sysbios-rpmsg can easily be used to generate a tesla binary
without having to specify any special entry point, in case if
they are not aware of the alignment restrictions. An user passed
entry point is still honored to retain the flexibility.

The entry point is set by default to point to c_int00 for
all targets. However, DSP has an additional alignment
requirement for the boot address to be aligned on a 1K
boundary. The ti_sysbios_family_c64p_Hwi0 is already
aligned by SYS/BIOS on a 1K boundary. This is the address
of vector 0 and branches off to c_int00.

This patch sets this symbol as the entry point for DSP
through a linker option for all sysbios-rpmsg builds,
thereby satisfying the alignment requirement.

The Makefile has been enhanced to be able to pick the BIOS
tool versions through parameters to the 'make' command. The
previous method of choosing custom versions through exported
shell environment variables is still valid. The parameters
to 'make' are the same as the environment variables, and
would override the corresponding environment variables.

Add the common configuration files used by samples and
other baseimages for OMAP5. The files include a sample
AMMU configuration file and IPC configurations satisfying
the OMAP5 M4 and DSP platform targets.

The build targets are chosen depending on whether its code generation
tools environment variable is set or not. This enables an user to do
a minimal build only for the target that the user is interested in.

In a clean build:
- If only TMS470CGTOOLPATH is set, only M3 target will be built.
- If only C6000CGTOOLPATH is set, only C64 target will be built
- If both tool path environment variables are set, both C64T and M3
targets will be built

In a dirty build:
- In order to enable or disable a target, an user would need to export
or unset the corresponding tool path variable, and touch the
src/config.bld to have the change become effective.

Warnings were returned when building for just one core target
(like dsp). Errors were due to uninitialized arguments for
core1. There is no need for checking these arguments if core1
is not being built.

This patch defines only the arguments that would be used based
on input files and passes these to genbase and mkheader
utilities.

DSP uses a different compiler toolchain (C6000), and throws a
warning "incomplete type not allowed" when an array is declared
without defining the array size. This option is already enabled
for the M3 target.

writeIdx and readIdx variables are placed at the the end of
the trace buffer. They should be allocated contiguously. So
the alignment should be the same as the size of the variables
(one word). Not specifying the alignment when allocating these
variables was working for M3 but not for DSP. Changing the
alignment to 0x4 (word size), both the variables are allocated
and aligned properly for both M3 and DSP.

Add support to build a BIOS-side sample for OMAP DSP processor.
This leverages the existing test_omx sample and builds it for
the DSP target as well. This sample enables to verify basic
messaging between DSP and the host.

Add a common configuration file that can be used by samples
and other DSP baseimages. The files include a common Tesla
configuration file satisfying the OMAP4 dsp platform target.

The configuration uses GPT5 as the source for System Tick on
the DSP core. The configuration is done manually to enable the
WUGEN bit and set the idlemode as smart-idle with wake-up. This
way, the GPT5 will be able to generate an interrupt and wakeup
the DSP core even if the sub-system has been gated.

Add a resource table for DSP with all the memory information and
other required resources. The proper mappings for peripheral and
data areas is specified by the physical address. The ipc, code
and data sections are assigned to fixed physical addresses too
just along-side the carveout memory regions reserved for Ducati
MM use-cases.

Additional macros were also defined to identify sub-1M sizes, and
are used in specifying the sizes for various DSP memory regions.