I get that including and keeping-active the PRU_ICSSG will be something we can expect TI to continue to do for the TDA4VM. However part of supporting a peripheral isn’t simply making it available. It’s also guaranteeing that every unit off the production line has been tested and that all supported functions and peripherals behave as advertised.
This testing takes time, so it’s no surprise when a peripheral isn’t claimed or supported, it isn’t going to be tested either.
Take the fictional “FOOtara” FU335x series microprocessors. Lets say the FU3352 doesn’t claim all peripherals and doesn’t “support” higher processor speeds that are supported on other offerings in the FOOtara line.
So even if the silicon being sold as a FU3352 has every component a FU3358 has, its production line testing won’t be as extensive making its cost-to-manufacture cheaper.
Likewise units that were intended to be FU3358s but couldn’t perform fully but passed all FU3352 tests can thus be marked and sold as FU3352s.
Once tape-out and manufacture of the controllers has matured, there’s a good chance that all FOOTARA controllers are made exactly the same, with the only difference being marking and production-line testing. Thus DIYers could buy FU3352s and safely use them as FU3358s for a bargain price with the understanding that they are playing the silicon lottery and hoping that all units actually perform as FU3358s OR the onus will be on them to write and perform those tests and manually throw-out failures.
My point is, is the Beagleboard organization not taking the same risk here with the PRU_ICSSG on the TDA4VM?
Even if the PRU_ICSSGs are present and kept active by TI, if TI isn’t verifying their functionality on every chip they sell, there’s a chance PRU-logic would run fine on one BBAI-64 but fail (intermittently or regularly) on another BBAI-64 and it not be clear/obvious that the issue is a hardware problem, not a developer/logic problem. That seems like the ingredients of firmware developer nightmares.
It almost begs the question if TI was experiencing issues during production-testing of the TDA4VM’s PRUs and instead of fixing the problem, they just decided to drop support for the PRU_ICSSGs and wash their hands of it.
Am I being overly paranoid? Or is this a fair argument?