Eng-Shien Wu

It was working on the 5.11 builds. I have not checked the latest builds, but it should still be working.

Nice work on the WiFi, but my understanding is that there is no Bluetooth on the Beelink X2. The chip on the board says AP6181 which has the same Broadcom WiFi module as the AP6210 but does not have the Bluetooth module.

I tried getting the wifi working a while back, but not a serious effort as I typically use a better performing USB Wi-Fi dongle. The main hurdle on the internal Wi-Fi was that the drivers exist in the sun7i but not the sun8i kernel. I was more interested in the eMMC, but didn't even know where to start.

Beelink X2 running "lima-memtester 100M" and the setting "dram_clk = 648". Grey background entire time, but only running 1 core at end--it is possible that I messed up the heatsink when I opened it up to solder serial out.

If you mean the AV port, you need to unmute: amixer set -c 0 'Audio lineout' unmute Then test it by speaker-test -twav -c2 -Dhw:0 (need to sudo if your user isn't member of audio group)

@tkaiser: thanks for the tip--now motd is correct. I have updated the Armbian 5.10 Beelink X2 image and re-uploaded: download here. @Tido: thanks for the links. From the picture, I was able to identify the WiFi module as AP6181 with a Broadcom chipset. According to this forum topic, the chipset is also used by BPi-M2 and the proper module is brcmfmac. However, loading the module doesn't seem to do anything. Another issue is that the internal eMMC doesn't not appear as /dev/mmcblk0 (SD card) or any device. Maybe this is because of the Android-derived config.bin. At this point, I am at the end of my skill/knowledge level to push this image further. Maybe others with better skills can figure out what I can't. As is, it is quite usable and snappy.

I have a working version of Armbian 5.10: download here [link updated 2016-05-07] Working Ethernet USB ports (2) HDMI w/ sound Not working: WiFi is missing No sound via S/PDIF Basically, I overwrite /boot/bin/beelinkx2.bin with the one from the blog post. I also manually link it to /boot/script.bin as /etc/init.d/firstrun is failing to detect that it is a Beelink X2 (/run/machine.id returns that it is a 'Orange Pi PC'). I think from this, somebody with a Beelink X2 should be able to figure out how to make Armbian work out of the box. I will look at this again next week if somebody hasn't already beat me to the punch. This script should reproduce the image:

Orange Pi Plus2 (3.4.110-sun8i) Internal 16GB eMMC (ext4 default) Samsung EVO+ 32GB

[Deleted]

My ES9024 DAC arrived earlier and I have been happily listening to music with it for the past several days. I can confirm that the instructions are correct and that the DAC works very well. The biggest challenge was soldering on female pin headers onto the wires (need small tip) and editing /boot/script.bin because I am a H3 noob (bin2fex/fex2bin). An easier option, albeit of lower sound quality (16-bit 48k), is a cm108 USB Sound DAC: http://www.banggood.com/USB-Virtual-7_1-Channel-Audio-Sound-Card-Adapter-p-938086.html It is plug-and-play on Armbian 5.05 and shows up as the third audio device (assuming you didn't edit script.bin for i2s): sudo aplay -l sudo speaker-test -twav -c2 -Dhw:2

@zamar19: the audio via AV port works just fine on OPI PC in Armbian 5.05, but you need to unmute it: amixer set -c 0 'Audio lineout' unmute Then test it by speaker-test -twav -c2 -Dhw:0 @Igor: Maybe first_run should unmute the Audio lineout by default? [That said, for my application (shairport-sync), the native audio of the OPI PC, like that of the NTC Chip and Raspberry PI 2b+, is unusable (either bad quality and/or loud pops when switching songs).]

Just curious.. what do you intend to use WIFI monitor mode for?

What is wrong with the ARMv7 binaries in https://nodejs.org/en/download/stable/(works for my code)?

If I understand correctly, the implications of a fixed voltage regulator is that the BPi M2+ will need a fan to achieve the same CPU performance under load as the OPI PC AND it won't support a low power 'idle'. I would consider that a FATAL FLAW for most ARM board use-cases.