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!
Cheers
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 sprui1c.zip?
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!
Cheers
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?
BeagleBoard.org - 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 | TI.com
sprsp36j is the most technical source I can find… are there others?
thanks very much…
gomer
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 | SourceForge.net to use this board, I’m going to wait.
still , and always interested in found documentation
thanks again
gomer
no mention of pru in SRM … where would we get the pinout spec? more skeptical than ever
gomer
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
running
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/4a334000.pru/remoteproc/remoteproc1
lrwxrwxrwx 1 root root 0 Jun 25 14:46 remoteproc2 → …/…/devices/platform/ocp/4a326004.pruss-soc-bus/4a300000.pruss/4a338000.pru/remoteproc/remoteproc2
root@bbb42:/service/ILI9341#
no way for me to tell if this is so on new board… lots of processors.
gomer
root@BeagleBone:~# cd /sys/class/remoteproc/remoteproc0
root@BeagleBone:/sys/class/remoteproc/remoteproc0# cat name
b034000.pru
I have also run the echo code on it and it works, there is definitely a pru there 
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
y
ls -l /sys/class/remoteproc/ | cut -d' ' -f9-
results in:
remoteproc0 -> ../../devices/platform/bus@100000/b000000.icssg/b034000.pru/remoteproc/remoteproc0
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/b038000.pru/remoteproc/remoteproc3
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/b134000.pru/remoteproc/remoteproc6
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/b138000.pru/remoteproc/remoteproc9
Are the ‘txpru’ and ‘rtu’ also PRU’s?
What is the difference?
Ok very basic info of getting something running on PRU0_0: AI64 - PRU Basics (very)
For addresses etc look in here: https://www.ti.com/lit/zip/spruil1
RTUs do not have pin access I think, I have not worked out the difference between the PRUs and TXPRUs yet. They are all PRUs though but I guess with different access,
They are, but they have different I/O. You can find out about them in other ICSSG documentation. Here are some useful search results: