did we change /proc/device-tree/compatible?

Stephane Charette

unread,

Oct 9, 2017, 3:39:34 PM10/9/17

to BeagleBoard

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

Robert Nelson

unread,

Oct 9, 2017, 3:50:52 PM10/9/17

to Beagle Board, Stephane Charette

Please run:

sudo /opt/scripts/tools/version.sh

as something didn't get assembled right...

Regards,

--
Robert Nelson
https://rcn-ee.com/

Stéphane Charette

unread,

Oct 9, 2017, 6:39:06 PM10/9/17

to Robert Nelson, Beagle Board

> 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

Stéphane Charette

unread,

Oct 9, 2017, 6:41:53 PM10/9/17

to Beagle Board

On Mon, Oct 9, 2017 at 12:39 PM, Stephane Charette <stephane...@gmail.com> wrote:

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

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

Robert Nelson

unread,

Oct 9, 2017, 9:18:19 PM10/9/17

to Beagle Board, Stephane Charette

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? ;)

Stéphane Charette

unread,

Oct 9, 2017, 9:25:05 PM10/9/17

to Robert Nelson, Beagle Board

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

Stéphane Charette

unread,

Oct 9, 2017, 9:27:53 PM10/9/17

to Robert Nelson, Beagle Board

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

Robert Nelson

unread,

Oct 9, 2017, 9:31:23 PM10/9/17

to Stéphane Charette, Beagle Board

On Mon, Oct 9, 2017 at 8:24 PM, Stéphane Charette
<stephane...@gmail.com> wrote:
>> 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...

Robert Nelson

unread,

Oct 9, 2017, 9:32:33 PM10/9/17

to Stéphane Charette, Beagle Board

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

Reply all

Reply to author

Forward