In the datasheet for Beaglebone ai-64 @ BeagleBoard.org - ai-64 of the bullet points says:
What does the 2x 6-core term refer too? The TI documentation only talks about 2 PRUs.
I am not sure that is quite correct.
However the are 2 PRU-ICSSG’s in the ai-64. Each PRU module has multiple cores. According to this Introduction to PRU-ICSSG, each PRU module has 4 cores. Two of the cores have direct I/O while the other 2 cores do not. There is a video in that link describing the PRU’s and some links for further information.
From what I’ve found, there are 6 cores in each PRU_ICSSG subsystem:
PRU0 and PRU1
RTU0 and RTU1
TX0 and TX1
They are each similar but different, and different in important ways, so I’ll let the documentation speak to them (J721E Programmable Real-Time Unit, sec 2.1):
I could not find a search on the TI website that would locate this document. It’s evidently marked to NOT display as a search result. However Google found it and I linked to it since it is a particularly hard document to just come across.
I too find it a little misleading for them to be promoted the way they are (i.e .2x 6-core). And while that is not inaccurate, it is misleading because the average person would assume they are 6 equally-capable cores, and that’s not the case.
But they do seem to exist. You can see all 12 are exposed here on my board:
I’ve got a makefile where I did my best to identify the ones I might use and give them better names than you see in remoteproc. I don’t know if they are completely accurate, but I named them based on the numbers in the paths shown.
Disclaimer: I HAVE NOT actually tried to deploy firmware to the RTUs or TXPRUs on my BBAI64, although I haven’t found any reason to believe they wouldn’t work. My focus has just been on I/O so that has me working only on the two PRUs, however I fully intend to use at least one of the RTUs for “background” tasks that don’t require I/O access.
The whole PRU business i badly handled by Ti I think.
Just found a document PRU_ICSSG feature comparison.
This mentions the TX_PRU which they say are available on the AM65x SR2.0 (but not SR1.0), AM64x and AM243x . Of course no mention of the TDA4VM.
The PRU units on the AM64x and AM243x can run at 333Mhz, 250Mhz
for the AM65x.
Wonder if the PRU units in the TDA4VM will run at 333Mhz. Maybe they would get too hot.
I asked a similar question on that thread about whether the PRUs exist at all on production BBAI64s since I was having a hard time finding anywhere, even in J721E documentation, where clock speed was discussed. But someone found a graphic where a clock line going to the PRU subsystem was marked (250MHz).
Having some documentation confirm a number, even if its just the default number was something. But I too would like to know if the mechanisms that clock the PRUs to 333MHz will do the same for the TDA4VM.
Although IIRC, the the AM243x that are capable of 333MHz only have the PRU_ICSS, not PRU_ICSSG subsystems.
Have you found some documentation for chips with PRU_ICSSGs that also say they are capable of 333MHz? If so, it might be interesting to see what registers and values you use to set that speed and then see what happens when you do the same on a BBAI64.
But as it relates to the TDA4VM, it really bothers me that TI pulled support for the PRUs and doesn’t even claim their presence yet the BB community is claiming them and relying on their presence. Not to take anything away from the other aspects of the TDA4VM, but the PRUs are what really add value to the platform IMO…and TI has abandoned them for TDA4VM.
Have you had a look at the ClockTreeTool There is a version that covers the TDA4xM chip. I need approval to download as I am not in the states, waiting for that.
I have not heard of that. I just downloaded it and will take a look at it. I’ll take all the info I can get since it seems finding information about these chips is not exactly an easy task.
A few weeks ago, I was reading over some Intel chip documentation that was written back in the 80s for the 16-bit microcontroller I’m working with the BBAI64 to interface with. And I’ve been so impressed as to how thorough and well organized their documentation has been. I guess prior to the Internet, it had to be. But it seems in the day of search engines and support forums, company’s have found they don’t need to be as diligent about documentation as they once were decades ago. In fairness to TI, the chip I was reading documentation about is simply not as complicated of a device as the microcontrollers we are working with here so it was probably easier to write documentation for.
I got the ClockTreeTool however it’s a Java executable JAR file so you need a Java JRE installed. The documentation requests Java 7, but that’s been replaced by Java 8 long time ago so I install that (from Java 9-on, JREs may not function correctly with code mean for older JREs). Once installed, I can run the program, also an executable JAR, and I can choose the processor and hardware version. But nothing after that. I can see a window flash up really fast then disappear, but the main window just sits and spins. So I think there’s some exception being thrown in the background preventing it from launching on my system. I even tried uninstalling Java 8 and finding a Java 7 JRE installer and put that on. Same result. This was on a Windows VM, not my host machine. So later tonight or tomorrow, I’ll try to execute it from my Linux VM and see what happens. So far, not encouraging results though. What’s more frustrating is why TI is putting out a program intended for a chip released on a few years ago that was written for a VM that’s been replaced nearly 10 years ago (Java 8 released in 2014).
I got it installed on my Linux VM and I got an error message:
Fortunately the jgraph.jar does come with the installation. So it was just a matter of including the path to it on the java launch line:
java -cp jGraphLib/lib/*:CTT-Jacinto7.jar:. org.ti.clockTreeTool.simulation.ClockTreeTool
Then this led me to this error:
java.io.FileNotFoundException: ./ClockTreeTool/TI_Clock_Tree_Tool/CTT-Automotive-v1.0.0.10/XMLFiles/TDA4xM/TDA4xM_SR1.0/PCIE0_CORE_CPTS_CFG_CPTS_VBUSP.xml (No such file or directory)
I look in that directory and the file is there, but it and 3 others have CAPITAL .XML extensions, but the program is looking for lowercase .xml file extension. I suspect this wouldn’t be the problem on a Windows machine, but the jGraph not being on the java command line would’ve been an issue.
So rename the 4 files and finally, I get a window to launch that doesn’t immediately shutdown…but it is completely blank. No error, just a gigantic white window.
Who at TI tests this stuff? I’ll have to go back to the Windows machine tomorrow and try again there later. I’m out of time tonight.
Ok running under linux, had the same issues you found, but it works for me.
Did you leave it running for long enough. I noticed a background window behind the main window with what looked like some sort of progress/working bar.
After a bit, not sure how long the main white window displayed correctly.
Looks complicated, but both PRU units are shown in the diagram. Not sure it would be of much help though
OK, after quitting and then trying to run again, it must have taken a couple of minutes for the main window to show anything. No idea what it is doing that takes so long.
Trying to open the user manual from the help menu, results in an error, telling me to open the pdf manually, but it doesn’t appear to be included.
Not the best piece of software !
Why they can’t include the documentation PDF with the installer, I don’t know. But here’s the link:
CTT User’s Guide
This would’ve been nice to have before I started, but…
Edit:
And yes, waiting was the trick. It took at least 6-7 minutes for the combobox to finally appear in the main window which allowed me to scroll through. And once I selected the PRU_ICSSG0, I now have it rendering for me as well. Some kind of progress bar would certainly be nice here. It also doesn’t help that the little window you 1st start with that has the PLEASE WAIT ping-pong “busy” indicator falls behind the big white window. So unless you just happen to notice its still there, you really have no way of knowing the program is just busy, but will eventually render. It also doesn’t help that once it finally does something, the only thing you see in the big white window is the single combobox at the top. I almost didn’t recognize it up there.
