So as some are find out; BeagleBone Rev D, are now ending up in users hands.
Why/What happened: BeagleBoard.org finally ran out of NXP TDA19988 PCN Last time buy: July 30, 2022 (so we made it 3 years)
Ignoring HDMI, Rev D should ‘boot’ with old images as a “Rev C” but HDMI will fail (i2c errors). For HDMI output, “Rev D” uses and ITE 66122 building on the ite-it66121.c driver. To date I’ve backported this to a few older kernels, but not everything due to sure age of some of my builds.
I probably missed a bunch, please reply with broken kernel and issues so we can fix them for other users..
Upgrades: 16GB eMMC
Never used HDMI and had disable_uboot_overlay_video=1 set in /boot/uEnv.txt your fine!
Known Drivers:
v6.0.x thru (mainline) we have Making sure you're not a bot!
v4.4.x-ti : custom Seeed Driver: ti-linux-kernel-dev/patches/drivers/it66121/0001-gpu-drm-i2c-suppot-it66121-hdmi-chip.patch at ti-linux-4.4.y · RobertCNelson/ti-linux-kernel-dev · GitHub (needs to be patched for it66122 id and it was hard-coded to one resoution..) BeagleBone® Green HDMI Cape | Seeed Studio Wiki
Regards,
You forgot to mention the bestest thing! It’s got 16GB eMMC!
1 Like
True that is the best part!
OK… This is not good!
My company has been using the Rev C boards forever. We are using an old image with the 3.8.13-bone80 kernel and have an app the uses HDMI. We have a couple thousand systems in the field and sell 30+ systems a month.
I have tried a number of times to upgrade to a newer image/kernel but have issues with the PRU.
Is there any possibility of getting the Rev D boards to work with that kernel?
Yup, using Debian 7.11.
$ cat /etc/dogtag
BeagleBoard.org Debian Image 2016-06-15
$ cat /etc/debian_version
7.11
$ uname -a
Linux ******* 3.8.13-bone80 #1 SMP Wed Jun 15 17:03:55 UTC 2016 armv7l GNU/Linux
My application also uses SDL1.2 and runs from the command line. SDL1.2 is another reason I use that old image. SDL2 or 3 are not an option since they removed the fbcon support and only work with a GUI environment.
Oh, I checked this morning and we actually use about 100 BeagleBone Black Rev C boards each month.
Any idea where I can get a Rev D board for testing?
Sounds like Mouser has started shipping Rev.D’s, so that’s a place to start.
But you can pick up the Phone and call your friendly CSR.
I’m sure they’ll be happy to answer any questions you might have. 
@bigguiness - just jumping on-board here with you, our company is in exactly the same place: using about 30+ of these a month, using an older kernel (because it was still working great and it’s harder to make a kernel change than a simple update)… and this new Rev D started showing up in our stock without warning and completely halted our line of devices.
We’re currently scrambling to get a newer kernel up and running and trying to update all of our software to adapt… but it’s been all-hands-on-deck for about three days now. It didn’t help that Digikey and Newark both insisted that they were only stocking/shipping Rev C… even when we had a handful of 30 Rev D’s shipped directly from them. We couldn’t request an older revision since they wouldn’t admit there WAS an older revision until today (August 21, 2025).
Yeap, right now Mouser has just Rev D’s.
At work, we have mixed inventory, so they are re-sorting so the old rev C’s go out first.. But we already started shipping D’s to user this week..
Regards,
I knew it, Debian 7, i’m working on Docker based armhf so we can try to recompile it..
Yeap, left hand doesn’t know what the right hand was doing!
We got the first technical call from customers yesterday, after which we started checking the inventory, and it’s mixed, now sorting pre June 2025 production dates.
I do not have any clue on pre (c) and post (d) numbers at this point.
Regards,
I’m still working on getting you some decent “Debian 7.x” Docker based build hosts.. but i found a fun an old patch for v4.4.x-ti when Seeed released and “HDMI” cape for the Green… It has other problems, (hardcoded frequency), but i think it’s the best bet for v3.8.x: ti-linux-kernel-dev/patches/drivers/it66121/0001-gpu-drm-i2c-suppot-it66121-hdmi-chip.patch at ti-linux-4.4.y · RobertCNelson/ti-linux-kernel-dev · GitHub
Regards,
Well… Mouser is useless…
Just called them and everything they have in their system shows Rev C.
I didn’t think there front line techs know!
I had one backorder with them on the bbb last month and it was rev c… I have another backorder on bbb industrial which should be a rev d when they get it.
I’m still waiting for our downstairs to give me a heads up.
Regards
That is a little disconcerting, I’ll give you that much.
and?
What if we aren’t using HDMI, but that line isn’t set? AKA #disable_uboot_overlay_video=1 or disable_uboot_overlay_video=0
Will it just log a i2c error? If so, does it print it a couple times and then stop? Or does it flood the logs nonstop(and then possibly waste lots of cpu cycles?) and burn out the eMMC?
EDIT:
I see no indication of flooding of logs/wasting cpu cycles/etc. I just see it print out some errors once at boot. Whether you have an HDMI cable plugged in or not doesn’t change anything. Aside from not displaying an image…
#disable_uboot_overlay_video=1 results in logs printed at boot(see attached image)
disable_uboot_overlay_video=1 or disable_uboot_overlay_video=0 results in no logs printed. You would think disable_uboot_overlay_video=0 would be equivalent to #disable_uboot_overlay_video=1 but it’s not, which tells me the number doesn’t mean anything.
If you have a display plugged in like a GEN4-4DCAPE-43CT-CLB – 4D Systems that automatically loads the BB-BONE-4D4C-01-00A1 overlay, then the errors don’t print no matter what. Seems to block the TDA driver from loading.
So if you don’t use the HDMI port, you shouldn’t expect any problems, irrespective of the disable_uboot_overlay_video flag in uEnv.txt
Tested in 5.10.145-ti-r55…
I think the one best positioned to answer those questions, is you.
It stands to reason that even though you might not ever have used it,
the overlay still gets loaded, which in turn makes the kernel load the TDA driver.
How much noise that makes is anyone’s guess.
Just an observation on this thread in general:
While I can sympathize with you to some extent,
I would very much like the tone move away from “the sky is falling”.
Could you have been notified earlier? Yes.
but we should also keep in mind that:
Not even the best laid plans survive contact with the enemy.
This is just one of those instances, where reality overtakes the plan.
So, with that in mind, I hope you all have a pleasant afternoon.
