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 version.sh script…

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

Regards,

git:/opt/scripts/:[a335abcf87d2ef5fd96e7de83cdf3f0ff5a4da2b]
]eprom:[A335BNLTBBG179Q
model:[TI_AM335x_BeagleBone_Green]
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:[BB-ADC-00A0.bb.org-overlays]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0.bb.org-overlays]
UBOOT: Loaded Overlay:[M-BB-BBG-00A0.bb.org-overlays]
kernel:[4.19.94-ti-rt-r57]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.14.20210821.0-0~buster+20210821]
pkg:[bb-customizations]:[1.20211215.2-0~buster+20220102]
pkg:[bb-usb-gadgets]:[1.20220106.0-0~buster+20220106]
pkg:[bb-wl18xx-firmware]:[1.20211222.2-0~buster+20211222]
pkg:[kmod]:[26-1]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
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
END

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

Regards,

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…)

Regards,

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