Minimal Cortex-R5 example on BBAI-64

Hi all,

After scouring TI’s documentation and failing to find a minimal working example for the Cortex-R5 cores that doesn’t depend on the Processor SDK or TI’s compilers, I have decided to whip one up myself.

(Extremely) Minimal Cortex-R5 remoteproc example for Beaglebone AI-64

This is a bare minimum program showing how to initialize the resource table and output into the remoteproc trace.

Any feedback is appreciated.

Regards,
Tony

4 Likes

Nice one Tony, I will have a look when I get some time…

Cheers

Andy

What a great example. Really appreciate you sharing!

An update: I was able to properly configure the MPU and cache to run code from external memory. As a proof of concept I ported the Dhrystone benchmark to the Cortex-R5 running out of DDR memory. Performance is nearly identical to using TCMs due to the benchmark fitting entirely within the R5’s L1 cache.

Code is here in a new branch: Cortex-R5 Dhrystone on DDR memory with MPU and cache for Beaglebone AI-64

Note that you will see many warnings from GCC about the dated Dhrystone code, which for this demonstration can be safely ignored.

Regards,
Tony

4 Likes

You are doing some great stuff here, very useful. Thanks :slight_smile:

Amazing work @Tony_Kao! Thanks for publishing this.

I don’t yet have a BB AI-64 of my own to play with – how is the latency between writing “start” to the “state” sysfs attribute and getting the “hello” message back? I imagine it’s under a second? (And although not directly related to your work, how long does the stock OS image take to boot to userspace?)

I infer the remoteproc devices exposed by the kernel are for the “MAIN”-domain cores. Are you aware of any existing exploration into the “MCU”-domain cores and implementing software images for them? I’m finding a lot of theoretical capabilities of the R5 cores in the reference manual for the TDA4VM as I read but successful implementations are rather sparse. It seems like the expected methodology is to load a boot image into the local RAM of the MCU-domain R5s and then communicate with it via internal SPI or I2C. Perhaps I’m just not looking hard enough in the upstream TI samples.

Also, are you or others aware of what the debugging capabilities on the R5 cores look like? I see the AI-64 maps some UART pins to external debug headers, as well as an MCU-specific header which has a selection of GPIOs. But I don’t see a JTAG interface for on-chip debugging of the R5 cores. Those pins don’t seem to appear in the AI-64 schematic. Are you aware of what’s going on there?

Thanks!

@kaelinl there are Tag Connect JTAG pads next to the SD Card socket.

1 Like

Oh nice, thank you! I was overlooking that port expecting something specific to the MCU cores but evidently I should have read the reference manual more closely.