AI-64 Discoveries and Insights Megathread

As I dig more and more thru various bits of TDA4VM documentation, I’ve come across lots of little tidbits of info that are intriguing and lead to deeper and understanding (and often more questions).

I don’t want to clutter up the forum with endless post about every little discovery and question as it would be impolite to other users, so I thought it would be better to create a single thread that we could update over time…

PLEASE JOIN IN with your own discoveries / questions! The goal here is to document these bits collaboratively and provide a way for future users to stumble upon these things when they search for something.


The boot process of BB-AI64 (TDA4VM / J721E) can be summarized as follows [1] and also [2]

  1. DMSC Wakes Up (which itself is a Cortex M3) and resets/boots the R5 in MCU Domain.

  2. R5 (MCU) begins loading various firmware bits back into DMSC (evidently the DMSC doesn’t have ability to load these files directly so the R5-MCU does it). These files include tiboot3.bin, sysfw.itb, tispl.bin. After these files are loaded back into DMSC, now the R5-MCU is free to boot whatever firmware it will run itself (eg. some safety domain software like AutoSAR OS that the automotive world uses)

  3. The DMSC now boots A72 which in turn loads u-boot.img and begins Linux boot process. A few notes here is that u-boot support remoteproc, so prior to booting Linux, the A72 could first boot all other CPUs in its Main Domain (4 other R5s, C7X, C66 and PRUs). This would be achieved by loading firmware in a similar way as you do in Linux itself…but via the u-boot prompt itself:

      u-boot prompt:
      >rproc init
      >rproc list
         0 - Name:'r5f@41000000' type:'internal memory mapped' supports: load start stop reset
         1 - Name:'r5f@41400000' type:'internal memory mapped' supports: load start stop reset
         2 - Name:'r5f@5c00000' type:'internal memory mapped' supports: load start stop reset
         3 - Name:'r5f@5d00000' type:'internal memory mapped' supports: load start stop reset
         4 - Name:'r5f@5e00000' type:'internal memory mapped' supports: load start stop reset
         5 - Name:'r5f@5f00000' type:'internal memory mapped' supports: load start stop reset
         6 - Name:'dsp@4d80800000' type:'internal memory mapped' supports: load start stop reset
         7 - Name:'dsp@4d81800000' type:'internal memory mapped' supports: load start stop reset
         8 - Name:'dsp@64800000' type:'internal memory mapped' supports: load start stop reset
      >load mmc 1:2 0x90000000 /lib/firmware/j7-main-r5f0_0-fw
      >rproc load 2 0x90000000 0x${filesize}
      >rproc start 2
      >boot #boots linux now

(NOTE: The alternative to starting processors in u-boot is to just load them after Linux boots via sysfs / remoteproc subsystem - this is probably easiest for testing)

One discovery I’ve had is that this clearly explains that there are 3 DOMAINS IN TDA4VM: DSMC, MCU, MAIN[1] [2]. The serial port headers on BB-AI64 are labeled WKUP and UART0 DEBUG.

So the port WKUP = DMSC!
While the DEBUG port = MCU / MAIN debug.

This had me confused for awhile as I kept thinking of board as 2 DOMAINS (MCU / MAIN), when in fact it is 3.

Lastly, in a proper TI EVM the DMSC runs a final bit of firmware known as TIFS (TI Foundational Security), this continues to run as other MCU and MAIN cores are booted and I believe that this is providing “secure-boot style services”…that is your other MCU and MAIN firmware’s could be signed and TIFS verifies signature before booting. From what I read, the chips in BB-AI64 have a part number of “GP” in them which signifies General Purpose whereas other J721E chips have “HS” (High Security) and thus, the Beagles do not have this ‘secure-boot’ ability. [1]



The TDA4VM/J721E has robust support for virtualization, This includes:

  • TI-MMU (a TI extension to normal IOMMU which enables deeper virt features)
  • eGPU

Watch this great TI Training video for more…

The big surprise here is how deep virtualization is enabled on this chip. Not just regular MMU virtualization, but full PCI, GPU, CPU, Display (DSS) sharing is available.

This means that via Linux / QEMU-KVM / iommu / vfio can be applied to applications running on the board. It appears this virtualization extends to things like the C7X which means that one of your VMs could access the AI engine directly from within a VM. Further, given that the GPU can split into 8 slices (the video says this can be done dynamically), this means that VM1 and VM2 could share the PowerVR GPU and if VM1 crashes, it won’t impact VM2.

The GPU in BB-AI64 is the PowerVR 8XE GE8430 which is listed as having 8x virtualization ability.

Here is a video showing vGPU virtualization with PowerVR 8x series. In this example we see 2 different VMs sharing the PowerVR GPU and dynamically adjusting FPS rates between the two running applications, finally when one of the GPUs crashes, the other remains unaffected.

Lastly the TI Training Video makes mention of the DSS being able to be virtualized 4x. This implies that you could have 4 VMs each being assigned its own Display (DSS) channel and eGPU slice!

Presumably the linux kernel in BB-AI64 is compiled with needed virt features? I haven’t been able to test this specifically but initial test seems like they are compiled into kernel.


Best thing for this gpu is that upstream mesa supports it directly. (In theory pcie could also be used to connect external gpu since this chip seems has pcie cache coherency)

this gpu is that upstream mesa supports it directly…

Good call…it appears was included in 22.1 per this article:

The current install has 22.3, I assume its using vulkan?

the kernel GPU interface bits are still being developed, and have not been pushed to yet.


1 Like

Just be aware that the video shown is using the PowerVR 8XT which is a different architecture and huge improvement over the 8XE featured on the AI-64.

Is powering the AI-64 from the 5v pin header supported?

I received my BBAI-64 on 11/10/2022. I wrestled with either buying the LattePanda 3 Delta or the BBAI-64 for a week or so before I made my final decision.

The BBAI-64 ‘as-is’, is a uniquely well suited platform for video streaming, motion estimation, FRS detection and AI Edge processing duties among others. And Debian 11 has proven itself to be a great choice.

But the TDA4VM it is too opaque. Not too difficult to use or to design with, but too much of a black box. It requires a level of expertise that I think is gratuitous and self serving.

And I wonder why it was chosen?

I am definitely going to use the BBAI-64 ‘as-is’, but it shouldn’t have taken 3 months to compile enough information about the TDA4VM (including experimentation) to see how to use it properly.

Conspiracy Theory
With the right sensors it would excel in VLF, ULF and ELF torpedo guidance as well as a motion / vision detection smart bomb chip. Perhaps this is why the PRU is not openly supported.