Beaglebone Black looks like a Beaglebone Green in /proc/device-tree/model

I have what appears to be a Beaglebone Black, but upon boot a cat /proc/device-tree/model informs me that it’s a TI AM335x BeagleBone Green. How could this be happening? Is there a way to fix it? Could this actually be a Beaglebone Green, but looks like a Beaglebone Black?

I’ve never used a Beaglebone Green so I don’t know the differences between it and the Black. If I do nothing and treat it like a Beaglebone Black, are there any side effects that this could lead to?

Any info is appreciated, thanks!

Hi @pocketnc_john please run the script…

i wonder what eeprom value the device has been programed with…


dogtag:[Pocket NC Debian Buster Image 2022-01-12]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 2019.04-g923f8b8 (Jan 02 2022 - 19:05:15 +0000)]:[location: dd MBR]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-g923f8b8]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 2019.04-g923f8b8 (Jan 02 2022 - 19:05:15 +0000)]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-g923f8b8]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-UIO-00A0]
UBOOT: Loaded Overlay:[]
UBOOT: Loaded Overlay:[]
UBOOT: Loaded Overlay:[]
/boot/uEnv.txt Settings:
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
cmdline:[console=ttyS0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet ostree=/ostree/boot.0/kinetic/e20588e5f33b72d1d8a20a562ce8549bbe55d8a032c5eb317cb85394f72a472f/0]
dmesg | grep remote
[   59.596844] remoteproc remoteproc0: wkup_m3 is available
[   60.204283] remoteproc remoteproc0: powering up wkup_m3
[   60.204310] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
[   60.204600] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[    1.306652] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[    1.325874] gpio-of-helper ocp:cape-universal: ready

Ah, yeah, these escaped GHI a few years ago…

GND TP4 (between Ethernet and barrel plug) then run this “one” command as root:

dd if=/opt/scripts/device/bone/bbb-eeprom.dump of=/sys/devices/platform/ocp/44e0b000.i2c/i2c-0/0-0050/eeprom


Thanks Robert! That fixed it.

This particular board was returned by a customer as we couldn’t figure out why we couldn’t upgrade our software on it. We were simply making a decision based on the board being a Black or an AI. Since it was a green, it didn’t know what to do. It would be easy enough to add a special case for a Green. My guess is there will be others in the field with this issue and I’m thinking about what the best course of action is for users that encounter this issue. I imagine it would be a bit of a hassle to ask the user to ground TP4. It seems like our older software ran fine with it configured as a green. Can you think of any issues that may arise from simply letting the eeprom stay as a green?

As long as you don’t use the HDMI output in your application… This eeprom mis-programming would not affect your end unit… Green is just a Black with no hdmi (and no 5v barrel jack…)


Perfect, that’s what I was hoping you’d say! Thanks Robert!