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.
DMSC Wakes Up (which itself is a Cortex M3) and resets/boots the R5 in MCU Domain.
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)
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:
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. 
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.
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.
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.