Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Banana Pi zero
#1
A very interesting board indeed, its a zero in its layout, but this time a quad core.. Sadly only a Mali 400Mp2 but it should out perform or at least match the Raspberry Zero in graphic terms, and blow it away in full computing mode.

As always though the software isn't here yet, Armbian does a fair attempt at getting it up and running but terrible graphic glitching makes it useless for any kind of graphic systems, and its GLMark2-es seemed to think it had OpenGLES3.0 GPU on board, the Mali 400's are strictly ES2.0 which probably explains why it wasn't able to complete the tests,though it did get quite far into them, though very slow

I'll do an update/upgrade cycle on it from time to time to see if there's any improvement, but for now this is a non starter for our gaming purposes.

Also interesting to note it gets bloody hot, I put a heat sink on it, wouldn't want to run without.


[Image: zero1.jpg]


edit... ok I found a slightly older verison of the Armbian/ubuntu test build which installed at 720p and it is much more stable, after update and upgrade it is still quite stable, no glitching and GLMark2-es2 worked better, showed as Mali400 and ran all the tests, but it reported a really crap score of 52, which is feeble compared to a Raspberry zero which averages 100. I suspect its not fully accelerated even though it got through all tests.

Not sure what to make of this, its quad cores make it a great unit, its crap graphics make it pretty useless, but functional barely. I guess as with all maker boards it depends what you want to do with it, if you need a small cpu system, its amazing.
I can't really tell if the GPU is accelerated, but given its an Allwinner it probably is/will be, so that score might go up as the Armbian guys get things moving on it.

Maybe Banana Pi themselves might get round to putting a decent OS with acceleration (don't hold your breath there though)
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#2
After a few months, I upgraded the unit and yeah, still crap video...but neat that it all works.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#3
And back after 3 months, to our old friend the Banana Pi M2 Zero to see what progress on software has taken place.
Last couple of attempts have shown a lot of instability with graphics, but there have been some updates on the Armbian sites, but sadly the graphic performance has not improved, still only showing a pitiful GLMark2 score of 49

Also I wasn't able to get the maze project to run at all, getting an immediate segmentation error before it even went to my code... no clue how to fix things like that. In fairness it did manage to build it pretty fast. But just unable to even get to the main() function so nothing I can really do about that.

Ah well, I decided to try a version of Ubuntu 16.04 LTS which is now available, and it is indeed very nice, though it has the usual annoying ubuntu habit of updating in the back ground when you start it up, meaning you have to wait for it to finish its updates before you can install anything else.(grr)

However, this ubuntu is quite nice, 720p again, glmark2 shows no improvement so I think basically its just maxed out on the ancient Mali400MP2's which really are not great
After an update/upgrade cycle, which really did take a long time as there's a helluva lot to update/upgrade, I left it running while i went to do some chores I'd been putting of until a long update was needed Big Grin
The system performs really well indeed but.... I can't run the maze demo...grr It compiles them all fine, no issues there but I keep getting the same error as Armbian gave me a segmentation fault related to armhf.so
it tells me this...but google gives no sign of a fix, something about kernal issues....way over my head.
ld-linux-armhf.so.pdb contains the debug information required to find the source for the module ld-linux-armhf.so.3

No clue how to fix this, anyone? It seems to be something to do with GDB but I can't see what I need to set or where to make that work
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#4
And to add insult to injury, after a reboot, ssh fails to work.... back in the drawer.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#5
found a fix for the ssh issue

mkdir /var/run/sshd

then

systemctl restart ssh

But sadly the ld-linux-armhf.so.pdb still escapes me. Though it seems related to the issue I had on the Nvidia Nano, since navigating to the executable dir and using ./ from the targets terminal it fires up fine...
This is an Older Ubunti 16.04LTS and the same fix for the Nano's 18.04 is not as clear here.
Resetting and restarting and rebuilding is just so slow though I don't really want to spend any more time trying to fix it.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)