Hey y’all,
I have a beaglebone-ai-64 ordered (back ordered) and was interested in it due to the R5F and Large number of PRU (notes in the beagleboard.org ai-64 pages. I read in this forum that only the prototype silicon had the pru and the production TDA4VM has no PRU.
Assuming that is true, can anyone confirm which processor is shipping now. Is it the TDA4VM with no PRUs?
Thanks,
Joey
citation needed, so i can nuke it…
Production Silicon with PRU’s enabled…
Regards,
Thanks Robert!
The thread from this forum is ai-64 remoteproc confusion and it referenced a thread in the TI processors forum
Joey
Hi @jmoreland “TI” does not want to support the PRU on this device…
Remember, 10 years ago, TI also didn’t want to support the PRU on the am335x… The community did most of the heavy lifting…
Today, the PRU is the reason the am335x does so well…
Regards,
Thanks Robert!
@jmoreland working with zmatt on our irc channel today…
source… GitHub - mvduin/py-uio: Userspace I/O in Python still a work in progress, ddr is broken, but basic stuff is workoing…
debian@BeagleBone:/opt/source/py-uio/pru-examples$ ./basic-test.py
waiting for core to halt
r0 = 124
debian@BeagleBone:/opt/source/py-uio/pru-examples$ ./intc-test.py
event 17
event 16
event 17
event 17
^C
debian@BeagleBone:/opt/source/py-uio/pru-examples$ sudo beagle-version | grep model
model:[BeagleBoard.org_BeagleBone_AI-64]
debian@BeagleBone:/opt/source/py-uio/pru-examples$ cat /boot/firmware/extlinux/extlinux.conf
label Linux eMMC
kernel /Image
append console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait net.ifnames=0
fdtdir /
fdtoverlays /overlays/J721E-PRU-UIO-00A0.dtbo
initrd /initrd.img
Mad respect to Robert, as usual. But my original post has all the citations needed. I want to use the PRUs on the AI-64 as much as anyone. But because I’m building a product I need to know the full, accurate story. As long as AI-64 shipments continue using the XJ721E “superset” device (also called a “prototype” device by TI due to the “X”, see data sheet page 314) the PRUs should be there. How long will TI make those devices available? How long will the AI-64 ship with them installed? Good question.
Here’s some additional info from the TI forums. The current data sheet rev J makes reference to something called the “AM752x” in addition to the TDA4VM / DRA829. The current TRM rev C does not, but the earlier revs A and B did. So what’s the story? Well, this post (2 years old) says the AM752x is a non-automotive SoC version. But then this post (11 months old) is the first I’ve seen where someone from TI specifically says there are no plans to support the PRU-ICSSG in any future (production) SoC version. 
Hi @jks …
When reading, yeah that would worry me: TDA4VM: PRU-ICSS and datasheet/Sysconfig tool? - Processors forum - Processors - TI E2E support forums
For us BeagleBoard.org, in our weekly or semi-random calls with TI, we are very vocal about the PRU’s… There are groups in TI that don’t want to support it with Soft Ware, so we’ve been very pointed, just leave it on the silicon and we will figure it out… But yet, it’s here: Gitweb @ Texas Instruments - Open Source Git Repositories - git.TI.com/gitweb - pru-software-support-package/pru-software-support-package.git/summary
As far as the TDA4 or J721E, i’m fully expecting TI will have to leave the PRU’s enabled… Now that boards are shipping and user’s start to design with the PRU’s TI will have no choice…
I know on TI’s next Silicon, AM62xx the PRU’s are still there… Beyond that i don’t know… I’m a little worried seeing a fully functional M0 on the AM62xx… But yet the M0/PRUSS combo would be fun…
TI likes to hide or enable features in later datasheet’s. For example, all our AM57xx’s had EVE enabled, till TI decided to support it… Then magically even boards shipped years prior got it enabled over night…
For us, we’ve got a lot of users heavily interested in the PRU, we have some basic’s working, but next we need to figure out all the co-pru’s… rtu/txpru…
@jkridner any other pru thoughts…
Edit, so on a production BBAI64 with the heat-sink removed its:
TDA4VMB6T6BALF
or
TDA4VM86T6BALF
(my eye’s suck, B6 or 86)
that should be fully production silicon with pru enabled…
Regards,
Thanks Robert, especially for taking the time to pop the heatsink. Extremely useful info.
Just to be clear though, the AM62xx has a single PRU_ICSS (dual core) very similar to the PRU_ICSS on the BeagleBone Black/am335x, just clocked much higher (333mhz instead of 200) and an extra 20K of shared memory. It doesn’t have the new PRU_ICSSG with the auxiliary cores and such. I believe the TDA4 and AM65x chips use the newer PRU_ICSSG (and multiple of them) so there likely will be some challenges from the community here to be able to fully support everything on both.
Like Robert mentioned, py-uio kinda worked out of the box on the J721e by applying the uio-pruss driver patch to the kernel and using a DT overlay I wrote. The advantage of uio is that it maps pruss into userspace in its entirety, which means that support for all of its features can be figured out from there without any specific kernel support, instead of having your hands tied by the limited functionality of the remoteproc kernel driver.
The different PRUSS flavors are more similar than they are different, and even though py-uio was originally written for the AM3358 it worked unmodified for the AM5729. One issue we did run into on the J721e is that the examples that used DDR memory failed, though that appears to be because using memset() to zeroize device memory will crash on ARM64, so it shouldn’t be too hard to implement a workaround. Adding support for the remaining four cores should be pretty trivial, I can probably even auto-detect their presence.
The main issue for me right now is that I currently don’t have access to an AI-64 myself yet, nor a ton of spare time, but it’ll get there!
I get that including and keeping-active the PRU_ICSSG will be something we can expect TI to continue to do for the TDA4VM. However part of supporting a peripheral isn’t simply making it available. It’s also guaranteeing that every unit off the production line has been tested and that all supported functions and peripherals behave as advertised.
This testing takes time, so it’s no surprise when a peripheral isn’t claimed or supported, it isn’t going to be tested either.
Take the fictional “FOOtara” FU335x series microprocessors. Lets say the FU3352 doesn’t claim all peripherals and doesn’t “support” higher processor speeds that are supported on other offerings in the FOOtara line.
So even if the silicon being sold as a FU3352 has every component a FU3358 has, its production line testing won’t be as extensive making its cost-to-manufacture cheaper.
Likewise units that were intended to be FU3358s but couldn’t perform fully but passed all FU3352 tests can thus be marked and sold as FU3352s.
Once tape-out and manufacture of the controllers has matured, there’s a good chance that all FOOTARA controllers are made exactly the same, with the only difference being marking and production-line testing. Thus DIYers could buy FU3352s and safely use them as FU3358s for a bargain price with the understanding that they are playing the silicon lottery and hoping that all units actually perform as FU3358s OR the onus will be on them to write and perform those tests and manually throw-out failures.
My point is, is the Beagleboard organization not taking the same risk here with the PRU_ICSSG on the TDA4VM?
Even if the PRU_ICSSGs are present and kept active by TI, if TI isn’t verifying their functionality on every chip they sell, there’s a chance PRU-logic would run fine on one BBAI-64 but fail (intermittently or regularly) on another BBAI-64 and it not be clear/obvious that the issue is a hardware problem, not a developer/logic problem. That seems like the ingredients of firmware developer nightmares.
It almost begs the question if TI was experiencing issues during production-testing of the TDA4VM’s PRUs and instead of fixing the problem, they just decided to drop support for the PRU_ICSSGs and wash their hands of it.
Am I being overly paranoid? Or is this a fair argument?
If TI was to drop the PRU, they’ll rename the part…
Regards,
Has anybody determined what speed the PRUs run at by default on the BBAI64?
Supposedly the PRU_ICSSGs are capable of 250MHz. Sec 1.4.2 (p 4858) PRU_ICSSG Getting Started Guide.
And, I’ve found documentation for the very similar AM65xx that corroborates this:
Section 6.5.3 PRU_ICSSG Integration in the AM65xx Technical Reference Manual:
The PRU cores supports three clock speeds — 200 MHz, 225 MHz (default), and 250 MHz. Below are the
basic register configurations required for enabling each clock speed:
• 200 MHz
– CTRLMMR_ICSSGn_CLKSEL[0] CORE_CLKSEL = 1 (CPSWHSDIV_CLKOUT2 is source clock)
– ICSSG_CORE_SYNC_REG[0] CORE_VBUSP_SYNC_EN = 0 (Async Mode, default)
• 225 MHz
– CTRLMMR_ICSSGn_CLKSEL[0] CORE_CLKSEL = 0 (PER1HSDIV_CLKOUT1, default)
– ICSSG_CORE_SYNC_REG[0] CORE_VBUSP_SYNC_EN = 0 (Async Mode, default)
• 250 MHz
– CTRLMMR_ICSSGn_CLKSEL[0] CORE_CLKSEL = don’t care
– ICSSG_CORE_SYNC_REG[0] CORE_VBUSP_SYNC_EN = 1 (Sync-to-VCLK Mode)
Clocked at 250MHz would yield 4ns resolution.
However TI it seems does improve on their numbers, and thus there’s a precedent that improvements are made to the PRUs to get faster clocks out of them. For example this passage from the AM243x documentation:
The Sitara Devices contain PRU Cores which are capable of executing instructions in a completely deterministic manner. The various clock speed options available are 200MHz, 225MHz, 250MHz, 300MHz, 333MHz giving us a resolution of upto 3ns. This allows us to use PRU Cores for realtime I/O control applications.
The question is was the PRU_ICSSGx improved in the J721E or is it a very close variant to the AM65x and thus can only be expected to go 250MHz?
If someone has an O-scope they can test this on, here’s a TI E2E thread where someone wrote a simple while-loop that would pulse an output at a known PRU execution rate to allow you to glean the PRU’s clock speed:
In the PRU ICSSG documentation for the J721E it looks like its clocked at 250MHz:
See page 26 in https://www.ti.com/lit/ug/spruj61/spruj61.pdf