This morning, a parcel turned up for me from Banggood with a couple of Orange Pi boards inside it. Specifically the Orange Pi PC2 and the Orange Pi Plus 2E. Shame they’d not turned up earlier as Banggood had their sale on over the weekend – oh, well.
Let’s get down to some detail as I open the packages and start investigating.
Regular readers will know I have my reservations about Orange Pi – partly due to lack of support from the design company and secondly as the WIFI on the Orange Pi Zero was and is basically rubbish (though that is possibly down to implementation rather than hardware – others may know better).
First things first – no, neither of these will fit in a Raspberry Pi case 🙂
The Orange Pi Plus2E
This unit is based on the familiar 32 bit H3 chip so no surprises there.
I won’t waste your time with the full specs, you can get that anywhere - important things… it has EMMC (faster than SD) and unlike some boards which only have 8GB you get 16GB. 2GB Ram – which for me should really be the standard as adding a RAMDISK to minimise SD wear can take a chunk out of systems with 512MB RAM.
Other things I like – audio output – so many skimp on this. There is also a microphone and an IR receiver. The unit came complete with antenna.
Three USB 2 sockets as standard. Not keen on the WIFI antenna – but then you do have Gigabit Ethernet.
The Orange Pi PC 2
Based on the H5 chip, this is smaller than the Plus2E both in width and height.
This time it is the 64 Bit H5 processor – which is good and bad – good as it is more powerful, but not the same support as the H3 as you’ll see later. This board, despite it’s greater power has 1GB, not 2GB of RAM and has no eMMC. In both cases of course you have an SD slot.
Again the audio output – again the microphone and IR receiver. As with the first board, this one has Giga Ethernet too – and three USB 2 sockets as before.
Not particularly interested in testing Android on either of these two units – though clearly if you want a media centre out of it, the Plus 2E would seem to be the better bet due to faster EMMC and 2GB RAM.
In neither case is there any support for getting power via the microUSB connection – a right pain in the bum as the power connector they give you is, erm, small – and I don’t have ANY supplies that will fit – however, there’s always the 40 pin connector!
On the Orange Pi site itself there are several operating systems for these boards but then I’ve hever had much luck with their site. I figured I’d try Armbian server software from the Armbian site on both – notably the PC2 version is marked “experimental”.
I took the Plus2E and grabbed the Armbian server image for it. I didn’t see much in the way of startup information but the screen came up asking for username and password after a while. I was asked to change password…. I then had the option to change the screen size. At this point I was on HDMI – and the resolution was poor – I chose 1080p at 60hz. I rebooted. NO build-up information at all which is unusual – but after a while, a green background came up – and sure enough – clear text at the resolution I’d asked for, asking for username and password.
The screen suggested I was using Armbian 5.30, Ubuntu 16.04, that I had 2GB Ram and the temperature was 46c. All of that was in order.
At that point I’d had enough of using a screen and keyboard and went off to get WinSCP running so I could do this from the comfort of my PC – sure enough it worked straight away – and that’s a GOOD thing as enabling remote access for root users can confuse beginners. This just worked. I had attached a little heatsink to the H3 processor – just as well because by now the processor was sitting at 60c.
I went off to try armbian-config which immediately went to get some updates before popping up with a menu. It warned me that the config program runs under supervisor permissions – I ticked the box and agreed. Despite the wrong font setup which meant instead of nice lines around the menu there were a bunch of x’s (no it ISN’T my Putty settings), the menu offered everything I needed to get started.
At this point I noted the ability to “boot from EMMC” – I took a chance – SLOW at 20 minutes to complete – but then – dead easy. When done – the menu options included power off and exit – i selected power off – after a moment the lights stopped flashing, I pulled the power and removed the SD. I re-applied power and…. sure enough – the unit came back up, running from eMMC. The few updates required had by now gone up to 42.
I closed the terminal session and opened again to get stats – sure enough – 16GB of eMMC and 2GB of RAM. I was getting a warm feeling – time to install “the script”. Now easier than ever of course..
wget --no-check-certificate http://bit.do/the-script
This did a quick collection of preliminaries and then told me to log out and in as pi user. The script remains easy…
Something about the screen setup – the script came up with a purple background – yechhh… I set it going and went off to hammer some nails in somewhere. 47c said the display (that’s ok). During installation it rose to 54c, also ok.
So – everything worked ! But there appears to be only one serial port on view – that is ttyS0… and that is used by the debug.
In /boot/armbianEnv.txt - console=both or console=serial
That’s the two options in the Armbian docs… what I want is the other one – ie not serial – what ever that is – anyone any idea? I really would rather have that port free than have debug on it.
I had only one serial port and that was being used for debug – so over at the Armbian blog, two helpful fellows came up with a “solution” – just as I was trying to destroy the board by altering the FEL settings many of which meant nothing to me (and which apparently don’t work on the “legacy” version of the software – which was the one that was staring me in the face).
However, to cut a long story short, in the file /boot/armbianEnv.txt – add this:
overlays=uart1 uart2 uart3 i2c0 i2c1
Well, you could have blown me away – after a reboot, my Node-Red had/has full access to those three UARTS (as well as UART0 still used for debug) and if I need the pins for something else I now know what to do. Also because of the above – the I2c port 0 which had previously shown a UU at location 0x48 and ignored my SSD1306, now worked perfectly and I2c1 was blank (I could probably skip the latter but you never know)….
On 21st of August, realising the RPI-CLONE will not currently work on eMMC-based installations – I put a copy of Armbian onto SD – this time, the latest nightly build marked ARMBIAN 5.32.170921 nightly Ubuntu 16.04.3 LTS 4.11.12-sun8i. The above overlay code also did the same job on this one.
This board gets better by the minute!!!
Meanwhile back on the dark side
Meanwhile I decided to try the PC2 board. That installed Armbian without issue – just as above – and “the script” installed similarly without issue – taking somewhat longer at 42 minutes to install. This time the end temperature (with a little heatsink similar to before) was 48c.
I rebooted the PC2 board and…. nothing – no HDMI output, no winSCP connection – lots of Ethernet activity but no light on the board. I’ve tried the script twice now – I think something in the update/upgrade is messing up the install. I have to say at this point I was not impressed with this board.
I then tried the Debian server image from Orange on the PC2. A red light came on along with the green – and lots of disk activity – but no HDMI output. I really do wonder if ANYONE tests this stuff before they put it on the web. At least the Armbian people said their version was experimental – no such honesty from the Orange website. Perhaps I should have watched MickMake’s video before testing (or even ordering) this board… might’ve saved some time. https://www.youtube.com/watch?v=SWysgpZBzos. The new Debian installation, despite not working on screen did come up on WinSCP – but the stated password (orangepi) would not work.
I took the “raspbian” image – that booted up though there was no HDMI output at all. Whoever tested this stuff should be SHOT. However, the unit appears on WinSCP and the default password worked. I was given an instruction to resize the SD (why they didn’t just do it is beyond me) – I did that and rebooted the unit.
A ray of light – and then the darkness…
Having decided the best thing to do with the PC2 was to put it up against a wall and shoot it having done my own tests, read other people’s tests and having seen some comments on the subject , I made what would appear to be a bit of a stupid move and took the image off one of my other H5 boards (Neo Plus2) which worked perfectly with I2c, GPIO, Node-Red, Grafana etc etc etc… and after making a back-up (in case the SD didn’t survive) – decided the worst that could happen by plugging it into the Orange Pi would be an explosion as the chip came flying off the board….
And guess what – it worked PERFECTLY including I2c and serial. Same SD, same power supply, same board, same conditions… but - with no HDMI out - I was concerned - how reliable was this going to be? I tried serial ports on Node-Red and at one point the board rebooted on me mid-operation. I then tried another SD - same code - this time it would not even start up (but it was an older SD) - maybe that has something to do with all of this - maybe it needs SDs that are so fast they don't exist yet - the first one I used was a Sandisk Ultra - you would think that would be fast enough...
The H3-based Plus 2E is fine – someone will tell me how to sort out the uart 0 debug thing (could it be you?) meanwhile I have three more serial ports to play with. Lovely
But back at the P2, there is something seriously wrong with this board (and it is not the H5 because my NEO Plus2 boards are just fine). I discovered that, by replacing my battery pack with a decent power supply, I could get the HDMI to work reliably – now bear in mind that this SAME battery supply has worked utterly reliably for loads of other boards. I also found that an older Samsung HC SD would not boot up AT ALL – so unlike other boards I’ve tested (and there are many) this P2 is sensitive to power AND to SD. As power affects SDs – my money is on the SD interface. If it would just work reliably and not keep throwing up memory errors I reckon it would be just fine on that FriendlyArm image.
This information I gleaned didn’t help me a lot – but it may be of some use to others. The Ubuntu image from FriendlyArm for the FriendlyArm Nanopi PLUS2 appeared to be working a TREAT on the P2 – when it works. It was fully updated, I had Node-Red, Apache, Grafana, HaBridge, Mosquitto and other items all running – and after removing changing the debug line in the boot to console=tty1 (missing it out causes all manner of issues) instead of it referring to the serial, I now had full access to ttyS0 and ttyS1 in Node-Red along with I2c.
However, next time I booted up, sure enough, a bunch of memory errors appeared. Do we really need this hassle? No. I have a pair of NEO2s running 24-7, same with my NEO+2 boards and a Raspberry Pi.
This P2 board seems to me to be WAY too picky and just plain unreliable – the images out there for it are rubbish – but the FriendlyArm image seems to be the business – if only the board would not keep throwing out error message on power up and occasionally when running – could it be there’s a setting that needs to say “use slower SD” ?? I don’t know but I’ve spent too much time on this.
But the Plus 2E – with 4 UARTS, 2GB RAM and 16GB fast eMMC… depending on what you are doing – gives Raspberry Pi with it’s only-one-uart-shared-with-bluetooth nonsense a run for it’s money at something like £8 more…
Not directly about the Orange PIs but while I was struggling today, I learned about FEX files… essentially a compiled file with info about what’s enabled etc… a fellow called Martinayonette answered a query of mine..
Here is a FEX Guide : http://linux-sunxi.org/Fex_Guide
In summary, you need to first do a backup of /boot/script.bin, then decompile in with "bin2fex /boot/script.bin > /tmp/script.fex", then edit the /tmp/script.fex to enable other I2C or UART, and finally recompile it using "fex2bin /tmp/script.fex > /boot/script.bin"
That is useful info to know if you’re stuck with trying to change a board but it seems it does not work with earlier images – like the one I’m apparently using as I chose “legacy”.
Having said that in this case (PLUS 2E) all I needed was that one liner in the ambianEnv.txt file and a reboot to end up with a board that really – is not bad at all.