AI-64 - remoteproc confusion

Hi Guys,

Looking at the remoteproc stuff I see:

0-11 (12) PRU stuff, looks good.

12-14 (3) DSP stuff, why 3 instead of 2?

15-19 (5) R5 stuff, why 5 instead of 6?



AH, ok worked out the dsp ones, the C71 is there as well as the two c66s I was expecting.

Still can’t get my head round the five r5s though:

– Two Arm® Cortex®-R5F MCUs in isolated MCU
– Four Arm® Cortex®-R5F MCUs in general
compute partition

Sorry I haven’t looked into loading firmware on the R5’s to much… but that might be how those 2 specific R5 in lockstep mode ends up looking in remoteproc…

C7x and 2x C66x.

I don’t know. Maybe one of them is set as lockstep?

Hi Andrew,

Your post got me interested in this and I just happened to have downloaded the Ref Manual for J721E/TDA4VM . So I started going down the rabbit hole.

It appears remoteproc16 - remoteproc19 are the (4) R5F cores running in split mode on the main domain (two, 2-core clusters each running individually).

The single remoteproc15 (bus@28380000) appears to be the one from the cluster on “MCU island”

According to the Ref sheets, any cluster may be run optionally individually in “split” mode, or “lockstep” mode, where one core checks the other for errors. In which case the second is not available for other tasks.

This core mode configuration is done at boot time.

For the cluster on the MCU domain, lockstep or split mode is set at the CTRLMMR_MCUSEC_CLSTR0_CFG Register (Physical address 45A50040h)

If readonly bit 3 on this register is set, then the device is lockstep capable. By setting bit 0, the cores will go to lockstep mode.

The default value of bit zero is set by an e-fuse (couldn’t find what that default is)

Here is the interesting part however; the MCU domain is started directly and separately by the DMSC via MCU ROM code before the main domain and OS etc. even start!

So does this mean that the mode must be selected by generated MCU ROM code rather than Linux? I wonder if there will be a way to halt, reconfigure, and restart the MCU side after Linux is running?

I guess we will see. Pretty cool how much stuff is on this chip!


Just found this. Looks like they have been working on a really great remoteproc driver for the R5 cores that will handle configuration and start/stop of cores in both split and lockstep modes.

Just as others have speculated, an R5 cluster operating in lockstep will appear as a single remoteproc instance:

“The subsystem is represented as a single remoteproc in LockStep mode, and
as two remoteprocs in Split mode.”

Read more here:

1 Like

Thanks Calvin for all the detective work.

Is the ref manual you downloaded called

Yes, that’s the one.

A good brief description of the MCU R5 cores can be found in section:

“1.4.1 MCU Arm Cortex-R5F Processor”

An interesting description of the boot sequence is covered in Chapter 4. I was surprised how the boot sequence has become much more complex than older devices. It’s worth reviewing and becoming familiar with.

The registers of interest are in “J721E_registers1.pdf” see section 3 and 4. Of course the remoteproc drivers will abstract all this required configuration away, but again it’s interesting to see how it all works!


Nice one, thanks Calvin.

would like to download sprui1c … do you have a link?

I’d be interested in any documentation regarding this new board, particularly TRM

As far as the 12 pru stuff looking good, I’m dubious. what is the confidence level of this assertion? - ai-64 asserts 2x 6-core Programmable Real-Time Unit and Industrial Communication SubSystem (PRU-ICSSG). are there any supporting references?

SPRSP36J page 1 – no mention of PRU feature
SPRSP36J page 13 — PRU_ICSSG0 and PRU_ICSSG1 are not available on this device. The prg* signals should not be used. Those pins can be used for other functions.
SPRSP36J page 114 — 6.3.23 PRU_ICSSG [Currently Not Supported]

no joy searching : Arm-based processors product selection |

sprsp36j is the most technical source I can find… are there others?

thanks very much…

I found it hard to find originally and now can’t find it again!

I will pm you and then I can send you the zip… (edit: see JKS post underneath for links)

p.s. the pru stuff is there even though TI say it isn’t, it seems the BB guys managed to get it going.

Does the PRU-ICSSG exist on the BBAI-64? The answer is it depends. I spent many hours sorting this issue out. Short answer: if your BBAI-64 is shipped with prototype silicon (part numbers beginning with XJ721E) then yes, this is a “full-featured” device and the PRU-ICSSG should be present (but beware bugs mentioned in the silicon errata). If your BBAI-AI is shipped with production silicon (part numbers beginning with TDA4VM) then no, none of these production devices have the PRU-ICSSG enabled. I have no idea why that is. Bugs? Marketing? Who knows… But I was pretty discouraged when I found out.

Evidence for this:

  • TRM table 5-1, device comparison (copy here).
  • Datasheet section 6.2 “Note: PRU_ICSSG0 and PRU_ICSSG1 are not available on this device”.
  • Last post in the TI forum says the PRU is not present in the production devices and mentions how the J721E is a “superset” device.
  • Backside photo of BBAI-64 showing XJ271E installed.

Links (Beware, these will go out-of-date over time. Refer to the technical docs page for the latest)

So is the guess that they are still there in the TDA4VM and not supported or they have actually really removed them?

Andrew, thanks so much for the quick response.

While the thought of 12 pru has my mouth watering, I’m no where near the ‘pioneer’ skill level… it has taken me 8 years to be competent with the AM3358 (BBB)… without AT LEAST the level of documentation necessary to update prudebug download | to use this board, I’m going to wait.

still , and always interested in found documentation

thanks again

no mention of pru in SRM … where would we get the pinout spec? more skeptical than ever


They are definitely there on mine:

cp PRU_Halt_0.out /lib/firmware/j7-pru0_0-fw
echo 'start' > /sys/class/remoteproc/remoteproc0/state
cat /sys/class/remoteproc/remoteproc0/state

pins/pinmux/dts are well beyond me at the moment though!

1 Like

Thank you again Andrew…

where did you get the spec for j7-pru0_0-fw?

on BBB AM335X, remoteproc0 is the ARM processor, remoteproc1 is PRU0 and remoteproc2 is PRU1. So … on BBB at least, your test would not reference a PRU

root@bbb42:/service/ILI9341# ls -l /sys/class/remoteproc/
total 0
lrwxrwxrwx 1 root root 0 Jun 25 14:45 remoteproc0 → …/…/devices/platform/ocp/ocp:l4_wkup@44c00000/44d00000.wkup_m3/remoteproc/remoteproc0
lrwxrwxrwx 1 root root 0 Jun 25 14:46 remoteproc1 → …/…/devices/platform/ocp/4a326004.pruss-soc-bus/4a300000.pruss/
lrwxrwxrwx 1 root root 0 Jun 25 14:46 remoteproc2 → …/…/devices/platform/ocp/4a326004.pruss-soc-bus/4a300000.pruss/

no way for me to tell if this is so on new board… lots of processors.


root@BeagleBone:~# cd  /sys/class/remoteproc/remoteproc0
root@BeagleBone:/sys/class/remoteproc/remoteproc0# cat name

I have also run the echo code on it and it works, there is definitely a pru there :slight_smile:

I have worked out the pinmux stuff as well, tomorrow I will get a pru pin mapped and get a walkthrough written up of how to do it all…

Wow! Excellent.

if not too much extra bother, would need the addresses of data ram, instruction ram, etc


ls -l /sys/class/remoteproc/  | cut -d' ' -f9-

results in:

remoteproc0 -> ../../devices/platform/bus@100000/b000000.icssg/
remoteproc1 -> ../../devices/platform/bus@100000/b000000.icssg/b004000.rtu/remoteproc/remoteproc1
remoteproc10 -> ../../devices/platform/bus@100000/b100000.icssg/b106000.rtu/remoteproc/remoteproc10
remoteproc11 -> ../../devices/platform/bus@100000/b100000.icssg/b10c000.txpru/remoteproc/remoteproc11
remoteproc12 -> ../../devices/platform/bus@100000/4d80800000.dsp/remoteproc/remoteproc12
remoteproc13 -> ../../devices/platform/bus@100000/4d81800000.dsp/remoteproc/remoteproc13
remoteproc14 -> ../../devices/platform/bus@100000/64800000.dsp/remoteproc/remoteproc14
remoteproc15 -> ../../devices/platform/bus@100000/bus@100000:bus@28380000/bus@100000:bus@28380000:r5fss@41000000/41000000.r5f/remoteproc/remoteproc15
remoteproc16 -> ../../devices/platform/bus@100000/bus@100000:r5fss@5c00000/5c00000.r5f/remoteproc/remoteproc16
remoteproc17 -> ../../devices/platform/bus@100000/bus@100000:r5fss@5c00000/5d00000.r5f/remoteproc/remoteproc17
remoteproc18 -> ../../devices/platform/bus@100000/bus@100000:r5fss@5e00000/5e00000.r5f/remoteproc/remoteproc18
remoteproc19 -> ../../devices/platform/bus@100000/bus@100000:r5fss@5e00000/5f00000.r5f/remoteproc/remoteproc19
remoteproc2 -> ../../devices/platform/bus@100000/b000000.icssg/b00a000.txpru/remoteproc/remoteproc2
remoteproc3 -> ../../devices/platform/bus@100000/b000000.icssg/
remoteproc4 -> ../../devices/platform/bus@100000/b000000.icssg/b006000.rtu/remoteproc/remoteproc4
remoteproc5 -> ../../devices/platform/bus@100000/b000000.icssg/b00c000.txpru/remoteproc/remoteproc5
remoteproc6 -> ../../devices/platform/bus@100000/b100000.icssg/
remoteproc7 -> ../../devices/platform/bus@100000/b100000.icssg/b104000.rtu/remoteproc/remoteproc7
remoteproc8 -> ../../devices/platform/bus@100000/b100000.icssg/b10a000.txpru/remoteproc/remoteproc8
remoteproc9 -> ../../devices/platform/bus@100000/b100000.icssg/

Are the ‘txpru’ and ‘rtu’ also PRU’s?
What is the difference?