Hi all — I’m the owner of Pocket NC; we build desktop 5-axis CNC mills that have run on the BeagleBone Black since the beginning (and the BeagleBone AI in our larger machine). We’re now porting the V2 mill to the AI-64 and have made a good start on real hardware. Sharing what works, and asking three questions we can’t settle ourselves.
What we’ve verified on a stock AI-64 (factory Bullseye image, 5.10.120-ti-arm64):
- PASM-assembled firmware (pasm -V2, wrapped with objcopy + pru-ld into an ELF32/EXEC with an empty resource table) loads and runs on ICSSG0 PRU0 via remoteproc. XIN/XOUT scratchpad, ZERO, FILL, and MVID all behave.
- The ICSSG IEP timer runs our production programming sequence unchanged from the AM572x (CMP0 compare + reset-on-match + CMP_STATUS poll/W1C at offset 0x74): a CMP0 of 3125 ticks gives exactly 40.000 kHz on a scope on P8_16.
- ICSSG core/IEP clock measured at 250 MHz (clk_summary, confirmed by the scope).
- Worst-case poll-loop detection latency ~28 ns over millions of events.
- /dev/mem reads of PRU DMEM0 (0x0B000000) work from Linux while the core runs.
The questions:
-
TI errata i2230 says “ICSSG: ICSSG is not supported” on the TDA4VM. The hardware clearly works. For a machine tool we’d ship and support for years, how should we weigh that advisory? Is there history or context behind it?
-
What is the recommended replacement for uio_pruss on K3? Our HAL driver mmaps PRU data RAM every servo period (the old prussdrv role). The uio_pruss in the 5.10 kernel has no DT match table, so it can’t bind to ICSSG. Is the blessed path a UIO overlay (py-uio style), plain /dev/mem, or something newer?
-
For hard real-time work on the AI-64, is 6.1-ti-rt-arm64 the right kernel line to build on? (We ship a PREEMPT_RT kernel today on 4.19 armhf.)
We’ll write up the full port and share it back here as it lands.
I got this repo here with some info you may find useful BeagleBoneAI64_Heterogeneous_App_Example
Note the way I am doing the R5 stuff is not ideal. If I were starting an R5 project today, I’d probably get Zephyr going, and add Zephyr support for hardware IO modules as needed.
BBAI64 PRU examples
Seeing how Bullseye leaves support in three days,
I sincerely hope that you’ll be going for Trixie and kernel 6.18 at least.
Are you using any of the AI-64’s features that prevent you
from looking at the BeagleY-AI or Pocketbeagle 2 Industrial?
Fair question — we did evaluate the BeagleY-AI. Three requirements ruled it out: we need the full PRU subsystem with PRU-direct pins on the headers (our step generation runs entirely on PRU R30 I/O), we need the P8/P9-class pin budget for a 5-axis machine’s signals, and the final product will expose a customer-facing DisplayPort, which the AI-64 uniquely provides among these boards.
Kernel point well taken — we’re surveying current RT options rather than assuming the 6.1 line.
And thanks @kevinacahalan for the examples repo — much appreciated.
6.18.x-k3 has PREEMPT and PREEMPT_DYNAMIC enabled..
6.18.x-lts/arm64-multiplatform-k3$ cat patches/defconfig | grep PREEMPT
CONFIG_PREEMPT_BUILD=y
CONFIG_ARCH_HAS_PREEMPT_LAZY=y
CONFIG_PREEMPT=y
# CONFIG_PREEMPT_LAZY is not set
CONFIG_PREEMPT_RT=y
# CONFIG_PREEMPT_RT_NEEDS_BH_LOCK is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPTION=y
CONFIG_PREEMPT_DYNAMIC=y
CONFIG_PREEMPT_RCU=y
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC_KEY=y
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set
add preempt=full to your bootargs..
Regards,
Valid points. I can see how the requirement of a HDMI port points in one direction only.
@RobertCNelson perfect — exactly what we needed. We’ll build the next phase on 6.18.x-k3 with preempt=full and report RT latency numbers (cyclictest + our PRU-side jitter instrumentation) back here as we get them.