Bernie_O

If you do a "i2cdetect -l", you will probably see that i2c-0 is dedicated to "sun4i_hdmi_i2c adapter", which maybe wasn't present before ...
 

I saw that you tested a SanDisk Extreme Pro 64GB - A2 card with ext4 and didn't get the expected results (https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md)
 
I tested my SanDisk Extreme Pro A2 256GB micro with A2 logo (bought beginning of October 2018), formatted ExFAT under MacOS 10.14 (iozone installed via homebrew). I thought this might be interesting for you:
 
Test 1:
random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 71735 74819 750573 769362 416685 61419 102400 2 72975 74808 1324810 1342211 787443 65213 102400 4 74887 76056 2067185 2154206 1440308 67627 102400 16 75828 76580 3978854 3807129 3004696 70542 102400 128 70181 75891 5519047 5797444 4493592 70074 102400 512 76834 76954 5866896 5991461 5061787 71180 102400 1024 79300 79602 5903994 4940446 5571237 72008 102400 16384 82960 82502 6244310 5044075 6105069 75332  
Test 2:
random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 72111 74632 706436 714325 388037 60997 102400 2 75580 74301 1283544 1363348 783629 64232 102400 4 76621 75244 2168159 2201398 1419623 66416 102400 16 76340 77138 4087649 3789092 3370748 69204 102400 128 75380 75991 5518693 4827877 5774217 71572 102400 512 63009 77769 5990458 5759273 5894918 66458 102400 1024 73595 68298 5961108 5981698 6634301 62683 102400 16384 72310 72862 5990121 6236754 6470780 68542  
Test 3:
random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 72706 72637 767523 787172 422875 61073 102400 2 73304 73348 1330300 1374293 800613 64702 102400 4 72564 74550 2140561 2198186 1445840 67664 102400 16 72701 76324 4004190 3749432 3430462 69190 102400 128 74825 76603 5780123 5851070 4953780 70198 102400 512 76477 76923 5890148 5900993 5225541 71628 102400 1024 77942 80417 5930079 5984115 5487737 72037 102400 16384 82740 82455 5965766 5569606 6449524 74115  
 

I am not sure if this is what you want to know, but:

- Debian.org or Ubuntu.com officially does not support any of those boards/boxes,
- Armbian userspace has many small but vital performance or security adjustments,
- Armbian fancy some kernel development and a lot of its maintaining. Debian relies on upstream sources for ARM hardware which can be years behind and/or lack of many functions,
- Armbian userspace is lean, clean but 100% Debian (or Ubuntu) compatible
- many stock Debian bugs are fixed on the way, "better than original :)"
- a build system is a central part of this whole ecosystem. You can DIY. Debian much harder.
- dedicated support forums per boards/boxes
- plug and play vs. complicated install scenarios on Stock Debian
- unified development scenarios and user experience vs. mess of different setup instructions scattered all around
 
I must have forgotten many other important points

Hi there Board,
 
I have bought my Tinkerboard after some good research with my fellow techies at Red Hat and reading thoroughly that 19+pages Tinkerboard Thread.
 
After crafting a super lean/mean kernel (kconfig at https://gist.github.com/rfrht/5f0fa113f12fbacf832e57ff4967785a ), I got a stable and lightweight kernel configuration.
 
Things got a lot funnier when doing some compatibility tests with specific Asterisk versions, I was able to install and run cleanly a Raspi .DEB pkg. And that got me thinking.
 
I have now JUST replaced the Raspberry Pi with the Tinkerboard. And guess what: It was a _inplace_ upgrade! Using the same userland, same hard drive, same everything.
 
I just had to set the MMC card with Tinkerboard /boot stuffs, specified the USB root device using rootdev=<proper clause> (in my case, rootdev=LABEL=TinkerRoot), edited /etc/fstab accordingly and... It RAN!
 
Smoothly. Perfectly. My 120 Mbps from carrier being diligently delivered. My userspace apps running nicely.
 
Well, I would like to send my deep respect and special thanks to @TonyMac32 for exploring Tinkerboard and putting it to work nicely, and  @Igor for hosting the project.
 
We grow when we share! ;-)

Well... At least I did not. Upgraded two Banana Pis without any issues.

If you are using mainline kernel this might help:
 

Now that you wrote that, I also remember, that it took quite a while for  the „freeze“ to disappear. So all you have to do is being patient ;-)

I also had this problem after updating to 5.36. I then noticed a permission error in  /var/log/syslog. Once I corrected the permissions of the appropriate path/file the welcome-screen did not „hang“ anymore with old information.
Unfortunately I can‘t remember which path or file I had to change the permissions, but it was clear when I saw the error in syslog.
Hope that helps at least for that „hanging“-with-old-information issue.

Nope.
 

Thank you. Fixed.

Yes, it is correct. But there is always but ... unrelated to armbian. Distribution upgrades might sometimes cause troubles.

In case you are running kernel 3.4.y you need to upgrade to NEXT kernel first since 3.4.y is not sufficient for running Stretch.
 
Add: it is possible that you might need to deinstall jessie-root package and manually install stretch. 

Just for the record:
the noise is actually a result of the mainline kernel powering down the audio subsystem when not in use. Disabling this as described in the below quoted post works also with my Banana Pi. With using a cable (as described above) the noise is gone, but still there is quite a loud "plop" when the audio-subsystem changes its power-state. Disabling the powering down of the audio subsystem removes also the "plop" - so I removed my cable.... and the "plop" :-)
Cheers, Bernie_O

I found a workaround!
 
After looking at some kernel stack traces, I found that this guy was responsible: https://www.kernel.org/doc/html/latest/sound/soc/dapm.html
 
When the PCM device is closed the following happens in the kernel:
snd_pcm_release() -> soc_pcm_close() -> delay of `pmdown_time` -> close_delayed_work() The last function powers down the audio subsystem, causing the hum. To circumvent this behavior, I simply set `pmdown_time` to -1:
echo -1 > /sys/devices/platform/soc@01c00000/1c22c00.codec/cdc/pmdown_time Now, once the sound subsystem is powered on, it stays powered on. Not ideal but it seems to work.

Hi,
 
Just joined to say thanks to all to those that are involved in the development of Armbian. I recently bought an Orange Pi PC after reading the internet full of people bitching about non-booting devices, HDMI issues, overheating and general crapness.
 
Decided to buy a Orange Pi PC nonetheless, found an old crap micro SD card, burnt Armbian (the internet has made it clear to not bother with the crap on the official Orange Pi website!) onto it and the thing booted without any issues! Typing this message from it as we speak in Iceweasel!
 
The thing only cost me 9 quid, so decided to donate what I would have wasted in cash on a Raspberry Pi 3 (which is anything but the 25 dollar SBC it seems to be advertised) as a donation to Igor and co.
 
I just run the Orange Pi PC out of the plastic static bag it came in LOL!
 
Once again, great work.

I found a solution:
There seems to be a voltage difference between ground on AV jack and actual ground on Banana Pro which is responsible for that noise: http://forum.lemaker.org/forum.php?mod=viewthread&tid=23054&page=1#pid91781
My device is a Banana Pi, but I suspected that there is a similar voltage difference.
By connecting a cable from ground pin on AV jack and GPIO-ground (PIN 9) the noise is gone :-)
Cheers, Bernie_O

- added already mentioned R1 patch for 4.5.x. Zador made a great job, again.
- upgraded Guitar kernel
- added / fixed C1. Thanks to Joe for C1 and Armbian mugs! My generic mugs has been replaced 

- various small bugfixes

It should work on kernel 4.4 with this patch (which is planned for 4.5).

Let's start with a weird image first:
 

 
In the plastic box is an Olimex A20-Lime2, a 2.5" HDD with 2TB and Olimex' largest battery with 6600mAh. Mounted on the top cover (box standing on the side) is a Banana Pi M2+ (to be replaced with NanoPi M1 or OPi One/PC in the future)
 
Why Lime2? Since this board from our friends at Olimex is designed intelligently and provides DC-DC step-up converters on the board providing the ability to power also the connected SATA disk when running from battery (unlike most other A10/A20 boards that do only provide 5V on USB ports in battery mode but not to the disk!). And since A20 is perfectly supported by mainline kernel (I run 4.6.4 on it with btrfs on both SD card and connected SATA disk. Since the Lime2 is used as monitoring/rsyslog host btrfs compression is active and the 2TB HDD might store up to 20TB of raw log/monitoring data)
 
Why BPi M2+? Since board was lying around and I have no other use for it (SinoVoip sent me a review sample a while ago). The idea to combine A20 with a H3 device was simply to add a camera capable and performant device that is ultra cheap (does not apply to BPi M2+ but to NanoPi M1 or OPi One for example). The H3 device will be used to off-load some stuff (eg. OpenVPN encryption), to capture images and do other hardware monitoring (eg. checking temperature in server racks using 1-Wire sensors)
 
Both boards in this mode run up to 8 hours on battery (6h when the 2 TB disk is also always spinning -- but I use a large 64GB Samsung EVO in the Lime2 and wake up the HDD only from time to time to move data over from SD card). And in this special mode the Lime2 is acting as UPS for the H3 board too since BPi M2+ is powered through Micro USB from Lime2's left USB type A receptacle. The same USB connection is also used as a 'private' network utilizing Ethernet gadget driver on the H3 device.
 
BPi M2+ is running our sun8i legacy kernel, g_ether module is active and configuration using a link local address as outlined in this thread. Therefore as soon as BPi M2+ boots and brings up his usb0 interface the board appears as Ethernet USB dongle on the Lime2 and can be used easily with the following settings as directly connected network device (providing ~120 Mbits/sec throughput over the USB cable):
 
 
 
This USB connection can now be used as a directly wired network connection (BPI M2+ is 169.254.2.1 and Lime2 169.254.2.2 and both can interact through this connection or use it as 'heartbeat' connection to monitor network outages). And using BPi M2+ or NanoPi M1 or NEO the very same USB connection can also be used to power the H3 device (not with Oranges there a hardware mod is needed).
 
Now the fun part: In case the USB powered H3 device freezes or is shut down and has to be restarted... how to do so? Some/most A10/A20 boards provide the 5V on their USB ports not directly from DC-IN but through their AXP209 PMU. And if the board is designed that way, power can be switched on/off on request. This is where the sunxi-pio tool gets interesting since with this tool you can query and switch pin state.
 
In the above example BPi M2+ is powered through Lime2's left USB port. VDD_USB of this port can be controlled through PH06 pin. So to cut power from Lime2 to BPi M2+ all I have to do is
sunxi-pio -m PH06'<default><default<default><0>' And to provide power again, it's the opposite:
sunxi-pio -m PH06'<default><default<default><1>' (at least on my Lime2 the left USB port is more reliable than the right port that can be controlled through PH03 pin). To be able to use the sunxi-pio tool you need a recent sunxi-tools version. As Armbian user you don't have to care since we ship always the most recent version.
 
Not all A10/A20 boards support this and pin mappings differ between different boards. So where to look? In the fex files (don't trust them blindly, some vendors horribly suck providing documentation for their own hardware, compare the pin mappings in bananapiprolcd7.fex and bananapipro.fex for example).
 
EDIT: Checked with both Banana Pi and Banana Pro: The USB voltage pin mappings in the fex files are plain BS and do not work (obviously 'copy&paste gone wrong' when they copied all of CubieTech's work in the beginning)
 
I let a script check the fex files of all Allwinner boards we currently support. Two H3 devices show the ability to switch USB voltage (OPi 2 and Plus/Plus2 -- the pin here most probably controls power for the internal Terminus USB hub) but all the others are A10/A20 based:
 
 
Edit: But at least on H3 Orange Pi boards it's possible to toggle power available on Micro USB port from userspace.
 
So if you want to switch power on the USB ports of a Banana Pro you would not use PH03/PH06 but PH00/PH01 instead (and yes, sunxi-pio works with exactly these settings/syntax even when the board runs vanilla/mainline kernel). Since we're talking about A20 Bananas now: These devices do not provide power to a connected SATA disk when running on battery unlike Olimex' boards. So in case you want to ensure that a connected SATA disk keeps spinning when DC-IN is not available then you have to DIY a cable solution taking power from the 2 USB ports and feeding SATA power this way (the SATA power connector on Banana boards is directly wired to the Micro USB DC-IN jack so you can both provide DC-IN here more reliably and have to keep in mind that battery/AXP209 is not involved at all)
 
BTW: sunxi-pio can be used for more than just switching power on USB ports. Simply call it without arguments to get the idea / help text. Anyone trying to decrease consumption of his Allwinner board might love this tool since you're able to switch off on-board consumers from user space.

Yesterday I showed in the first post above how on some AXP209 equipped boards like Lime2 the 5V provided through the USB host ports can be switched on/off using the sunxi-pio utility. So if we use a battery equipped A10/A20 board we can use this also to power other consumers through the USB ports, can switch them off and on and provide an 'uninterruptable power supply' (UPS) mode.
 
The same way we can also cut power to on-board components that are controlled through AXP209, for example a connected SATA disk. The following graph shows Lime2 powered through USB OTG (to get the 'big picture' regarding consumption -- see the post before for reasons when to choose which powering mode). On the left the 2TB Samsung is in 'active/idle' state (spinning but doing nothing -- ~480 mA consumption), then my power management settings in /etc/rc.local let the disk switch to 'standby' mode after 5 minutes of inactivity (340 mA) and then I switched off power to the disk completely using sunxi-pio (230 mA):
 

 
How to know which pin has to be toggled? I just looked into the fex file again:
sata_power_en = port:PC03<1><default><default><0> So by using the following we can physically power off the disk after unmounting the filesystems of course (not available as device later until we power it on with sunxi-pio again or reboot the board):
sunxi-pio -m PC03'<default><default<default><0>' # off sunxi-pio -m PC03'<default><default<default><1>' # on Unfortunately from all our AXP209 equipped boards only a few support powering the disk through AXP209:
 
 
 
But what about other onboard components that might not be used but are by default in 'powered on' state and add to the board's consumption while not needed. Let's search for the magical word '_power' inside the fex files:
 
 
Would be interesting to play around with LCD and CSI power settings and to have a look whether switching those pins off where defined as on by default makes any difference regarding consumption (or for example the GBit Ethernet PHY on some boards when they do not need network connectivity). But this is stuff I leave for others to test and get back to this thread with results.
 
Since we're talking about disks. These are the two lines I add to /etc/rc.local to spin-down Samsung/Seagate SATA disks on A20 boards after 5 minutes of inactivity:
hdparm -B 254 /dev/sda hdparm -S 60 /dev/sda And to manually send SATA disks to sleep 'hdparm -Y /dev/sdX' can be used. Please keep in mind that this is SATA stuff and not every USB-to-SATA bridge contained in USB disk enclosures supports this. Also some disks ignore sleep and power management settings and then scripted approaches like hdd-spindown.sh are needed (as we can see above physically powering off a disk leads to further energy savings but without switching power on the disk won't come back when needed -- unlike sleeping since then the disk's controller simply wakes it up when a new disk access happens)

Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations.
 
 
 
Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance.
 
Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: http://tech.scargill.net/a-question-of-lifespan/ (see also/especially the comments there)
 
Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards: http://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/
 
Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread.
 
Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast.
 
 

 
Preparations:
 
I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected).
  Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot).   Sequential speeds:     Random I/O:     The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run)   Sequential speed mostly irrelevant / random I/O differs and matters a lot!   The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s).   Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot.   All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes.   Detailed results (summary table also available as .ods, .xlsx or .txt):   Samsung Pro 64GB (brand new) http://sprunge.us/DEYd   Samsung EVO+ 64GB (brand new) http://sprunge.us/NLQd   Samsung EVO+ 32GB (brand new) http://sprunge.us/heGL   Samsung EVO 64GB (already used some time) http://sprunge.us/DUOS   SanDisk Extreme Pro 8GB (already used some time) http://sprunge.us/ZPFZ   SanDisk 'Class 10' 8GB (already used some time) http://sprunge.us/OHjT   Intenso 'Class 10' 16GB (already used some time) http://sprunge.us/LUMZ   Intenso 'Class 4' 4GB (already used some time) http://sprunge.us/GbAY   Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter):   Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD  
 
 
Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ
 
 
 
Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF
 
 
 
Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf
 
 
 
Sandisk 8GB (almost new) http://sprunge.us/iViT
 
 
 
Sandisk 8G (new) http://sprunge.us/XHjj
 
 
 
Transcend 8Gb (used) http://sprunge.us/NTRT
 
 
 
Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh
 
 
    Further readings: http://www.bunniestudios.com/blog/?page_id=1022 http://thewirecutter.com/reviews/best-microsd-card/ http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card http://www.bradfordembedded.com/2014/05/flashbenching/ Conclusions:
If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card

It was already fixed and an update will be issued ASAP to minimize the problem. This was simple overlooked so it could not appear in the changelog. We are overloaded. Sorry. 

- SS fix added, tnx
 
Also made:
- initrd @allwinner
- eMMC installer for H3 (you need to build new u-boot for testing)

Thank you very much for the answer and for armbian in general :-)