Hi!

Yesterday I get my first build of a NanoPi port of pi4j (http://pi4j.com/) running. A simple test with a double color led on a NanoPi M1 works fine. Actually I am going to adapt the board specific code. Hence some questions are open.

 

• Is there a simple way to differ NanoPi Boards by SW (NanoPi M1, Neo and Air) to set the correct board?
• Memory size of the board

 

The Raspberry code uses the revision string of /proc/cpuinfo to retrieve this informations. But this info is PI specific. Any idea how to get this info? Using C is not a problem - pi4j is a mix of Java and native libraries.

 

Peter

 

P.S: Java Example File - don't be confused - the extension bsh stands for bean shell, scripting for Java - quick testing without compiling

script.bsh

Forget about /proc/cpuinfo, memory size or any generic attempt. It can only be solved using software and it depends on you flashing the right OS image to the appropriate device (using correct fex or device tree stuff or not altering armbian-release file). With Armbian we took care that devices are 'named' identically regardless of which kernel is running (by adopting machine names in fex file on Allwinner boards to the ones used by upstream kernel maintainers): http://tech.scargill.net/banana-pi-m2/#comment-27947

 

Please note, that this only works with legacy kernel when Armbian's fex files (script.bin) are used (we did this to allow 'consumers' of our build system to also benefit from this, eg. DietPi OS images for H3 boards or RetrOrangePi and maybe Lakka too). But if Armbian is already a requirement it's also possible to just check a single file:

root@orangepiplus2e:~# cat /etc/armbian-release 
# PLEASE DO NOT EDIT THIS FILE
BOARD=orangepiplus2e
BOARD_NAME="Orange Pi+ 2E"
VERSION=5.27
LINUXFAMILY=sun8i
BRANCH=dev
ARCH=arm
IMAGE_TYPE=stable

With mainline kernel it's just checking /proc/device-tree/model given the correct DT is used (not always the case even with Armbian since just a few weeks/months ago we shared DT configurations between different boards so when using Armbian relying on contents of /etc/armbian-release is always the best choice).

 

Please see also: