examples: define DCFLAGS for AM65x and J7es
Some am65x & j7es Makefiles include DCFLAGS without defining it anywhere in the
file. Added a standardized comment explaining what DCFLAGS is in every Makefile
that uses the variable.
As of this commit, no changes were made to the labs/ Makefiles since none of the
labs Makefiles have DCFLAGS.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Some am65x & j7es Makefiles include DCFLAGS without defining it anywhere in the
file. Added a standardized comment explaining what DCFLAGS is in every Makefile
that uses the variable.
As of this commit, no changes were made to the labs/ Makefiles since none of the
labs Makefiles have DCFLAGS.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
labs: Update AM65x Hands_on_Labs cmd files
AM65x cmd files were updated in a prior commit. Updating the cmd files in the
Hands-on Labs to match the rest of the cmd files in the PRU Software Support
Package.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
AM65x cmd files were updated in a prior commit. Updating the cmd files in the
Hands-on Labs to match the rest of the cmd files in the PRU Software Support
Package.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
labs: Fixup AM65x linker command files for resource table alignment
The AM65x SoCs use an ARMv8 Cortex-A53 core for running Linux. The Linux
kernel is 64-bit and uses 8-byte (64-bit) pointers, but the various
PRU/RTU/Tx_PRU cores in ICSSG are 32-bit cores. The resource table section
therefore needs to be aligned on 8-byte addresses for proper pointer
dereferencing.
The addresses are aligned on existing examples only by chance. Update
all the relevant AM65x linker cmd files to enforce the alignment, and
match the updates done in examples/am65x folders in commit 0f2ebe7ed4aa
("examples/am65x: Fixup linker command files for resource table alignment").
Signed-off-by: Suman Anna <s-anna@ti.com>
The AM65x SoCs use an ARMv8 Cortex-A53 core for running Linux. The Linux
kernel is 64-bit and uses 8-byte (64-bit) pointers, but the various
PRU/RTU/Tx_PRU cores in ICSSG are 32-bit cores. The resource table section
therefore needs to be aligned on 8-byte addresses for proper pointer
dereferencing.
The addresses are aligned on existing examples only by chance. Update
all the relevant AM65x linker cmd files to enforce the alignment, and
match the updates done in examples/am65x folders in commit 0f2ebe7ed4aa
("examples/am65x: Fixup linker command files for resource table alignment").
Signed-off-by: Suman Anna <s-anna@ti.com>
examples/j721e: Fixup linker command files for resource table alignment
The J721E SoCs use an ARMv8 Cortex-A72 core for running Linux. The Linux
kernel is 64-bit and uses 8-byte (64-bit) pointers, but the various
PRU/RTU/Tx_PRU cores in ICSSG are 32-bit cores. The resource table section
therefore needs to be aligned on 8-byte addresses for proper pointer
dereferencing of different resource types on the Linux side.
The addresses are aligned on existing examples only by chance. Update all
the relevant linker cmd files to enforce the alignment that will be
effective even with any automatic shifting that might happen with some
code changes otherwise.
Signed-off-by: Suman Anna <s-anna@ti.com>
The J721E SoCs use an ARMv8 Cortex-A72 core for running Linux. The Linux
kernel is 64-bit and uses 8-byte (64-bit) pointers, but the various
PRU/RTU/Tx_PRU cores in ICSSG are 32-bit cores. The resource table section
therefore needs to be aligned on 8-byte addresses for proper pointer
dereferencing of different resource types on the Linux side.
The addresses are aligned on existing examples only by chance. Update all
the relevant linker cmd files to enforce the alignment that will be
effective even with any automatic shifting that might happen with some
code changes otherwise.
Signed-off-by: Suman Anna <s-anna@ti.com>
examples/am65x: Fixup linker command files for resource table alignment
The AM65x SoCs use an ARMv8 Cortex-A53 core for running Linux. The Linux
kernel is 64-bit and uses 8-byte (64-bit) pointers, but the various
PRU/RTU/Tx_PRU cores in ICSSG are 32-bit cores. The resource table section
therefore needs to be aligned on 8-byte addresses for proper pointer
dereferencing of different resource types on the Linux side.
The addresses are aligned on existing examples only by chance. Update all
the relevant linker cmd files to enforce the alignment that will be
effective even with any automatic shifting that might happen with some
code changes otherwise.
Signed-off-by: Suman Anna <s-anna@ti.com>
The AM65x SoCs use an ARMv8 Cortex-A53 core for running Linux. The Linux
kernel is 64-bit and uses 8-byte (64-bit) pointers, but the various
PRU/RTU/Tx_PRU cores in ICSSG are 32-bit cores. The resource table section
therefore needs to be aligned on 8-byte addresses for proper pointer
dereferencing of different resource types on the Linux side.
The addresses are aligned on existing examples only by chance. Update all
the relevant linker cmd files to enforce the alignment that will be
effective even with any automatic shifting that might happen with some
code changes otherwise.
Signed-off-by: Suman Anna <s-anna@ti.com>
labs: update AM65x linker command files
Updated AM65x linker command files in the getting started labs to match the
AM65x Silicon Revision 2.0 updates in examples/am65x.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Updated AM65x linker command files in the getting started labs to match the
AM65x Silicon Revision 2.0 updates in examples/am65x.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples: add TRM links to READMEs
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Manifest: Update Manifest from v6.0 to v6.1
* types.h removed since it is unused
* GPL-2.0 license removed since types.h is removed
* added support for new devices (J7)
* This package is compatible with TI's Linux 5.4. Minor revisions will allow
compatibility with later Linux releases
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
* types.h removed since it is unused
* GPL-2.0 license removed since types.h is removed
* added support for new devices (J7)
* This package is compatible with TI's Linux 5.4. Minor revisions will allow
compatibility with later Linux releases
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
headers: Remove types.h header file
The types.h header file is not used anywhere, so get rid of it.
It defined some integer types, but they are not needed, and the
project can just rely on the types defined in the standard
stdint.h.
Reported-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The types.h header file is not used anywhere, so get rid of it.
It defined some integer types, but they are not needed, and the
project can just rely on the types defined in the standard
stdint.h.
Reported-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
headers: Use standard integer types in pru_virtio_ring.h
Replace all references to the custom integer type __u16 with
the standard equivalent uint16_t integer type. The only usage
in code is in the macro vring_avail_event, which itself is
not used in the code anywhere.
Signed-off-by: Suman Anna <s-anna@ti.com>
Replace all references to the custom integer type __u16 with
the standard equivalent uint16_t integer type. The only usage
in code is in the macro vring_avail_event, which itself is
not used in the code anywhere.
Signed-off-by: Suman Anna <s-anna@ti.com>
examples/am65x: Update the examples for AM65x SR2.0
The AM65x SR2.0 SoC contains a revised ICSSG IP based off the IP
version used on J721E SoCs. This revised IP adds two new additional
auxiliary cores called Tx_PRUs, one per slice, in each of the ICSSG
instances.
Add a new example project Tx_PRU_Halt that can be used to generate
firmwares that can be loaded onto these new cores. The new example
uses revised linker command files where the existing Data RAMs are
repartitioned to provide memory for the data sections of the Tx PRU
cores. The new firmwares will be able to run on both the AM65x SR1.0
and AM65x SR2.0 SoCs, with the Tx_PRU firmwares usable only with
AM65x SR2.0 SoCs.
The linker command files on all the existing examples are updated
to match this. The Data RAM split is slightly different on the
PRU_MAC_Multiply_Accum and RTU_MAC_Multiply_Accum examples to
accomodate the larger data utilization.
The ReadMe.txt file is also updated to list the new examples and
a paragraph is added about the examples usage between SR1.0 vs SR2.0.
Signed-off-by: Suman Anna <s-anna@ti.com>
The AM65x SR2.0 SoC contains a revised ICSSG IP based off the IP
version used on J721E SoCs. This revised IP adds two new additional
auxiliary cores called Tx_PRUs, one per slice, in each of the ICSSG
instances.
Add a new example project Tx_PRU_Halt that can be used to generate
firmwares that can be loaded onto these new cores. The new example
uses revised linker command files where the existing Data RAMs are
repartitioned to provide memory for the data sections of the Tx PRU
cores. The new firmwares will be able to run on both the AM65x SR1.0
and AM65x SR2.0 SoCs, with the Tx_PRU firmwares usable only with
AM65x SR2.0 SoCs.
The linker command files on all the existing examples are updated
to match this. The Data RAM split is slightly different on the
PRU_MAC_Multiply_Accum and RTU_MAC_Multiply_Accum examples to
accomodate the larger data utilization.
The ReadMe.txt file is also updated to list the new examples and
a paragraph is added about the examples usage between SR1.0 vs SR2.0.
Signed-off-by: Suman Anna <s-anna@ti.com>
examples/am65x: Update labels in linker command files
The ICSSG IP has two slices, with each slice containing a PRU and RTU
cores for a total of 4 cores per instance. Each IP also has three Data
RAMs - Data RAM0, Data RAM1 and a Shared Data RAM2. The cores use a
Harvard memory architecture, with each core seeing its own Instruction
RAM at address 0, and also a Data RAM at address 0. The cores in Slice0
see the Data RAM0 at their 0x0 and Data RAM1 at their 0x2000, while the
cores in Slice1 see Data RAM1 at their 0x0 and Data RAM0 at their 0x2000
conversely.
Update the current labels in the linker command files to reflect this
usage. The convention followed is {PRU/RTU}X_DMEM_Y, with X representing
the Slice and Y representing the actual Data RAM.
Eg: PRU0_DRAM_0 and PRU1_DRAM_1 would both point to 0x0
A few of the typos have also been fixed while at this. These include
correcting the PRU_INTC_0x200 address, using the label MII_RT and
KB for kB. The license years are also updated.
Signed-off-by: Suman Anna <s-anna@ti.com>
The ICSSG IP has two slices, with each slice containing a PRU and RTU
cores for a total of 4 cores per instance. Each IP also has three Data
RAMs - Data RAM0, Data RAM1 and a Shared Data RAM2. The cores use a
Harvard memory architecture, with each core seeing its own Instruction
RAM at address 0, and also a Data RAM at address 0. The cores in Slice0
see the Data RAM0 at their 0x0 and Data RAM1 at their 0x2000, while the
cores in Slice1 see Data RAM1 at their 0x0 and Data RAM0 at their 0x2000
conversely.
Update the current labels in the linker command files to reflect this
usage. The convention followed is {PRU/RTU}X_DMEM_Y, with X representing
the Slice and Y representing the actual Data RAM.
Eg: PRU0_DRAM_0 and PRU1_DRAM_1 would both point to 0x0
A few of the typos have also been fixed while at this. These include
correcting the PRU_INTC_0x200 address, using the label MII_RT and
KB for kB. The license years are also updated.
Signed-off-by: Suman Anna <s-anna@ti.com>
examples/am65x: Cleanup Halt and MAC_Multiply_Accum Makefiles
Replace the usage of a Makefile variable SUBSYS with the more
appropriate SLICE in the PRU_Halt, RTU_Halt, PRU_MAC_Multiply_Accum
and RTU_MAC_Multiply_Accum examples. The SUBSYS was primarily
meant to mean the PRUSS instance, while SLICE represents the
correct partition within a PRUSS the PRU or RTU core belongs to.
There is no functional difference in the outputs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Replace the usage of a Makefile variable SUBSYS with the more
appropriate SLICE in the PRU_Halt, RTU_Halt, PRU_MAC_Multiply_Accum
and RTU_MAC_Multiply_Accum examples. The SUBSYS was primarily
meant to mean the PRUSS instance, while SLICE represents the
correct partition within a PRUSS the PRU or RTU core belongs to.
There is no functional difference in the outputs.
Signed-off-by: Suman Anna <s-anna@ti.com>
labs: fix makefiles for Labs
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
labs: Add the PRU Getting Started Labs
The labs directory is now divided into two sets of labs:
* The PRU Hands-on Labs are currently unchanged. The Hands-on Labs
guide customers through using the PRU with GPI/GPO signals, and using
the RPMsg driver to communicate between a Linux ARM core and the PRU
The Hands-on Labs apply specifically to the AM335x Beaglebone Black
with a PRU cape.
* The PRU Getting Started Labs are a new set of labs described below.
The PRU Getting Started Labs apply to the PRU on AM335x, AM437x, AM57xx, and
AM65xx.
The Getting Started Labs demonstrate how to compile PRU firmware that is written
in C, assembly, or mixed C and assembly. Steps are provided for compiling the
firmware from Linux, or from Code Composer Studio (CCS).
The Getting Started Labs also demonstrate how to initialize the PRU from CCS,
another processor core running Linux, or another processor core running RTOS.
The PRU Getting Started Lab instructions will be located in the Processor SDK
Linux documentation, section "PRU-ICSS / PRU_ICSSG":
http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
The labs directory is now divided into two sets of labs:
* The PRU Hands-on Labs are currently unchanged. The Hands-on Labs
guide customers through using the PRU with GPI/GPO signals, and using
the RPMsg driver to communicate between a Linux ARM core and the PRU
The Hands-on Labs apply specifically to the AM335x Beaglebone Black
with a PRU cape.
* The PRU Getting Started Labs are a new set of labs described below.
The PRU Getting Started Labs apply to the PRU on AM335x, AM437x, AM57xx, and
AM65xx.
The Getting Started Labs demonstrate how to compile PRU firmware that is written
in C, assembly, or mixed C and assembly. Steps are provided for compiling the
firmware from Linux, or from Code Composer Studio (CCS).
The Getting Started Labs also demonstrate how to initialize the PRU from CCS,
another processor core running Linux, or another processor core running RTOS.
The PRU Getting Started Lab instructions will be located in the Processor SDK
Linux documentation, section "PRU-ICSS / PRU_ICSSG":
http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
am65x examples: add ReadMe
AM65x examples were missing a readme file. The new readme briefly describes
each AM65x example, and explains how the AM65x PRU_ICSSG example structure is
different from the example structure of our previous PRU-ICSS devices.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
AM65x examples were missing a readme file. The new readme briefly describes
each AM65x example, and explains how the AM65x PRU_ICSSG example structure is
different from the example structure of our previous PRU-ICSS devices.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
PRU_gpioToggle: toggle all GPO pins by default
Update gpioToggle examples on AM335x and AM437x so that all PRU GPO
pins toggle by default. This makes initial GPO debug easier for customers,
since it no longer matters which GPO signal they connect to a scope to see
if things are working as expected.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Update gpioToggle examples on AM335x and AM437x so that all PRU GPO
pins toggle by default. This makes initial GPO debug easier for customers,
since it no longer matters which GPO signal they connect to a scope to see
if things are working as expected.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Manifest: Update Manifest from v5.0 to v6.0
Differences in the PRU Software Support Package between manifest v5.0 and v6.0:
* Linux driver code moved from PRU Software Support Package into the Linux
kernel
* added support for new devices (am570x, am574x, am65x)
* PRU Software Support Package is now bundled into Linux Processor SDK
* This package is compatible with TI's Linux 4.19. Minor revisions will allow
compatibility with later Linux releases.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Differences in the PRU Software Support Package between manifest v5.0 and v6.0:
* Linux driver code moved from PRU Software Support Package into the Linux
kernel
* added support for new devices (am570x, am574x, am65x)
* PRU Software Support Package is now bundled into Linux Processor SDK
* This package is compatible with TI's Linux 4.19. Minor revisions will allow
compatibility with later Linux releases.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Examples: J721E: Add Halt examples
Add the PRU_Halt examples for the various cores present in the ICSSG
subsystems on J721E SoCs. The J721E SoCs has the next version of the
AM65x ICSSG IP and contains two instances of this newer ICSSG IP. Each
ICSSG instance contains 2 PRU cores, 2 RTU cores, and 2 new additional
auxiliary cores called Tx_PRU cores. The example code is ported from
the equivalent examples on AM65x SoC.
Examples are added in three different folders based on each of the PRU,
RTU and Tx_PRU core type. The source code and resource table are identical
across the three folders but are built for each core instance using
different linker command files (J721E_PRU0.cmd, J721E_PRU1.cmd,
J721E_RTU0.cmd, J721E_RTU1.cmd, J721E_TX_PRU0.cmd and J721E_TX_PRU1.cmd)
for each core. An output file is generated for each of the 6 cores present
within an ICSSG instance. The same images can be reused for the equivalent
cores across the two ICSSG instances.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the PRU_Halt examples for the various cores present in the ICSSG
subsystems on J721E SoCs. The J721E SoCs has the next version of the
AM65x ICSSG IP and contains two instances of this newer ICSSG IP. Each
ICSSG instance contains 2 PRU cores, 2 RTU cores, and 2 new additional
auxiliary cores called Tx_PRU cores. The example code is ported from
the equivalent examples on AM65x SoC.
Examples are added in three different folders based on each of the PRU,
RTU and Tx_PRU core type. The source code and resource table are identical
across the three folders but are built for each core instance using
different linker command files (J721E_PRU0.cmd, J721E_PRU1.cmd,
J721E_RTU0.cmd, J721E_RTU1.cmd, J721E_TX_PRU0.cmd and J721E_TX_PRU1.cmd)
for each core. An output file is generated for each of the 6 cores present
within an ICSSG instance. The same images can be reused for the equivalent
cores across the two ICSSG instances.
Signed-off-by: Suman Anna <s-anna@ti.com>
Examples: J721E: Add RPMsg examples for J721E SoCs
Add the RPMsg echo examples for the latest K3 J721E SoC family. The
J721E SoCs uses the next version of the AM65x ICSSG IP and contains
two instances of this newer ICSSG IP. Each ICSSG instance contains 2
PRU cores, 2 RTU cores, and 2 new additional auxiliary cores called
Transmit PRU (Tx_PRU) cores that are normally used to control the
TX L2 FIFO if enabled in Ethernet applications.
Examples are added for each of the PRU and RTU cores (Tx_PRUs are
left out for the moment) within a single ICSSG IP instance. The same
source files are used to rebuild the project for all the two different
ICSSG instances - ICSSG0 and ICSSG1. The output ELF firmware images
and map files are generated under "gen/icssg<#inst>/" folder in each
of the respective core example folder.
The following are the notable differences w.r.t AM65x:
- The Tx_PRUs uses the same interrupt sources as the regular PRU
cores, so the resource tables can use the Version 0 interrupt
resource type (Version 1 still recommended for all PRU, RTU and
Tx_PRU cores).
- J721E-specific Linker command files, the Constants are identical
to AM65x, but the addition of the Tx_PRU cores required additional
partitioning of the Data RAMs. The second 4 KB in each Data RAM
is equally partitioned between the RTU and Tx_PRU cores, while
the size for PRU core is left unchanged.
- Use a separate copy of the interrupt header file using a J721E
specific folder. The INTC is identical to that of AM65x, so the
same register definitions are used. See commit 91f4f1861b28
("J721E: Add header file for ICSSG INTC"). The same limitations
around CREGISTER #6 exists as on AM65x.
Please see commit df1d9da20473 ("Examples: AM65x: Add RPMsg examples
for AM65x SoCs") for differences w.r.t AM572x.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the RPMsg echo examples for the latest K3 J721E SoC family. The
J721E SoCs uses the next version of the AM65x ICSSG IP and contains
two instances of this newer ICSSG IP. Each ICSSG instance contains 2
PRU cores, 2 RTU cores, and 2 new additional auxiliary cores called
Transmit PRU (Tx_PRU) cores that are normally used to control the
TX L2 FIFO if enabled in Ethernet applications.
Examples are added for each of the PRU and RTU cores (Tx_PRUs are
left out for the moment) within a single ICSSG IP instance. The same
source files are used to rebuild the project for all the two different
ICSSG instances - ICSSG0 and ICSSG1. The output ELF firmware images
and map files are generated under "gen/icssg<#inst>/" folder in each
of the respective core example folder.
The following are the notable differences w.r.t AM65x:
- The Tx_PRUs uses the same interrupt sources as the regular PRU
cores, so the resource tables can use the Version 0 interrupt
resource type (Version 1 still recommended for all PRU, RTU and
Tx_PRU cores).
- J721E-specific Linker command files, the Constants are identical
to AM65x, but the addition of the Tx_PRU cores required additional
partitioning of the Data RAMs. The second 4 KB in each Data RAM
is equally partitioned between the RTU and Tx_PRU cores, while
the size for PRU core is left unchanged.
- Use a separate copy of the interrupt header file using a J721E
specific folder. The INTC is identical to that of AM65x, so the
same register definitions are used. See commit 91f4f1861b28
("J721E: Add header file for ICSSG INTC"). The same limitations
around CREGISTER #6 exists as on AM65x.
Please see commit df1d9da20473 ("Examples: AM65x: Add RPMsg examples
for AM65x SoCs") for differences w.r.t AM572x.
Signed-off-by: Suman Anna <s-anna@ti.com>
J721E: Add header file for ICSSG INTC
Add the preliminary header file for the PRUSS INTC instance present
in the ICSSG IP on J721E SoCs. The INTC on J721E SoCs is identical to
the INTC present on AM65x SoCs, with 20 host interrupts & channels and
164 PRU System Events. The file is copied from the corresponding AM65x
file.
NOTE:
1. The ICSSG on J721E SoCs have two additional Tx_PRU cores and
associated Task Managers, but there is no increase in the INTC host
interrupts.
2. The current pruIntc is defined as a single structure and the defined
global instance variable CT_INTC leverages the Constant Table Entry #0
even though there is an additional Constant Table Entry #6 that starts
at an offset of 0x200. The Constant Table Entry #6 should be commented
out in any example linker command files accordingly.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the preliminary header file for the PRUSS INTC instance present
in the ICSSG IP on J721E SoCs. The INTC on J721E SoCs is identical to
the INTC present on AM65x SoCs, with 20 host interrupts & channels and
164 PRU System Events. The file is copied from the corresponding AM65x
file.
NOTE:
1. The ICSSG on J721E SoCs have two additional Tx_PRU cores and
associated Task Managers, but there is no increase in the INTC host
interrupts.
2. The current pruIntc is defined as a single structure and the defined
global instance variable CT_INTC leverages the Constant Table Entry #0
even though there is an additional Constant Table Entry #6 that starts
at an offset of 0x200. The Constant Table Entry #6 should be commented
out in any example linker command files accordingly.
Signed-off-by: Suman Anna <s-anna@ti.com>
Labs: Use FW_RSC_ADDR_ANY for vring device addresses
The current examples use a value of 0 for da in the vrings in the
resource table, with the Linux kernel filling in the actual allocated
address. The newer Linux kernels (> 4.19) update this vring da field
only if it is set as FW_RSC_ADDR_ANY. So, update the resource tables
to use this value instead of 0 to get these firmwares to work with
the newer kernels. The change is backward compatible for existing
kernels.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
The current examples use a value of 0 for da in the vrings in the
resource table, with the Linux kernel filling in the actual allocated
address. The newer Linux kernels (> 4.19) update this vring da field
only if it is set as FW_RSC_ADDR_ANY. So, update the resource tables
to use this value instead of 0 to get these firmwares to work with
the newer kernels. The change is backward compatible for existing
kernels.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Examples: Use FW_RSC_ADDR_ANY for vring device addresses
The current examples use a value of 0 for da in the vrings in the
resource table, with the Linux kernel filling in the actual allocated
address. The newer Linux kernels (> 4.19) update this vring da field
only if it is set as FW_RSC_ADDR_ANY. So, update the resource tables
to use this value instead of 0 to get these firmwares to work with
the newer kernels. The change is backward compatible for existing
kernels.
Signed-off-by: Suman Anna <s-anna@ti.com>
The current examples use a value of 0 for da in the vrings in the
resource table, with the Linux kernel filling in the actual allocated
address. The newer Linux kernels (> 4.19) update this vring da field
only if it is set as FW_RSC_ADDR_ANY. So, update the resource tables
to use this value instead of 0 to get these firmwares to work with
the newer kernels. The change is backward compatible for existing
kernels.
Signed-off-by: Suman Anna <s-anna@ti.com>
rsc_types: Add the definition of FW_RSC_ADDR_ANY
Add the definition for a FW_RSC_ADDR_ANY macro. This macro
should be used for da in various resource types if that
particular memory needs to be dynamically allocated on the
kernel. This value is now actively used in all the upstream
kernels post the v4.19 release.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the definition for a FW_RSC_ADDR_ANY macro. This macro
should be used for da in various resource types if that
particular memory needs to be dynamically allocated on the
kernel. This value is now actively used in all the upstream
kernels post the v4.19 release.
Signed-off-by: Suman Anna <s-anna@ti.com>
examples/am335x: update comments
Updated comments in examples to clarify:
These two projects are no longer supported, and are included as a legacy
reference only:
PRU_ARMtoPRU_Interrupt
PRU_PRUtoARM_Interrupt
Comments were added to PRU_Hardware_UART to clarify how loopback works.
ReadMe.txt was updated to add new examples and point to new documentation.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Updated comments in examples to clarify:
These two projects are no longer supported, and are included as a legacy
reference only:
PRU_ARMtoPRU_Interrupt
PRU_PRUtoARM_Interrupt
Comments were added to PRU_Hardware_UART to clarify how loopback works.
ReadMe.txt was updated to add new examples and point to new documentation.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples/am335x/PRU_ADC_onChip: bug fixes
Fixed several bugs in PRU_ADC_onChip:
* pru_adc_userspace.c
- changed firmware name from PRU_ADC.out to PRU_ADC_onChip.out
- changed size of RPMsg read from MAX_BUFFER_SIZE to
RPMSG_MESSAGE_SIZE
* pru_adc_firmware.c
- reduced noise in single-ended ADC voltage measurements by
setting SEL_INM_SWC_3_0=0x8 (VREFN) for each STEPCONFIG
register
* README.txt
- changed PRU_ADC to PRU_ADC_onChip
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Fixed several bugs in PRU_ADC_onChip:
* pru_adc_userspace.c
- changed firmware name from PRU_ADC.out to PRU_ADC_onChip.out
- changed size of RPMsg read from MAX_BUFFER_SIZE to
RPMSG_MESSAGE_SIZE
* pru_adc_firmware.c
- reduced noise in single-ended ADC voltage measurements by
setting SEL_INM_SWC_3_0=0x8 (VREFN) for each STEPCONFIG
register
* README.txt
- changed PRU_ADC to PRU_ADC_onChip
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples/am335x: rename PRU_ADC to PRU_ADC_onChip
TI design TIDA-01555 is added to Processor Linux SDK 5.1 as pru-adc-1.0.
Rename the PRU SW Support Package example PRU_ADC to PRU_ADC_onChip to prevent
confusion in the future.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
TI design TIDA-01555 is added to Processor Linux SDK 5.1 as pru-adc-1.0.
Rename the PRU SW Support Package example PRU_ADC to PRU_ADC_onChip to prevent
confusion in the future.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
labs: Lab_0, Lab_5 cleanup
Added Lab_0 & Lab_5 to the top level Makefile in the labs directory.
Fixed wrong register names in Lab_5 caused by a copy-paste error.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Added Lab_0 & Lab_5 to the top level Makefile in the labs directory.
Fixed wrong register names in Lab_5 caused by a copy-paste error.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples: fixed dates
Some previous commits changed the copyright date from the original
year that the code was written to the current year (2018) on code
that was updated by the commit.
E.g., Copyright (c) 2015 Texas Instruments Incorporated
changed to
Copyright (c) 2018 Texas Instruments Incorporated
This commit fixes that mistake by retaining the original year the
code was written in, but adds the year that the code was last
modified.
Continuing the above example,
Copyright (c) 2015-2018 Texas Instruments Incorporated
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Some previous commits changed the copyright date from the original
year that the code was written to the current year (2018) on code
that was updated by the commit.
E.g., Copyright (c) 2015 Texas Instruments Incorporated
changed to
Copyright (c) 2018 Texas Instruments Incorporated
This commit fixes that mistake by retaining the original year the
code was written in, but adds the year that the code was last
modified.
Continuing the above example,
Copyright (c) 2015-2018 Texas Instruments Incorporated
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples, labs: Linux kernel 4.14 Resource Table
TI Linux kernel 4.14 introduces a new style of resource table, where TYPE_CUSTOM
is replaced by TYPE_POSTLOAD_VENDOR and TYPE_PRU_INTS is ORed with
PRU_INTS_VERx. am335x, am437x, am57x, k2g all use PRU_INTS_VER0.
TYPE_INTS_VER1 is used by am65x and adds support for 20 channels and 20 host
interrupts. examples/am65x/RTU_RPMsg_Echo_InterruptX contains an example of
TYPE_INTS_VER1 usage. An am65x PRU application that does not use the task
manager may save a little memory space by using TYPE_INTS_VER0 instead of
TYPE_INTS_VER1. examples/am65x/PRU_RPMsg_Echo_InterruptX contains an example
of am65x TYPE_INTS_VER0 usage. Note that an am65x PRU firmware that wants to
make use of the task manager must use TYPE_INTS_VER1.
Updated all non-empty resource tables in the examples folder and the labs folder
to match the new style.
Any resource tables with names like rsc_table_pru were renamed to match the
predominant naming convention (resource_table.h if no PRU/RTU is specified,
resource_table_0.h if the table is specifically for PRU/RTU0, etc).
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
TI Linux kernel 4.14 introduces a new style of resource table, where TYPE_CUSTOM
is replaced by TYPE_POSTLOAD_VENDOR and TYPE_PRU_INTS is ORed with
PRU_INTS_VERx. am335x, am437x, am57x, k2g all use PRU_INTS_VER0.
TYPE_INTS_VER1 is used by am65x and adds support for 20 channels and 20 host
interrupts. examples/am65x/RTU_RPMsg_Echo_InterruptX contains an example of
TYPE_INTS_VER1 usage. An am65x PRU application that does not use the task
manager may save a little memory space by using TYPE_INTS_VER0 instead of
TYPE_INTS_VER1. examples/am65x/PRU_RPMsg_Echo_InterruptX contains an example
of am65x TYPE_INTS_VER0 usage. Note that an am65x PRU firmware that wants to
make use of the task manager must use TYPE_INTS_VER1.
Updated all non-empty resource tables in the examples folder and the labs folder
to match the new style.
Any resource tables with names like rsc_table_pru were renamed to match the
predominant naming convention (resource_table.h if no PRU/RTU is specified,
resource_table_0.h if the table is specifically for PRU/RTU0, etc).
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples/am65x: re-updated linker command files
Updated the linker command files AM65x_PRU0.cmd, AM65x_PRU1.cmd,
AM65x_RTU0.cmd, AM65x_RTU1.cmd to better match TRM documentation.
External regions of the linker command file do not point to valid
addresses, so re-added RESERVED entries for external regions.
There are still outstanding FIXMEs that need to get addressed in
future commits.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Updated the linker command files AM65x_PRU0.cmd, AM65x_PRU1.cmd,
AM65x_RTU0.cmd, AM65x_RTU1.cmd to better match TRM documentation.
External regions of the linker command file do not point to valid
addresses, so re-added RESERVED entries for external regions.
There are still outstanding FIXMEs that need to get addressed in
future commits.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
RPMsg: Add RPMSG_MESSAGE_SIZE
Add RPMSG_MESSAGE_SIZE = 496 to include/pru_rpmsg.h.
Use this to define max message size in RPMsg examples rather than
RPMSG_BUF_SIZE. RPMSG_BUF_SIZE can cause problems because it allows
the PRU to send messages up to 512 bytes long. All RPMsg examples
were updated to use the new constant.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Add RPMSG_MESSAGE_SIZE = 496 to include/pru_rpmsg.h.
Use this to define max message size in RPMsg examples rather than
RPMSG_BUF_SIZE. RPMSG_BUF_SIZE can cause problems because it allows
the PRU to send messages up to 512 bytes long. All RPMsg examples
were updated to use the new constant.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
labs: add lab_0
Created Lab 0 to provide a software-only starting point for
developing PRU programs in a Linux environment on all supported
PRU processors.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Created Lab 0 to provide a software-only starting point for
developing PRU programs in a Linux environment on all supported
PRU processors.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples/am65x: updated linker command files
Updated the linker command files AM65x_PRU0.cmd, AM65x_PRU1.cmd,
AM65x_RTU0.cmd, AM65x_RTU1.cmd.
Fixed some typos. Replaced incorrect RESERVED constant table register
names with the actual register names. There are still outstanding
FIXMEs that need to get addressed in future commits.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Updated the linker command files AM65x_PRU0.cmd, AM65x_PRU1.cmd,
AM65x_RTU0.cmd, AM65x_RTU1.cmd.
Fixed some typos. Replaced incorrect RESERVED constant table register
names with the actual register names. There are still outstanding
FIXMEs that need to get addressed in future commits.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples/am65x: added Halt, MAC_Multiply_Accum
Ported PRU_Halt and PRU_MAC_Multiply_Accum forward to am65x examples PRU_Halt,
RTU_Halt, PRU_MAC_Multiply_Accum, and RTU_MAC_Multiply_Accum.
The firmware in main.c for these examples is the same regardless of whether it
is loaded onto PRU0/RTU0 or PRU1/RTU1. Because of that, code for any PRU core
was placed in PRU_Halt / PRU_MAC_Multiply_Accum, and code for any RTU core was
placed in RTU_Halt / RTU_MAC_Multiply_Accum.
The generated output files for PRU0 & PRU1 are different, as are the generated
output files for RTU0 & RTU1. A different command linker file is used for PRU0,
PRU1, RTU0, and RTU1 (AM65x_PRU0.cmd, AM65x_PRU1.cmd, AM65x_RTU0.cmd,
AM65x_RTU1.cmd). That command linker file is the reason that these examples
generate different output files for each core. PRU0 output code can be loaded
into the PRU0 of any ICSSG in am65x, PRU1 output code can be loaded into any
PRU1, etc.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Ported PRU_Halt and PRU_MAC_Multiply_Accum forward to am65x examples PRU_Halt,
RTU_Halt, PRU_MAC_Multiply_Accum, and RTU_MAC_Multiply_Accum.
The firmware in main.c for these examples is the same regardless of whether it
is loaded onto PRU0/RTU0 or PRU1/RTU1. Because of that, code for any PRU core
was placed in PRU_Halt / PRU_MAC_Multiply_Accum, and code for any RTU core was
placed in RTU_Halt / RTU_MAC_Multiply_Accum.
The generated output files for PRU0 & PRU1 are different, as are the generated
output files for RTU0 & RTU1. A different command linker file is used for PRU0,
PRU1, RTU0, and RTU1 (AM65x_PRU0.cmd, AM65x_PRU1.cmd, AM65x_RTU0.cmd,
AM65x_RTU1.cmd). That command linker file is the reason that these examples
generate different output files for each core. PRU0 output code can be loaded
into the PRU0 of any ICSSG in am65x, PRU1 output code can be loaded into any
PRU1, etc.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples/am65x: updated RPMsg examples
Updated register names used in the PRU and RTU RPMsg examples from SICR to
STATUS_CLR_INDEX_REG to match the updated am65x header files.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Updated register names used in the PRU and RTU RPMsg examples from SICR to
STATUS_CLR_INDEX_REG to match the updated am65x header files.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
include/am65x: added generated ICSSG header files
Added header files for am65x devices. Files are auto-generated from the
same source files used to populate the TRM register descriptions.
The TRM naming convention changed for many registers between ICSS (am335x,
am437x, am57x, k2g) and ICSSG (am65x). For example, REVID changed to
REVISION_REG. If porting code between ICSS and ICSSG, be careful to check that
the register names are still valid.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Added header files for am65x devices. Files are auto-generated from the
same source files used to populate the TRM register descriptions.
The TRM naming convention changed for many registers between ICSS (am335x,
am437x, am57x, k2g) and ICSSG (am65x). For example, REVID changed to
REVISION_REG. If porting code between ICSS and ICSSG, be careful to check that
the register names are still valid.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples: Update RPMsg payload message length
The RPMsg payload buffer is 512 bytes. However, it includes a 16 byte header.
Thus, the max message length that can be stored in the payload is 496 bytes.
The max payload message length was changed from 512 to 496 in PRU example
firmware.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
The RPMsg payload buffer is 512 bytes. However, it includes a 16 byte header.
Thus, the max message length that can be stored in the payload is 496 bytes.
The max payload message length was changed from 512 to 496 in PRU example
firmware.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples/am335x: Add PRU_ADC example
Add PRU_ADC example for am335x. This example demonstrates how to control an
on-chip peripheral (in this case, the ADC) with the PRU. The example also
demonstrates an implementation of RPMsg to communicate between userspace and the
PRU. The example was developed on a BeagleBone Black.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Add PRU_ADC example for am335x. This example demonstrates how to control an
on-chip peripheral (in this case, the ADC) with the PRU. The example also
demonstrates an implementation of RPMsg to communicate between userspace and the
PRU. The example was developed on a BeagleBone Black.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples: Bug fixes for EMCR addr
fix EMCR address in PRU_edmaConfig for am335x and am437x.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
fix EMCR address in PRU_edmaConfig for am335x and am437x.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
examples: Update DDR len in Linkr Cmd Files
updated linker command files for all am335x, am437x, am572x, k2g examples:
changed DDR len from 0x100 to 0x10000. This allows the use of constant table
register value for DDR to access DDR memory from offset=0x0 to offset=0x10000.
Accessing other areas of DDR memory are still possible, but the constant table
register with the DDR base address can not be used for those addresses.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
updated linker command files for all am335x, am437x, am572x, k2g examples:
changed DDR len from 0x100 to 0x10000. This allows the use of constant table
register value for DDR to access DDR memory from offset=0x0 to offset=0x10000.
Accessing other areas of DDR memory are still possible, but the constant table
register with the DDR base address can not be used for those addresses.
Signed-off-by: Nick Saulnier <nsaulnier@ti.com>
Examples: AM65x: Add RPMsg examples for AM65x SoCs
Add the RPMsg echo examples for the new K3 AM65x SoC family.
The AM65x SoCs have three ICSSG IP instances, with each instance
containing 2 PRU cores and 2 new auxiliary cores called RTU cores.
Examples are added for each of the PRU and RTU cores within a
single ICSSG IP instance. The same source files are used to
rebuild the project for all the three different ICSSG instances
- ICSSG0, ICSSG1 and ICSSG2. The output ELF firmware images and
map files are generated under "gen/icssg<#inst>/" folder in each
of the respective core example folder.
The following are the notable changes w.r.t AM572x:
- There is no STANDBY_INIT nor a SYSCFG register with ICSSG,
so there is no need to program any value.
- The rpmsg channel description and port numbers are constructed
using macros passed through the compiler.
- The PRU resource tables uses the new PRU interrupt resource
types and macros, but uses the Version 0 interrupt resource
type for illustration purposes (Version 1 recommended for all
PRU and RTU cores in general).
- The RTU resource tables uses the newer Version 1 interrupt
resource type that had to be introduced specifically for AM65x
ICSSG.
- AM65x-specific Linker command files, most of the Constants for
AM65x now are local ICSSG sub-module addresses. Note that each
PRU and RTU core needs its own linker command file due to
differences in their Constant Table Registers # 10, 11 and 22.
- Use the AM65x specific interrupt header file. See commit
c97858ef9945 ("AM65x: Add preliminary header file for ICSSG INTC")
and the commented out CREGISTER #6 for some usage caveats.
- Makefile improvements to build three output images for each
ICSSG instance reusing the same source files and linker command
files for each of PRU0, PRU1, RTU0 and RTU1 cores.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the RPMsg echo examples for the new K3 AM65x SoC family.
The AM65x SoCs have three ICSSG IP instances, with each instance
containing 2 PRU cores and 2 new auxiliary cores called RTU cores.
Examples are added for each of the PRU and RTU cores within a
single ICSSG IP instance. The same source files are used to
rebuild the project for all the three different ICSSG instances
- ICSSG0, ICSSG1 and ICSSG2. The output ELF firmware images and
map files are generated under "gen/icssg<#inst>/" folder in each
of the respective core example folder.
The following are the notable changes w.r.t AM572x:
- There is no STANDBY_INIT nor a SYSCFG register with ICSSG,
so there is no need to program any value.
- The rpmsg channel description and port numbers are constructed
using macros passed through the compiler.
- The PRU resource tables uses the new PRU interrupt resource
types and macros, but uses the Version 0 interrupt resource
type for illustration purposes (Version 1 recommended for all
PRU and RTU cores in general).
- The RTU resource tables uses the newer Version 1 interrupt
resource type that had to be introduced specifically for AM65x
ICSSG.
- AM65x-specific Linker command files, most of the Constants for
AM65x now are local ICSSG sub-module addresses. Note that each
PRU and RTU core needs its own linker command file due to
differences in their Constant Table Registers # 10, 11 and 22.
- Use the AM65x specific interrupt header file. See commit
c97858ef9945 ("AM65x: Add preliminary header file for ICSSG INTC")
and the commented out CREGISTER #6 for some usage caveats.
- Makefile improvements to build three output images for each
ICSSG instance reusing the same source files and linker command
files for each of PRU0, PRU1, RTU0 and RTU1 cores.
Signed-off-by: Suman Anna <s-anna@ti.com>
AM65x: Add preliminary header file for ICSSG INTC
Add the preliminary header file for the PRUSS INTC instance present
in the ICSSG IP on AM65x SoCs. The INTC on AM65x SoCs have increased
number of host interrupts & channels (20 vs 10) and PRU System events
(160 vs 64), so there are new additional registers.
NOTE:
The current pruIntc is defined as a single structure and the defined
global instance variable CT_INTC leverages the Constant Table Entry #0
even though there is an additional Constant Table Entry #6 that starts
at an offset of 0x200. The Constant Table Entry #6 should be commented
out in any example linker command files accordingly.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the preliminary header file for the PRUSS INTC instance present
in the ICSSG IP on AM65x SoCs. The INTC on AM65x SoCs have increased
number of host interrupts & channels (20 vs 10) and PRU System events
(160 vs 64), so there are new additional registers.
NOTE:
The current pruIntc is defined as a single structure and the defined
global instance variable CT_INTC leverages the Constant Table Entry #0
even though there is an additional Constant Table Entry #6 that starts
at an offset of 0x200. The Constant Table Entry #6 should be commented
out in any example linker command files accordingly.
Signed-off-by: Suman Anna <s-anna@ti.com>
pru_types: Add a new custom intc resource structure for ICSSG
The PRU INTC within ICSSG on K3 AM65x SoCs supports increased
number of host interrupts/channels and system events. The
current fw_rsc_custom_ints structure is not sufficient to
properly configure these additional host interrupts/channels
on the Linux side. So, a new custom interrupt resource type
structure fw_rsc_custom_ints_k3 is added to support this.
The Linux driver can support both versions simultaneously,
so the previous structure can still be used on AM65x resource
tables to save space if desired when the additional interrupt
configuration is not required. The new structure is mandatory
for the RTU cores though as their host interrupts are part
of the additional interrupts.
Note that this resource structure should be used with a version
value of 1 to allow the Linux driver to differentiate this new
structure from the previous resource structure.
Signed-off-by: Suman Anna <s-anna@ti.com>
The PRU INTC within ICSSG on K3 AM65x SoCs supports increased
number of host interrupts/channels and system events. The
current fw_rsc_custom_ints structure is not sufficient to
properly configure these additional host interrupts/channels
on the Linux side. So, a new custom interrupt resource type
structure fw_rsc_custom_ints_k3 is added to support this.
The Linux driver can support both versions simultaneously,
so the previous structure can still be used on AM65x resource
tables to save space if desired when the additional interrupt
configuration is not required. The new structure is mandatory
for the RTU cores though as their host interrupts are part
of the additional interrupts.
Note that this resource structure should be used with a version
value of 1 to allow the Linux driver to differentiate this new
structure from the previous resource structure.
Signed-off-by: Suman Anna <s-anna@ti.com>
pru_types: Deprecate fw_rsc_custom_ints version field
The first element of the fw_rsc_custom_ints structure has been
defined as a version field. The versioning of the custom resource
types has since been defined as a sub-field within the custom
resource type field itself in the fw_rsc_custom structure. So,
rename this version field as reserved. A value of 0 should be
continued to be used for this field for existing users. The field
itself is retained for now to maintain backward compatibility
of various firmwares, and will be removed later on.
Signed-off-by: Suman Anna <s-anna@ti.com>
The first element of the fw_rsc_custom_ints structure has been
defined as a version field. The versioning of the custom resource
types has since been defined as a sub-field within the custom
resource type field itself in the fw_rsc_custom structure. So,
rename this version field as reserved. A value of 0 should be
continued to be used for this field for existing users. The field
itself is retained for now to maintain backward compatibility
of various firmwares, and will be removed later on.
Signed-off-by: Suman Anna <s-anna@ti.com>
rsc_types: Sync up remoteproc resource types with TI 4.14 kernels
Update the default resource types to match the latest changes done on
the TI 4.14 Linux kernels. The previously unused RSC_INTMEM type is
re-purposed into a vendor pre-load custom resource RSC_PRELOAD_VENDOR
type. The RSC_CUSTOM is actually the post-load custom resource type,
RSC_POSTLOAD_VENDOR so has been renamed appropriately. The TYPE_CUSTOM
is still defined for now for compatibility purposes.
The fw_rsc_custom structure type is also updated to add provision for
the versioning of any custom resource type. The structure size itself
is not changed, but is split up to add the versioning using the higher
bytes within the previous sub_type element. Note that the name of this
structure is not updated to match the fw_rsc_vendor used on the Linux
kernel side.
Signed-off-by: Suman Anna <s-anna@ti.com>
Update the default resource types to match the latest changes done on
the TI 4.14 Linux kernels. The previously unused RSC_INTMEM type is
re-purposed into a vendor pre-load custom resource RSC_PRELOAD_VENDOR
type. The RSC_CUSTOM is actually the post-load custom resource type,
RSC_POSTLOAD_VENDOR so has been renamed appropriately. The TYPE_CUSTOM
is still defined for now for compatibility purposes.
The fw_rsc_custom structure type is also updated to add provision for
the versioning of any custom resource type. The structure size itself
is not changed, but is split up to add the versioning using the higher
bytes within the previous sub_type element. Note that the name of this
structure is not updated to match the fw_rsc_vendor used on the Linux
kernel side.
Signed-off-by: Suman Anna <s-anna@ti.com>
pru_demo: update fw path in StarterWare Makefile
The relative path to the PRU firwmares was incorrect in the
StarterWare pru_demo Makefile. This commit corrects the
relative path error.
Reported-by: Arturs Elksnis
Signed-off-by: Jason Reeder <jreeder@ti.com>
The relative path to the PRU firwmares was incorrect in the
StarterWare pru_demo Makefile. This commit corrects the
relative path error.
Reported-by: Arturs Elksnis
Signed-off-by: Jason Reeder <jreeder@ti.com>
Updating PRU UART header file for the AM572x 2.0
Pulling the latest changes from the TRM into the pru_uart.h
header file for the AM572x 2.0 device.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Pulling the latest changes from the TRM into the pru_uart.h
header file for the AM572x 2.0 device.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Mimic the StarterWare PRU cape demo on Linux console
This commit adds a shell script (and everything else that
it needs) in order to provide a Linux console demo on the
BeagleBone and BeagleBone black.
Signed-off-by: Jason Reeder <jreeder@ti.com>
This commit adds a shell script (and everything else that
it needs) in order to provide a Linux console demo on the
BeagleBone and BeagleBone black.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Fixed an ECAP interrupt issue in the TempSensor demo
It was discovered that PRU1 could get stuck waiting on the
ECAP PRDEQ event if the ECAP flags were not cleared during
initialization.
This commit clears the ECAP flags during initialization for
both the lab_3 and pru_fw examples.
Signed-off-by: Jason Reeder <jreeder@ti.com>
It was discovered that PRU1 could get stuck waiting on the
ECAP PRDEQ event if the ECAP flags were not cleared during
initialization.
This commit clears the ECAP flags during initialization for
both the lab_3 and pru_fw examples.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Update the BeagleBoneBlack PRU cape dtsi file
As of the latest Linux Processor SDK release (3.1.0.6) the
BeagleBoneBlack PRU cape dtsi file needs to be updated in
order to avoid pin mux conflicts.
This commit disables all necessary nodes dealing with the
HDMI output in order to remove all pin mux conflicts with
the PRU cape.
Signed-off-by: Jason Reeder <jreeder@ti.com>
As of the latest Linux Processor SDK release (3.1.0.6) the
BeagleBoneBlack PRU cape dtsi file needs to be updated in
order to avoid pin mux conflicts.
This commit disables all necessary nodes dealing with the
HDMI output in order to remove all pin mux conflicts with
the PRU cape.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Fix incorrect pinout in PRU cape dtsi files
The device trees for the BeagleBone and BeagleBoneBlack are
using the incorrect pin for PRU0_UART_rts. It should be
pin P9.21, not P9.19. This also corrects a potential pin
conflict with I2C2.
Reported-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
The device trees for the BeagleBone and BeagleBoneBlack are
using the incorrect pin for PRU0_UART_rts. It should be
pin P9.21, not P9.19. This also corrects a potential pin
conflict with I2C2.
Reported-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
Make it more clear that CCS is not needed to build fws
The previous comments and error messages in the Makefiles
of the support package could make it seem like Code
Composer Studio (CCS) was necessary to use the TI provided
PRU C compiler.
This is not the case as the PRU code gen tools (including
the C compiler/linker) can be downloaded separately from
CCS. This allows the firmwares in the support package to
be modified and rebuilt using only these Makefiles and
the PRU code gen tools.
Signed-off-by: Jason Reeder <jreeder@ti.com>
The previous comments and error messages in the Makefiles
of the support package could make it seem like Code
Composer Studio (CCS) was necessary to use the TI provided
PRU C compiler.
This is not the case as the PRU code gen tools (including
the C compiler/linker) can be downloaded separately from
CCS. This allows the firmwares in the support package to
be modified and rebuilt using only these Makefiles and
the PRU code gen tools.
Signed-off-by: Jason Reeder <jreeder@ti.com>
[WIP] Updating makefiles using script
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
Adding MCSPI headers for AM335x, AM437x, and AM572x
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
Fixes an rpmsg bug concerning available buffers
The vring implementation used by rpmsg contains a free
running index for the last available buffer that was
filled by the ARM side. The PRU rpmsg library also keeps
track locally of the last available buffer index that it
consumed in the form of a free running index.
The PRU rpmsg library can compare the last available index
that it consumed with the last available index reported by
the ARM core (to the vring) to determine if there is a new
buffer to be consumed. If the two available indexes are
equal to one another, then the PRU rpmsg library can tell
that there are no messages waiting for it in the vring.
Both of these indexes need to be of the same type in order
for unsigned integer overflow to affect them equally. This
was not the case prior to this commit. Previously, the
vring index was 16 bits and the local rpmsg library index
was 32 bits. Once the vring index rolled over from 0xffff
back to 0, the PRU continuously thought that a new message
was available because of the index mismatch. In the echo
example case this caused the PRU to send 65536 unsolicited
messages to the ARM, bringing it to a crawl due to all of
interrupts associated with the messages.
This commit corrects the size of the local rpmsg library's
last_avail_idx to use 16 bits instead of 32.
Signed-off-by: Jason Reeder <jreeder@ti.com>
The vring implementation used by rpmsg contains a free
running index for the last available buffer that was
filled by the ARM side. The PRU rpmsg library also keeps
track locally of the last available buffer index that it
consumed in the form of a free running index.
The PRU rpmsg library can compare the last available index
that it consumed with the last available index reported by
the ARM core (to the vring) to determine if there is a new
buffer to be consumed. If the two available indexes are
equal to one another, then the PRU rpmsg library can tell
that there are no messages waiting for it in the vring.
Both of these indexes need to be of the same type in order
for unsigned integer overflow to affect them equally. This
was not the case prior to this commit. Previously, the
vring index was 16 bits and the local rpmsg library index
was 32 bits. Once the vring index rolled over from 0xffff
back to 0, the PRU continuously thought that a new message
was available because of the index mismatch. In the echo
example case this caused the PRU to send 65536 unsolicited
messages to the ARM, bringing it to a crawl due to all of
interrupts associated with the messages.
This commit corrects the size of the local rpmsg library's
last_avail_idx to use 16 bits instead of 32.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Correcting capitalization in RPMsg example comments
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
Remove SYSCFG accesses from AM437x PRUSS0 code
The SYSCFG register is reserved for PRUSS0 in the AM437x
devices. Accesses to the register were removed from the
provided examples and the comments were updated to make
this more clear.
Signed-off-by: Jason Reeder <jreeder@ti.com>
The SYSCFG register is reserved for PRUSS0 in the AM437x
devices. Accesses to the register were removed from the
provided examples and the comments were updated to make
this more clear.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Examples: Update Readme files
PRU_RPMsg_Echo_Polling examples are no longer present,
and have been cleaned up in commit 6980582 ("Convert
RPMsg examples from mailboxes to interrupts"). Update
the various Readme files to reflect the same.
Signed-off-by: Suman Anna <s-anna@ti.com>
PRU_RPMsg_Echo_Polling examples are no longer present,
and have been cleaned up in commit 6980582 ("Convert
RPMsg examples from mailboxes to interrupts"). Update
the various Readme files to reflect the same.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add hex utility output to the PRU_RPMsg_LED0 fimware
In order to make all of the projects in the pru_cape/pru_fw/
folder uniform, hex utility output has been added to the
PRU_RPMsg_LED0 project.
This allows all project in the pru_fw folder to share the
same Makefile.
Signed-off-by: Jason Reeder <jreeder@ti.com>
In order to make all of the projects in the pru_cape/pru_fw/
folder uniform, hex utility output has been added to the
PRU_RPMsg_LED0 project.
This allows all project in the pru_fw folder to share the
same Makefile.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Remove the hex utility step from lab projects
The output of the hex utility step was not being used in
the lab projects. This step has now been removed from the
two lab projects that were using it.
Examples of usage of the hex utility can still be found in
the pru_cape/pru_fw/ folder of the support package.
Signed-off-by: Jason Reeder <jreeder@ti.com>
The output of the hex utility step was not being used in
the lab projects. This step has now been removed from the
two lab projects that were using it.
Examples of usage of the hex utility can still be found in
the pru_cape/pru_fw/ folder of the support package.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Indentation and comment fixes in RPMsg code
Due to incorrect settings in one of the text editors being
used, there were indentation errors introduced throughout
the package. This commit cleans up the indentation in the
RPMsg example and library.
In order to reduce the development effort of updating
RPMsg code for multiple devices, a script was created to
generate the main.c file from a template. The previous
method of copy/paste/modify led to human error in the
comments that were not caught. The script corrected these
errors.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Due to incorrect settings in one of the text editors being
used, there were indentation errors introduced throughout
the package. This commit cleans up the indentation in the
RPMsg example and library.
In order to reduce the development effort of updating
RPMsg code for multiple devices, a script was created to
generate the main.c file from a template. The previous
method of copy/paste/modify led to human error in the
comments that were not caught. The script corrected these
errors.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Improve the abstraction of RPMsg lib and examples
This commit adds an initializiation function to the rpmsg
API - pru_rpmsg_init().
Previously the top level user program had to call init
functions directly from the pru_virtqueue api. Now the top
level user program only calls functions from the pru_rpmsg
api and no longer needs to include the pru_virtqueue header
file.
The provided RPMsg example projects have been updated to
reflect this change.
Signed-off-by: Jason Reeder <jreeder@ti.com>
This commit adds an initializiation function to the rpmsg
API - pru_rpmsg_init().
Previously the top level user program had to call init
functions directly from the pru_virtqueue api. Now the top
level user program only calls functions from the pru_rpmsg
api and no longer needs to include the pru_virtqueue header
file.
The provided RPMsg example projects have been updated to
reflect this change.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Further line ending and trailing whitespace cleanup
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
Update the software manifest to version 5.0.0
Due to changes in the underlying mechanisms of rpmsg, the
previous examples will no longer work with the Linux kernel
v4.4 drivers. For this reason the major revision number of
this software package is getting bumped to 5.0.0.
New rpmsg examples have been provided and a new software
manifest to cover this major revision has been added.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Due to changes in the underlying mechanisms of rpmsg, the
previous examples will no longer work with the Linux kernel
v4.4 drivers. For this reason the major revision number of
this software package is getting bumped to 5.0.0.
New rpmsg examples have been provided and a new software
manifest to cover this major revision has been added.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Add includes and examples for k2g (66AK2G02)
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
Convert RPMsg examples from mailboxes to interrupts
This commit moves the rpmsg library and examples away from using the
SOC mailboxes. Master interrupt events in the PRU-ICSS interrupt
controller are now being used for the signaling between the PRUs and
the ARM core(s).
PRU-ICSS System Events 16 and 17 are being used for PRU0 in all
subsystems and System Events 18 and 19 are being used for PRU1.
This change is necessary because existing devices may not have enough
mailboxes to support each PRU core (AM437x) and future devices (k2g)
based on the KeyStone architecture do not have mailboxes at all.
This change simplifies the PRU_RPMsg_Echo_Interrupt examples to the
point that the PRU_RPMsg_Echo_Polling examples are no longer
necessary so they have been removed.
Signed-off-by: Jason Reeder <jreeder@ti.com>
This commit moves the rpmsg library and examples away from using the
SOC mailboxes. Master interrupt events in the PRU-ICSS interrupt
controller are now being used for the signaling between the PRUs and
the ARM core(s).
PRU-ICSS System Events 16 and 17 are being used for PRU0 in all
subsystems and System Events 18 and 19 are being used for PRU1.
This change is necessary because existing devices may not have enough
mailboxes to support each PRU core (AM437x) and future devices (k2g)
based on the KeyStone architecture do not have mailboxes at all.
This change simplifies the PRU_RPMsg_Echo_Interrupt examples to the
point that the PRU_RPMsg_Echo_Polling examples are no longer
necessary so they have been removed.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Reformat code and remove whitespace errors
Changes here include:
- Remove trailing whitespace from files
- Move function open brace to next line
- Normalize line endings
- Fix mixed spaces and tabs
- Normalize statement spaceing
- Remove space at the begining of lines
- Various other code formatting fixes
Signed-off-by: Andrew F. Davis <afd@ti.com>
Changes here include:
- Remove trailing whitespace from files
- Move function open brace to next line
- Normalize line endings
- Fix mixed spaces and tabs
- Normalize statement spaceing
- Remove space at the begining of lines
- Various other code formatting fixes
Signed-off-by: Andrew F. Davis <afd@ti.com>
Remove exacutable bit from file permissions for code files
C files, text files, headers, etc.. are not executable, remove this flag.
Signed-off-by: Andrew F. Davis <afd@ti.com>
C files, text files, headers, etc.. are not executable, remove this flag.
Signed-off-by: Andrew F. Davis <afd@ti.com>
PRUSS0 enablement patch update to latest SDK
The patch needed to be updated for the latest Linux
Processor SDK v2.0.2.11.
Signed-off-by: Jason Reeder <jreeder@ti.com>
The patch needed to be updated for the latest Linux
Processor SDK v2.0.2.11.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Adding header files for the ADCs on AM437x devices
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
Differentiate between AM572x silicon revisions
There are slight deltas in the PRU registers between silicon
revision 1.1 and 2.0 on the AM572x device. This commit
creates a new include folder for each silicon revision and
then updates the Makefiles in the AM572x examples to use
the 2.0 version of the registers by default.
Signed-off-by: Jason Reeder <jreeder@ti.com>
There are slight deltas in the PRU registers between silicon
revision 1.1 and 2.0 on the AM572x device. This commit
creates a new include folder for each silicon revision and
then updates the Makefiles in the AM572x examples to use
the 2.0 version of the registers by default.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Removing code that causes compiler warnings
There were several places where a halt instruction was being
used after a while(1) loop. These halt instructions have
been removed.
There were also two instances where a 32 bit pointer was
getting used as an 8 bit pointer which caused a compiler
warning. This has been corrected.
Signed-off-by: Jason Reeder <jreeder@ti.com>
There were several places where a halt instruction was being
used after a while(1) loop. These halt instructions have
been removed.
There were also two instances where a 32 bit pointer was
getting used as an 8 bit pointer which caused a compiler
warning. This has been corrected.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Ability to use PRUSS0 instead of PRUSS1 on AM437x
The current implementation of pruss_remoteproc is not able
to load both PRU subsystems in the AM437x device
simultaneously. pruss_remoteproc defaults to using PRUSS1
because it has larger instruction/data rams as well as a
shared memory. PRUSS0 has access to more external GPIO pins
however, which has led to multiple customers asking to load
PRUSS0 instead of PRUSS1.
This commit provides a patch that modifies the Linux kernel
source to load PRUSS0 instead of PRUSS1 in the AM437x
device. New RPMsg examples are also provided for PRUSS0
because small modifications were necessary (PRUs in
subsystem 0 must access the global memories through
subsystem 1's OCP master port. This means that code is
needed to not only enable subsystem 0's OCP master port but
also to enable subsystem 1's OCP master port. See the
main.c files in the new PRUSS0 RPMsg examples for the code).
Signed-off-by: Jason Reeder <jreeder@ti.com>
The current implementation of pruss_remoteproc is not able
to load both PRU subsystems in the AM437x device
simultaneously. pruss_remoteproc defaults to using PRUSS1
because it has larger instruction/data rams as well as a
shared memory. PRUSS0 has access to more external GPIO pins
however, which has led to multiple customers asking to load
PRUSS0 instead of PRUSS1.
This commit provides a patch that modifies the Linux kernel
source to load PRUSS0 instead of PRUSS1 in the AM437x
device. New RPMsg examples are also provided for PRUSS0
because small modifications were necessary (PRUs in
subsystem 0 must access the global memories through
subsystem 1's OCP master port. This means that code is
needed to not only enable subsystem 0's OCP master port but
also to enable subsystem 1's OCP master port. See the
main.c files in the new PRUSS0 RPMsg examples for the code).
Signed-off-by: Jason Reeder <jreeder@ti.com>
Adding PAGE 2 to the hex utility input files
The previous commit moves the PRU shared memory to PAGE 2
in the command linker files of all the projects. This
commit updates the hex utility input file to reflect this
change as well.
Signed-off-by: Jason Reeder <jreeder@ti.com>
The previous commit moves the PRU shared memory to PAGE 2
in the command linker files of all the projects. This
commit updates the hex utility input file to reflect this
change as well.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Moving PRU_SHAREDMEM to PAGE 2 in the linker files
CCS can only access the PRU shared memory located at
subsystem address 0x10000 through PAGE 2. It was discovered
that if the DATA_SECTION pragma was used to place
initialized variables into the shared memory that CCS would
fail to load the program binary once it tried to validate
that the data was written correctly because it had not in
fact written any data to shared memory.
Once PRU_SHAREDMEM is moved to PAGE 2 in the command
linker file, CCS can successfully load and verify the
binary.
PAGE 1 versus PAGE 2 for the shared memory has no effect
on the pruss_remoteproc module's ability to load data
correctly into the shared memory.
Signed-off-by: Jason Reeder <jreeder@ti.com>
CCS can only access the PRU shared memory located at
subsystem address 0x10000 through PAGE 2. It was discovered
that if the DATA_SECTION pragma was used to place
initialized variables into the shared memory that CCS would
fail to load the program binary once it tried to validate
that the data was written correctly because it had not in
fact written any data to shared memory.
Once PRU_SHAREDMEM is moved to PAGE 2 in the command
linker file, CCS can successfully load and verify the
binary.
PAGE 1 versus PAGE 2 for the shared memory has no effect
on the pruss_remoteproc module's ability to load data
correctly into the shared memory.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Remove the patches directory
Future versions of the Processor SDK will have the PRU
Software Support Package built in so patches should not
be necessary.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Future versions of the Processor SDK will have the PRU
Software Support Package built in so patches should not
be necessary.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Correcting a typo in the BBB PRU cape dtsi file
There was a forward-slash instead of a semicolon in the
am335x-boneblack-prucape.dtsi file.
Signed-off-by: Jason Reeder <jreeder@ti.com>
There was a forward-slash instead of a semicolon in the
am335x-boneblack-prucape.dtsi file.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Refer to hdmi and sound node using absolute path
Previously, a patch was necessary to add a label to both
the hdmi and sound node in the am335x-boneblack.dts file in
order to be able to disable them in this dtsi file.
This commit moves away from using the labels to using the
absolute path of the nodes. This removes the dependency on
the label adding patch.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Previously, a patch was necessary to add a label to both
the hdmi and sound node in the am335x-boneblack.dts file in
order to be able to disable them in this dtsi file.
This commit moves away from using the labels to using the
absolute path of the nodes. This removes the dependency on
the label adding patch.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Modifying CCS build configurations
There were two post-build steps that were meant for
development purposes that were removed from the CCS
examples.
Signed-off-by: Jason Reeder <jreeder@ti.com>
There were two post-build steps that were meant for
development purposes that were removed from the CCS
examples.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Updating the ReadMe files
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
Updating the Software Manifest file
New software manifest for the v4.0 package.
Signed-off-by: Jason Reeder <jreeder@ti.com>
New software manifest for the v4.0 package.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Header file corrections
Small modifications to the header files.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Small modifications to the header files.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Putting a halt example into each device folder
This commit adds an example PRU_Halt example into each
device folder. This firmware can be used to create
a firmware that will load into any of the PRU cores
to satisfy the pruss_remoteproc Linux driver's need
to load a firmware into all cores.
Signed-off-by: Jason Reeder <jreeder@ti.com>
This commit adds an example PRU_Halt example into each
device folder. This firmware can be used to create
a firmware that will load into any of the PRU cores
to satisfy the pruss_remoteproc Linux driver's need
to load a firmware into all cores.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Removing AM571x examples from this release
There is currently no AM571x board available so these
examples will be removed for now. Once a board becomes
available they will be replaced.
Signed-off-by: Jason Reeder <jreeder@ti.com>
There is currently no AM571x board available so these
examples will be removed for now. Once a board becomes
available they will be replaced.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Adding example for the AM57xx devices
The multiply/accumulate and the direct connect examples
should work on the AM571x and AM572x devices so they have
been added to the respective example folders.
Signed-off-by: Jason Reeder <jreeder@ti.com>
The multiply/accumulate and the direct connect examples
should work on the AM571x and AM572x devices so they have
been added to the respective example folders.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Updating the CCS build configurations
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
Updating commit messages and checkPatch warnings
Corrected typos in commit messages. Also, ran the latest
checkPatch script on the rpmsg_pru driver and made the
suggested changes.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Corrected typos in commit messages. Also, ran the latest
checkPatch script on the rpmsg_pru driver and made the
suggested changes.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Added a status check in the RPMsg examples
It was found that a race condition could occur during boot
where the virtio_rpmsg_bus module may not have been ready
for RPMsg operations. A check on a status bit was added to
the RPMsg PRU firmwares in order to wait under the Linux
modules were ready for communication.
Signed-off-by: Jason Reeder <jreeder@ti.com>
It was found that a race condition could occur during boot
where the virtio_rpmsg_bus module may not have been ready
for RPMsg operations. A check on a status bit was added to
the RPMsg PRU firmwares in order to wait under the Linux
modules were ready for communication.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Update the labs/cape examples include folder
This commit adds the newly created include/am335x folder
to the include patch of all the existing labs and PRU
cape examples.
Signed-off-by: Jason Reeder <jreeder@ti.com>
This commit adds the newly created include/am335x folder
to the include patch of all the existing labs and PRU
cape examples.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Decouple the RPMsg library from the MBX internals
This commit updates the RPMsg library in order to remove
any dependencies on the MBX structure. Now, the examples
pass a 32 bit pointer to the message address that the
library needs write to in order to 'kick' the ARM.
Previously, the library had to include the mailbox
header file and use the instance variable provided. This
did not scale to the new devices, hence the change.
Signed-off-by: Jason Reeder <jreeder@ti.com>
This commit updates the RPMsg library in order to remove
any dependencies on the MBX structure. Now, the examples
pass a 32 bit pointer to the message address that the
library needs write to in order to 'kick' the ARM.
Previously, the library had to include the mailbox
header file and use the instance variable provided. This
did not scale to the new devices, hence the change.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Changing the name of the structure instances to match
Removing the 'CT' prefix from the previous header files
and making sure that the instance names match across
devices. This should allow different devices to share
PWMSS code.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Removing the 'CT' prefix from the previous header files
and making sure that the instance names match across
devices. This should allow different devices to share
PWMSS code.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Adding RPMsg examples for AM571x and AM572x
Created RPMsg echo example for each of the 4 PRU cores in
the AM57xx devices.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Created RPMsg echo example for each of the 4 PRU cores in
the AM57xx devices.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Copy examples into device-specific folders
Added example folders for the AM335x and AM437x devices
and copied the existing examples into these two folders.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Added example folders for the AM335x and AM437x devices
and copied the existing examples into these two folders.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Adding patches to fix the RPMsg highmem issue
The RPMsg vring descriptor buffers could be placed in
highmem which meant that the virtual to physical address
translation would be incorrect. These patches introduce
changes to address this issue.
Signed-off-by: Jason Reeder <jreeder@ti.com>
The RPMsg vring descriptor buffers could be placed in
highmem which meant that the virtual to physical address
translation would be incorrect. These patches introduce
changes to address this issue.
Signed-off-by: Jason Reeder <jreeder@ti.com>
First pass at adding device specific header files
Added a directory for each supported device and duplicated
the header files into each folder. Changes were made where
differences between the devices are present.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Added a directory for each supported device and duplicated
the header files into each folder. Changes were made where
differences between the devices are present.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Remove the divide by 4 from the const table example
There were two pointers to 32 bit arrays in the example. In
order to use a register offset in the array, the offset had
to be divided by 4 (4 bytes in 32 bits). This was confusing
so this commit changes the arrays from 32 bit arrays to 8
bit arrays. This removes the requirement for the divide by 4.
Signed-off-by: Jason Reeder <jreeder@ti.com>
There were two pointers to 32 bit arrays in the example. In
order to use a register offset in the array, the offset had
to be divided by 4 (4 bytes in 32 bits). This was confusing
so this commit changes the arrays from 32 bit arrays to 8
bit arrays. This removes the requirement for the divide by 4.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Updating the software manifest for v3.0
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
Updating the BSD License header in the source code
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>
Changing the copyright date to 2015
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Jason Reeder <jreeder@ti.com>