How Can Application Software Best Differentiate Which Beagle Device Its Running On?

Hi,

Our software team is developing a C# application which runs over mono-runtime on both the BeagleBone Black and our custom board which is based off of the BeagleBoard-X15.

They’d like to make one software build which can detect whether its running on a BeagleBoard-X15 vs. BeagleBone Black in order to swap out/switch configuration options (e.g. BeagleBoard-X15 has 2 Ethernet ports, whereas BBB just has 1).

What are some “lasting ways” for application software to detect whether its running on BBB vs BB-X15 or even BeagleBone vs. BeagleBoard?

When I told them about reading the EEPROM board ID in /opt/scripts/device …/ show-eeprom.sh, they were worried about having to track a whole set of BOARDID’s over time in order to detect the device the application software is running on.

Are there any other more permanent means (maybe independent of hardware changes to the BBB device) application software can use so that it always reads BBB vs BB-X15?

Thanks!

Jeff

Hi Jeff,

All BBB's start out:

aa 55 33 ee 41 33 33 35

The x15's start the same 4, then go differently..

aa 55 33 ee

Regards,

Thanks Robert!!

Some follow up questions:

debian@beaglebone:/$ sudo ./opt/scripts/device/bone/tester/show-eeprom.sh

eeprom raw: [00000000 aa 55 33 ee 41 33 33 35 42 4e 4c 54 30 30 43 30 |.U3.A335BNLT00C0|]

debian@BeagleBoard-X15:~$ sudo /opt/scripts/device/x15/show-eeprom.sh

eeprom raw: [00000000 aa 55 33 ee 41 4d 35 37 32 50 4d 5f 41 2e 33 41 |.U3.AM572PM_A.3A|]

  1. Will the Board Name ASCII string always be the same unique identifier on all BBB devices and on all BB-X15 devices regardless of changes in hardware on those boards (e.g. eMMC, AM335X vs AM335Y, AM5728X vs AMAM5728Y)?

  2. Will only the 4 byte, Version string change from hardware revision to hardware revision on the BBB?

  3. Can we rely on uname -n always returning the same answer on BBB vs BB-X15 image, regardless of the image version for all time? This seems like an easy solution to the problem the software team is trying to solve. However, if the answer changes in the slightest with future kernel upgrades, then the platform detection scheme will break.

debian@beaglebone:/$ uname -n
beaglebone

debian@BeagleBoard-X15:~$ uname -n
BeagleBoard-X15

  1. Can we manipulate what uname returns by hacking, for instance, UTS_NODENAME or is that a bad practice? If so, is there a better place to do this?

Thanks!

Thanks Robert!!

Some follow up questions:

debian@beaglebone:/$ sudo ./opt/scripts/device/bone/tester/show-eeprom.sh
eeprom raw: [00000000 aa 55 33 ee 41 33 33 35 42 4e 4c 54 30 30 43 30
>.U3.A335BNLT00C0|]

debian@BeagleBoard-X15:~$ sudo /opt/scripts/device/x15/show-eeprom.sh
eeprom raw: [00000000 aa 55 33 ee 41 4d 35 37 32 50 4d 5f 41 2e 33 41
>.U3.AM572PM_A.3A|]

1) Will the Board Name ASCII string always be the same unique identifier on
all BBB devices and on all BB-X15 devices regardless of changes in hardware
on those boards (e.g. eMMC, AM335X vs AM335Y, AM5728X vs AMAM5728Y)?

Currently all BBB like devices have "A335"

https://github.com/u-boot/u-boot/blob/master/board/ti/am335x/board.h

our current list:

https://github.com/beagleboard/image-builder/blob/master/readme.md

The x15 doesn't have "A335".. here's the current list:

https://github.com/u-boot/u-boot/blob/master/board/ti/am57xx/board.c#L37-L48

2) Will only the 4 byte, Version string change from hardware revision to
hardware revision on the BBB?

After A335 things got complicated due to needed compatibility with the
"3.8.13" kernel, till we fixed that issue in v4.1.x/etc..

3) Can we rely on uname -n always returning the same answer on BBB vs BB-X15
image, regardless of the image version for all time? This seems like an
easy solution to the problem the software team is trying to solve. However,
if the answer changes in the slightest with future kernel upgrades, then the
platform detection scheme will break.

Nope, don't rely on that...

debian@beaglebone:/$ uname -n
beaglebone

debian@BeagleBoard-X15:~$ uname -n
BeagleBoard-X15

4) Can we manipulate what uname returns by hacking, for instance,
UTS_NODENAME or is that a bad practice? If so, is there a better place to
do this?

Just be careful around "uname -r" that's needed for linking u-boot <->
kernel in /boot/uEnv.txt and /lib/modules/`uname -r`/

Regards,

Ok thanks a bunch Robert!!

Will cook up a shell script or something which parses the EEPROM BNAME field and provides some kind of agreeable interface for the C# application…

Regards,

Jeff