In the past, I used to identify the type of device by reading the file /proc/device-tree/compatible. For example, see this:
hexdump -C /proc/device-tree/compatible
00000000 74 69 2c 61 6d 33 33 35 78 2d 62 6f 6e 65 2d 67 |ti,am335x-bone-g|
00000010 72 65 65 6e 00 74 69 2c 61 6d 33 33 35 78 2d 62 |reen.ti,am335x-b|
00000020 6f 6e 65 2d 62 6c 61 63 6b 00 74 69 2c 61 6d 33 |one-black.ti,am3|
00000030 33 35 78 2d 62 6f 6e 65 00 74 69 2c 61 6d 33 33 |35x-bone.ti,am33|
00000040 78 78 00 |xx. |
Last night I upgraded to a new build. I installed this one:
https://rcn-ee.com/rootfs/bb.org/testing/2017-10-08/stretch-iot/BBB-blank-debian-9.2-iot-armhf-2017-10-08-4gb.img.xz
Now I see that same model no longer identifies itself as a BBG. it now thinks it is a BBB:
hexdump -C /proc/device-tree/compatible
00000000 74 69 2c 61 6d 33 33 35 78 2d 62 6f 6e 65 2d 62 |ti,am335x-bone-b|
00000010 6c 61 63 6b 00 74 69 2c 61 6d 33 33 35 78 2d 62 |lack.ti,am335x-b|
00000020 6f 6e 65 00 74 69 2c 61 6d 33 33 78 78 00 |one.ti,am33xx.|
0000002e
Did I install the wrong build? Is this a bug, or is there a new/better way for me to identify the difference between BBB, BBG, BBGW, etc?
Stéphane
Please run:
sudo /opt/scripts/tools/version.sh
as something didn't get assembled right...
Regards,
> Did I install the wrong build? Is this a bug, or is there a new/better
way
> for me to identify the difference between BBB, BBG, BBGW, etc?
Please run:
sudo /opt/scripts/tools/version.sh
as something didn't get assembled right...
Was that supposed to fix it, or do you just want to see the output? This
is the output:
sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[9e4538c8313aae2d2ff50b07ec5e0ee7685a840c]
eeprom:[A335BNLT BBG115080190]
dogtag:[BeagleBoard.org Debian Image 2017-10-08]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
2017.09-00003-g11d92ba68a]
kernel:[4.4.90-ti-r132]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20171005.0-0rcnee1~stretch+20171005]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
Stéphane
I should also have mentioned: I have not upgraded or installed new builds
since...early 2017? This is my first time back working with my beaglebones
in probably 8 months. So this change in behaviour may actually have been
quite a while ago.
Stéphane
Ugh, so it's not a bug, it's just the way the final *.dtb is generated
with u-boot overlays: (we build up from one dtb..)
So if we assume the BeagleBone Green = BeagleBone Black (minus) HDMI
(audio/video)...
BeagleBone Green:
Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
BeagleBone Black:
Model: SeeedStudio BeagleBone Green:
uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...
uboot_overlays: Switching too: dtb=am335x-boneblack-uboot.dtb ...
loading /boot/dtbs/4.9.53-ti-r67/am335x-boneblack-uboot.dtb ...
55752 bytes read in 170 ms (319.3 KiB/s)
uboot_overlays: [fdt_buffer=0x60000] ...
uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
1105 bytes read in 871 ms (1000 Bytes/s)
uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo ...
695 bytes read in 830 ms (0 Bytes/s)
[ 0.000000] OF: fdt:Machine model: TI AM335x BeagleBone Black
BeagleBone Black:
Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
BeagleBone Black:
Model: BeagleBoard.org BeagleBone Black:
uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...
uboot_overlays: Switching too: dtb=am335x-boneblack-uboot.dtb ...
loading /boot/dtbs/4.9.53-ti-r67/am335x-boneblack-uboot.dtb ...
55752 bytes read in 69 ms (789.1 KiB/s)
uboot_overlays: [fdt_buffer=0x60000] ...
uboot_overlays: loading /lib/firmware/OSD3358-00A0.dtbo ...
441 bytes read in 1234 ms (0 Bytes/s)
uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
1105 bytes read in 160 ms (5.9 KiB/s)
uboot_overlays: loading /lib/firmware/BB-HDMI-TDA998x-00A0.dtbo ...
4169 bytes read in 877 ms (3.9 KiB/s)
uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo ...
695 bytes read in 175 ms (2.9 KiB/s)
[ 0.000000] OF: fdt:Machine model: TI AM335x BeagleBone Black
So you can see how both boards start out as
"am335x-boneblack-uboot.dtb" and we add, eMMC/HDMI/WL1835/ADC..
I guess we could patch in the model/compatble...
BBBW:
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BBBW-WL1835-00A0.dts#L32-L33
BBGW:
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BBGW-WL1835-00A0.dts#L41-L42
Is it really worth it thou? 
Regards,
Is it really worth it thou? 
Sorry, Robert, you lost me, I'm not familiar with the things you're
pointing out. From an end-user perspective, all I need to know is how can
I determine what type of board my code is running? I used to look at
/proc/device-tree/compatible but that no longer works. Is there a
different or better file I should be reading to determine if I'm on a BBG,
BBB, BBGW, etc?
Stéphane
So if we assume the BeagleBone Green = BeagleBone Black (minus) HDMI
(audio/video)...
...and the addition of the two GROVE ports. Not sure if that's important,
but in my case the software behaves differently and initializes different
things if running on a BBG since we expect certain devices to be hooked up
to the GROVE ports.
Stéphane
Is it really worth it thou?
Sorry, Robert, you lost me, I'm not familiar with the things you're pointing
out. From an end-user perspective, all I need to know is how can I
determine what type of board my code is running?
Well today:
sudo /opt/scripts/tools/version.sh | grep eeprom
I used to look at
/proc/device-tree/compatible but that no longer works. Is there a different
or better file I should be reading to determine if I'm on a BBG, BBB, BBGW,
etc?
No, i just need to write a fixup pass in u-boot so those two strings
are the correct value for the BBG...
Regards,
...and the addition of the two GROVE ports. Not sure if that's important,
but in my case the software behaves differently and initializes different
things if running on a BBG since we expect certain devices to be hooked up
to the GROVE ports.
The i2c port is always active, the usart port just needs a (config-pin
<> uart ; config-pin <> uart) (dont' know the pin number off the top
of my head..)
Regards,