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:
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.
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!
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.
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.
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.
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?
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 )
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.
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
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.
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.
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.
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.
)