BeagleBone AI-64 - lost in information

Hello! I’ve been using and developing on Raspberry Pi since the beginning in 2012. I use the original Debian based OS, I also build Yocto images for it, and there was a time when I built an OS with Buildroot. Although I am not a professional I have some experience with Embedded Linux.
I bought a BeagleBone AI-64 and although I am impressed with the hardware, I am completely lost in the software field.
I have read through the Getting Started Manual and have successfully installed it. However, I refuse to believe that I have to program on the SBC itself.
Is there an official Yocto build, cross toolchain? How can I develop software for it on PC?
Unfortunately for me, BeagleBoard is completely unknown and I approach the question in the classic embedded linux way: develop on PC with cross toolchain and sysroot, then deploy to target system.

My other big problem is that sometimes appears in an “interesting” way. It’s like it randomly switches between two different sites. I attached the screenshots…

Sorry for the long post, I really need some guidance! Thanks in advance!

1 Like

If all you are wanting to do is write and deploy scripts or programs (Java/C/C++/Python) to the board, then this shouldn’t be too much different than any other Linux platform you might’ve worked with. You may need to install some additional assistance tools to make quality-of-life aids like WinSCP work to make the transfer easier, but no, you do not need to program ON the target. There are most definitely cross-compilers for Windows and Linux to program for ARM.

And because the chip is a TI chip, you can install Code Composer Studio and program the chip with that IDE. But I have to admit, the learning curve for CCS is steep if you have no prior experience with Eclipse. So as useful as it is and as much as I recommend serious development plan to use it, I can’t recommend it to people just looking to throw a program together to do something rather small. Thus if what you are doing is super-simple, often it’s easier to just develop on the target rather than figure out all the details necessary to make a transfer possible.

But to your point of information scatter and overload, I’m a firmware developer, and I have NOT been impressed with the cohesiveness of the documentation or ease of finding what documents are relevant to the target…and a huge part of that is TI. It’s my understanding they did a bit of a bait-n-switch on the BB community. They gave a prototype chip with all the various features needed by the BB engineer(s), then released a product that does NOT claim to have all those features, has no documentation about those features, but they do actually seem to exist (i.e. PRUs & Power Modes)…which is exactly what I wanted to use. My experience with other vendors is if they claim support for a chip feature, they also have some example code that exercises that feature. TI doesn’t seem to have a lot of “supporting” code for this chip…at least not that I’ve been able to find. The handling of this product has been very much “Here, we made this quite-capable hardware, now yall (the Community) figure out what to do with it. Our job is done here.”

And I say that because it seems as though their e2e forum wants NOTHING to do with questions related to the BBAI64. They view BB questions as an annoyance and something they don’t want to deal with. I’ve been told on the e2e that questions about the BB should be put over here, not over there. What they fail to recognize is just how many developers (aka professional influencers) there are using BBs. Treating BB enthusiasts as 2nd class citizens in the TI community is not doing themselves any favors…IMO. This recent experience with TI has made me seriously decide to encourage the company I work for to NOT use TI for future projects. Unless they just happen to have a silver-bullet-of-a-product when we plan our next generation hardware, I don’t expect to use them again.

Thank you for your response and advice, it was enlightening for me.
In particular, your comments on documentation were useful because they confirmed what I had experienced. At least now I am not only looking for fault within myself, why despite the wealth of information I have, a lot of details are not clear to me.
I am sorry to read your opinion about TI’s attitude. It makes me feel a bit cheated too, because I too started to get interested in the card because of the Cortex-R5F cores and DSPs.
I do firmware development myself, using mainly STM32 microcontrollers. They have documentation problems (as all chip vendors do), and the community support from STMicroelectronics is not very strong. Nevertheless, I think overall STM provides decent documentation and good development tools for development.
Eclipse is not far from my mind. Although I never liked it, for STM32 it is still the most convenient for me. Or cmake and any IDE… :slight_smile: And for debugging there are the Segger tools.
I was a bit naive about the BB AI-64… Although maybe I’m just approaching it all wrong: I shouldn’t be looking for information and support for C/C++ development from BeagleBoard / BeagleBone, but from TI. Although here then it’s the attitude you mentioned that made the whole thing fail.

Fortunately if all you are interested in are the Cortex R5Fs and maybe the A72s, there’s knowledge right here on them. And they are pretty well documented since those are aspects of the TDA4VM that TI does claim support for.

Now finding the documentation you need, start making searches (both on TI website and Google) for not only the TDA4VM but the J721E (the prototype/superset part number the TDA4VM is based on). A LOT of the documentation for the TDA4VM is classified under its predecessor part number. So just knowing that, alone, will get you a lot more info than you are probably finding right now.

Hey All,

@ptihanyi for the site looking different… it’s because sometimes your browser/DNS resolver is adding www. prefix without telling you, doing so takes you to the “new” site that is much nicer graphically but still has some content migration to undergo (as far as I know).

Now for the meat and potatoes that @Chris_Grey describes I understand a lot of the frustrations there, and a lot of it are things that are actively being addressed in one way or another, or at least I’d like to think so.

What I’m curious about is what IP (besides PRU and Power Modes that is well noted) or pieces of documentation you find lacking? What are you trying to do with the device that you’d want to see examples for? These would all be good data points for me to go and try to ask for internally if they’re not already in progress.

What I will say is that on E2E you are able to ask processor specific questions or things that pertain to TI provided tools, so if you have SDK, Yocto, CCS or IP Specific Questions then those are perfectly valid and should be answered by an engineer on E2E. That being said, if you ask “Debian has x. broken”, that’s more a question for Robert or Jason on the forum here since they are the ones that maintain that aspect.

I would also encourage you to join the Discord because it’s a healthy mix of regular users, the beagle maintainers and some TI folks (like myself) who are putting in our own time to try and improve things and answer questions where we can.

Ideally, things that get answered there will make their way into Beagle Documentation…

Most of what I’m referring to as scattered info relates to the lack of documentation for the PRUs. Even what is documented, there are some very technical details that are missing from the documents like latency numbers, exactly what speeds are supported, and how to adjust those speeds from default to something faster (or slower).

What I have found and learned is scattered amongst the following:

  • The 5 J721E register PDFs
  • PRU Read Latencies (sprace8a) - doesn’t cover J721E/TDA4VM
  • PRU_ICSSG Getting Started Guide (sprace9a)
  • PRU Assembly Language Tools (spruhv6c)
  • PRU C/C++ Compiler Users Guide (spruhv7c)
  • PRU Assembly (spruij2)
  • J721E TRM (spruil1c)
  • J721E Programmable Real-Time Unit (spruj61)
  • SysConfig (PinMuxing Tool)

Most of these are documents I had to either find linked in other threads or stumble across while Google searching. There was no single place for me to find ALL of these together since they all relate to the the TDA4VM in some manner (either directly or peripherally). And these are only documents I found for peripherals I cared about. I wouldn’t be surprised if there are more documents that touch on the Cortex R5Fs, C66xx/C7x, and PowerVR GPU that aren’t mentioned here.

The mere fact I have to know about the J721E to find info about the TDA4VM is somewhat annoying.

Then add that there seems to be some explicit blocking of search results on the TI website. Some of these documents I could only find & download because Google was able to give me links to them. How it was able to get them, I have no clue. Even when I KNEW the document’s name verbatim because I was reading it, a search on the TI website came up empty. But a Google search for the same thing found a link on the TI website that took me right to the download page I got the document from. Why would that be? Either the search engine the TI website is using sucks OR TI is, for some reason, actively suppressing search results.

Other code I’d like to see examples for are the Machine Learning stuff. So far, all I can find is the Youtube video and example code that basically use the already-compiled Machine Learning logic TI supplies to be used with the C7x/C66xx. But the source & development getting-started documents are more what I’d be interested in if I were interested in that aspect of the BBAI64 (I’m not). For example, I’d want to program the ability to recognize things that are not generic like a book or a coffee cup. I’m sure that is not a trivial task, and I suspect there’s a LOT to know about how to do stuff like differentiate between a spool of thread and a spool of solder. But THAT, I think, is what developers interested in this technology want to get their hands into. I could see this being extremely useful for automated drones to orient themselves for certain tasks within a known geographic area.

What is supplied is certainly an interesting starting point…a machine-learning Hello World! if you will. But I don’t think it is sufficient to deploy as-is for anything very useful. I never stumbled across any detailed documentation or youtube videos walking developers through developing for this technology and altering it for their own needs. Perhaps that’s just not practical or feasible to do with the technology at this point, I don’t know since I’m not a machine-learning developer and know very little about it.

1 Like

My situation is different from @Chris_Grey’s in that I’m not developing a product for TDA4VM, I’m just interested in it as a technical challenge, a technical hobby so to speak. Although who knows, if I manage to create something useful, maybe the device will be considered for the next company project.
Nevertheless, I experience the same frustration he describes about the availability of documentation.
Let me mention STMicro’s STM32MP1 MPU as a positive example in terms of documentation. Obviously, the STM32MP157 is not comparable to the TDA4VM: TI’s product is a light years more complex unit.
However, STMicro makes virtually all relevant information available in one place. Be it datasheet, application note, errata, SDK, example programs, extension packages, etc.
The same is true for evaluation boards.
I would have been looking for something similar for the TDA4VM- or BB AI-64.

A few more things that are particularly confusing to me as a “newbie” in the BeagleBone world:
When I read the documentation for the AI-64 on, I don’t see any specific examples of programming hardware and IPs. Not even a link to the relevant TI documents.
There is a “BOOKS” section where there are example programs, but they typically only refer to BB Black.
How should I know if the information I read there can be used for BB AI-64?
I actually bought a really impressive piece of hardware at a rather steep price that can run the pre-installed example programs. However, I am a skilled embedded linux developer and I have been programming ARM Cortex-M microcontrollers for many years if I spend most of my time trying to filter out useful information from the vast amount of irrelevant and half-truths.
However, I already know from the official documentation how to update packages on debian…

I really appreciate you guys taking the time to go into this much detail and I think I can speak a bit for both sides of the fence (from a personal level none of this is in any official capacity obviously)

But it’s all very valid. I can tell you from plenty of meetings that the search results being “hidden” is not intentional, just quirks with how the website works that need to be fixed… a lot of discoverability things like that in fact we’re trying to get right.

There’s frankly a challenge on both sides for documentation, both TI and Beagle… It’s hard to tailor to both new users and “experienced” users within different niches (Think Yocto developer vs someone with interest in ML stuff like Chris mentioned). A lot of it is also things just changing fast enough that it’s hard to keep documentation current enough as to be relevant and sometimes the people working to enable a feature are such “experts” in what they do that a lot of things seem trivial to them just by having done them 1000x of times, despite them being very much not obvious, you know how it goes, it’s not a problem unique to this. PRU documentation is probably the biggest “victim” of the latter. An updated PRU master doc and cookbook is something that I’m looking into getting prioritized in the near term.

Otherwise I’ve been trying to get some more projects and documentation out there based on what I’ve been messing around with for my own projects - HomeAssistant and Zigbee Integration are one example:

There’s OpenOCD support for controlling and debugging the M4 core with the A53 cores on Play for example that a colleague is working on as a side project of his.

I’m also trying to get more videos out there and we started the now by-weekly BeagleCast to discuss some of these topics outside of TI. Of course right now none of this fixes IP specific issues but the goal is to get some of the more advanced topics like developing EdgeAI apps beyond the demos, using the DSPs etc. It just takes a bit of time to get going, and of course I encourage anyone to both contribute and be critical of mistakes when they see them.

But excuses out of the way, thank you guys again for the feedback, I’ll do my best to make sure it doesn’t fall on deaf ears and I can tell you that the way I see it at least, both TI and Beagle are waking up from a bit of a slumber the past few years, so there’s definitely a lot of work to do, but there’s a lot of people both internally and out that are genuinely excited to make things with these boards and processors, and I’m happy I get to be part of that, so that’s something to look forward to, it’s always good to have enthusiasm behind projects.

This is actually kind of a good example of exactly what @Chris_Grey was mentioning with how to label data for video recognition, but again, same problem, it’s mentioning AM6x processors, not TDA4. Is it perfectly applicable? Yeah…

1 Like

@ptihanyi ,

Hello…about the “BOOKS” section and BBAI-64. In the docs, there is a section for BeagleBone cape interface spec — BeagleBoard Documentation that will provide help in this type of circumstance.


P.S. So, 3.3v logic mostly outside of the ADC and 5v pins for Cape Compatibility. But, the two Cortex-A72 processors will get anyone to the end quicker than if using the “BOOKS” section for the BBB or BBGW and so on w/ the am335x processor onboard.

I was thinking. Should I start to apply myself again or fade and just read? This is where I am at currently but the docs. are 100% better, in my sight, versus the older way of ideas that were sparse and unfounded.

That link highlights the differences that are known in the /dev/bone/* world and the other board motives are a mystery to me so far. I still know little about the PRUSS or in this case the PRUSSG. I think motive and momentum in this case are coming around to be a notion of positive behavior where we can all chip in. The git repo for located at may help people like you or I in developing w/ and around the processors available from this .org.

@ptihanyi ,

I got what you are saying now. Some images contain specific ideas while other images have other ideas.

So, like w/ me and my current image for the BBAI-64, /sys/class/leds/* does not have P9_16 like described in the docs pages.

So, let me work now to configure things. BBL!


P.S. I will try to give some insight and some ideas or I may have to update the image instead of just the kernel. Okay! Hello World in hardware ideas is a go!

I found this info. from the docs. for P9.14 w/ GPIOD in python3 for the BBAI-64. This may not be what you are describing but from what I can tell, this may prove valuable since it is really just:

Line 93
and then this source:

and then look for GPIOD in 02 # again it matters what versioning?



And then the odd video w/ some man’s voice! Mine!

Please excuse the odd talk. I hide in voice.


P.S. It was not easy on me w/ everything going on right now but LEDs! I think w/ the RT kernels, /sys/class/leds/* is not available right now for whatever reason.

As I read through the responses and rethink my own response, I want to be clear that my frustration is not, specifically, with information being scattered across so many documents. That’s just natural as documents cover more specific topics that may be generic to lots of platforms (i.e. PRU programming). And I don’t mind sifting through lots of different documents to get additional/updated information. That’s kind of the job and that’s OK when I know the document exists and it’s on me to sift through the mountain of info to find exactly what I’m looking for.

It’s another issue completely when I see from a forum post that a document exists; I even have the name of the document, but I can’t find it on the site that I expect to find it on.

It’s even worse to be new to a platform and have no clue there is additional documentation available that could help me, if I just knew it existed.

I know a big part of web design is to not overwhelm people with too much information. But as an engineer/developer, I’d rather be given all relevant info and allowed to figure out for myself what’s useful and what isn’t. Now where the web designers can help is to organize the data such that the most relevant info is higher in the page, or organized into logical tabs that put the most relevant info in more-left-located tabs and less relevant links deeper in the tab list. But don’t hide the info from me. That’s all I ask.

What would be even more useful is to have documents, like the TRMs, make reference to all these other documents (by name or preferably by link) where applicable. The easiest topic for me to again reference is PRUs, so in the section that talks about the PRU subsystem, let the reader know there are additional resources for the PRU (performance docs, compilers, assemblers, inter-process com technique documents, example code, etc). But even things like UARTs that are configured via registers, if there is more info in the Registers doc, refer off to which doc has that info for more reading. Although if the registers are relevant to operating the UART, I’d rather have that in the TRM, even if it makes the TRM 10,000+ pages. That’s hardly a concern today where everything is digital, and nothing actually printed anymore.

I know there are Technical Document authoring solutions that can help with this. One that comes to mind is AuthorIt. It’s not cheap, but it does let you make topics their own entity (e.g. PRU_ICSS or PRU_ICSSG documentation), and then link those topics into NUMEROUS other documents that all need that info. Then if you ever update/add to that topic, you can automatically reversion & republish all documents that contain that info. I assume TI is using documentation technologies like this. But I’m wondering how effectively they are being utilized. I suspect there are no automated procedures in place to republish updated documents, whether the trigger be when a single topic gets updated or just once a year. I have no problem with keeping my PDFs up to date as long as they are clearly versioned so I can see that I have version 12, but version 18 is now available.

It is also nice to be able to get previous revisions. It’s not something that is used regularly, but sometimes in the process of editing or refactoring documentation, things get removed/relocated…and sometimes those removals are not an overall improvement for SOME documents (but were necessary for others), so being able to get previous versions of a given document is often valuable. Unfortunately, this does require quite a bit of storage space and while this is nice, I get that the cost/benefit ratio often isn’t in favor of doing this. And dynamically re-generating previous revisions from the documentation database, on demand, is also not easy to do or to make secure. But I thought I’d mention it.

It is good to know that there is recognition of these issues and a desire within TI to correct these issues. I also understand that these more modern chips are orders of magnitude more complicated than the chips of the past (e.g. 8096) and their documentation. So it is, somewhat, unfair to compare the documentation for these products to those much simpler offerings. A single Cortex R5F within the TDA4VM is more complicated and requires more documentation than the original 8096. So complicate that by having multiple groups of them, along side multiple A72s, multiple PRU subsystems, and all the other peripherals, the documentation and organization necessary grows exponentially. Then add that this is not the only product TI sells and documents, and the documentation management is absolutely astronomical. I can appreciate this challenge. And I’m quite aware that these challenges will exist for any vendor.

Sorry for the wall of text…

Haha no worries on the “wall of text”, it’s all very good feedback.

There is the internal system that allows for topic reuse across documents, and it’s something that is being used more and more, but like you mentioned, it’s a bit of a titanic effort with a lot of content having to be moved from legacy sources, updated, cleaned up etc. and when you add in processor, IP versions etc. you can imagine they balloon up in size. A document like Datasheet and TRM being 10K+ pages for a single processor is just part of the story of course, you also have to ensure all the data is accurate and a lot of it needs to be bench characterized across PVT, so simple parameters in these end up taking quite a bit of effort to generate and get reviewed etc.

But yes, there is definitely a large scale effort to constantly improve documentation and searchability, a lot of it is in place, a lot of it is an ongoing task but I think there’s an overall positive outlook from my point of view.