Search the Community

Showing results for tags 'research'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements & first aid
    • Announcements
    • Board doesn't start
  • Community forums
    • Common issues
    • Peer to peer technical support
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner H5 & A64
    • Allwinner H6
    • Armada A388, A3700
    • Amlogic S905(x)
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Other supported boards
  • Development
    • Rockchip 3399
    • Development

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 100 results

  1. Tanix TX6 is H6 based Android TV Box and it can boot from SD cards prepared with PhoenixCard. It should be possible to make it work with Armbian too, right? I tried a recent Lite2 image, it didn't work, but it also didn't boot main Android, which means SD boot takes priority. I don't think it's a normal behavior for other Android TV boxes, but maybe it is for those with H6 boards.
  2. I have got 2x USB 3.0 RTL8156 ethernet dongles using one on my Rockpi4 the other windows client If the rockpi4 is the server speeds are awful [rock@rockpi4 ~]$ iperf3 -s ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.12, port 52620 [ 5] local 192.168.1.9 port 5201 connected to 192.168.1.12 port 52621 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 56.7 MBytes 475 Mbits/sec [ 5] 1.00-2.00 sec 43.7 MBytes 367 Mbits/sec [ 5] 2.00-3.00 sec 46.3 MBytes 388 Mbits/sec [ 5] 3.00-4.00 sec 39.3 MBytes 330 Mbits/sec [ 5] 4.00-5.00 sec 45.2 MBytes 379 Mbits/sec [ 5] 5.00-6.00 sec 38.3 MBytes 321 Mbits/sec [ 5] 6.00-7.00 sec 41.4 MBytes 347 Mbits/sec [ 5] 7.00-8.00 sec 38.0 MBytes 319 Mbits/sec [ 5] 8.00-9.00 sec 42.0 MBytes 353 Mbits/sec [ 5] 9.00-10.00 sec 46.4 MBytes 389 Mbits/sec [ 5] 10.00-10.05 sec 2.29 MBytes 404 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.05 sec 440 MBytes 367 Mbits/sec receiver ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- RockPi4 as client [rock@rockpi4 ~]$ iperf3 -c 192.168.1.12 Connecting to host 192.168.1.12, port 5201 [ 5] local 192.168.1.9 port 38240 connected to 192.168.1.12 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 186 MBytes 1.55 Gbits/sec 0 220 KBytes [ 5] 1.00-2.00 sec 190 MBytes 1.60 Gbits/sec 10 212 KBytes [ 5] 2.00-3.00 sec 215 MBytes 1.80 Gbits/sec 0 212 KBytes [ 5] 3.00-4.01 sec 208 MBytes 1.74 Gbits/sec 10 245 KBytes [ 5] 4.01-5.00 sec 180 MBytes 1.52 Gbits/sec 30 212 KBytes [ 5] 5.00-6.00 sec 197 MBytes 1.65 Gbits/sec 10 214 KBytes [ 5] 6.00-7.01 sec 161 MBytes 1.34 Gbits/sec 0 214 KBytes [ 5] 7.01-8.00 sec 137 MBytes 1.15 Gbits/sec 30 214 KBytes [ 5] 8.00-9.01 sec 138 MBytes 1.15 Gbits/sec 20 217 KBytes [ 5] 9.01-10.00 sec 159 MBytes 1.34 Gbits/sec 0 217 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.73 GBytes 1.48 Gbits/sec 110 sender [ 5] 0.00-10.00 sec 1.73 GBytes 1.48 Gbits/sec receiver iperf Done. I prob need to sort some better cabling as my dodgy collection of battered and old ethernet cables made me rummage around until I got 2 half decent ones but I am not sure why client/server should make such a big difference and set speed? If the rockpi4 is the server and the client uses -R then [rock@rockpi4 ~]$ iperf3 -s ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.12, port 52663 [ 5] local 192.168.1.9 port 5201 connected to 192.168.1.12 port 52664 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 181 MBytes 1.52 Gbits/sec 10 151 KBytes [ 5] 1.00-2.00 sec 187 MBytes 1.57 Gbits/sec 20 231 KBytes [ 5] 2.00-3.01 sec 199 MBytes 1.66 Gbits/sec 31 210 KBytes [ 5] 3.01-4.00 sec 204 MBytes 1.71 Gbits/sec 10 155 KBytes [ 5] 4.00-5.01 sec 184 MBytes 1.54 Gbits/sec 124 212 KBytes [ 5] 5.01-6.01 sec 205 MBytes 1.72 Gbits/sec 0 212 KBytes [ 5] 6.01-7.00 sec 187 MBytes 1.58 Gbits/sec 20 214 KBytes [ 5] 7.00-8.01 sec 207 MBytes 1.73 Gbits/sec 10 238 KBytes [ 5] 8.01-9.01 sec 198 MBytes 1.67 Gbits/sec 11 212 KBytes [ 5] 9.01-10.00 sec 182 MBytes 1.53 Gbits/sec 30 230 KBytes [ 5] 10.00-10.04 sec 8.15 MBytes 1.85 Gbits/sec 0 230 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.04 sec 1.90 GBytes 1.62 Gbits/sec 266 sender ----------------------------------------------------------- Server listening on 5201 Confused as it can but why not as the server? Anyone know more about iperf and networking than obviously me I prob need to get some better cabling as had a mare with some cables that just where not liked even though just 2.5g Also any tweaks or tips on network and packet settings to get the most and lower overhead?
  3. Fun stuff - and something that's kept me offline/busy for the last few weeks... # uname -a Linux blaster 3.4.0 #1 PREEMPT Wed May 13 14:43:07 PDT 2020 armv7l GNU/Linux # cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS : 586.13 Features : swp half thumb fastmult vfp edsp neon vfpv3 tls CPU implementer : 0x51 CPU architecture: 7 CPU variant : 0x1 CPU part : 0x00f CPU revision : 2 Hint - it's old enough not to have a device-tree... actually, in CPU years, it's old enough to vote/drink, and in dog-years, it's probably dead. I'll sent $20USD and a possible job offer if you can ID the specific chip... No @Igor, you don't get to play here
  4. Hi, A small discussion started here, but I would like to lift it to here. The question and tests should be. Are there alternatives to Etcher? A must was - standard writing verification. IIRC this was back in the days an option you had to set a 'tick' on Win32 DiskImager.. and so not an option. Before we change anything - proper testing and writing down the steps to achieve a great result is a must. Multiplatform, would be nice, but we can as well recommend 2 or 3 SDcard writing programs. Can you please help to write a table of available programs (you can do a table in the forum, but consider quantity of lines & rows first). And whether or not the software is an equivalent replacement for armbian? Please help us to collect here your knowledge and expericence Of course your recommendation should support the minimum mentioned above - otherwise it is not a recommendation but Spam Thank you in advance for your participation on this challenge
  5. As we know, the PCIe on H6 is buggy, which doesn't offer linear address, and Linux cannot support such kind of configuration. However, the Cortex-A53 cores used by H6 supports virtualization, which can be used to change the order of the address space. Recently, I tried to make use of virtualization to provide linear mapping of PCIe, and I succeed in making an Intel 6205 wireless card working. The hypervisor code is at https://github.com/Icenowy/aw-el2-barebone . It's intended to start before U-Boot, and located at 0x40010000. A U-Boot fork that is patched to load the hypervisor is at https://github.com/Icenowy/u-boot/tree/h6-load-hyp , and a kernel that utilizes the wrapped PCIe (and patched to reserve memory for the hypervisor) is at https://github.com/Icenowy/linux/tree/h6-pcie-wrapped . In order to let the hypervisor start before U-Boot, BL31 needs to be built with `PRELOADED_BL33_BASE=0x40010000` in make parameter -- this will change the EL2 entrypoint to the hypervisor. Mainline ATF from ARM works. Contributions to the hypervisor is welcomed. (In addition, abusing virtualization in such way will prevent us from using KVM. But I think more people will want PCIe instead of KVM, right?)
  6. Hi - Earlier this week ( begin April 2020 ) I found out H5 boards become scarce. I was unable to find the H5 chip at allwinner tech H series section, suppose this will be replaced ? Anyone more info perhaps?
  7. Hello, I'm try to setup my OPiZero as mediaplyer, and I need to use it sometimes as WiFi Client - Managed mode and sometimes as WiFi AP - Master mode. Scenario 1 Work in "dual mode", I mean, when my wifi network within reach, then OPiZ start as "client", and connect to my preferred wifi network when wifi network not in range, it start as AP+DHCP (hostapd and dnsmasq) Scenario 2 Switched mode, Make any push button on gpio, and then make scripts "to do the job" .. disconnect from wifi, stop wpa_supplicant, run hostapd an dnsmasq. Has anybody something like "scenrio1" or "scenario2" .. ?? (or my ideas are totally bad ... )
  8. Recently, a new SBC, the Rock Pi S by Radxa, was launched. Here's it's wiki page: https://wiki.radxa.com/RockpiS It's a 4 core A35 design. I'm debating getting one, but I can't find any information anywhere as to whether or not it's supported on Linux, or Armbian. Of course, if it's not listed in the download section it's not supported, but there's a difference between, "I need to add 100 lines of code and it will work." to "Geez, I need to redesign most of the Linux kernel after pulling my hair out." I did search the sunxi wiki and the local armbian wiki without success. Anyone know anything? Thanks!
  9. <smaeul> scanning bus dwc3@5200000 for devices... 2 USB Device(s) found <smaeul> wooo, got USB3 boot working on H6 :D patchset at https://github.com/smaeul/u-boot/commits/h6-dwc3 Just catched this on #linux-sunxi IRC channel. I do not have a H6 board to test this but maybe someone else wanna give it a shot.
  10. Looking to find out why the Orange Pi OS Build isn't finding this file. Tried on two separate Linux 18.04 OS and neither has this file. When running Build_OrangePi.sh, right after entering the initial password, it drops out and claims the file lib32z1-dev not locate able. The only thing I can think is I need to install the SDK to build the OrangePi OS for this? Trying to do this from the Orange Pi Git Hub. https://github.com/orangepi-xunlong/OrangePi_Build Thanks for any help.
  11. Ever since patchfolders were created for different branches and different board families it has become more and more a nightmare to maintain these folders and keep them clean. Instead of taking the approach to clear one or more of these folders by myself, last but not least due to lack of necessary skills, I was thinking maybe I can provide some tools that make such tasks a little easier for somebody else. Last but not least was (and still is) this a perfect opportunity to pratice with my quite new Python skills. https://github.com/EvilOlaf/refactorpatches What this script basically does is break down all patches in a certain folder and check which files are targeted by each individual diff (if you choose to split them up) and sort the output by the target file. This way it should be an easy thing to merge patches that affect the same file and therefore it is no longer necessary to take care about the order to apply them. Requirements from apt: patchutils, python3 Requirements from Pypi: none but just make sure the prettytable.py is in the same folder as main refactor.py. I have tested this with random patch folders for kernel patches and for what it is expected to do at the current state it seems to just work as it should. There is still a ton of room for improvements. Let me know what do you think or if it is useful at all. Even if it is not I had fun coding and using Python
  12. Dear Armbian community, we are looking for a low-power SBC with (deep sleep) / poweroff features for IoT applications. Arduino or any other MCU board are not suitable for doing our use cases, so we are investigating the use of an low-power SBC. i.MX6ULL (https://www.seeedstudio.com/NPi-i-MX6ULL-Dev-Board-Industrial-Grade-Linux-SBC-eMMC-Version-p-4221.html) has an integrated PMU with a lot of different low-power modes. Like SNVS mode, where only the power for the SNVS domain remain on. In this mode, only the RTC and tamper detection logic is still active This board is quietly new is there any possibility that this board can be supported by the Armbian community. Thankyou in advance. IMX6ULLIEC.pdf
  13. Java Periphery has finally been released! Java Periphery is a high performance library for GPIO, LED, PWM, SPI, I2C, MMIO and Serial peripheral I/O interface access in userspace Linux. This will replace User Space IO. I'm seeing GPIO write speeds of 500K/s from userspace. Compared to User Space IO and libgopid speeds of 2K/s. I switched from JNA wrapper generation to JNI wrapper generation. The build process is much simpler (only single install.sh) and building libgpiod is no longer required. The API follows c-periphery, python-periphery and lua-periphery. This should cover the widest array of SBCs and languages around. Java Periphery should work on Armbian/Ubuntu/Debian, but also other non-Armbian distributions. If you run into issues please use Github issues to report. Nano Pi Duo 13:30:43.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 13:31:23.062 [main] INFO com.codeferm.periphery.demo.GpioPerf - 500613.25 writes per second 13:31:23.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 13:31:54.471 [main] INFO com.codeferm.periphery.demo.GpioPerf - 318440.91 reads per second Nano Pi Neo Plus 2 15:06:51.946 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 15:07:22.522 [main] INFO com.codeferm.periphery.demo.GpioPerf - 654964.63 writes per second 15:07:22.524 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 15:07:46.696 [main] INFO com.codeferm.periphery.demo.GpioPerf - 413770.27 reads per second
  14. Hello, I'm currently running Gentoo on my BananaPIs (M1). I'm using one as graphical Dashboard using DirectFB. Unfortunately, DirectFB is deprecated, not anymore supported and facing some compilation issue. Time to change. I tried with SDL configured with KMS but it's crashing. I don't want to install X because it will take ages to compile without any garanty it will work at the end. So ... probably the time to change. So, is DirectFB still supported on Armbian ? If not, is SDL2 working without X support. If not, with X support ? And if so, is X accelerated ? Thanks Laurent
  15. Goodmorning, i would like to ask if someone have ever tried to use musl libc with Armbian. From some research appear that using it instead of glibc make programs consume a lot less ram and less space on disk. I never tried personally, but i'm curious about that because it could be especially useful for single board computer with less than 2gb of ram (like mine ). Since, from what i know, programs do not statically link to glibc, but dynamically link to a generic libc at runtime, could be possible to use musl as drop in replacement for libc, without rebuild everything? From what i know there could be some incompatibilities because glibc does not fully respect the standards of libc, but i would like to know some opinions and experiences. Thanks for listening, have a good day
  16. After working with sysfs and libgpiod as cross platform solutions I was wondering if there was a faster way using /dev/mem or mmio? I know this gets more bare metal and SBC specific, but for some things you may want absolute speed. https://opensource.com/life/16/4/bulldog-gpio-library for instance claims 1 MHz GPIO writes in Java. However it only supports 3 SBCs as you can see from https://github.com/SilverThings/bulldog. Is there a more generic way to do this and not lose performance? Using my generated JNA wrappers for libgpiod I get about 2K writes per second. In Python I think it's about 70K using libgpiod Python bindings. I realize you may not always need 1 MHz GPIO writes, but it would be neat to offer this in a more generic way.
  17. I'm setting up a new Armbian system from a cold start. I ran armbian-config and used the personal > welcome option to set the MOTD_DISABLE options in /etc/defaults/armbian-motd. It did not do anything to the welcome screen. I asked for the header tips and updates to be excluded. Looking at the resulting /etc/defaults/armbian-motd file : netadmin@ups-monitor:/etc/update-motd.d$ cat /etc/default/armbian-motd # add space-separated list of MOTD script names (without number) to exclude them from MOTD # Example: # MOTD_DISABLE="header tips updates" MOTD_DISABLE="" ONE_WIRE="" # yes = show 1-wire temperature sensor if attached netadmin@ups-monitor:/etc/update-motd.d$ The edit has been applied, but to the comment line, not the actual MOTD_DISABLE line. I don't know where the script that takes the action is located to check it, but I guess this is not intentional, and thus it needs to be updated to ignore lines beginning with # Second point, I'm reasonably sure, some time back, I put in a change to modify the script 41-armbian-config to change it's THIS_SCRIPT line to "config" rather than "armbian-config", so that it's disable syntax matched the other files in the set. At the moment, on a fresh install, it still needs armbian-config in the MOTD_DISABLE line. My build today is: Has that pull request got lost somewhere ? Harry
  18. Hi, Armbian gurus, I'm trying to make the build system to build image with LibreELEC kernel tree for PineH64 I heard the kernel is patched for being better at hardware decoding Here are what I have done in order: 1. Retrieve patched kernel tree from LibreELEC build system. Upload the patched kernel tree to my gitlab account. 2. Modify config/sources/families/include/sunxi64_common.inc to make KERNEL_SOURCE = my previous repo; KERNELBRACH = master. To make it fetchable during bilding. 3. Modify lib/compilation-prepare.sh: skip aufs patch. 4. Modify lib/compilation.sh: skip advanced_patch in compile_kernel() After all these hassle, I can use compile.sh to build an Armbian 64 bit image with the 5.5.6 patched. BUT unfortunately, I flash the image and found it cannot boot properly. So here are my question: 1. How do you typically debug boot problem for PineH64. 2. Do you think anything could go wrong in those procedure? 3. Do I need to upgrade u-boot as well? It's using v2019.10 as far as I can tell. Thank you.
  19. Hi there, I am about to use an OrangePi Zero to handle the temperature and display some information on a custom contraption related to network. The problem I have is that this contraption will be powered on and powered off at will, without notice. So... I guess that after some time, the Zero running Armbian won't be that happy about being shut off brutally. I have seen some setups with supercapacitors for Raspberry Pis, but has anyone in here tried something similar with the OrangePi Zero? Or anything else that would delay the power loss, so that the board can shutdown properly? I made searches about supercapacitors with Armbian, but only found some information related to RTC (which would be nice to have too...). Thanks!
  20. Found an old (2015) Ugoos UT3+ / UT3 Plus with an rk3288 - the neat thing about this board is it has HDMI-IN ! Also has PIP Specs: I'm was eventually able to successfully screen capture @ 1920 x 1080 ~29 fps using the Android 5.1.1 firmware V3.0.7 for UT3+ https://mega.nz/#!cQpl0ICS!8EgHddI3_PXQsSe-TSrkHfxdHCmkbckNWBYuLhfuA7w The firmware crashes frequently and the painful part is the IR remote is required to start recording.. so I'll be porting gentoo / armbian to this device to turn this paper weight into a linux friendly screen capture device. It maybe also worthwhile to document the process and create an armbian porting guide. Aside, for those interested, its worth to mention the LKV373A HDMI / ethernet sender is a potential $30 HDMI screen capture alternate.
  21. Since I've seen some really weird disk/IO benchmarks made on SBCs the last days and both a new SBC and a new SSD arrived in the meantime I thought let's give it a try with a slightly better test setup. I tested with 4 different SoC/SBC: NanoPi M3 with an octa-core S5P6818 Samsung/Nexell SoC, ODROID-C2 featuring a quad-core Amlogic S905, Orange Pi PC with a quad-core Allwinner H3 and an old Banana Pi Pro with a dual-core A20. The device considered the slowest (dual-core A20 with just 960 MHz clockspeed) is the fastest in reality when it's about disk IO. Since most if not all storage 'benchmarks' for SBC moronically focus on sequential transfer speeds only and completely forget that random IO is way more important on any SBC (it's not a digital camera or video recorder!) I tested this also. Since it's also somewhat moronically when you want to test the storage implementation of a computer to choose a disk that is limited the main test device is a brand new Samsung SSD 750 EVO 120GB I tested first on a PC whether the SSD is ok and to get a baseline what to expect. Since NanoPi M3, ODROID-C2 and Orange Pi PC only feature USB 2.0 I tested with 2 different USB enclosures that are known to be USB Attached SCSI (UAS) capable. The nice thing with UAS is that while it's an optional USB feature that came together with USB 3.0 we can use it with more recent sunxi SoCs also when running mainline kernel (A20, H3, A64 -- all only USB 2.0 capable). When clicking on the link you can also see how different USB enclosures (to be more precise: the included USB-to-SATA bridges used) perform. Keep that in mind when you see 'disk performance' numbers somewhere and people write SBC A would be 2MB/s faster than SBC B -- for the variation in numbers not only the SBC might be responsible but this is for sure also influenced by both the disk used and enclosure / USB-SATA bridge inside! The same applies to the kernel the SBC is running. So never trust in any numbers you find on the internet that are the results of tests at different times, with different disks or different enclosures. The numbers presented are just BS. The two enclosures I tested with are equipped with JMicron JMS567 and ASMedia ASM1153. With sunxi SBCs running mainline kernel UAS will be used, with other SoCs/SBC or running legacy kernels it will be USB Mass Storage instead. Banana Pi Pro is an exception since its SoC features true SATA (with limited sequential write speeds) which will outperform every USB implementation. And I also used a rather fast SD card and also a normal HDD with this device connected to USB with a non UASP capable disk enclosure to show how badly this affects the important performance factors (again: random IO!) I used iozone with 3 different runs: 1 MB test size with 1k, 2k and 4k record sizes 100 MB test size with 4k, 16k, 512k, 1024k and 16384k (16 MB) record sizes 4 GB test size with 4k and 1024k record sizes The variation in results is interesting. If 4K results between 1 and 100 MB test size differ you know that your benchmark is not testing disk througput but instead the (pretty small) disk cache. Using 4GB for sequential transfer speeds ensures that the whole amount of data exceeds DRAM size. The results: NanoPi M3 @ 1400 MHz / 3.4.39-s5p6818 / jessie / USB Mass Storage: Sequential transfer speeds with USB: 30MB/s with 1MB record size and just 7.5MB/s at 4K/100MB, lowest random IO numbers of all. All USB ports are behind an USB hub and it's already known that performance on the USB OTG port is higher. Unfortunately my SSD with both enclosures prevented negotiating an USB connection on the OTG port since each time I connected the SSD the following happened: WARN::dwc_otg_hcd_hub_control:2544: Overcurrent change detected ) ODROID-C2 @ 1536 MHz / 3.14.74-odroidc2 / xenial / USB Mass Storage: Sequential transfer speeds with USB: ~39MB/s with 1MB record size and ~10.5MB/s at 4K/100MB. All USB ports are behind an USB hub and the performance numbers look like there's always some buffering involved (not true disk test but kernel's caches involved partially) Orange Pi PC @ 1296 MHz / 4.7.2-sun8i / xenial / UAS: Sequential transfer speeds with USB: ~40MB/s with 1MB record size and ~9MB/s at 4K/100MB, best random IO with very small files. All USB ports are independant (just like on Orange Pi Plus 2E where identical results will be achieved since same SoC and same settings when running Armbian) Banana Pi Pro @ 960 MHz / 4.6.3-sunxi / xenial / SATA-SSD vs. USB-HDD: This test setup is totally different since the SSD will be connected through SATA and I use a normal HDD in an UAS incapable disk enclosure to show how huge the performance differences are. SATA sequential transfer speeds are unbalanced for still unknown reasons: write/read ~40/170MB/s with 1MB record size, 16/44MB/s with 4K/100MB (that's huge compared to all the USB numbers above!). Best random IO numbers (magnitudes faster since no USB-to-SATA bottleneck as with every USB disk is present). The HDD test shows the worst numbers: Just 29MB/s sequential speeds at 1MB record size and only ~5MB/s with 4K/100MB. Also the huge difference between the tests with 1MB vs. 100MB data size with 4K record size shows clearly that with 1MB test size only the HDD's internal DRAM cache has been tested (no disk involved): this was not a disk test but a disk cache test only. Lessons to learn? HDDs are slow. Even that slow that they are the bottleneck and invalidate every performance test when you want to test the performance of the host (the SBC in question) With HDDs data size matters since you get different results depending on whether the benchmark runs inside the HDD's internal caches or not. SSDs behave here differently since they do not contain ultra-slow rotating platters but their different types of internal storage (DRAM cache and flash) do not perform that different When you have both USB and SATA not using the latter is almost all the time simply stupid (even if sequential write performance looks identical. Sequential read speeds are way higher, random IO will always be superiour and this is more important) It always depends on the use case in question. Imagine you want to set up a lightweight web server dealing with static contents on any SBC that features only USB. Most of the accessed files are rather small especially when you configure your web server to deliver all content already pre-compressed. So if you compare random reads with 4k and 16k record size and 100MB data size you'll notice that a good SD card will perform magnitudes faster! For small files (4k) it's ~110 IOPS (447 KB/s) vs. 1950 IOPS (7812 KB/s) so SD card is ~18 times faster, for 16k size it's ~110 IOPS (1716 KB/s) vs. 830 IOPS (13329 KB/s) so SD card is still 7.5 times faster than USB disk. File size has to reach 512K to let USB disk perform as good as the SD card! Please note that I used a Samsung Pro 64GB for this test. The cheaper EVO/EVO+ with 32 and 64GB show identical sequential transfer speeds while being a lot faster when it's about random IO with small files. So you save money and get better performance by choosing the cards that look worse by specs! Record size always matters. Most fs accesses on an SBC are not large data that will be streamed but small chunks of randomly read/written data. Therefore check random IO results with small record sizes since this is important and have a look at the comparison of 1MB vs. 100 MB data size to get the idea when you're only testing your disk's caches and when your disk in reality. If you compare random IO numbers from crap SD cards (Kingston, noname, Verbatim, noname, PNY, noname, Intenso, noname and so on) with the results above then even the slow HDD connected through USB can shine. But better SD cards exist and some pretty fast eMMC implementations on some boards (ODROID-C2 being the best performer here). By comparing with the SSD results you get the idea how to improve performance when your workload depends on that (desktop Linux, web server, database server). Even a simple 'apt-get upgrade' when done after months without upgrades heavily depends on fast random IO (especially writes). So by relying on the usual bullshit benchmarks only showing sequential transfer speeds a HDD (30 MB/s) and a SD card (23 MB/s) seem to perform nearly identical while in reality the way more important random IO performance might differ a lot. And this solely depends on the SD card you bought and not on the SBC you use! For many server use cases when small file accesses happen good SD cards or eMMC will be magnitudes faster than HDDs (again, it's mostly about random IO and not sequential transfer speeds). I personally used/tested SD cards that show only 37 KB/s when running the 16K random write test (some cheap Intenso crap). Compared to the same test when combining A20 with a SATA SSD this is 'just' over 800 times slower (31000 KB/s). Compared to the best performer we currently know (EVO/EVO+ with 32/64GB) this is still 325 times slower (12000 KB/s). And this speed difference (again: random IO) will be responsible for an 'apt-get upgrade' with 200 packages on the Intenso card taking hours while finishing in less than a minute on the SATA disk and in 2 minutes with the good Samsung cards given your Internet connection is fast enough.
  22. Just got this error at the very end of a build. [ o.k. ] Checking git sources [ linux-firmware-git master ] fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/': The requested URL returned error: 504 [ .... ] Fetching updates fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/': The requested URL returned error: 504 [ .... ] Checking out error: pathspec 'FETCH_HEAD' did not match any file(s) known to git. I checked a very few minutes later and the URL https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ did eventually respond with a reasonable page, though with a huge delay. Presume that git.kernel.org had a problem, and returned the 504 error, not that the build system timed out waiting, but maybe wiser heads than me can check. If it was just lag, we may see a lot more of this sort of error, given the load on the internet at the moment.... Harry
  23. I have a supported build host running, and successfully building and testing kernels for a few targets that I have examples of. I'm looking to extend my repertoire to building complete armbian images. I think I also want to use EXTERNAL and/or EXTERNAL_NEW to configure additional packages into the image. This has led me to this stanza: BUILD_MINIMAL (yes|no): set to “yes” to build bare CLI image suitable for application deployment. This option is not compatible with BUILD_DESKTOP=”yes” and BUILD_EXTERNAL=”yes” I can find no BUILD_EXTERNAL referenced elsewhere, should this be simply EXTERNAL ? or have I missed something. Is there documentation on how EXTERNAL and EXTERNAL_NEW parameters are invoked? Harry
  24. Hello together, I need help to build a new ARMBIAN - Image based on DEBIAN fort this board: https://www.tq-group.com/de/produkte/tq-embedded/arm-architektur/stka8mx/ Can anyone help me with building, etc. for this board? Best regards Matthias