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

Jeff_Andich1 · June 20, 2018, 4:51pm

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

RobertCNelson · June 20, 2018, 5:01pm

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,

Jeff_Andich1 · June 20, 2018, 9:33pm

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|]

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)?
Will only the 4 byte, Version string change from hardware revision to hardware revision on the BBB?
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

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!

RobertCNelson · June 20, 2018, 9:42pm

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"

github.com

u-boot/u-boot/blob/master/board/ti/am335x/board.h

/* SPDX-License-Identifier: GPL-2.0+ */
/*
 * board.h
 *
 * TI AM335x boards information header
 *
 * Copyright (C) 2011, Texas Instruments, Incorporated - https://www.ti.com/
 */

#ifndef _BOARD_H_
#define _BOARD_H_

/**
 * AM335X (EMIF_4D) EMIF REG_COS_COUNT_1, REG_COS_COUNT_2, and
 * REG_PR_OLD_COUNT values to avoid LCDC DMA FIFO underflows and Frame
 * Synchronization Lost errors. The values are the biggest that work
 * reliably with offered video modes and the memory subsystem on the
 * boards. These register have are briefly documented in "7.3.3.5.2
 * Command Starvation" section of AM335x TRM. The REG_COS_COUNT_1 and
 * REG_COS_COUNT_2 do not have any effect on current versions of

This file has been truncated. show original

our current list:

github.com

beagleboard/image-builder/blob/master/readme.md

eeprom database
------------

BeagleBoard.org BeagleBone (original bone/white):

      A4: [aa 55 33 ee 41 33 33 35  42 4f 4e 45 30 30 41 34 |.U3.A335BONE00A4|]
      A5: [aa 55 33 ee 41 33 33 35  42 4f 4e 45 30 30 41 35 |.U3.A335BONE00A5|]
      A6: [aa 55 33 ee 41 33 33 35  42 4f 4e 45 30 30 41 36 |.U3.A335BONE00A6|]
     A6A: [aa 55 33 ee 41 33 33 35  42 4f 4e 45 30 41 36 41 |.U3.A335BONE0A6A|]
     A6B: [aa 55 33 ee 41 33 33 35  42 4f 4e 45 30 41 36 42 |.U3.A335BONE0A6B|]
       B: [aa 55 33 ee 41 33 33 35  42 4f 4e 45 30 30 30 42 |.U3.A335BONE000B|]

BeagleBoard.org or Element14 BeagleBone Black:

      A5: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 30 41 35 |.U3.A335BNLT00A5|]
     A5A: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 41 35 41 |.U3.A335BNLT0A5A|]
     A5B: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 41 35 42 |.U3.A335BNLT0A5B|]
     A5C: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 41 35 43 |.U3.A335BNLT0A5C|]
      A6: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 30 41 36 |.U3.A335BNLT00A6|]
       B: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 30 30 42 |.U3.A335BNLT000B|]

This file has been truncated. show original

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

github.com

u-boot/u-boot/blob/master/board/ti/am57xx/board.c#L37-L48


      
          #include <dwc3-omap-uboot.h>
          #include <ti-usb-phy-uboot.h>
          #include <mmc.h>
          #include <dm/uclass.h>
          #include <hang.h>
          
          #include "../common/board_detect.h"
          #include "../common/cape_detect.h"
          #include "mux_data.h"
          
          #ifdef CONFIG_SUPPORT_EMMC_BOOT
          static int board_bootmode_has_emmc(void);

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,

Jeff_Andich1 · June 21, 2018, 6:43pm

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