manuti reacted to TonyMac32 in La Frite (AML-S805X-AC)
It is extremely helpful that this is billed as a low-cost S905X. What I've read so far just basically says it's a clocked down Meson GXL with a few missing hardware supports (Max 1 GB RAM, 1080p, simpler vdec, etc). So software support should be mainly the same drivers, just a sparser device tree (I'm obviously glossing over some specifics that could be theoretically be an issue, but this is nothing like using an all-new SoC).
manuti reacted to TonyMac32 in Le Potato - writing armbian to eMMC
The Amlogic flash tools will be relevant when discussing La Frite as well, should we support it (I think the S805X is to the S905X what the H2+ is to the H3). I'll need to review their function (I actually plugged the eMMC in during boot of the SD to get it in a position where I could work with it the first time, not a fun task)
Sent from my Pixel using Tapatalk
manuti got a reaction from gounthar in H2: Sunvell R69 Android TV Box (AliExpress)
Is pretty old ... but this week I give a second chance to my Sunvell R69 and with new kernel from here
and never boot on Sandisk microSD card ... but works really perfect with Toshiba Exceria 16GB white color https://www.toshiba-memory.com/es/products/toshiba-microsd-cards-exceria-m302/
So @guidol maybe trying a different brand or micrSD cards works.
manuti reacted to balbes150 in Armbian for Amlogic S9xxx kernel 5.x
Information in this topic is very outdated see this topic.
The start system in Coreelec is not compatible with LibreELECE Armbian etc. If you run coreelec on your TV box, you will no longer be able to run LE and Armbian normally until the full recovery of the standard firmware via the USB Burn Tool and the new activation of the universal multi-boot, which is used in all new systems.
The new version 5.55 of images. In this version, images with a single DE (XFCE) and a server in composition are as close as possible to the official versions. Version with a Mate and Icewm will probably be later and the gathering will be from another branch GIT (specially adapted for this DE). Since now all the images will be collected using the main kernel "4.1 x", have a common structure for the entire line of s9xxx and differ significantly in steps when configuring the system, I open a separate topic for this direction.
The primary steps to capture an image, activate multi-boot, and select a dtb file are common with the previous images.
Please note that starting with the version number version 20180928.
Major change. A new algorithm for the use of the dtb. Starting with this version, you no longer need to copy the dtb files and rename it to "dtb.img." In order to specify which dtb file to use, you need to edit the file 'uEnv.ini" (specify the desired file name for use dtb). This is a plain text file and can be easily edited. This change will make it easy to update the kernel from the "deb" file in the future. The new algorithm is now used in the eMMC system installation script.
Be sure to activate multi-boot using the new image. If multiboot previously activated is required to repeat activation using files in a new image.
Pay attention. To use the system with
u-boot-2015 (regular firmware Android), you need to edit the file "uEnv.ini"
u-boot-2018, you need to edit the file "/extlinux/extlinux.conf"
For those who doubt or do not know what u-boot is used, you can specify the desired name in both files at the same time.
To change the used MAC address.
You can add the required parameter to the startup files (uEnv.ini and extlinux.conf). To do this, at the end of the line with the launch parameters, you need to add a parameter specifying the desired MAC address.
Old info multiboot
Install Armbian to eMMC.
1. Be sure to activate multi-boot using the new image. If multiboot previously activated is required to repeat activation using files in a new image.
2. Run Armbian from external media, run "ddbr" and create full backup eMMC.
3. install Armbian on eMMC execute script “/root/install.sh”.
Please note, this is a test installation, which was tested only on a few models. Possible errors (Armbian will not boot) when you are working on unverified models which used non-standard distribution of partitions in the eMMC. Therefore, be sure to back up the "ddbr" utility before running the scripts.
manuti got a reaction from olivluca in kodi on armbian?
Luca cómprate un MXQ cualquiera por ejemplo y tendrás triple boot sin problemas gracias a las imágenes de @balbes150
Luca buy some MXQ for example and you will have triple boot without problems thanks to the images of @balbes150
The triple boot works like this: you modify the Android TV boot so that it checks the SD slot, the USB and finally the internal eMMC. Once this is done, if you turn on the computer with an SD or USB with the image of Armbian prepared by @balbes150 will be the partition that boots and from it you can choose Kodi or Linux Desktop, and if you do not place the SD then starts the Android serial.
Translated with www.DeepL.com/Translator
manuti reacted to balbes150 in The list of models that are running Armbian (Amlogic, Rockchip, Allwinner etc)
This theme is designed to help potential users with the selection of equipment to run Armbian on TV boxes and other devices with ARM chips. I propose to leave here information about specific models, with a description of the technical parameters of the equipment, which specific versions of Armbian images and what settings or additional steps have been launched.
Pay attention. In this thread are only a good or not run the system on specific models TV box. All discussions and questions, post in other topics.
manuti reacted to balbes150 in kodi on armbian?
You can only use RPi (1-2-3) for video and audio if you already have RPI. Spending money now to buy PRi3 for multimedia content = this is the worst choice. Look at Amlogic S905X2\D2 S922 or Rockchip RK3328 RK3399. Series RK32XX-outdated and not worth it to buy now. If video playback is the main task (other tasks to run Linux are secondary), it is better to look for the TV box. You will get all the necessary components at once and do not have to spend time and money on the equipment (remote control, power supply, housing, good eMMC memory, etc.). I have no LePotato with S905X, but I'm sure Libreelec (KODI) can work perfectly on this model.
And start by reading the topics in this section, much will become more clear.
manuti reacted to balbes150 in Armbian for RK3399
To start the system enough to download, unzip, burn the image to the SD card. Connect the SD card to the EDGE and turn the power on.
The system starts automatically. Details on the initial setup of the running system can be found in these topics.
manuti reacted to tkaiser in Librecomputer Renegade RK3328
Care to provide numbers from a quick iozone benchmark as described here: https://forum.armbian.com/topic/954-sd-card-performance/?
I tested some 'quality' pendrives last year and was highly disappointed about the performance after some time or usage. Nice performance when starting to use them but after some time or amounts of write performance really started to suck. The only 'pendrive' working flawlessly so far looks like this for me:
A real M.2 SATA SSD with heatsinks to prevent overheating/throttling on a JMS578 adapter. Without heatsink and with enclosure closed also unusable since the SSD overheats too much (sequential transfers then drop from 400 MB/s to ~30 MB/s)
Why should everybody have the same needs? Users might want to attach a HDD to the USB3 port then 'booting from USB3' is not an option any more as long as you want the HDD to spin down. Putting an USB hub between host and disk is always a great idea to introduce problems.
manuti reacted to NicoD in Benchmarking CPUs
I'll check that. I've used 7-zip to compare the Bpi-zero to the rpi zero/3b. But the versions are different. I think because of that the numbers aren't exactly comparable. But it is a lot better than most other tools.
The best way for me is to use as many different programs. Some do better with 32-bit architecture, some better with 64-bit. Then take an average of all the results and your close.
Any way of installing exactly the same version of 7zip on all sbc's?
Here's the Rasp 3B+ result you wanted. All default settings.
nicod@nicod-desktop:~$ 7zr b ; 7zr b 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 927 MB, # CPU hardware threads: 4 RAM usage: 850 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1623 299 528 1579 | 45650 371 1110 4118 23: 1553 300 527 1582 | 45169 373 1108 4133 24: 1555 306 546 1672 | 40410 372 1008 3749 Killed 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 927 MB, # CPU hardware threads: 4 RAM usage: 850 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1681 320 511 1635 | 39773 371 966 3588 23: 1483 310 487 1511 | 38959 370 963 3565 24: 1408 306 495 1514 | 38199 370 958 3543 Killed Here my results of the Bpi-zero(i know you don't care for that one
pi@bpi-iot-ros-ai:~$ taskset -c 0-3 7zr b -mmt4 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 494 MB, # CPU hardware threads: 4 RAM usage: 434 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1224 328 363 1190 | 34817 393 799 3141 23: 1203 335 366 1226 | 33868 389 796 3099 24: 1078 328 353 1159 | 30588 359 789 2837 ---------------------------------------------------------------- Avr: 330 361 1192 380 795 3026 Tot: 355 578 2109 -------------------------------------------------------------------- Single Thread -------------------------------------------------------------------- pi@bpi-iot-ros-ai:~$ taskset -c 0 7zr b -mmt1 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 494 MB, # CPU hardware threads: 4 RAM usage: 419 MB, # Benchmark threads: 1 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 435 99 426 423 | 9036 100 819 815 23: 425 99 436 433 | 8884 99 817 813 24: 403 99 436 433 | 8753 100 815 812 25: 349 97 411 399 | 7673 90 804 721 ---------------------------------------------------------------- Avr: 99 427 422 97 814 790 Tot: 98 620 606 And here the same for the Rpi 3b
pi@Raspi:~ $ taskset -c 0-3 7zr b -mmt4 7-Zip (a)  16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,32 bits,4 CPUs LE) LE CPU Freq: 765 1192 1193 1193 1191 1193 1193 1193 1193 RAM size: 858 MB, # CPU hardware threads: 4 RAM usage: 450 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1813 319 553 1764 | 56458 391 1232 4817 23: 1756 320 559 1790 | 54822 389 1218 4743 24: 1734 328 569 1865 | 53375 390 1203 4686 ---------------------------------- | ------------------------------ Avr: 322 560 1806 | 390 1218 4749 Tot: 356 889 3277 ------------------------------------- Single Thread ------------------------------------- pi@Raspi:~ $ taskset -c 0 7zr b -mmt1 7-Zip (a)  16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,32 bits,4 CPUs LE) LE CPU Freq: 1016 1192 1192 1192 1192 1192 1192 1192 1192 RAM size: 858 MB, # CPU hardware threads: 4 RAM usage: 435 MB, # Benchmark threads: 1 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 684 100 666 666 | 15163 100 1295 1295 23: 663 100 676 676 | 14808 100 1282 1282 24: 637 100 686 685 | 14440 100 1268 1268 25: 609 100 696 696 | 13990 100 1245 1245 ---------------------------------- | ------------------------------ Avr: 100 681 681 | 100 1273 1272 Tot: 100 977 977 As you can see, bpi-zero was :
7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)
Rpi 3b :
7-Zip (a)  16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,32 bits,4 CPUs LE)
The result of the Bpi-zero seemed a bit on the low side. I did cool it so it wouldn't throttle.
The result of the rpi 3b+ also look lower than 3b. I'll try again with the same command on the 3b.
Also yesterday I've made a new video about the Rpi 3b+ where I overclock it in Ubuntu. It clocks quite a bit higher in Ubuntu than in Raspbian. How comes? Did the people of canonical do a better job in managing the cpu? It also didn't throttle in Ubuntu. I've closed the case completely and let it run on the max to test that. More than 80°C and still at the max frequency.
Here's the video
Video install Ubuntu + Overclock
manuti reacted to tkaiser in Benchmarking CPUs
...is crap. It's not a CPU but only a compiler benchmark. You chose the worst 'benchmark' possible.
Sysbench numbers change with compiler version and settings or even with sysbench version (higher version number --> lower scores). There's no 'benchmark' known producing more unreliable results wrt hardware/CPU. Use 'Google site search' here to get the details.
If it's about a quick and rough CPU performance estimate I would recommend 7-zip's benchmark mode (7z b).
manuti reacted to rodolfo in Winw for Orange Pi (PC+)
Orange Pi runs Armbian Linux. With little effort you'll find equivalent or most likely vastly superior replacements for 'simple Windows applications'..
Emulating Windows on ARM is not a satisfactory experience, WINE is a tweaked emulated X86 WIN-environment and the Raspi infomercial you mention tries to sell you their proprietary version of it. QEMU is a possibility to install some WINDOWS 'Operating System' in a X86-emulator - it 'works' but you will hear your beard growing.
Long story short : If you desperately need the Windows experience, go buy a Windows box. Meanwhile experience the excellent Armbian on OPI !
manuti reacted to devman in tried out armbian on orangepi one allwinner h3, thanks
The major difference between those three images is:
Stretch : modern 4.x (14? 17?) kernel, based on Debian
Bionic: modern 4.x (14? 17?) kernel, based on Ubuntu
Xenial: legacy 3.4 kernel, based on Ubuntu
The modern kernels are generally pretty-close-to-mainline linux, thanks to the hard work of the guys in the linux-sunxi group.
Since not everything has been reverse-engineered, it doesn't (yet) support all the device features.
h3consumption will not work with the modern kernels, so is not included
The legacy kernel is based off a vendor-provided kernel that has been cleaned up and had a few dozen (hundred) security patches on top of it.
It's based of the now end-of-life 3.4.y kernel tree that was initially released in 2012 and was marked end-of-life in 2016 following the final 3.4.113 update
All the hardware should work with these kernels, but the anything that relies on a modern kernel (eg. btrfs) won't work, and you'll be missing the last 2 years of security/stability updates.
manuti reacted to Seasalt in Armbian for OrangePi PC2, AllWinner H5
I have just update my OrangePi PC2 and now I can play 720p video really well.
It appears to use 80 - 90 CPU to do it . So I am wondering is it playing the HEVC 720p file in software or is it using Hardware VPU decoding.
I am also totally impressed now that Armbian has fixed the screen resolution option box. Huge improvement.
This is a really big set of improvements to the Armbian PC2. Well done.
manuti reacted to tkaiser in NanoPi K1 Plus to be released soon
With 10,000 the kernel takes a look 100 hundred times each second, when set to 200,000 it's just 5 times any more. And this is all off-topic here as already said (but same applies to the other thread that talks about OPi Zero)
As a first step I tried to consolidate timer frequency settings accross all kernels since what we have today is just chaos.
manuti reacted to datsuns in Quick review of NanoPi Fire3
Ok, I'm going to just keep adding boards if it continues to work. I was more worried about it throttling down the performance of the boards before they shut off but it sounds like that's not what it would do.
You seem knowledgeable about the board so what do you feel like is a good stable operating temperature for these units? I am running active cooling and no overclock (1.4GHz) on all of my fires and I am seeing something between 66-70 degrees C on average when I periodically check on temps. This can of course vary depending on the ambient temerature in the room as well. If I tried out a mild overclock what temperature range would you start to get concerned at? It sounds like you are running yours at 1.6GHz - what kind of cooling are you running? I'm currently using small fans running on 3.3v. My setup is close to my desk and I have found running them at 5v is on the annoying side so I'd like to keep them at 3.3v.
manuti got a reaction from Igor_K in Replace Odroid C2 for pi hole and plex
The NanoPi K1 Plus:
[ ] armbian good support - not yet
[x] 2+GB ram - yes
[x] fast cpu - yes and 64bits
[x] Gigabit Ethernet - yes
[x] eMMC support could be nice for fast OS - yes
[x] it will run headless - yes
[ ]- docker support - yes when armbiam come
[ ]- USB 3 support could be nice, otherwise USB 2 is ok - USB2.0
manuti reacted to @lex in NanoPi K1 Plus to be released soon
openssl speed -elapsed -evp aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 21097762 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 13885050 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 5712407 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1744124 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 232965 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 16384 size blocks: 116966 aes-256-cbc's in 3.00s OpenSSL 1.1.0g 2 Nov 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 112521.40k 296214.40k 487458.73k 595327.66k 636149.76k cpufreq-info -c 1 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to email@example.com, please. analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.54 ms. hardware limits: 480 MHz - 1.37 GHz available frequency steps: 480 MHz, 648 MHz, 720 MHz, 768 MHz, 912 MHz, 1.08 GHz, 1.20 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.37 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1.37 GHz. cpufreq stats: 480 MHz:4.74%, 648 MHz:1.64%, 720 MHz:0.35%, 768 MHz:0.59%, 912 MHz:0.48%, 1.08 GHz:0.44%, 1.20 GHz:0.38%, 1.37 GHz:91.36% (3239) at least, 4.17 pretty stable...
I think there is room for improvement, board does not get Temp over 54 ºC so lets the experts handle this...
manuti reacted to tkaiser in Amlogic still cheating with clockspeeds
I just looked through those numbers on https://libre.computer/2018/03/21/raspberry-pi-3-model-b-review-and-comparison/ again just to realize that there's also something seriously wrong. The OpenSSL tests are also a great benchmark to check for real CPU clockspeeds since not affected by memory bandwidth at all (the AES scores with ARMv8 Crypto Extensions available scale linearly with clockspeed when comparing different A53).
When comparing Le Potato (S905X claiming to run at 1.5 GHz) with Renegade (RK3328 at 1.3 GHz) then it's pretty obvious that the S905X was running with 1320 MHz maximum. Which is a bit too low even if we already take into account that S905X can't reach the 1.5 GHz anyway due to bl30.bin situation.
There's something seriously wrong with CPU clockspeeds on Amlogic platforms. And maybe there's also a relationship with broken/weird scheduling though I really don't understand how this can happen (there should be no difference on a quad-core CPU whether the kernel decides to run on cpu 0-3 or the user 'forces' exactly the same using 'taskset -c 0-3' -- but reality draws a different picture)