This leaves a lot of questions for me. TI is working on a more formal response that better summarizes our/their position. There are a number of mitigations, but I think more analysis should be performed to determine the confidence-level they provide. GKH has some thoughtful blog material, but also stops short of being conclusive. I've heard some question if VFP or NEON provide additional attack vectors.
Fundamentally, I think those of us making embedded systems need to be conscientious of what untrusted code we allow to run on our systems and that there are likely more interesting attack vectors, depending on how we secure our systems.
For example, do you disable ssh and evaluate the security of other network-based servers on the system? I just mean that Meltdown and Spectre attacks assume some ability to run userspace code on your system and you should probably already be preventing that. IoT worms/trojans and/or web server overflow bugs are more likely to be a security issue in an embedded system.
In yet more other words, security requirements should be considered at a system-design level and a one-size-fits all solution of chasing down the latest issues facing desktop systems isn't likely to address your security needs.
Hope this didn't come across as deflective or rude, as I do think a good analysis of the BeagleBone/BeagleBoard risks related to Meltdown/Spectre are necessary. I just don't think the analysis or the mitigations are ready to declare at this time.
The ARM recommended mitigations look a bit complex at this point, but are worth examining if you have concerns about the information that can be recovered using these attack methods and your system is exposed to them.