tkaiser

If this was on Linux then forget about Etcher (and always forget about dd of course). On Linux Etcher is as bad as dd and simply broken since it does NOT verify what it writes (learned this just a few days ago).

Testers wanted: https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update The new firmware release should provide full SAT support (so we can directly talk to the disk and apply spindown settings there, also hdparm should report the drive's state correctly now). Also TRIM is now reported to work. Feedback welcome.

Testers wanted: https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update The new firmware release should provide full SAT support (so we can directly talk to the disk and apply spindown settings there, also hdparm should report the drive's state correctly now). Also TRIM is now reported to work. Feedback welcome.

All armbianmonitor thermal read outs are broken on at least pine64/legacy and odroidxu4/next

Easy: apt.armbian.com broken again (at least wrt jessie). No idea why that happened (we prefer to not communicate here), no idea how it has been fixed last time, no idea how stuff like this can be avoided.

There should be no /boot fstab entry at all so there's something wrong here witch Stretch. I asked a while back whether other devs are testing this but got zero answers. A nand-sata-install related thread has been trashed in the past and I've no idea what happened to 'team testers'.

I would better try out whether such a udev rule works and if so propose a simple change to Armbian to enable users who are member of gpio group to access the stuff as unprivileged users. It needs testing, it needs code, it does not need more frustrating babbling with the only result afterwards that nothing happens.

If that's true then this is a clear indication to better stay away from this at all (since 4.13 is already EOL this means he doesn't take care about the kernel part at all and now only thinks about an upgrade to please concerned users). More thoughts here BTW: https://www.cnx-software.com/2017/11/30/zeroshell-firewall-router-linux-distribution-works-on-x86-hardware-raspberry-pi-23-some-orange-pi-boards/#comments

Just two reasons: 1) It does what it tries not always good 2) It does what it tries not always good But since discussions never happen, the only way to deal with this is frustration and discouragement

There's something with Support_Package.tar in its name at http://kaiser-edv.de/tmp/NumpU8/ but I don't understand what you're doing since all that's needed is Armbian's build system, config file ending on .csc and latest fex file. We use boot config from OPi Zero Plus 2 H3 and I hope this one uses 408 MHz DRAM speed. BTW: https://github.com/Allwinner-Homlet (forward ported BSP stuff to kernel 4.4, one single code vomit as usual)

To do this correctly a lot of work is needed. I started with something like that based on @Peter Scargill's 'the script' but gave up back then due to other priorities. IMO it would be great if Armbian lays the foundation for something like that (root-less GPIO access and such basics, having I2C and SPI active with mainline kernel by default without having to fiddle around with DT overlays first and so on...) and it would also be great to fix current issues with eg. armbian-monitor first before adding new functionality.

H2+/H3/H5 boards overview (early 2018 update) For the methodology/categorization please see above. This is just a brief overview adding the boards that appeared within the last few months (Banana Pi Zero, NanoPi Duo, Orange Pi R1, Orange Pi Zero Plus, Sunvell R69) and will appear soon or are just released (ACT Power X-A1, Libre Computer's H2+/H3/H5 Tritium, NanoPi NEO Core and Core2): NAS category (only due to Gigabit Ethernet available): Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Core 2: H5, 512MB/1GB DRAM, eMMC, 1+3 USB ports useable, GbE on pin header NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB slow eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi Orange Pi Zero Plus: H5, 512MB, 1+1+2 USB ports useable, Wi-Fi X-A1: H3, 1GB DRAM, 8GB eMMC, 1+2 USB ports useable IoT category (cheap, small, energy efficient, most of them headless): Banana Pi Zero: H2+, 512MB DRAM, no eMMC, 1 USB port useable, Wi-Fi/BT, Fast Ethernet (pin header) NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi Duo, H2+, 256/512MB DRAM, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet (pin header) NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Core: H3, 256/512MB DRAM, optional eMMC, 1+3 USB ports useable, Fast Ethernet (pin header) NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet Orange Pi R1: H2+, 256MB DRAM, 1+2 USB ports useable, Wi-Fi, 2 x Fast Ethernet (1 x USB RTL8152) OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI Tritium IoT: H2+, 512MB DRAM, 1+3 USB ports useable, Fast Ethernet General purpose (HDMI and full legacy kernel support: video/3D HW accelerated): Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Sunvell R69, H2+, 1GB DRAM, 8GB eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet Tritium: H3, 1GB DRAM, 1+3 USB ports useable, Fast Ethernet Tritium: H5, 2GB DRAM, 1+3 USB ports useable, Fast Ethernet

'sudo armbianmonitor -u' or it didn't happen...

Hmm... now we have detailed instructions in Armbian forum for a problem that has been solved long ago in Armbian (by stopping to use unreliable device identifiers and doing it correctly --> UUID). Why not adjusting the above to UUID usage instead?

This (and iozone output) looks more correct. But currently with 5.35 on sunxi hardware the CPU cores won't ramp up the clockspeed correctly (fix will be in 5.36 so simply do an 'apt upgrade' on monday) so for a new round of NAS tests (LanTest and Explorer) you might want to use the cpufreq-set call from above to switch from ondemand to performance to get an estimate how NAS performance will look like next week again. I understood it this way and just wanted to warn that things might happen you don't expect. It's stuff people normally don't think about, it happens way too often and it's always fun to try to recover from such stuff. For example encodings and umlauts: you create something with an Ä in its name on a file server, then attach the disk directly to the client. Still looks like Ä but different representation. So you can see the file but don't access it (there exist 4 different Unicode Normalization forms with 2 being used here and there). That's why I would refrain from trying such stuff. If data is on a NAS share then only access it there with the same daemon as when you created the data (eg. only using SMB/Samba or only using NFS or only using AFP/Netatalk when macOS clients are in the network)

Yeah, it's called Samba! Seriously no idea since I stopped using Windows prior to Win95 release (only deal with it on servers and there that's not an issue). And I don't know for sure with Windows but AFAIK it's not the best idea to access any filesystem that's shared in NAS style locally at the client (due to different encodings that might be chosen and different representation of file metadata and 'extra attributes', do a web search for 'alternate data streams' combined with either 'ntfs' and 'samba')

Hmm... the iozone read values are bogus but since /dev/sda1 is a FUSE filesystem that's understandable. For whatever reasons the 5.35 repo does not contain latest fixes so I can only guess whether it's NTFS or ExFAT (smells like NTFS). Either choice is just a great way to limit NAS performance on something that weak as a NanoPi NEO. For whatever reasons with 5.35 also our cpufreq governor tuning is broken (fix comes with 5.36 soon) so in your setup you're currently bottlenecked by CPU cores clocking too low and wrong filesystem. If you repeat the test with an ext4 or btrfs write performance should be much better.

And now please cd /srv/dev-disk-by-id-usb-JMicron_Tech_0000000045D9-0-0-part1 cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state iozone -e -I -a -s 100M -r 4k -r 128k -r 16384k -i 0 -i 1 cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state cpufreq-set -g performance iozone -e -I -a -s 100M -r 4k -r 128k -r 16384k -i 0 -i 1 armbianmonitor -u BTW: only two suspicious entries are 'inherit acls = Yes' and 'hide special files = Yes' -- suspicious since I never tested whether they are able to influence performance.

Yep, and that's why I asked for LanTest and not Windows Explorer numbers (since with the latter it depends on your Windows version too what's happening since starting from Windows 7 on Explorer uses up to 8 connections in parallel and also tunes blocksizes dynamically). Can you post output from 'testparm' please?

The problem is the created confusion and armbian-config is here only part of the problem but not of a solution. It just looks in a directory for files that follow a specific naming scheme (${OVERLAYDIR}/${overlay_prefix}*.dtbo), presents them as list, you can tick checkboxes, then something will be written to another file, done. What happens after the mandatory reboot might be surprising and what's displayed depends solely on the contents of a directory defined as $OVERLAYDIR (and the contents are subject to package updates that happen somewhere else) and is not related to the hardware in question. A suitable UI (it's called USER interface for a reason since it should focus on the user) would try to address the job from the user perspective. That would require: displaying what's available as selectable hardware and what's already active, therefore not needing a DT overlay! (not happening now, usb0host for example is displayed as inactive while it's active in reality or not -- the most basic principle of an UI is already violated here) allow to only do something that really works (a lot of overlays would require additional parameters and without them activation is pretty much useless) checking and trying to resolve overlay conflicts Creating such an UI that really works is days of works but would add least be something useful and not add further to the confusion that's already there. IMO the only stuff where the current armbian-config implementation helps (activating stuff on pin headers like USB, Audio (analog-codec and I2S, SPDIF where appropriate) without the need to specifiy additional parameters) could be avoided in the first place by activating this stuff by default.

No. http://linux-sunxi.org/FriendlyARM_NanoPi_NEO2#USB -- that's the hardware side of things. NanoPis with USB on pin headers have there usb1 and usb2 while Orange Pis with USB on pin headers use usb2 and usb3 there. It was all the time like this but this is also surrounded by a high amount of confusion since day 1. No idea why usb1host appeared on your installation when for whatever reasons (the OMV images all the time added usb1, usb2 and usb3 as default DT overlays but I've no idea what armbian-config displayed based on what). IMO the armbian-config 'UI' is not really sufficient since showing only the status of loaded DT overlays and not taking into account what's really active (which would involve accessing stuff below /proc/device-tree, comparing with what's available as system and user DT overlays and what's active -- it would need a lot more efforts to turn this into a really suitable UI with U as in 'user') I won't comment on NAS performance any more since I suggested in this thread already testing with another tool to no avail

Did you read through this already?

Fine with me.

Adding unreliable overclocking settings on Allwinner and Rockchip devices is unfortunately pretty easy (and the proposed patch looks wrong already in the first line since increasing cpufreq by 100 MHz without adjusting the voltage at all). That's why stuff like https://github.com/ehoutsma/StabilityTester exists. Feel free to try it out, @ErwinH used the tool to develop a sane DVFS OPP table last year for Orange Pi PC2 with this (since we found out that this highly optimized Linpack is a great way to check for DVFS undervoltage caused instabilities already before the board freezes/crashes. That lesson was learned when dealing with unreliable overclocking on Pine64 before)

Did you do this: 'On Allwinner devices after switching to boot from NAND or eMMC clearing the boot loader signature on the SD card is recommended: dd if=/dev/zero of=/dev/mmcblkN bs=1024 seek=8 count=1 (replace /dev/mmcblkN with the correct device node'