manuti reacted to tkaiser in Fix a damage SD card
If you're inexperienced maybe the best idea is to simply follow the 'Getting started' guide step by step: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card
(so prior to flashing with Etcher always testing the SD card first with F3 or H2testw and in case this is an SD card that was already in use you might want to reset it to 'factory performance' with 'SD Formatter' in the next step still prior to flashing with Etcher -- everything explained in the link above)
manuti reacted to antricos in RPi-monitor remove - fix
Found a solution.
Because I installed it with this command sudo armbianmonitor -r i couldn't remove it with sudo apt autoremove rpimonitor.
However this is what I did :
1. sudo apt autoremove rpimonitor (uninstall some portion of the unofficial package)
2. sudo apt-get install rpimonitor (install the official package)
3. sudo apt autoremove rpimonitor (uninstall official package completely)
manuti reacted to antricos in RPi-monitor remove - fix
I'm new here and i would like to ask a question.
I have installed rpimonitor on an Orange PI zero but doesn't work so good (graphs doesn't show) so i decided to uninstall.
However I cannot! It removes "some" of it but I still get the rpi monitor screen at 8888 port...
sudo apt autoremove rpimonitor
sudo apt-get purge rpimonitor
Can somebody help me remove it completely?
I installed it with this command sudo armbianmonitor -r
manuti reacted to tkaiser in Orange Pi Zero Plus 2 available
Funnily with Zero Plus 2 a silent downgrade to H3 happened (I would assume that's related to Xunlong's software guy Buddy not being able to resolve voltage regulation issues with Allwinner's BSP and H5): http://www.cnx-software.com/2017/03/17/18-9-orange-pi-zero-plus-2-board-allwinner-h3-wifi-bluetooth-le-hdmi-and-8gb-emmc-flash/
manuti reacted to Braulio in OpenGL on Mali GPU (BananaPi, OrangePi PC, etc)
Hello guys , I try to install Gl4ES (https://github.com/ptitSeb/gl4es) with success , in armbian Ubuntu Xenial Desktop . For GL4ES you need to "put libGL.so.1 in your LD_LIBRARY_PATH". LD_LIBRARY_PATH is "/usr/lib/arm-linux-gnueabihf" in the same path you need find "mesa" folder and rename it to ".mesa", maybe is the same for glshim.
You can run games like foobillard++ , openarena,quake ,etc .
Gl4ES is a wrapper for OpenGL 1.5, but the Hardware accelerated for chromium or firefox doesnt work.
manuti reacted to bob_v2 in h3consumption to be included into future Armbian releases
Worked for me.
Orange Pi one
root@orangepione:~# h3consumption -p
cpu 1200 mhz allowed, 1200 mhz possible, 4 cores active
dram 624 mhz
usb ports active
eth0 100Mb/s/Full, Link: yes
manuti reacted to olti in OrangePi Zero high temperature?
1st OPi Zero (512 MB, heatsink, no case, capped to 768 MHz, room temp 15°C, 2A power supply via USB, ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i):
20:06:21: 240MHz 0.06 1% 0% 0% 0% 0% 0% 64°C
20:06:26: 240MHz 0.06 1% 0% 0% 0% 0% 0% 63°C
20:06:31: 240MHz 0.05 2% 1% 0% 0% 0% 0% 64°C
2nd OPi Zero (256 MB, no heatsink, no case, capped to 768 MHz, room temp 10°C, 1.5A power supply via pin1+2, ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i):
20:05:35: 240MHz 0.17 2% 1% 0% 0% 0% 0% 60°C
20:05:40: 240MHz 0.16 1% 1% 0% 0% 0% 0% 60°C
20:05:45: 240MHz 0.14 1% 1% 0% 0% 0% 0% 61°C
So there seems to be no effect of power supply.
However, it runs 50°C over room temp on idle... I wonder what will happen in the summer
To compare: OPi One, heatsink, case, room temp 15 °C, ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i:
20:11:09: 1008MHz 0.34 3% 0% 3% 0% 0% 0% 34°C
20:11:15: 1008MHz 0.40 4% 0% 3% 0% 0% 0% 35°C
20:11:20: 240MHz 0.37 4% 0% 3% 0% 0% 0% 35°C
manuti reacted to tkaiser in A cluster with 5 BPI M2+
Well, I have to admit that I don't understand why you're talking about Raid0/Raid5 spanning accross different servers. IMO the whole idea is questionable especially using 5 overpriced SBC (BPi M2+ is IMO the least interesting H3 device around, if you need same feature set then look at NanoPi M1 Plus that doesn't overheat that much due to better voltage regulation or even Orange Pi Plus 2E where you get way faster eMMC twice the size and also 2GB DRAM and slightly higher clocked CPU).
Anyway: if I would have a use case where SBC with Gigabit Ethernet and as much USB2 ports as possible are required I would clearly go for Orange Pi PC 2 instead. And if I would like to implement RAID I clearly wouldn't use 5 SBC with USB disks but one board combined with SATA disks for the same price: Clearfog Pro combined with 2 x ASM1062 in the mPCIe slots for example.
manuti reacted to tkaiser in Wi-Fi performance and known issues on SBC
In the meantime my Zero W arrived and it took me only 1 hour to set up Raspbian headlessly on the device:
Quick Wi-Fi test made in 'location 1' using the well known script from above (still not showing differences regarding powermanagement since this also has no effect on the Zero W -- it's still just result variation):
RPi 3 (kernel 4.9.13-v7+):
powermanagement on: 23.36 Mbits/sec powermanagement off: 22.54 Mbits/sec
RPi Zero W (kernel 4.4.50+):
powermanagement on: 28.54 Mbits/sec powermanagement off: 27.68 Mbits/sec
RPi Zero W (after kernel upgrade to 4.9.13-v7+):
powermanagement on: 24.58 Mbits/sec powermanagement off: 25.49 Mbits/sec
So throughput is the same or at least not lower (tests done all at different hours so not comparable since uncontrolled environment) and that's also a good reason to not further waste time with RPi tests. To my surprise onboard aerials of both WiFi equipped RPi work quite well but can't overcome 2.4GHz single antenna limitations of course. For some numbers with more antennas, 5GHz too and also 802.11ac see here for example: https://netbeez.net/2016/06/01/iperf-wifi-comparison-on-raspberry-pi-raspberry-pi-3-vs-asus-vs-hawking-vs-linksys-vs-tp-link/
manuti reacted to tkaiser in Raspberry Pi Zero Wireless - Rumors & Speculation!
Not enabling SSH any more by default is now called a 'security update' since even RPi foundation got it that pre-defined users/passwords are a really bad thing: https://www.raspberrypi.org/blog/a-security-update-for-raspbian-pixel/
But instead of doing it correctly (forcing the user to change the password on 1st login or even create an own sudo enabled user) they chose to make it harder to set a new RPi up (I'm glad I did the first step with my RPi 3 since without knowing the /boot/ssh hack I would've been lost with Zero W since I have no HDMI adapter for this board).
Regarding wpa_supplicant: Really no need to use this anachronistic stuff even on Raspbian. All I did was
apt-get --no-install-recommends install network-manager iw reg set DE nmcli device wifi connect 'Snort-Honeynet' password 'secret' ifname wlan0 (nmtui didn't work for whatever reasons, maybe network-manager is too outdated in Raspbian? And I also had to add 'iw reg set DE' to /etc/rc.local to be able to use Wi-Fi channel 13 which is the one my AP always chooses in 2.4 GHz band since least polluted)
Will start testing on the weekend with Zero W since buyzero.de managed to process my order from 1st March yesterday and DHL tracking confirmed delivery today. Not the best performance compared to Pimoroni in last summer (they processed my first Zero order within 24 hours, sent from the UK for less costs in shorter total time) but it doesn't really matter since I don't think I'll ever buy 'non products' from this mythical Foundation again. If the 'Zero W' will ever turn from a marketing stunt into a product (can be bought in quantities and is available at normal resellers) then it doesn't matter how bad 'authorized resellers' perform or not
manuti reacted to tkaiser in Wi-Fi performance and known issues on SBC
Next round of tests in 'location 3' (still 5m away from AP with 2 walls in between, 1 m next to 'location 2' but with less troublesome stuff between devices and AP). I use the script from above to see whether enabling/disabling Wi-Fi powermanagement does change anything (or is possible at all). Obviously enabling/disabling on RPi 3 has no effect (brcmfmac driver), with RTL8189FTV and RTL8192CU is was not possible (same error message from iwconfig: 'Error for wireless request "Set Power Management" (8B2C) : SET failed on device wlan0 ; Operation not permitted.'), only with AP6212 (using legacy kernel dhd module) there were huge differences in performance.
I chose two rounds of tests at different times of the day. The first ran was shortly after midnight and the 2nd run started at 10:00 in the morning. This time I tried to find optimal antenna position but obviously that did not work that great with the TL-WN823N dongle (I have to admit that I slightly changed antenna positions between 1st and 2nd run, also not the best idea).
Software settings remained the same to before (so you can check dmesg output and so on above) and boards were tested one at a time (test execution lasts ~20 minutes which is also bad since environmental conditions between different test runs can change in between since for example the neighbour next to me transfers 15 min large amounts of data in his Wi-Fi interfering with mine and ruining performance in my network)
Results as follows, on the left nightly results as averaged iperf3 throughput numbers followed by those from now.
NanoPi Air, AP6212 module, external small vertical aerial:
powermanagement on: 5.53 / 5.16 Mbits/sec powermanagement off: 30.14 / 14.66 Mbits/sec
Orange Pi Lite, RTL8189FTV module, external small vertical aerial:
powermanagement on: 30.47 / 32.41 Mbits/sec powermanagement off: 30.57 / 32.56 Mbits/sec
ODROID-C2 with TP-Link MIMO TL-WN823N dongle, RTL8192CU module, upright position:
powermanagement on: 34.90 / 48.51 Mbits/sec powermanagement off: 35.34 / 49.27 Mbits/sec
RPi 3, BCM43438 module, onboard antenna oriented obviously properly:
powermanagement on: 35.42 / 25.59 Mbits/sec powermanagement off: 34.56 / 25.13 Mbits/sec How to interpret the results?
Powermanagement on/off matters at least with AP6212. With the other implementations there was no difference and numbers for on/off are just result variation. Further investigation needed whether it's just not possible adjusting PM settings with iwconfig or if it's not possible at all Environmental conditions matter at lot. Between the two test runs nothing regarding software/settings has changed, it was just different time of the day and slightly moving around antennas/boards. IMO it's already pretty obvious that this sort of 'performance' testing in real-world environments is too stupid to be continued since numbers depend highly on stuff you can't control. When RPi Zero W arrives I will add it to the test setup and move the whole setup to 'location 4' (will have to ask my neighbour to host the cardboard box with the 5 SBC inside). And then I might rewrite the testing script so that I can test through each board every 60 seconds to minimize external temporary influences.
Also interesting whether performance of TL-WN823N dongle improves when operated horizontally and not upright (Edit: nope). Same with Raspberries and their onboard antenna but here it seems upright position is better (at least when comparing the average 30 Mbits/sec from this test with the results from yesterday with RPi 3 just lying randomly around: 6 and 12 Mbits/sec)
manuti reacted to kasparsd in Guide: Orange Pi Zero GPIOs
It took me a while to get this ILI9340 based LCD monitor working with the Orange Pi Zero until I found a post on this forum that explains how the H2+ ports are mapped to the GPIO numbers in the Linux kernel. So I built an online tool that does the math for you:
Here is a map of all the Orange Pi Zero GPIO pins:
All the additional details are described in this blog post.
manuti reacted to tkaiser in BPi R16
Can't believe it myself
Well, I'm thinking about the data logger / sensor use case and compare here with el cheapo H2+/H3 boards. Given the used Ampak chip combined with a reasonable aerial provides long range connectivity (most probably then using 802.11b, right?) and battery situation and price are ok it might be worth a look (ok, differs a bit from 'interesting' as before).
We'll see. At least this hardware category starts to emerge (cheap Allwinner IoT stuff with battery support). BTW: It's 2 USB ports, 1 x host and 1 OTG
manuti reacted to tkaiser in BPi R16
Just FYI: the first interesting Banana board since ages: BPi R16 based on Allwinner's A33 SoC (R16 is just a relabeled A33 with a different Allwinner business unit being responsible for).
For R16 exists a horribly outdated 'SDK' made by Allwinner's BU5: https://github.com/tinalinux/linux-3.4 (relies on unpatched kernel 3.4.39 which might contain more security flaws than features in the meantime. Their tinalinux approach combines this with an outdated Android 4.4 and somehow also a smelly OpenWRT version for reasons unknown to me. Surprisingly they also rely on their own proprietary LiveSuit image format no one on this planet outside of Allwinner wants to use).
But the good news is: There are some mainline kernel branches with patches for A33 around that are in a pretty good shape eg. https://github.com/Icenowy/linux/tree/a33-cedrus-pr (seems Icenowy also managed to get Allwinner video engine working with mainline kernel already). So most probably no need to fiddle around with Allwinner's tinalinux stuff or SinoVoip OS images at all
For me personally such an R16 IoT board has one big advantage over el cheapo H2+/H3 boards: PMIC support and therefore the ability to use/charge a connected battery (and also control voltage/useage and act on accordingly).
Let's see whether SinoVoip manages to introduce the usual design flaws (eg. not being able to use an external aerial unless you desolder components on the board), when they release (hopefully accurate) schematics, how the battery connector looks like and whether this device will be priced competitively.
Edit: According to the above pictures the same DRAM as on NanoPi Air is used (512MiB K4B4G1646Q-BCK0 DDR3) and at least not the ultra-slow eMMC they used on every other board since BPi M2+ (there they use KLM8G1WEMB-B031 -- can't read the exact writing on the picture above)
Edit 2: According to linux-sunxi IRC Ampak AP6212 is used on the board (WiFi/BT combo like on nearly all other Banana boards and also NanoPi Air or the upcoming OPi Zero 2 -- so we then have 3 flat and lightweight boards with eMMC, camera connector and the same Wi-Fi/BT combination but from 3 different companies using 3 different Allwinner SoCs. Funny)
manuti reacted to tkaiser in Summary of boards for a NAS
Well, the majority of people does this sort of el cheapo NAS with an old 2.5" disk lying around. If we get back to the basics (see post #10 and especially #11 from my 2nd link above) we see that random IO with HDDs is crap anyway and that sequential throughput is also limited especially if the disk will be filled to its whole capacity (ZBR -- zone bit recording is responsible for empty HDDs being almost twice as fast as full HDDs)
For this use case Gigabit Ethernet and USB2.0 attached storage is already sufficient, if we've seen how A64 with an UASP connected SSD outperforms A20 with the same SSD connected through SATA when it's about random IO (3rd link above) then it's obvious that 'SATA' is not an own value but it depends on the SATA implementation in question (again: 2nd link above). So regarding el cheapo NAS an OPi PC2 combined with good USB enclosures is already sufficient. Gets even better if Xunlong will make such a NAS Zero with H5 and GBit Ethernet.
Regarding performant NAS attempts in SBC form factor please be aware that there's ESPRESSOBin and maybe other Marvell designs will follow.
Edit: One of the real advantages of SATA regardless of performance is that you have better control over HDD/SSD features (checking drive health with SMART, setting disk sleep parameters, being able to make use of TRIM). This is stuff that does not work automatically with USB but it always depends on the bridge chip used in the enclosure (and that's why I love Xunlong's decision to put 2 of the best available USB-to-SATA bridges on their NAS Expansion board, now only the appropriate H5 board missing )
manuti reacted to Igor in Armbian on MiQi SBC hardware ?
MiQi added to Armbian. What I did:
- added kernel 4.4.50 ... took from https://github.com/mqmaker/linux-rockchip(4.4.16) ... and patch all the way up to 4.4.50.
- added stock MiQi uboot. I tried too merge it with mainline but figured out soon that it's not going to be easy and abandoned that
- added boot scripts with environment file
- packaged kernel, u-boot, ...
- updated kernel config to meet Docker requirements
- added proper serial console
- tested CLI and desktop build. Both runs smoothly.
Known bugs: random MAC, eMMC install script and boot script need some adjustments
Unknown: mali, video accleration librarires, ... etc. most likely those should go: https://github.com/mqmaker/rk-rootfs-build
From tomorrow morning, betas will be available here: https://dl.armbian.com/miqi/nightly/
manuti got a reaction from köksal in XFCE in Spanish or any other language
Yes. is completely and always in Spanish, the XFCE GUI and the Terminal. You can check here https://raspberryparatorpes.net/comandos/armbian-en-espaol/ but I repeat also just below.
The steps are:
1. Remove and reinstall the locales from the Terminal / console / CLI:
sudo apt-get purge locales sudo apt-get install locales 2. Configure the locales choosing Spanish, es_ES UTF-8:
sudo dpkg-reconfigure locales 3. Confirm that everything is OK using locale command:
locale If some line is not es_ES.UTF-8 you must change doing:
export LANGUAGE=es_ES.UTF-8 export LANG=es_ES.UTF-8 4. And after that regenerate the locales:
sudo locale-gen es_ES.UTF-8 5. And finally install the language pack for the common apps like LibreOffice and Firefox:
sudo apt-get install libreoffice-help-es libreoffice-l10n-es firefox-l10n-es-es
manuti got a reaction from Igor in Which image should I install on Odroid U3 Community (exynos4412)
No, ODROID-U3 is not supported and I suppose that's is not going to happen. You must use the hardkernel official images.