manuti reacted to rodolfo in improve XFCE experience
I've been using Linux desktops on a vast number of physical and virtual systems from enterprise to dinky toys, standardizing on plain Debian and LXDE for robust and stable systems. The LXDE-desktop uses even less ressources than XFCE and is particularly suited for small boards. The choice of desktop ( XFCE ) and Ubuntu bloat are somewhat contrary to the idea of Armbian as a lean and robust distribution. If your seriously interested in Linux desktops opt for the real thing and set up a lightning fast LXDE desktop based on Debian stable. In combination with x2go terminal server you'll experience a vastly superior and universal desktop world.
manuti reacted to tkaiser in Some storage benchmarks on SBCs
Early 2018 update
Time for another small update. It's 2018 now and since it seems Armbian will support a couple of RK3399 devices later this year let's have a closer look at the storage performance of them.
RK3399 provides 2 individual USB3 ports which seem to share a bandwidth limitation (you get with a fast SSD close to 400MB/s on each USB3 port but with two SSDs accessed in parallel total bandwidth won't exceed 400MB/s). RK3399 also features a PCIe 2.1 implemenation with 4 lanes that should operate at Gen2 link speeds (that's 5GT/s so in total we would talk about 20GT/s if the SoC is able to cope with this high bandwidth). Rockchip changed their latest RK3399 TRM (technical reference manual) last year and downgraded specs from Gen2 to Gen1 (2.5GT/s or 10GT/s with 4 lanes). So there was some doubt whether there's an internal overall bandwidth limitation or something like that (see speculation and links here).
Fortunately a Theobroma engineer did a test recently using Theobroma System's RK3399-Q7 with a pretty fast Samsung EVO 960 NVMe SSD: https://irclog.whitequark.org/linux-rockchip/2018-03-14 -- it seems RK3399 is able to deal with storage access at up to 1.6GB/s (yes, GB/s and not MB/s). This is not only important if you want ultra fast NVMe storage (directly attached via PCIe and using a way more modern and efficient protocol like ancient AHCI used by SATA) but also if RK3399 device vendors want to put PCIe attached SATA controllers on their boards. ODROID guys chose to go with an ASM1061 (single lane) on their upcoming N1 since they feared switching to a x2 (dual lane) chip would only increase costs while providing no benefits. But Theobroma's test results are an indication that even x4 attached controllers using all PCIe lanes could make reasonable use of the full PCIe bandwidth of 20GT/s.
Below we'll now have a look at USB3/UAS performance and PCIe attached SATA using ASM1061 (both done on an ODROID N1 developer sample some weeks ago). Those tests still use my usual EVO840 SATA SSD so results are comparable. You see two ASM1061 numbers since one is made with active PCIe link state powermanagement and the other without (more or less only affecting access patterns with small block sizes).
Then of course beeble's NVMe SSD tests are listed (here fio and there iozone -- numbers should also be valid for the other RK3399 devices where you can access all 4 PCIe lanes via M.2 key M or a normal PCIe slot: Rock960, NanoPC-T4 or RockPro64 (M.2 adapter needed then of course -- ayufan tested and got even better iozone numbers than beeble). And maybe later I'll add SATA and USB3 results from EspressoBin with latest bootloader/kernel.
(for an explanation which boards represent which SoC and why please see my last post above)
Random IO in IOPS Sequential IO in MB/sec 4K read/write 1M read/write RPi 2 under-volted 2033/2009 29 / 29 RPi 2 2525/2667 30 / 30 Pine64 (USB2/UAS) 2836/2913 42 / 41 Banana Pi Pro (SATA) 3943/3478 122 / 37 Wandboard Quad (SATA) 4141/5073 100 / 100 ODROID-XU4 (USB3/UAS) 4637/5126 262 / 282 ROCK64 (USB3/UAS) 4619/5972 311 / 297 EspressoBin (SATA) 8493/16202 361 / 402 Clearfog Pro (SATA) 10148/19184 507 / 448 RK3399 (USB3/UAS) 5994/6308 330 / 340 ASM1061 powersave 6010/7900 320 / 325 ASM1061 performance 9820/16230 330 / 330 RK3399-Q7 (NVMe) 11640/36900 1070 / 1150 As we can see RK3399 USB3 performance slightly improved compared to RK3328 (Rock64). It should also be obvious that 'USB SATA' as in this case using USB3/SuperSpeed combined with a great UAS capable USB-to-SATA bridge (JMicron JMS567 or JMS578, ASMedia ASM1153 or ASM1351) is not really that worse compared to either PCIe attached SATA or 'native SATA'. If it's about sequential performance then USB3 even outperforms PCIe attached SATA slightly. The 2 USB3 ports RK3399 provides when combined with great UAS capable bridges are really worth a look to attach storage to.
NVMe obviously outperforms all SATA variants. And while combining an ultra fast and somewhat expensive NVMe SSD with a dev board is usually nothing that happens in the wild at least it's important to know how the limitations look like. As we've seen from the RK3399-Q7 tests with fio and larger blocksizes we get close to 1600 MB/s at the application layer which is kinda impressive for devices of this type. Another interesting thing is how NVMe helps with keeping performance up: This is /proc/interrupts after an iozone run bound to the 2 big cores (taskset -c 4-5): https://gist.github.com/kgoger/768e987eca09fdb9c02a85819e704122 -- the IRQ processing happens on the same cores automagically, no more IRQ affinity issues with all interrupts ending up on cpu0
Edit 1: Replaced Pine64 numbers made with EVO750 from last year with fresh ones done with a more recent mainline kernel and my usual EVO840
Edit 2: Added Rasperry Pi 2 results from here.
Edit 3: Added EspressoBin numbers from here.
manuti reacted to guidol in How to auto mount NAS after boot?
you could try to create a script which does check the mounts and create a auto-mount in cron every minute if isnt mounted.
take a look here for commands:
manuti reacted to Moklev in Motioneye (OPI)
You don't need a new guide. Motion 4.1.1 isn't available on Armbian, Mr Dave's build is only for Raspbian.
On Armbian (i.e. Orange Pi Zero) download new Stretch build 5.38 next, mainline 4.14.14. Do not use Ubuntu.
Follow original installation guideline:
(For Debian Stretch)
BEFORE point 4 install pip dependencies:
sudo pip install wheel
sudo pip install setuptools
sudo apt-get install zlibc zlib-gst zlib1g-dev
Continue to point 4...
... at the end of installation point to [yourip]:8765 and configure it.
et voilà! :-)
Now Motioneye 0.38 run on motion 4.01.
New motion version is usefull for new cam h264/rtsp based.
With little OPZ performance is quite respectable:
15fps (streaming) / 10 fps (analisys and capture) with a HD stream 1280x720px, H264 900 kbit/s
12fps (streaming) / 7 fps (analisys and capture) with a HD stream 1280x720px, mjpeg 2,5 mbit/s
Load: 1.94 1.24 0.53
Temp: 70 °C
(without hardware acceleration...)
manuti reacted to Igor in Next major upgrade v5.60
On Which image can I test? Any
How? Go to armbian-config -> System -> Nightly and proceed. If this option is not there, defreeze upgrading
Restart and after your system is up, proceed to one of those areas:
- desktop install from armbian-config on top of CLI (any board)
- set first_run_network configuration, setting ip within /boot/armbian_first_run.txt (any board except Espressobin)
- kernel switching or upgrade (any board, especially Odroid XU4 NEXT)
- setting fixed/dhcp network with armbian-config (any board except Espressobin)
- configure frame buffer within h3disp utility (any h3 board with a legacy kernel)
- DTS sound on DEV kernel (miqi, Tinkerboard)
- ROCK 64 default kernel
- check effects of changing everything to Network Manager withing firstrun/armhwinfo and other scripty
- check install from a blank image (https://dl.armbian.com/odroidc2/nightly/ and https://dl.armbian.com/orangepiplus2e/nightly/)
- set AP mode (any board)
All changes are reflected in a beta repository and are coming from the build script, branch "development". If you want to build this state, use LIB_TAG="development" while running the script. Make sure you are doing this on sine test install.
In case you find a bug:
- report it here
- push a fix to the build script, branch development
manuti reacted to chwe in Powering through micro USB
Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!
The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).
Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.
Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).
Illustration 1: AWG print on cable
If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
*this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).
Figure 2: Voltage drop of a copper cable at various thiknesses
If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).
Illustration 2: Setup vor measurement
FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
Table 1: Specification of the tested chargers
Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
Table 2: Tested micro USB cables
After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.
Figure 3: Voltage drop at delivered current of all chargers
Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger. If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)
Figure 4: Voltage without load, with load and on output and @powerbank
Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side. The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
What's next? Should we never buy again a micro USB powered SBC? IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load. Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!
Illustration 3: Recommended powersource
manuti reacted to hojnikb in Kickstarter: Allwinner VPU support in the official Linux kernel
Even if they get h264 decoding working, its going to be a huge win for allwinner community.
Having a working h265 isn't really all that useful to be honest, since the common chips (H3,H5 etc) only support 8 bit decoding, while most media i came across is encoded for 10 bit.
h264 media on the other hand is still widely available, so having mainline support would be awesome. Now if someone would get this working under chrome or firefox, that would be a different ballgame
manuti got a reaction from w1nner4fun in MXQ Pro+ (plus) 4k Android 7.1.2, boot problem, probably lightdm
I can't remember all the options, but I think "armbian-config" has a switch to go directly to the Desktop or not.
And "nodm" must be properly configured see: https://wiki.archlinux.org/index.php/Nodm
manuti got a reaction from w1nner4fun in MXQ Pro+ (plus) 4k Android 7.1.2, boot problem, probably lightdm
These are my MXQ https://raspberryparatorpes.net/rivales/rivales-raspberry-pi-mxq-pro-4k-y-mxq-pro-plus/
Related to the performance of the OS, the system go quite well in my MXQ PRO PLUS (2GB RAM) but have micro freezes or hang for 1 second every minute in MXQ PRO (1GB RAM).
I flashed Ubuntu Mate and Debian Server. But the image installed to the eMMC is Armbian_5.37_S9xxx_Ubuntu_xenial_3.14.29_mate_20171226.img.xz
To install in the eMMC I use the option in armbian-config tool. You can launch from Terminal with:
sudo armbian-config I can't remember where it is exactly in the menu tree. Bear in mind when you choose to Install (install in SATA, NAND or something like this say the option) you lose the Android and the option don't ask for confirmations.
manuti got a reaction from w1nner4fun in MXQ Pro+ (plus) 4k Android 7.1.2, boot problem, probably lightdm
I have another MXQ Pro Plus 4K and works quite well.
I flashed finally Linux in eMMC memory.
Normally the system must start in graphic mode but asking for an user and password.
If you want to go straight to the Desktop you must install "nodm" ( sudo apt install nodm ) and maybe remove "lightdm". I don't have any flickering or video issues.
manuti reacted to ginkrust in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)
I was confused, my box doesn't have 9082xs it needs ssv6051 drivers which armbian @balbes150 supports
after installing all relevant firmware deb files, i see in dmesg
*** sta_cfg_set, /usr/lib/firmware/ssv6051/ssv6051-wifi.cfg *** [ 80.459198] ERROR: filp_open I looked for the file, is in /lib/firmware instead
my quick fix
ln -s /lib/firmware /usr/lib/firmware now wifi works. Using Armbian_5.41_S9xxx_Debian_stretch_3.14.29_server_20180305.img.xz
device: s905w based x96 mini with ssv6051
manuti reacted to w1nner4fun in MXQ Pro+ (plus) 4k Android 7.1.2, boot problem, probably lightdm
First, thanks everybody here for making this possible.
Second, I am a newbie on booting Linux on TV box, so bear with me. Thanks.
I have a MXQ Pro+ 4k (2GB RAM - 16GB storage - Android 7.1.2 - 64bit) box and have tried most of the recent images for x905s based TV boxes, following the instructions on the first page of this topic.
I have a semi-workable result using Armbian_5.37_S9xxx_Ubuntu_xenial_3.14.29_mate_20180203, but still it is not really usable.
I wrote this image to USB 3.0 stick and booted after updating via local update on Android.
After setting user I can only access desktop after typing ctrl+alt+f1 -> login -> startx.
The system doesn't login automatically and I get a lot of screen flickering with messages regarding lightdm and light desktop manager.
What am I doing wrong? How do I get to desktop automatically? Can anyone help, please?
(please ask if I didn't specify all the necessary details)
manuti reacted to TonyMac32 in Librecomputer Renegade RK3328
That's what I've been hearing, especially concerning ddr4.
I have a board coming, and a heatsink. So I can give some comments on the design/etc later on. My assumption going in is, other than RAM and a few pins, this should be virtually identical to Rock64. RK805/RK3328/GbE/Same USB setup/eMMC/etc. The big difference is the RAM.
manuti reacted to segv in [RK3328] Scishion V88 Piano and V88 Mini III TV boxes
Ayufan’s Armbian on a V88 Piano or V88 Mini III
These two TV boxes seem to be electrically identical except that the V88 Mini III has 2 GB RAM and 8 GB ROM whereas the V88 Piano has 4 GB RAM and 16 GB ROM.
They use the same PCB as can be seen from the photos in these FreakTab topics:-
I do not have a V88 Mini III to test but I believe that my results for the V88 Piano should also be relevant to it.
N.B. many sites claim that the V88 Piano has Gigabit Ethernet (1000 Mbps). It does not: it only has Fast Ethernet (100 Mbps) like the V88 Mini III.
One nice thing about these TV boxes is that, unlike many others, they will boot easily from a micro-SD card.
Just insert the card and power on
My aim was to have Ubuntu running with all version-specific partitions (boot and root) on a USB drive.
I wanted to keep Android in the internal eMMC so that I could dual-boot by just inserting or removing the micro-SD card.
I wanted to have the root partition on a USB stick for three reasons:
1) A good USB stick is faster than a micro-SD card.
2) This avoids the system writing repeatedly to the micro-SD card because, if the root partition is on the micro-SD card, after a while it gets corrupted and will no longer boot. This happened to me with both a cheap Ansonchina card and also with a Kingston card. Maybe the write timings in the micro-SD card driver are incorrect.
3) Whilst experimenting on Amlogic boxes I have fried two big micro-SD cards. I have read that others have fried cards on Rockchip boxes. Moving the rootfs to a USB stick enables me to use a smaller and cheaper card.
(I suspect that they were destroyed by over-voltage due to a badly programmed regulator. With a 5 V USB stick and a 5 V PSU there should be no risk as I don’t think the regulators used can step up the voltage.)
I also wanted the boot partition to be on the USB stick so that I could have several GNU/Linux distributions on different USB sticks and boot with the same unmodified micro-SD card containing just the boot loaders.
I have deliberately avoided the necessity to have a Linux (or even Windows) PC.
N.B. the Ubuntu system will not (yet) have working Wi-Fi.
You will need:-
- a rooted V88 Piano (mine was sold pre-rooted)
- a micro-SD card: mine was 8 GB but 4 GB should suffice
- a USB Flash Drive: I have used both 32 GB and 8 GB but 4 GB may suffice for a fairly minimal system
- a USB keyboard (and mouse if installing a desktop): I used a wireless mini-keyboard/mouse
- a wired (RJ45) Ethernet connection with DHCP and Internet access
- an HDMI display
WARNING: before using a /dev/ or /dev/block device verify that you are using the correct one, using dmesg for instance. Otherwise you could overwrite precious data.
However if you remove all additional USB drives the names below should be correct.
The login is rock64 with password rock64 which is also required for sudo.
First step – install Ayfan’s Ubuntu Xenial Minimal 0.5.15 on a micro-SD card and prepare 0.6.25 on a USB stick.
I installed and used Google Chrome for the following downloads because, with the stock Lightning browser, I couldn’t see when the download had finished.
(The busybox wget can't be used because it doesn’t support https.)
Open https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.15 in the browser.
If you wish to pass directly to Ubuntu Bionic you could use the Bionic 0.6.25 image instead of Xenial below.
However this may make it more difficult to update U-Boot later as I think a Xenial environment is expected to compile it.
Open https://github.com/ayufan-rock64/linux-build/releases/tag/0.6.25 in the browser.
Insert the micro-SD card and the USB stick.
N.B. all existing files on both will be destroyed.
You will be asked how to use the USB stick: choose "removable storage" and "cancel" if asked whether to format it.
Execute the following actions and commands (in the text following the $ or #).
Install and start ConnectBot.
Open a local shell.
Enter the directory where browsers save downloaded files.
# cd /sdcard/Download
Decompress the files.
# busybox xz -d xenial-minimal-rock64-0.5.15-136-arm64.img.xz
# busybox xz -d xenial-minimal-rock64-0.6.25-193-arm64.img.xz
Write the 0.6.25 image to the USB stick.
# dd if=xenial-minimal-rock64-0.6.25-193-arm64.img of=/dev/block/sda bs=1048576
Write the 0.5.15 image to the micro-SD card.
# dd if=xenial-minimal-rock64-0.5.15-136-arm64.img of=/dev/block/mmcblk1 bs=1048576
Ensure everything is written.
Power off the box.
Second step – boot Ayfan’s Ubuntu Xenial Minimal 0.5.15 and prepare the switch to 0.6.25 on the USB stick.
Insert the micro-SD card.
Boot and login (rock64/rock64).
$ sudo -s
Remove partitions 6 (boot) and 7 (root) from the micro-SD card so that U-Boot and Linux will use the ones on the USB stick next time.
Luckily this only deletes their entries so Linux can continue to use them until they are unmounted.
Reply "Yes" and "Ignore" to the warnings.
# parted /dev/mmcblk1
Third step - boot Ayfan’s Ubuntu Xenial Minimal 0.6.25 from the boot and root partitions on the USB stick and prepare to update to a recent version.
Insert the USB stick in the middle USB slot and insert the micro-SD card.
Boot and login.
$ sudo -s
This DHCP configuration will be necessary for Bionic.
# cd /etc/network/interfaces.d
# sed s/eth0/eth1/ eth0 > eth1
At the time of writing there are only pre-release versions of 0.6.x but Ayufan has promised an official release shortly after the official release of Bionic due on 24th April.
If, in addition to Ubuntu updates, you want to update to Auyufan's pre-release versions with an added risk of instability then:
# vi /etc/apt/sources.list.d/ayufan-rock64.list
Uncomment the last line
# apt update
The following lines are necessary if you update to a more recent Ayufan version which will disable eth1:
This is needed to re-enable eth1:
# apt install device-tree-compiler
Make rc.local enable eth1 which is disabled in recent versions and disable eth0 which is not used on the V88 Piano:
# vi /etc/rc.local
Add these two lines just before the last line (exit 0):
enable_dtoverlay eth1 ethernet@ff550000 okay
enable_dtoverlay eth0 ethernet@ff540000 disabled
# apt dist-upgrade -y
If you want a Mate desktop you can:
# install_desktop.sh mate
This gave me an error which I corrected with:
# apt -f install
If you wish you can also upgrade from Xenial to Bionic with do-release-upgrade.
You should now be running an up-to-date version with the boot and root partitions on the USB stick.
The next step will be to compile and install a more recent U-Boot supporting the USB 3.0 port correctly.
To be continued...
The procedure above may seem convoluted so here are some additional explanations.
0.5.15 is used for its boot loaders as it is the latest version which will boot directly from a micro-SD card. Unfortunately it does not have working Ethernet and its U-Boot will not load correctly from the USB 3.0 slot.
0.6.25 is used because it has working Ethernet to install device-tree-compiler which is needed to re-enable eth1 on recent versions.
manuti reacted to heimlich in Armbian very slow on mxq pro 4k s905
Answer to myself, in fact i had problems on my bpl but now my lan is ok.
But i ve got another problem, plex server is installed on my mxq pro, when plex check the library after a short time it is freezed.
Where can i see temp log? What is the max temp supported?
manuti reacted to balbes150 in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)
The test version of the KODI-17.6 (for s905\s905x). Important warning. This version is built on Ubuntu, so when you try to install on Debian libraries may not be suitable and you will have to manually install the necessary packages and create the necessary links to these libraries. In the future, I hope to build a deb version of the package for Debian as well. The order of installing the new version on the previous images.
1. To remove all packages with for version 17.3 names that start in aml-* (amremote, mali, kodi).
2. Remove the package "libasound2-plugins" with all its dependencies (**this is important**). Corrected. This item does not need to perform.
3. Restart the system.
4. Install a set of new packages at this link (aml-remote aml-codec aml-mali6 aml-kodi).
5. Restart the system.
After these steps, you can test the new version of KODI-17.6.
Please note-this is a test version and there may be errors. You can go back to the previous version of KODI-17.3 (remove the new packages and install old versions of packages).
Update Armband images for s9xxx 20180303 .
In the image with Ubuntu Mate now uses a new version of KODI 17.6 (for s905\s905x).
manuti reacted to TheLinuxBug in H2: Sunvell R69 Android TV Box (AliExpress)
Well, it wasn't that weekend, it took me a while but I did eventually make a blog post for it: Sunvell R69 - My adventures with a cheap TV Box
Additionally, Sunvell R69 is fully supported by H3Droid but we do suggest the use of a fan for sure!
manuti reacted to tkaiser in Learning from DietPi!
The nice dashboard screenshot above is used by @Fourdee to explain why DietPi is superiour to Armbian: 'With #DietPi, logs and DietPi scripts are mounted to RAM , this reduces SD card write operations vastly' -- while I don't understand the purpose to 'mount scripts to RAM' of course the idea to cache logs into RAM is great! That's why Armbian does it since 2014 already.
While the above 'proof' is somewhat questionable (watching a 5 min period in a dashboard and once there's activity in one graph taking a screenshot with numbers without meaning) let's look into what makes DietPi that superiour compared to Armbian since it's always a great idea to improve even if that means taking over other project's USPs.
For whatever reasons DietPi dropped support for all Orange and Banana Pis recently (seems this started with a conversation between @Igor and @Fourdee on Twitter, then continued here and ended up there) so I had to take another board to do a direct comparison. The only boards that are supported by both projects are now Pine64, Rock64, Tinkerboard, some NanoPi and the ODROIDs. I chose Rock64 mostly to ensure that we use same kernel and almost same settings (Armbian's philosophy is to fix as much as possible upstream so our usual performance fixes went into ayufan's Rock64 build scripts DietPi in this case is relying on by accident so even DietPi users can continue to benefit from our work )
I took latest official DietPi image for Rock64 and the first surprise was the rootfs being pretty small and entirely full so no way to proceed:
/dev/mmcblk1p7 466M 453M 0 100% / For whatever reasons DietPi chose to overtake ayufan's partition layout (for users new to DietPi: this is always just someone else's Debian image processed manually and by some scripts until it becames 'DietPi') but their 'dietpi-drive_manager' responsible to resize the rootfs seems not to be able to cope with this (I wanted to report it to DietPi but there's already a report that gets ignored and it seems I can't comment there).
Edit: Ah, it seems @Fourdee blocked me from helping them entirely. I wanted to assist DietPi folks over at https://github.com/Fourdee/DietPi/issues/1550 but can't point them to fix the thermal issues they're running into again or why it's a bit weird to reintroduce the 'rootmydevice' issue again or why the new Allwinner BSP code is not such a great idea due to non-existing dvfs/thermal support
Fortunately our scripts below /usr/local/sbin/ were not deleted by DietPi so I simply called /usr/local/sbin/resize_rootfs.sh which instantly resized the rootfs partition and was then able to continue. For whatever reasons it took 3 whole reboots to get DietPi upgraded to their latest version v6.2 but then I was able to do so some measurements:
I then downloaded our Rock64 nightly image (based on Ubuntu Xenial but that doesn't matter that much -- as we all know the userland stuff is close to irrelevant since kernel and settings matter) and did the same thing. But no reboot needed since for whatever reasons DietPi remained on pretty outdated 4.4.77 kernel so I chose to not update Armbian's kernel to our 4.4.115 but to remain at 4.4.77 too:
Let's look at the results leaving aside the various performance and security issues DietPi suffers from since not relevant if we want to look at stuff where DietPi outperforms Armbian. First 'idle behaviour':
DietPi Armbian DRAM used: 39 MB (2%) 44 MB (2%) processes: 120 134 cpufreq lowest: 97.5% 99.8% cpufreq highest: 2.0% 0.1% idle temp: 46°C 43.5°C %idle percent: 99.95% 99.98% So we're talking more or less about identical numbers. 'Used' memory after booting is 2% of the available 2GB (anyone thinking 'free' RAM would be desirable on Linux... please try to educate yourself: https://www.linuxatemyram.com), the count of processes reported by ps is almost the same, cpufreq behaviour, %idle percentage and temperatures are also the same (DietPi temperature readout is somewhat flawed since their 'cpu' tool affects system behaviour negatively).
Even if Armbian ships with almost twice as much packages installed by default the process count doesn't differ that much (and idling processes really don't hurt anyway) and used memory after booting also doesn't differ significantly. But this 'boot and sit there in idle' use case isn't that relevant anyway and in situations when RAM is really needed I would assume Armbian users are in a much better position since we ship with zram active allowed to use half of the physical DRAM (see here for a brief introduction to zram).
So far I don't see that much advantages (none to be honest) but most probably I missed something?
Anyway: let's continue focussing on storage utilization and 'use':
DietPi Armbian size img.7z: 104 MB 223 MB (x 2.1) size img: 668 MB 1.6 GB (x 2.5) rootfs size: 457 MB 1.2 GB (x 2.7) packages: 229 436 (x 1.9) commit interval: 5 s 600 s kB_wrtn: 156 KB 448 KB (x 2.9) kB_read: 1008 KB 5912 KB (x 5.9) So both compressed and uncompressed image sizes are much larger with Armbian, same goes for used space on the rootfs which is understandable given that Armbian does not try to be as minimalistic as possible (see the count of pre-installed packages). I don't think going minimalistic is something desirable though we could think about removing development related packages from default installations as @zador.blood.stained suggested already. Maybe it's worth to adjust the rootfs partition size calculation to use slightly less so the uncompressed image size can be a little bit smaller?
Anyway: for people being concerned about smallest image size possible even without leaving out packages from default install simply building an own image and then switching from ext4 to btrfs does the job since reducing image size to around ~60% (one of Armbian's advantages is that our images are not hand-crafted unique 'gems' but the fully automated result of our build system so everyone on this earth can simply build his own Armbian images suiting his own needs).
And besides that I really see no benefit in trying to get the rootfs size smaller since we surely don't want to start to encourage users to write Armbian images to old and crappy SD cards with less than 4GB size (though I already consider 4GB cards nothing anyone should use these days since almost all those cards are insanely slow). Let's better continue to educate our users about the importance to choose good and reliable SD cards!
Now looking at the last 3 lines above. I executed an 'iostat -y 3600' to query the kernel about the total amount of data read and written at the block device layer. within one whole hour With DietPi/Stretch 156KB/1008KB (write/read) were reported and with Armbian/Xenial 448KB/5912KB (write/read). All numbers are too low for further investigations though something is worth a look: that's the default rootfs 'commit interval.' DietPi seems to use ext4 defaults (sync every 5 seconds to SD card) while in Armbian we choose a somewhat high 10 minute value (commit=600).
So while with Armbian and 448 KB written in one hour almost three times as much data has been written at the block device layer it might be possible that the 156 KB written by the DietPi installation caused more wear at the flash layer below due to a phenomenon called Write Amplification (TL;DR version: writes at the flash layer happen at 'page sizes', usually 8K, and by using a high commit interval somewhat larger data chunks will be written only every few minutes which can result in significantly less page writes at the flash layer compared to writing every few seconds smaller chunks of data. Adding to the problem once a card is 'full' now we're talking about much higher Write Amplification since now not just pages are written but usually whole Erase Blocks are affected that are much larger. So please choose your SD card wisely and always use a much larger capacity than needed since there's no TRIM with SD cards in Linux!)
It would need a lot of more detailled analysis about this write behaviour but IMO it's not worth the efforts and Armbian's 10 min commit interval does a great job reducing further SD card wearout (anyone with too much spare time? Grab 'iostat 5' and 'iotop -o -b -d5 -q -t -k | grep -v Total' and start to analyse what's happening at the block device and application layer forgetting about the filesystem layer in between!)
So where's some room for improvement when comparing our defaults with DietPi's?
Maybe removing development related packages from default package list? Maybe tuning rootfs partition creation to use slightly less space? Mostly unrelated but an issue: improving our log2ram behaviour as already discussed?
manuti reacted to tkaiser in ODROID N1 -- not a review (yet)
USB3 anomalies / problems
When I tested this almost 2 weeks ago I did not pay attention close enough to the crappy write performance: 470 MB/s with 4 SSDs in parallel attached to all SATA and USB3 ports is just horribly low given that we have a 'per port' and a 'per port group' limitation of around 390 MB/s. What we should've seen is +650 MB/s taking the overhead into account. But 470 MB/s was already an indication that there's something wrong.
Fortunately in the meantime an ODROID community member tested various mirror attemps with 2 Seagate USB3 disks, reported 'RAID 0 doubles disk IO' while in reality showing exactly the opposite: None of his three mirror attempts (mdraid, lvm and btrfs) reported write performance exceeding 50 MB/s which is insanely low for a RAID0 made out of two 3.5" disks (such lousy numbers are usually not even possible with 2 USB2 disks on separate USB2 ports).
So let's take a look again: EVO840 and EVO750 both in JMS567 enclosures connected to each USB3 port. I simply created an mdraid RAID0 and measured sequential performance with 'taskset -c 5 iozone -e -I -a -s 500M -r 16384k -i 0 -i 1':
kB reclen write rewrite read reread 512000 16384 85367 85179 312532 315012 Yep, there's something seriously wrong when accessing two USB3 disks in parallel. Only 85 MB/s write and 310 MB/s read is way too low especially for rather fast SSDs. 'iostat 1' output shows that each disk when writing remains at ~83 tps (transactions per second): https://pastebin.com/CvgA3ggQ
Ok, let's try to get a clue what's bottlenecking. I removed the RAID0 and formatted both SSDs as ext4. First tests with only one SSD active at a time:
kB reclen write rewrite read reread EVO840 512000 16384 378665 382100 388932 392917 EVO750 512000 16384 386473 385902 377608 383549 Now trying to start the iozone runs at the same time (of course iozone tasks sent to different CPU cores to avoid CPU bottlenecks, same applies to IRQs: that's /proc/interrupts after test execution):
kB reclen write rewrite read reread EVO840 512000 16384 243482 215862 192638 160677 EVO750 512000 16384 214356 252474 168322 195164 So there is still some sort of a limitation but at least it's not as severe as in the mirror modes when all accesses to the two USB connected disks happen exactly in parallel.
When looking closer we see another USB3 problem long known from N1's little sibling ROCK64 (any RK3328 device is a much nearer relative to N1 than any of the other ODROIDs):
[ 3.433165] xhci-hcd xhci-hcd.7.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 3.433183] xhci-hcd xhci-hcd.7.auto: @00000000efc59440 00000000 00000000 1b000000 01078001 [ 3.441152] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 3.441171] xhci-hcd xhci-hcd.8.auto: @00000000efc7e440 00000000 00000000 1b000000 01078001 [ 11.363314] xhci-hcd xhci-hcd.7.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 11.376118] xhci-hcd xhci-hcd.7.auto: @00000000efc59e30 00000000 00000000 1b000000 01078001 [ 11.385567] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 11.395145] xhci-hcd xhci-hcd.8.auto: @00000000efc7ec30 00000000 00000000 1b000000 01078000 [ 465.710783] usb 8-1: new SuperSpeed USB device number 3 using xhci-hcd [ 465.807944] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 465.817503] xhci-hcd xhci-hcd.8.auto: @00000000efc7ea90 00000000 00000000 1b000000 01078001 [ 468.601895] usb 6-1: new SuperSpeed USB device number 3 using xhci-hcd [ 468.671876] xhci-hcd xhci-hcd.7.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 468.671881] xhci-hcd xhci-hcd.7.auto: @00000000efc591f0 00000000 00000000 1b000000 01078001 I updated bootloader and kernel this morning and have no idea whether this was introduced (again?) just recently or existed already before:
root@odroid:~# dpkg -l | egrep "odroid|bootini" ii bootini 20180226-8 arm64 boot.ini and its relatives for ODROID-N1 ii linux-odroidn1 4.4.112-16 arm64 Linux kernel for ODROID-N1
But I guess we're still talking about a lot of room for improvements when it's about XHCI/USB3, BSP kernel and RK3399
Edit: Strangely when I tested with USB3 when I received the N1 two weeks ago the RAID0 results weren't that low. Now I remembered what happened back then: I immediately discovered coherent pool size being too low and increased that to 2MB (gets removed every time the 'bootini' package will be updated). And guess what: that does the trick. I added 'coherent_pool=2M' to kernel cmdline and we're back at normal performance though there's still a ~390 MB/s overall limitation.
manuti reacted to tkaiser in Banana Pi R64
Just for the record: Banana people work on another MediaTek based board: https://github.com/BPI-SINOVOIP/BPI-files/commit/a3c53c233fd2059a43763a78b13ca1c5fd0b0f50
SoC is a MT7622A (dual core ARM Cortex A53 processor with some 'dedicated network accelerator', RAID/XOR engine, SATA and PCIe 2.0), latest bootloader commit suggests that the board will be equipped with 802.11ac (AC2600) Wi-Fi.