[FAQ] AM6442: How to Get R5F PRU Ethernet working alongside Linux A53

First, make your basic design decisions

1) are you using SPL boot, or SBL boot? 

This impacts where the board config settings need to go. Please refer to
the AM64x academy, multicore module, "Booting and disabling processor cores":
https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__ATo1YYblar8bnpnjYwvd1g__AM64-ACADEMY__WI1KRXP__LATEST

2) How do you want the R5F cores to be initialized? 

Will the R5F cores be loaded with the Linux remoteproc driver, or during SBL boot?

3) Do you want to have RPMsg IPC communication between Linux and the R5F? 

If yes, you will need to modify the R5F project to make sure the Linux RPMsg IPC resources get allocated.

.

For this example, we will be using AM6442 on the TMDS64EVM.
* We will be using the Linux SDK's SPL boot
* We will use the Linux remoteproc driver to initialize the R5F cores
* We will build in the Linux RPMsg IPC resources to enable Linux to initialize the remote cores, but we will NOT write any RPMsg IPC code for this example

Modify the R5F project so that it can be initialized by Linux 

This is ONLY needed if the R5F project will be initialized by the Linux remoteproc driver, or if you will be using RPMsg IPC to communicate between Linux and the R5F.

Add a resource table that the remoteproc driver can read. Follow the AM64x academy, multicore module steps here:
https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AeMVTHckwFDmFoNkRHpRPw__AM64-ACADEMY__WI1KRXP__LATEST
Application Development on Remote Cores > How to create remote core firmware that can be initialized by Linux > Option 1: Add Linux IPC to an MCU+ Project

Modify the Linux devicetree file & the R5F project to ensure that each peripheral and memory region are used by only one OS 

Unless it is shared memory, each peripheral and memory region should be owned by a single OS (i.e., either Linux, or one of the R5Fs).

Linux works differently from RTOS. An RTOS only takes the specific resources you give it. Linux is "greedy", so it WILL try to use a peripheral or memory unless you specifically disable it. Please make sure there are no conflicts between the Linux devicetree settings and the R5F cores' settings. 

This means disabling resources that will be used by R5F, like the entire PRU subsystem, specific UART instances, etc. No need to disable each subnode of the PRU subsystem - disabling the top-level PRU subsystem is sufficient.

That also means that Linux and the remote core should agree on where SHARED memory is (e.g., the resource table if booting with Linux remoteproc, and the VRINGS if using Linux RPMsg).

For more information, refer to 
the AM64x academy, multicore module, "How to allocate peripherals" and "How to allocate memory"
https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AROmAnuFxeqz306G2XuoZw__AM64-ACADEMY__WI1KRXP__LATEST

Allocating peripherals for this example: MCU+ side

Most of the peripherals used in the MCU+ enet example, I allocated to R5F0_0. This means that these peripherals (like I2C1 and ICSSG1) need to be disabled from the Linux devicetree.

I did choose to keep UART0 assigned to Linux. We moved R5F0_0 to use UART1 by modifying this section in SysConfig:
TI Driver Porting Layer > Debug Log > UART Instance > USART1

And then we can verify that the uart instance was properly changed by going to 
TI Drivers > UART > to see that the UART instance was updated to UART1.

Save the SysConfig changes by going File > Save

Allocating peripherals for this example: Linux side 

Some changes to the Linux devicetree are obvious. Is a peripheral used by the MCU+ project? Then it should be set to "disabled" or "reserved" in the Linux devicetree.

However, you also have to keep the PCB board design in mind. On TMDS64EVM, CPSW port 2 is connected to the same Ethernet interface as one of the ICSSG1 ports. Thus, in the Linux devicetree, we need to disable the second CPSW Ethernet port and the MDIO mux to make sure that Linux does not interfere with the R5F using that Ethernet connector.

delete response when publishing

delete response when publishing

delete response when publishing