AM6442: Industrial Communication SDK application and Linux A53 using Remote Proc checklist.

Hello Decameron,

There are several different things we will need to keep in mind. I might turn your thread into an official document later, so if anything doesn't make sense or you have any feedback, please let me know!

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? 

It sounds like you are planning to use the Linux remoteproc driver, instead of loading the R5F cores in SBL boot. Just keep in mind that both are potential options.

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.

With the above questions answered, here are things you'll need to keep in mind

The R5F project will need to be modified

If you are using Linux remoteproc driver to initialize the R5F cores, you will need to make sure there is a resource table that the remoteproc driver can read. Please find information about adding a resource table (and Linux RPMsg IPC resources if you are using them) in
the AM64x academy, multicore module, "Application Development on Remote Cores"
https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AeMVTHckwFDmFoNkRHpRPw__AM64-ACADEMY__WI1KRXP__LATEST

ALL of the OSes should agree on where the memory regions are, and who owns each peripheral and memory region

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

The board configuration settings need to allow R5F to access the ICSSG DMAs 

This topic will require a bit more discussion, and I haven't looked into it yet on SDK 9.x. Let me know when you're here and we can move forward.

Regards,

Nick

Hi Nick,

Thank you for your comprehensive reply.

Please see below my case for design decision:

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

SPL boot.

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

Linux remoteproc driver.

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

Yes

Thank you

Hello Decameron,

Modifying the Linux devicetree files & the R5F project

Sounds good. I should have provided you all the links you need above in order to modify the Linux devicetree files, and the R5F MCU+ firmware. So feel free to start making progress on that.

I am not going to have time to try things out on my end for a bit, but if you make changes and run tests on your end, I'll support you.

Is there a "hello world" style MCU+ project that is probably be the easiest to get working with Linux?

The Industrial Communication developers said that the enet lld mac/switch project in the base MCU+ SDK 9.1 is probably the simplest networking example to experiment with as we are getting started. That way we can avoid dependencies on any third party stacks.

What about the board config settings?

Since you are using SPL boot, the board config files are built into uboot.

You can find some VERY basic getting started info for using the tool that generates board config settings here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1308689/faq-how-to-use-resource-partitioning-tool-with-processor-sdk-v9-1

And then you can find information about building that updated board config info into uboot here:
https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_01_00_08/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html

Regards,

Nick