Determine hardware version from commandline

Banana Pi SBCs design BPI-M1/M1+/R1(A20)
5

If you want only know device (not hw revision) you can use info from devicetree

[08:45] frank@bpi-r2-e:~$ cat /sys/firmware/devicetree/base/model
Bananapi BPI-R2[08:45] frank@bpi-r2-e:~$
6

Sounded like what I was looking for, but at my machine /sys/firmware is empty…

7

I understand I can visually inspect the hardware, but how about telling “from inside” the machine: can software know which Bananpi it is running on?

8

Maybe kernel is too old and/or devicetree is mapped to /proc (imho first versions were here)

Also last official versions passing board in commandline to linux-kernel

cat /proc/cmdline
1 Like
9

Yes, /proc/cmdline has “board=bpi-m1”! Do all BPis have a similar board parameter on the kernel commandline??

(It seems the RPi I have access to does use /sys/firmware/devicetree/base/model, and it doesn’t have a board parameter on the kernel commandline…)

@frank-w Is there a more modern kernel than 3.4.112-sun7i for the M1?

10

I suggest combining these options…the cmdline board parameter is banana pi specific (and only if uboot uses this…if you override bootargs this is gone)…model in devicetree is more device-independed (if you stay on arm architecture) and if kernel has devicetree included (imho 4.x).

I think m1 should have mainline-support so just build one by youself…i don’t know if there any ready-to-use kernels available.

You can try this and maybe copy config from it:

M1 should be this dts: https://github.com/frank-w/BPI-R2-4.14/blob/5.4-merged/arch/arm/boot/dts/sun7i-a20-bananapi.dts m1+: https://github.com/frank-w/BPI-R2-4.14/blob/5.4-merged/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts

Maybe this helps (did not know if i got it this time): BananaPi bananian newer Kernel also found this (just replace kernel version to get newer one: https://watchmysys.com/blog/2015/07/building-linux-4-1-for-the-banana-pi/

1 Like
11

Hi pepa65,

for systems with u-boot support I’m using this subroutine:

check_4_u_boot()
{
   U_BOOT_DIR=`ls /usr/lib | grep "u-boot-next-"` > /dev/null 2>&1
   if [ $? -eq 0 ]
   then
        echo "$P>      u-boot-next directory...:  $U_BOOT_DIR"
        HW=`ls /usr/lib | grep "u-boot-next-" | cut -d '-' -f5 | cut -d '_' -f1`
        DEFCONFIG=`find /usr/lib/u-boot -print | grep "defconfig"` > dev/null 2>&1
        if [ $? -eq 0 ]
        then
           HW_DET=`cat $DEFCONFIG | grep "CONFIG_DEFAULT_DEVICE_TREE" | cut -d '=' -f2 | tr -d '"' `
           echo "$P>      CONFIG_DEVICE_TREE......:  $HW_DET"
        fi
   else
	echo "$P!      NO u-boot-next support..!"
   fi
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Regards
WolliK
12

Yes, the OS running on my M1 does not seem to use u-boot-next, I only have a /usr/lib/u-boot directory and it doesn’t have any entries with defconfig.

13

these are many non-standard-checks…at least on my images (r2/r64) there is no uboot-next source dir. i have them also not seen it on official images for these boards.

the boards supported by mainline-kernel should use them instead of the very very old 3.x one at least for security reasons. and then you have devicetree and can use the model property

14

Hi pepa65,

for my BPI M2 Zero I’m running an old Debian version 3.xx with no u-boot support. On this system I read out the brand details from the script.bin file. But not all releases uses a script.bin file. Here is my subroutine to process the script.bin file:

check_4_script_bin()
{ 
	BIN2FEX=`sudo find / -name bin2fex` > /dev/null 2>&1
	if [ $? -eq 0 ]
	then
		SCRIPT_BIN=`sudo find /boot -name script.bin` > /dev/null 2>&1
		if [ $? -eq 0 ]
		then
			echo "$P>      Check script.bin file...:  $SCRIPT_BIN"
			echo ' '
			HW=`sudo $BIN2FEX -q $SCRIPT_BIN | grep "machine" | cut -d '"' -f2` 
			echo ' '
			echo "$P>      HW via script.bin.......:  $HW"
		else
			echo "$P!      No script.bin file found!" 
		fi
	fi	
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Regards
WolliK
1 Like
15

Thanks for the pointer. My machine didn’t come with bin2fex, so I built the Sunxi-tools and used them on the script.bin in /boot, with the result: “orangepi-plus” (interesting, but I am sure I have a Banana Pi M1). Must be an artifact of the Ubuntu 16.04.6 LTS image that I’m using…

16

Hi pepa65, I’m using today ARMBIAN for my BPI’‘s systems (different models) and RASPIAN for my RPI’ systems (also different models), so I don’t run into this kind of problems.

Regards Wolfgang

1 Like
17

I’m considering switching to Armbian, more recent kernel too, better maintained. I would like to be running from the SATA harddrive, because I am worried about the SD card with all the writes…

18

why not just move heavy written folders (like temp,var) to hdd and leave system on sdcard…so you can restore/update/reinstall your system by replace the sdcard, but have not that write-load on it

19

That’s what I have now, /tmp on tmpfs, swap and /var on the harddrive. Is it hard to get most things on the HDD?

20

the easiest way getting most things to HDD is moving full rootfs and change root-var in cmdline (uboot bootargs). Here you need only kernel (at least with sata buildtin-not module) on sdcard and of course uboot+uenv.txt, basicly content of your boot-partition, root-partition can be on hdd

1 Like
21

This is the function that works on the BPi M1

Bpiname(){
  sudo mount /dev/mmcblk0p1 /mnt
  grep '^BPINAME' /mnt/.config |grep -o '[^=]*$'
  sudo umount /mnt
}

Outputting: MIKEY Banana Pi BPI v1.0

22

So after all directories are properly copied to the HDD, just change the file cmdline.txt on /dev/mmcblk0p1, and reboot?

23

if it is cmdline.txt on your setup…yes…my boards have only uenv.txt…your kernel has builtin-sata-support?

24

I tried checking for the SATA support, my /proc/config.gz has:

CONFIG_SATA_PMP=y
CONFIG_SW_SATA_AHCI_PLATFORM=y

So to me it seems the SATA support is builtin – right?

(My uEnv.txt only has one line: ethaddr=aa:bb:cc:dd:ee:ff…)