Naguissa

I tried again with a new power supply and a new sd card. Same issue.
 
I cannot access the serial debug output (ttl to usb), so I think I am about to consider the board completely lost.

http://www.zdnet.com/article/linux-gets-blasted-by-blueborne-too/
 
Not sure if we'd seen this/had exposure.

I am a sailor and use OpenCPN for the navigation chart plotter. The charts load and zoom much faster with hardware openGL/ or ES.
It has a way to display rendering technique and frames/sec and is barely useful without acceleration. It is very nice with it, even on the Orange Pi One. But I will use the Opi PC Plus for my final installation.
 
I compiled opencpn(4.2 and 4.4) on the default Jessie desktop of both 5.05 and 5.10. I will be recompiling on 5.17 soon.
 
So it is not only games and display managers that use openGL and hardware acceleration.
Thank you all for armbian and the rest.

Hello,
 
I wish to share my research on getting OpenGL to work on Mali GPU. I realize Armbian focuses on server images, but I suppose many people would be interested nevertheless. I have a Banana Pi Pro and an Orange Pi PC, which both have a compatible GPU. Perhaps it will work on other boards as well.
 
Here are the commands I used to get OpenGL to work.
 
1. Install:
# install GLX Gears, mesa GL and GLU libraries apt-get -y install mesa-utils # install development tools apt-get -y install build-essential automake pkg-config libtool ca-certificates git cmake subversion # install required libraries apt-get install libx11-dev libxext-dev xutils-dev libdrm-dev x11proto-xf86dri-dev libxfixes-dev # get source code git clone https://github.com/robclark/libdri2 git clone https://github.com/linux-sunxi/libump git clone https://github.com/linux-sunxi/sunxi-mali git clone https://github.com/ssvb/xf86-video-fbturbo git clone https://github.com/ptitSeb/glshim # install mali driver cd sunxi-mali                                                                    git submodule init                                                               git submodule update                                                             git pull                                                                         wget http://pastebin.com/raw.php?i=hHKVQfrh -O ./include/GLES2/gl2.h             wget http://pastebin.com/raw.php?i=ShQXc6jy -O ./include/GLES2/gl2ext.h    make config ABI=armhf VERSION=r3p0                                               mkdir /usr/lib/mali                                                              echo "/usr/lib/mali" > /etc/ld.so.conf.d/1-mali.conf                             make -C include install                                                          make -C lib/mali prefix=/usr libdir='$(prefix)/lib/mali/' install            cd .. 2. Build
# Step 1: build and install helper libraries cd libdri2 autoreconf -i ./configure --prefix=/usr make make install cd .. cd libump autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 2: build video driver cd xf86-video-fbturbo autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 3: build GL wrapper cd glshim cmake . make cp lib/libGL.so.1 /usr/lib/ # replace the software GL library with the wrapper cd .. 3. Configure your system
- configure your kernel to allocate memory for the GPU
- make sure mali and mali_drm kernel modules are loaded
- give your user permissions to access /dev/ump and /dev/mali
- configure Xorg to use fbturbo driver
 
4. Test:
# run a basic test glxgears # install and run a GL benchmark apt-get -y install globs /usr/lib/globs/benchmarks/GL_pointz/gl_pointz # try to run a real game apt-get -y install billard-gl billard-gl This all worked out for me rather nicely. The only issue I have encountered is a segfault that many GL programs get when they shut down. I'm currently debugging this issue, but it would be helpful to know others experience it as well, and perhaps get some advice from people experienced in GLX or SDL.
 
Edit: I know glxgears is not a real benchmark, but let me give you some numbers to make it clear what I'm talking about. Results are from Orange Pi PC clocked at 1296000 Hz (and are CPU-bound):
user@bananapi:~$ glxgears LIBGL: Initialising glshim libGL: built on Jun 12 2016 06:12:01 LIBGL: Current folder is:/home/user libGL:loaded: libGLESv1_CM.so libGL:loaded: libEGL.so 2074 frames in 5.0 seconds = 414.688 FPS 2071 frames in 5.0 seconds = 414.085 FPS 2070 frames in 5.0 seconds = 413.915 FPS ^C

Unfortunately I have the Orange Pi not Banana Pi so hardware could be the problem here.  I have also seen it working on the original Raspberry Pi with no problems.   Thank you for the reply though :-)
 

Product specs does not list Linux support so maybe there is no driver in the Linux kernel.

It could be in my case too. At around 95% I still had around 15G of free space, notebook drive is anyway on the limit all the time since its small ... strange.

Dear Johnny,
 
I appreciate it very much for your great effort on Banana Pi R2 development, I am the Banana Pi PM, we're working with MTK linux team for months. If you are interested to get a R2 new version sample, pls contact me (nora.sh.lee63@gmail.com). Any further advice will be welcome, we're making next version PCB this week.
 
Nora
Banana Pi PM
 
 

It's not my job no but if we all followed that ethos then we'd not have open source software at all.

I think this is a very different beast in terms of support - MediaTek have been reasonably busy adding support for their various chips - there's a datasheet that's complete from a development standpoint (currently assessing the possibility of PiFM like functionality) - the switch driver is done, ethernet, USB3, IR, sound blah blah - there's full source for uboot and the kernel. Capability wise the board is nicely priced - true SATA, USB3.0, mPCIe - don't use the media features and it's a solid router platform - do use them and it's feature packed board with a built in GB switch - the perfect little ARM cluster controller for robotic projects or other such low power distributed projects (I'm using mine as the main controller for a distributed wideband SDR project - GPIO and relays controlling banks of filters - that kind of nonsense)

The hardware is good - sinovoip rightly or wrongly have slapped together a crazy little board with extensive capabilities at a good price.

I know sinovoip are terrible when it comes to communication and specs but given MediaTek have at least 4 competent developers working on kernel support and it's already progressed to an advanced stage?

This is quite the flagship for MTK and they appear to have correctly taken on the responsibility of supporting their SoCs under Linux which is more than you can say about most.

Things are different with this board - I'm not bothered about sinovoip and nobody has to get anything out of them anymore - what's already available is light years ahead of their previous efforts even though they're not responsible for basically any of it - MTK are carrying the torch.

I know there's much I don't know - in this field? people here are the experts and I deffer to your wisdom but at least from my limited perspective - I currently think I raise reasonable points.

I'm powering a few Orange Pi Zeros, so I don't have any choice but to use USB for power (well, more or less). So, I spent some time searching for the right power adapter. It has to be at least 2A and only have one plug (to keep people from plugging in their phones). I thought I found the right product and purchased 20 of them.
 
I was having issues with not booting from the microSD card and was really lost as to why this problem kept popping up. Anyway, I thought to double check the power. I wasn't getting more than 700mA -- sometimes much less. And so, I decided to look deeper...
 
 

Make the Raspberry Pi great again! 

I'm not sure if anyone is interested in a very small distro without gcc, but I spent some time the last week using buildroot and armbian's source files to create a 3.4.112-rt image for the nanopi neo. It is going to be part of a realtime audio project (think synth or guitar pedal) that I'm working on and it demands a quick boot, among other things. 
 
There is also a mainline version, but it doesn't have all the fixings you folks like, so I don't know if you'd want to use that. 
 
You can find the build scripts and config files on my github. I'll be posting the legacy image in a zip file tonight, once I verify everything is reproducible. 
 
I would like to thank the Armbian developers for all their time and energy doing what they do. Their code and guides have helped me understand how one would even attempt something like this, and I'm very grateful. If you ever use my image, please donate to the Armbian community. 
 
The screenshot is proof that the system works, and how much ram it uses while forwarding a puredata session over X-forwarding. 
 
I'm open to any questions. Thanks. 

I have to close the door when I'm soldering. My black cat only walks by but my whitevone tries to catch the iron and the cables...
 
 
Edit: typo.
 
 
Enviado desde mi Jolla mediante Tapatalk
 
 
 
 

You need to buy an Eltechs license I think this type: Eltechs ExaGear Desktop for ARMv7 devices and after installing ExaGear intall inside WINE and inside of Wine the Windows software.
I do some test https://raspberryparatorpes.net/instalacion/probando-exagear-emulador-x86-sobre-arm/
but for me is only usable under ODROID-U3 quad core 2GB RAM and eMMC memory.

I was curious to see how Mainline kernel performs on GbE test against a Legacy kernel.
 
For the Armbian side i chose the nightly dev Armbian_5.27.170602_Orangepiwin_Ubuntu_xenial_dev_4.11.1_desktop.img  (Desktop) and for the Legacy i chose my own build with all  "Bells and whistles" (full Desktop, hdmi, camera, bt and wifi).
I did not optimized Armbian Mainline, just installed and run stock. For the Legacy i optimized as usual. If there is some optimization to do on Mainline side, i missed.
 
I have some observations about the board and results:
* Board is without Heat-sink,
* Legacy subsequent test got lower values, i suspect it runs hotter than Mainline, maybe due to HDMI, camera and BT enabled, drops about 30~50 MBits/sec,
* After Mainline installation, the next boot came without HDMI output, so i had to guess which IP was assigned without looking at router (OK, we know it is a development Image),
* Board act as a Server (iperf3 -s) and my ultra fast Duo core Intel box as a client.
* Both Image are build with gcc 6.3
 
Armbian Mainline kernel 4.11.1 results:
 
Legacy kernel 3.10.105 results:
 

Any of you have such a beautiful problem?
They like Orange Pi's, they are hot !
 
 
 
 

If Wireless is handled by a router that should be very simple: a web server as Apache or nginx, desired software and a compatible connected camera (ip or usb).

Enviado desde mi Jolla mediante Tapatalk

General public is easy to mislead to backup the project - general public aka kick-starter community is dumb as hell. It's all about marketing. SBC's are still hot stuff and hardware development become ridiculous cheap so it's a great way to make money.
 
As I see you already made it to persuade investors. Why bother developers community, where you don't intent to invest more then few free boards here and there and use our channels for free marketing? BTW: You can run your marketing campaign on your own website or wherever but here you need to ask for permission. I hate ads.
 
Even before your boards become stable (to be used by professionals which is stated in your first line of your marketing appeal) you will probably restart the whole thing with a "new and better" board and hope to catch as many backers as possible. All board manufacturers are using community's current and future contribution in their business models and everyone want's to become next RPi in numbers. This is the only way you don't need to pledge anyone. Until then, we control the game.
 
Free sample? I have a bunch of boards and so do other people who develop and contribute. I don't even think to support your boards without paradigm change toward community. You collected the money for our work and you kept it. What the f*?
 
You are an engineer. It's is not your fault nor responsibility to think about this in such way. Don't take it personally either.

Main source repo for build tools:
https://github.com/igorpecovnik/lib
Bug tracker:
https://github.com/armbian/build/issues
 
Documentation - not perfect, but they exists:
https://docs.armbian.com/

For SBC to provide USB3 either the SoC has to be USB3 capable or the SoC needs a high speed bus (like PCIe) to attach an USB3 controller to it (which would be wrong if the SoC has just a single PCIe lane since then you don't use USB3 but SATA instead). That's why Armbian currently only supports the following boards with USB3:
 
LeMaker Guitar and Roseapple Pi (Actions Semi S500 is USB3 capable but performance and software support are a sh*t show and Ethernet there is Fast Ethernet only --> forget about NAS use cases) Clearfog Base / Clearfog Pro (always wrong to use USB3 here since they feature native SATA -- performance numbers/comparison) ODROID XU4 (too expensive, technically questionable since everything is USB there, an internal USB hub is always between host controller and disks and host controller as well as recommended peripherals have their own issues paired with a user base trapped in a micro community rejecting reality) Hummingboard (you could add USB3 via a mPCIe card here but this would be wrong since this board has native SATA but limited Gigabit Ethernet so NAS performance is even lower than what cheap USB2/GbE H3/H5 boards provide)  
What's coming soon with USB3:
 
EspressoBin (using USB3 here is just wrong since the board features native SATA -- even up to 3 ports by adding a cheap ASM1062 mPCIe card). Status: ready soon Helios4 (4 x SATA so why thinking about the 2 x USB3? ): Status: ready soon (the board is on Kickstarter the next 4 weeks) Rock64 (not even announced using Quad core Cortex-A53 RK3328 with native Gigabit Ethernet and USB3). Status: unknown but if price and SDK looks good there's no doubt Armbian will support it Rockchip RK3399 based devices (like this): Status: not even really announced, IMO uninteresting since way too expensive Boards based on Allwinner H6 (Quad core Cortex-A53, new 28nm process, 1 x USB3, PCIe 2.x x1 so you could avoid USB3 and use SATA through an ASM1061 instead). Status: nothing announced yet but if price and SDK looks good there's no doubt Armbian will support it (speaking of 2018)  
In other words: for NAS use cases forget about USB3 now and in the foreseeable future, choose EspressoBin if you want both affordable and fast or choose the combination H3/H5+GbE+USB2. Only potential exception from the USB3 rule: Rock64 soon and maybe later Allwinner H6 based boards.
 
(Allwinner A20/R40 boards not mentioned by intention since too slow and especially R40 at the moment close to unusable since the only board available is from SinoVoip so no vendor support and most probably documentation/schematic f*cked up as usual)
 
 

Yesterday my 14" Pinebook arrived so I thought I'll collect some already available information. A lot of work still has to be done to get a decent laptop experience with this hardware so this is neither a review nor a stupid Un-Review but just a preview instead.
 
To get the idea about dimensions I added a 13" and a 15" laptop to the picture. Pinebook is wedge-shaped and thickness matches both the 2011 15" MacBook Pro and the 13" from 2015:
 

 
Display size closely matches the 13" MacBook Pro (but of course pixel density / resolution don't match as well as quality: TN vs. IPS and coating -- it should be obvious if you've the 'you get what you pay for' principle in mind but I'm sure we'll see reviews somewhere else where people are comparing Pinebook with Chrome/MacBooks and think they would get the same display quality for a fraction of costs)
 
Last hardware detail: heat dissipation. I've been curious how well the Pinebook's thermal design is and it looks pretty good. This is the moronic sysbench pseudo benchmark calculating prime numbers endlessly and the Pinebook sitting on a pillow to prevent airflow below the case bottom. Throttling settings are rather conservative with 65°C defined as first trip point and only after a couple of minutes the internal A64 SoC temperature reached this value and slight throttling occured (1.15 GHz down to 1.1 GHz, that's a 'difference' you won't be able to notice). So it seems the combination of a thermal pad with a large metal plate inside the case is rather sufficient:
 

 
What you see here is a graph drawn by RPi-Monitor, one of my favourite tools to get a clue what's going on with ARM devices (since it's not a heavy monitoring tool that changes the way the OS behaves but it's pretty lightweight sp you can run it in the background and let it monitor/record stuff like cpufreq scaling, consumption and so on).
 
Pinebook currently ships with a rather clean Ubuntu Xenial on the eMMC with Mate desktop environment based on latest BSP u-boot and kernel. To get RPi-Monitor installed on this Ubuntu @pfeerickprovides a script (please follow progress over there). When I played around with Wi-Fi I noticed that Wi-Fi powermanagement seems to be enabled (makes working via SSH close to impossible) and that MAC address changes on every reboot. To disable Wi-Fi powermanagement I simply used the Armbian way:
root@pinebook:~# cat /etc/NetworkManager/dispatcher.d/99disable-power-management #!/bin/sh case "$2" in up) /sbin/iwconfig $1 power off || true ;; down) /sbin/iwconfig $1 power on || true ;; esac Unless Wi-Fi driver gets a fix to use a MAC address based on the SoC's individual so called SID one way to assign a fixed MAC address for the Wi-Fi is to add a wifi.cloned-mac-address property to all NetworkManager profiles after establishing a Wi-Fi connection first:
nmcli con show | grep wlan | while read ; do set ${REPLY}; nmcli con modify "$1" wifi.cloned-mac-address $(cat /sys/class/net/$4/address); done (I'm pretty sure some masochistic people prefer fiddling around in /etc/network/interfaces instead so if you're not using your laptop as a laptop being carried around and seeing a lot of Wi-Fis you can also use the usual tweaks for the interfaces file. Please also note that using a random MAC address can be considered a privacy feature on laptops since it makes tracking of you in public environments harder).
 
While watching the Pinebook's charging/discharging behaviour I noticed that consumption drawn from wall while charging oscillates between 9W and 15W while being used and display active so it's really great that Pine Inc fixed Pine64's design flaw N° 1: Pinebook is NOT equipped with shitty Micro USB for DC-IN leading to all sorts of trouble but just like SoPine baseboard now uses a 3.5mm/1.35mm barrel jack combined with a 5V/3A PSU (for other hardware details please refer to linux-sunxi wiki page).
 
Battery status (health, capacity, voltage and so on) is already available through sysfs but some values are wrong or need calibration. This needs to be fixed with further upgrades. Also interesting: charging seems to be under control of the ARISC core inside A64 SoC and works together with Pinebook's AXP803 PMIC (powermanagement IC) even when there's no OS running. This will be somewhat challenging to implement later with mainline I would believe...
 
I'll stop here for now since Pinebook is still stuff for developers and not end users. Just some resources for interested parties:
https://github.com/ayufan-pine64/boot-tools (Kamil implemented an u-boot based approach to flash directly to eMMC and there you find the necessary BLOBs to convert other BSP based Pine64 images for Pinebook since different DRAM and other settings require different SPL+u-boot) https://github.com/ayufan-pine64/linux-pine64 (based on longsleep's BSP kernel but with more fixes currently for Pinebook) $mainline resources (I lost track where to find most recent stuff but will add this later)  
Wrt Armbian running on Pinebook we could now simply exchange u-boot+SPL+DT of our Xenial Desktop image... but I hope we won't do that but wait until dust has settled while helping with development efforts in the meantime. In other words: no Armbian on Pinebook (right) now