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

56 views
Skip to first unread message

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:


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:


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
0 new messages