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?
4d80800000.dsp
4d81800000.dsp
64800000.dsp
15-19 (5) R5 stuff, why 5 instead of 6?
41000000.r5f
5c00000.r5f
5d00000.r5f
5e00000.r5f
5f00000.r5f
Cheers
Andy
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
subsystem
ā 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!
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:
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:
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!
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?