Making use of R5 on BeagleY-AI

The BeagleY gets advertized with “Arm Cortex-R5 subsystem for low-latency I/O and control”. How can the (one of the) R5 cores be used along with the BeagleY Linux on the Cortex-A53?

The TI Technical Reference Manual for the AM67A is confusing when it comes to the R5 subsystem: sometimes it talks about dual-core R5, sometimes single core R5… What I currently assume is this, taking the block diagram as reference:

  • the WKUP R5 is the “Device management” R5 which is used for booting and for securely unlocking the peripherals for the other cores.
  • the MCU R5 is unused and can be used (?)
  • no idea what the “Runtime management” R5 is… or is this R5 core running the security firmware for unlocking the peripherals?

Maybe one of the BeagleY team experts can comment…? Thanks!

Regards
jgrmpf

1 Like

This will be the first thing I’ll be trying when I get one. Personally, I think good documentation on how to run some code on the R5 and pass some data between that and Linux will be key to making this an (unnamed other SBC) killer.

The AI stuff doesn’t interest me, but I’m sure will be important for others. The “new PRU” interests me the most.

Do you have any examples of how to run code on the R5’s? The examples i have found appear to be way outside my range and confort zone. The PRU’s, I have already managed.

If you don’t mind please post the links to those.

Hi guys, interesting topic, but please be so kind and discuss this in a separate thread. I’d like here to get first the answer to the original question which of the R5 on the AM67A can be used for running user code and how the others are being used.
Thanks!

This one from TI, is not specific, but has a few examples.
mcupsdk-core/examples/hello_world_cpp/am273x-evm/r5fss0-0_nortos/main.cpp at next · TexasInstruments/mcupsdk-core · GitHub

This is one i could not, for the life of me, understand. It was posted in the these forums somewhere…
GitHub - kaofishy/bbai64_cortex-r5_example

Have you tried it out, if it does actually work that linker script .ld would be helpful. As far as understanding it,I was watching the eclipse today and that would be a good excuse for me not understanding it.

lol. I couldnt watch the eclipse. I wanted to share this example. If you understand it, of figure it out, please dumb it down for someone like me. Thank you.

test.c · main · BeagleBoard.org / bbai64_cortex-r5_example · GitLab (openbeagle.org) Was busy in a meeting. This is an example i found on the

I just got an AI64 off the shelf and in the process finding an image to load on it. Stuck a load cape on it and will get that up first then look at the R5 stuff. I would say if the tree builds and it actually does output “hello” it would be worth the time trying to figure it out.

1 Like

@jgrmpf, What do you want to do with the R5 core?

If you want to do a baremetal MCU to control I/O you need to review the board schematics and the TRM. This will let you know what to study. Also, review all the BBAI64 R5F examples that the community has posted. For baremetal, Learn about ARMv7 and newlib. For peirpherials, study the TRM and the TI libraries.

@foxsquirrel, For the BBAI64 Using TI libraries to control GPIO example that @ewaldhr linked above. Use the firmware from here ARM64 - Debian 12.x (Bookworm) - Monthly Snapshots - 2023-10-07. Debian 12 with kernel 5.10. That example uses the TI CSL layer to access the periperials. If you use firmware 6.1 or later, the examples don’t work because the layout of some stuff has moved around.

1 Like

@FredEckert Thank you very much for the heads up.

Before reading your advice I installed the desktop image from the official images page. Needed the backend set up for doing some graphics testing along with the R5 and load cape integration. It is on this version: 5.10.168-ti-arm64-r113.

Since this is still 5.10 am I safe to assume it will work?

Should work. We are using 5.10.168-ti-arm64-r111

1 Like

Hi Fred,

What do you want to do with the R5 core?

I am familiar with the R5 in general and had already run code controlling GPIO (the LEDs) on the BBAI-64 using a proprietary OS (loaded at u-boot time) and sharing data in DRAM with the OS on the A72. For the BeagleY I’d just be interested how to make use of the R5 (because I plan to purchase a BeagleY :grin:)

For me it is more interesting which of the R5F listed on the block diagram of the AM67A is available for user code programming, so that I know in which chapter of the TRM I have to look into. As mentioned, I suppose the “Device Management” R5 is occupied. But I am not sure with of the MCU R5 or the “Run-time Management” R5.

Regards
jgrmpf

Yes, these are interesting questions. I hope we can get some clarity on these.

For the BBAI64, I selected a main domain R5F because it was easier to talk between A72 and R5F in the same domain. At this time, I am not going to purchase a BeagleYAI. I still have yet to master the BBAI64 :wink:

Please share if you figure it out. Would love to use these.

The plan, from my perspective, is to largely support Zephyr as the new bare-metal. This means giving some infrastructure for communicating back to Linux via raw shared-memory, messages and streams as well as some ability to hand off peripherals, not just GPIO, with functions to support, not just bit-banging. The ability for Zephyr to create small, targeted binaries with or without a scheduler included coupled with strong upstream support provides my rationale.

2 Likes

Hello jasson.

May i ask why the interest in zephyr? Is it some kind of open source rtos?

yes, managed by the Linux Foundation.

It is easier to manage than a collection of bare-metal code because it gives it structure, maintenance and documentation, but it is able to produce code that approaches bare-metal sizes thanks to Kconfig-style #ifdef blocks, device-tree definitions and very granular modules.

1 Like

With the AI64 the issues with special firmware have to do with device tree problems. GPIO will not work with the newer firmware unless you setup some custom overlays to mux the IO pins as needed. Everything is not muxed by default. If you go back to the firmware from April 2023 GPIO will work from an R5 by default. SPI 6 and 7 will also work if you setup the overlays. I could not get PWM working.

You can grab that April firmware here Index of /rootfs/bb.org/testing/2023-04-06/bullseye-minimal-arm64

ANYWAY… With my current setup I am using the firmware from 2023-10-07. It’s Debian 12.2 with kernel 5.10. For my device tree setup I am using a mashup derived from a setup I got from @klindsayjr. With this setup I am controlling GPIO, SPI, and PWM from an R5 core. I even have shared memory with Linux working.

Here’s my device tree setup, read the README for instructions: GitHub - kevinacahalan/bbai64_sketch_dt_setup_5_10: Enables GPIO, SPI 6 and 7, EPWM4, and 16MB shared memory at 0x90000000

2 Likes