Banana Pi M2

Peter ScargillBanana Pi, Debian, Raspbian17 Comments on Banana Pi M2

banana pi m2 Updated December 13, 2016:  Technically referred to as the BP1-M2+  I received this Banana Pi board in the post this morning. It is SMALL – that is, the same width but just a tad wider than the FriendlyArm M1 and M2.

But there the similarity ends. Firstly this little thing has EMMC, microSD, Bluetooth, WIFI, Wired Ethernet, 2 USB sockets (a tad limiting), 1GHZ Arm quad-core processor, 1GB Ram, 8GB EMMC (which to me is too small but I’m sure people will find it useful – and as for backup… I’d rather use microSD), and it claims to run Android 4.4 smoothly – hence my comment about the EMMC – what use is 8GB for Android??!?!?

The Android version is a little old for me so I thought I’d try the recently updated Raspbian. The blurb SAYS the GPIO is compatible with Raspberry Pi (really? Does it run the Raspberry Pi modules for Node-Red? If so I’ll be impressed).

The downloads and docs are all here  https://bananapi.gitbooks.io/bpi-m2-/content/en/ which is a big improvement on some others – Orange Pi with hopelessly out-dated images – others with non-working Google Drive images etc.. I got the image no problem for Debian and as I received no documentation with the board, I was grateful for the online version.

I DID notice no audio output other than that on HDMI – which is a bit of a bummer – I like to see a 3.5mm jack for audio. Sadly the manual refers to plugging in a 3.5mm jack for audio – but there is definitely no 3.5mm jack socket on the board.

There is also an IR receiver. I’ve yet to see one of these boards run it out of the box but there IS a reference to this in the manual! https://bananapi.gitbooks.io/bpi-m2-/content/en/bpim2+irinterface.html – would be awfully handy if this worked in Android for remote controlling stuff.

At this point I just about had the image downloaded and things were going downhill a little.

At the end of the instructions, sure it was obvious you could be now running your operating system – but from WHERE was unclear. I didn’t want to load it into EMMC.

I was encouraged to see WIRINGPI available – https://bananapi.gitbooks.io/bpi-m2-/content/en/bpim2+wiringpi.html but it was not clear if this was a special – if it WAS a special I found myself wondering why they claimed above that the board was PI-image compatible??

THIS page – http://www.banana-pi.org/m2plus-download.html on copying images – got my interest – up to now in all the boards I’ve tested, the Raspberry Pi is the ONLY board that has a simple to use copy/backup facility that will make duplicate images even on different size SDs!! This would prove to be no good.

SO – first things first… claims about being Raspberry Pi compatible – MYTH (like all the rest) if it were compatible it would run the RPI ROMS and it does NOT – I just tested it – result – nothing.

But on the other hand for the FIRST TIME their package they describe as “Raspbian booted first time – and had an “expand file system” which after a reboot opened up the operating system to the full size of the SD (others – ARE YOU READING THIS!!!). Marvellous.

Not only that but their “Raspbian” which features the Raspberry Pi logo and looks really like a Pi – apart from the monitor overhang which made closing programs difficult – has the latest file backup system that ONLY (as far as I know) the Pi has had up to now – would it work? I took the Raspberry Pi image disk that was supposed to work with the Banana Pi – now defunct as it does not – and used that as the backup.

I booted up “Raspbian” as supplied on the Banana Pi site – and ensured the WIFI worked – it DID (however it only found one access point which compares badly to other systems which find even my neighbour’s access point). It said I had a connection – but a poor one – no more than 12ft away from the access point!!! 2ft away my PC streams movies on that connection!

I plugged in the USB with my microSD in the BP1-M2+ and ran the graphical backup program. All looked well as it found the USB3 drive and started partitioning. “preparing partitions” it said. After what seemed like a similar time to the Raspberry Pi, maybe a pit longer, the software went off to start copying the two partitions, just like the Pi. If I were honest it SEEMED a little slower than the Pi2 but there are so many factors to take in here. It copied partition one and then…

“Could not mount partition” – I have NEVER seen that in a Pi2 or 3 before (and I make live backups all the time)  so I took the chip out and formatted it on a PC – and re-inserted…Once again – “preparing partitions”… I’m sure it took longer than normal… (and remember when I do this normally it is on a system doing all SORTS of jobs with all SORTS of software. This is a simple empty system).

Partition one started to copy – 60%… 70%… 90%… slow.   Not in the same league as Pi3… it stuck at 100% for AGES – I was convinced it was going to fall over… and…

“Could not mount partition”. I tried this three times in total with different SD holders – same result.  Having failed to get anywhere I took the same chip in the same container, put it back into a Raspberry Pi 2 and initiated a backup. This worked PERFECTLY.

I’m sorry guys – this is NOT Raspberry Pi compatible – STOP CLAIMING COMPATIBILITY. the RPI backup program WORKS. This does NOT.

At this point I noted, having received a heatsink with no glue and having written back to ask if it was necessary, that the main ARM chip was running hot enough to cook an egg. Fortunately I found a little heatsink I had lying around and that improved matters.

I wondered if it was worthwhile doing the usual apt-get update/upgrade – and checked to ensure I had a WIFI signal. Sure enough my WIFI was connected – but I could not browse the web or do anything Internet-related. I got that IP address which means – no.   I even tried putting the address in manually – no.

As I was looking at the WIFI – I noted the volume control top right was on mute. I clicked on the slider to adjust it – nothing – would not come out of mute.

With no audio and no WIFI I thought I’d go off on a tangent and try the recommended ARMBIAN. Aside from (again) overscan on my monitor (which works perfectly with a Pi and various other boards) Armbian came up – with a very nice screen and packed full of utilities (but no SD backup). Once again the WIFI would not have it. I plugged in Ethernet and decided to give the video a try – I opened up Firefox – and went to the BBC iPlayer.  Sorry – HTML5 content will not work – you need the FLASH player – and we all know what getting that running is like.

At this point I was ready to give up… but there was one thing left to try.

Android – a particularly old Android 4.x but I figured it might be worth a try. I followed the instructions which unlike any other board I’ve tried did not include blowing an image with Win32DiskManager but instead a piece of converted Chinese software. I tried several times and failed but eventually got a complete, verified image. Put it into the M2, the Banana Pi info came up and then… blank. The instructions said wait a while the first time – I waited 15 minutes – still blank.

Such a promising start, it looked like an RPI, acted like an RPI but… I have to say, disappointed.

I left this for a while – and having given up totally on using this board for any graphical interface due to the fact  thaty there were SO many issues, I thought I’d have a go with Armbian Debian server, the text-only version which has worked well on the FriendlyArm Neon. After a couple of false starts probably due to using a slow SD, I convinced the M2+ to boot from an 8GB SD with Armbian. Aside from some overscan which made it very difficult to do the initial change of password as the text was somewhat off-screen, I managed to get past that stage and onto WinSCP to do the usual apt-get update and apt-get upgrade which worked a treat. I installed the server version of Jessie – so no graphical desktop but it would be easy to add in. I’m inclined to use larger SD cards if I’m installing a graphical interface but 8GB is more than enough for a command-line only setup even with all the extras I typically add including Node-Red, Mosquitto, SQLITE, PHPLiteAdmin, Webmin etc. by my script.

I ran my install script – see the home control project and although it seemed to run somewhat slower than usual, it did run (ignoring unused variable warnings which are irrelevant but keep popping up in part of the script – I do wish people would keep information to a minimum).

Ok, early days – but it does appear that everything works at least in this simple use of the board – I have yet to look at the hardware in depth – clearly the Raspberrry Pi GPIO stuff DOES NOT work – I installed WIRINGOP as this is after all an H3 board and sure enough – pin 40 – that’s GPIO21 – could be made to turn on and off by turning on and off GPIO number 25.

http://www.orzalabs.tech/2016/08/15/wiringpi-library-on-nanopi-m1/

And so after much trial and error…

  • Pin 3 GPIO2 =   gpio write 8 on
  • Pin 5 GPIO3 =   gpio write 9 on
  • Pin 7 GPIO4 =  gpio write 7 on
  • Pin 11 GPIO17 = could not figure out – default off
  • Pin 13 GPIO27 = gpio write 2 on
  • Pin 15 GPIO22 = gpio write 3 on
  • Pin 19 GPIO10 = gpio write 12 on
  • Pin 21 GPIO9 = gpio write 13  on
  • pin 23 GPIO11 = gpio write 14 on
  • pin 29 GPIO5 = gpio write 21 on
  • pin 31 GPIO6 = gpio write 22 on
  • pin 33 GPIO13 = gpio write 23 on
  • pin 35 GPIO19 = gpio write 24 on
  • pin 37 GPIO26 = could not figure out – default off
  • pin 8 GPIO14 =  gpio write 15 on
  • pin 10 GPIO15 =  gpio write 16 on
  • pin 12 GPIO18 =  could not figure out – default off
  • pin 16 GPIO23 =  could not figure out – default on
  • pin 18 GPIO24 =  gpio write 4 on
  • pin 22 GPIO25 =  gpio write 6 on
  • pin 24 GPIO8 =  gpio write 10 on
  • pin 26 GPIO7 =  gpio write 5 on
  • pin 32 GPIO12 =  could not figure out – default off
  • pin 36 GPIO16 =  could not figure out – default off
  • pin 38 GPIO20 =  could not figure out – default on
  • pin 40 GPIO21 = gpio write 25 on

When I say I could not figure out p particular pin – I mean it would don’t respond to simple gpio commands – I assume those pins have other functions like serial that is not clear on the banana pi diagram. STILL not a bad haul!! A quick Node-Red lookup table will sort these and the NEO out…

NOW – take a look at my updated M1 article which not only has the pins for THAT chip but also now has a solution for general pin control – for non-root users.. https://tech.scargill.net/cheapest-almost-complete-iot-solution/

December 13, 2016 I installed Armbian again after a long break – with my script it installed first time, no problem with everything working – and 4 UARTS appearing in Node-Red – at least 3 of which should be usable.

 

17 thoughts on “Banana Pi M2”

  2. Found today the time to check out the wrong GPIO pin mappings used by the vendor and tried to correct them: https://github.com/igorpecovnik/lib/commit/6473cfff9941e2e7dd573ca3d2fea8cb16de64e4

    Still it would be great if one brave soul collects all the different pin mappings of those H3 devices and provides a single WiringOP library that detects on which board it runs (possible — you can query information from those so called fex files from RAM at runtime) and then ‘simply works’. 🙂

      1. Sorry. In the meantime I could convince others to add the pin mapping information to H3 device pages in linux-sunxi wiki where applicable. All the larger H3 Orange Pi for example implement an identical pin mapping on the 40 pin header: http://linux-sunxi.org/Xunlong_Orange_Pi_PC#Expansion_Port

        The freshly released little one does it like this: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero#Expansion_Port

        All NanoPi receive great vendor support so the same stuff is already documented in FA wiki: http://wiki.friendlyarm.com/wiki/index.php/Main_Page#NanoPC.2FPi_Series

        The only real exception is this Banana here since the vendor doesn’t care about correct information. You never know whether their hardware description is correct or not unless you tried out everything yourself (boring, waste of time). So with BPi M2+ we end up with: http://linux-sunxi.org/Sinovoip_Banana_Pi_M2%2B#Expansion_port

        But fortunately the bananapi.org forum link there shows the code change necessary to adopt different pin mappings to WiringOP. And while I have currently 10 different H3 boards lying around I never dealt with WiringOP/WiringPI — so am the wrong person to start with this.

        But as soon as anyone shows interest I’m more than happy to point to ressources how to determine on which board WiringOP is currently running so that such a pin mapping switch can be implemented at runtime and from then on only one enhanced WiringOP library is needed for all those different H3 boards out there.

        And since you’re Mr. IoT I thought I try it again with another comment to start something the whole community could benefit from 🙂

        You and your user base could do it and I’m confident that here are enough coders around who are able to fork/enhance WiringOP so that at least all H3 devices are supported (since I ‘fear’ we will see in 2017 lots of new cheap H3/H2+ devices targeting IoT area)

        1. Mt IT – I like that.. however my coding skills are a bit specific and I howl in terror when I look at compiling anything in Linux – so if anyone here wants to take on this REALLY worthwhile challenge – I suggest we continue this conversation – the biggest problem with the various boards out there is having a common interface to get to ports, I2c etc. It’s all very well them claiming the boards have this – that and the other -but using the facilities – expecially as user Pi (ie non-root) can be a pain. WiringOP if made to work with the various boards could then result in a node for Node-Red with a simple parameter for which board to work and… I’m getting excited already…

          1. Well, device auto detection can work — with mainline kernel it’s already there: /proc/device-tree/model (will show then ‘Banana Pi M2+’) and with the old and smelly 3.4.x kernel mostly used now on the cheap H3 boards it’s fetching the same information simply from an address in memory (there’s properly licensed code flying around for this).

            So it’s really just a bunch of interested enthusiasts needed that take the available information, take WiringOP (or the ‘BPI_M2P’ branch here https://github.com/BPI-SINOVOIP/BPI-WiringPi/tree/BPI_M2P) and add the various different pin mappings and device auto detection.

            And I would assume another blog post of yours is needed to spread the word/idea. BTW: the last time I tried to start with something in this direction over at Armbian I was sent directly back to you — remember? https://forum.armbian.com/index.php/topic/1851-rfc-make-armbian-more-iot-friendly/#entry19012

            1. Here we go: At least Armbian (and distros that rely on Armbian, DietPi with H3 devices for example) should from now on be compatible regarding ‘device name’ regardless of kernel version:
              https://github.com/igorpecovnik/lib/commit/3f0373451907ace899c96501595796ac1f6a7c24

              And there is the code to extract the ‘machine’ name when H2+/H3 devices running with the old 3.4 kernel: https://github.com/jernejsk/OpenELEC-OPi2/blob/openelec-7.0/packages/sysutils/sunxi-sys-utils/src/read_fex.c

              1. So to get the name of the device it’s checking the existence and contents of /proc/device-tree/model and if not existent (old kernel used) doing the equivalence to ‘read_fex product machine’.

                This way all H2+/H3 devices currently supported can be differentiated safely. Now it’s up to the IoT crowd to use the information 🙂

  3. Hi,
    I have banana pi M3, I have installed the BPI-wiringPI corectly, but don’t know how to control the GPIO from node-red. I installed the contrib-gpio node and contrib-ui but no configuration works. Everytime error sign shows up.
    Could You give me any sugestions how to solve this?

    Regards
    Mike

    1. It is unlikely that any Raspberry Pi-specific GPIO code will work with the Banana Pi – don’t be fooled by the “Pi” – NONE of these other systems are completely compatible with the Raspberry Pi – hence alternatives such as WiringOP which only really works perfectly with I think the Orange Pi – as the port assignments are different on different machines.

  4. As you can see I’ve updated the blog and at least figured out the pin mappings for outputs – lots of them! PWM and other functions might be harder – really would be nice if someone would make WiringOP configure for different boards via a table…

  5. Pete, all H3 boards are more or less the same. If you want nearly the same feature set as the BPi M2+ for half the price then choose an Orange Pi PC Plus (both featuring 1 GB DRAM, 8 GB eMMC — OPi being faster, 3 USB host ports vs. 2 on BPi M2+). The only real differences:

    BPi M2+: GbE Ethernet (at least 150mW more consumption!) and BT, primitive voltage regulation (wasting energy) and prone to overheating

    OPi PC Plus: Fast Ethernet only, WiFi also able to be used in monitor and AP mode, best voltage regulation and better performance (temperature lower, clocks higher, less throttling)

    As long as you run Armbian all ~15 H3 boards out there behave more or less the same since differences are always just Fast vs. GBit Ethernet, voltage regulation, thermal behaviour (we use therefore board specific throttling and cpufreq settings), camera connector or not and GPIO pins available: http://forum.armbian.com/index.php/topic/1351-h3-board-buyers-guide/

    And please don’t call the M2+ ‘Banana Pi M2’ since this is another ancient board relying on pretty much unsupported A31s SoC and the BPi folks have already a so called ‘BPi M2 Ultra’ in the pipeline that relies on the new announced and totally different R40 SoC. So they have 4 BPi with M2 in the name which are all 100 percent incompatible to each other and your M2+ being 99 percent compatible to every Orange Pi or Nano Pi M1/NEO (or even the upcoming NanoPi Air which features also M2+’s AP6212 for WiFi/BT).

    BTW: M2+ pin mapping are surprisingly different than described by the vendor in his own hardware description (fex file). Access to GPIO from sysfs is therefore partially broken and you have to adjust pin mappings to get WiringPi/OP running correctly: http://forum.armbian.com/index.php/topic/1745-different-gpio-pin-mappings-on-bpi-m2-compared-to-orange-pis/

    1. Thanks for all of that – all points taken in – erm that last table on pins – I got excited for a minute but no – pin 40 – WiringOp works when you punch in 25 !!! I’ve no idea how that is supposed to compare to anything – I can see I’m going to need to map all the pins by hand…. :=(

    2. So overall what would your preferred TOP and SECOND top boards be? If I don’t have them I’ll get hold of them to give them a bash…

      1. Well, it’s hard to answer the question about a ranking. Let’s try it the other way around: Since all H3 boards are more or less the same one can have a close look which features he needs and then choose from a wide variety of SBC that feel the same at least when using Armbian.

        If it’s about lowest consumption unfortunately neither BPi M2+ nor NEO can shine but all the other smaller Fast Ethernet equipped H3 boards are perfect and behave pretty much the same: NanoPi M1 and Orange Pi Lite, One, PC or PC Plus can all be configured to consume as less as 400 mW (!). Though in this mode there is neither USB nor Ethernet working so more realistic configurations with all 4 USB ports and Ethernet PHY enabled add ~300 mW. If the boards are configured for more performance then again a few hundred mW can be added.

        Good news: today we added h3consumption tool to Armbian which works on all H3 devices of course. So consumption (idle as well as full/peak) can be now configured individually and also settings can be switched easily from userspace — no reboot required, switching between low-power and full-performance mode takes not even a second: http://forum.armbian.com/index.php/topic/1878-testers-wanted-h3consumption-to-be-included-into-future-armbian-releases/ (there’s one link that explains more in detail which savings are caused by which setting)

        And since on all the H3 based Orange Pi boards and NanoPi also everything is exactly the same when it’s about stuff happening on the 40 pin GPIO header it’s then really that simple: Check your requirements and buy the H3 board of choice: No Ethernet required but WiFi? Choose Orange Pi Lite or NanoPi Air. GBit Ethernet needed? Choose Orange Pi Plus 2E? As cheap as possible? Choose Orange Pi One. All 4 USB ports needed? Choose OPi PC or NanoPi M1? Also WiFi needed and high random IO required? Then choose OPi PC Plus (adds WiFi/eMMC)… and so on.

        The only 2 H3 based SBC that are not like that are NEO and BPi M2+ since both show different GPIO header pinouts (still no idea why they changed something on BPi M2+), higher idle/overall consumption and are prone to overheating (applies somewhat to NanoPi M1 too). The latter can be compensated partially by settings and is already done this way in Armbian. But any other H3 based SBC can be simply chosen by required feature set. On a related note: community works hard to get GC2035/OV5640 (2MP/5MP) cameras fully working on the H3 boards. Most recent step: Using Allwinner’s HW video encoder freeing up CPU cores completely when encoding h.264 from the cameras works somehow 🙂

        1. Hi Tkaiser

          As a relative newcomer to Armbian you’ve raised more questions here.

          I will try that consumption setting program – I just realised I put Armbian on my NEOS but not on the M1s – I’ll fix that early in the week then try out the consumption code as my M1s run hot enough to boil eggs.

          Thanks for that info – useful to myself and others in here.

          I don’t suppose YOU happen to know of anyone who’s managed to port WiringOP to the various boards? It kind of works with the M1 and NEO but the pins are wrong – and that’s fine because I figured them out – but the PWM pins (and no doubt I2c) are hardwired so if you try hardware PWM on the M1 for example it just says sorry – wrong pin.

          Now why is that important? Because like some others – I use non-ROOT Node-Red which simply cannot access root programs – and wiring Pi can easily be made to work as non-root – whereas that MATRIX stuff that FriendlyArm produce ONLY works as root despite my best efforts – why oh WHY do people go off and do their own thing instead of making ports etc compatible with the “proper” pi…

          Anyway, any knowledge you have on that subject would be appreciated – I’ve spent way too much time just trying to get basics like port control and i2c without having to give my Node-Red root access which all the experts say NOOO- DON’T DO It…

          1. No idea, why your SUID set binary does not work (except of looking wrong anyway since it checks for ‘BOARD_NANOPI_T2’?). Setting binaries to SUID is also not the best idea but hey…

            NanoPi M1 is unfortunately somewhat prone to overheating. The Orange Pi all use copper layers inside the PCB to spread heat away from the SoC which works pretty good. When you choose the available Armbian image for M1 please keep in mind that his still contains a bug that will raise temperatures (the temporary fix has to be applied to /etc/defaults/cpufrequtils). Please note that you get a good overview about thermal behaviour in Armbian using ‘sudo armbianmonitor’ with -m switch (CLI monitoring) or -r which installs RPi-Monitor: http://www.cnx-software.com/2016/03/17/rpi-monitor-is-a-web-based-remote-monitor-for-arm-development-boards-such-as-raspberry-pi-and-orange-pi/

Comments are closed.