tkaiser

Sure. Don't try to 'edit lib/*.sh files' but use the established mechanisms: Documentation: https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script Example: https://github.com/armbian/build/blob/master/config/templates/customize-image.sh.template Be smart and search: https://www.google.com/search?rls=en&dcr=0&q=Armbian+Customization+site%3Aarmbian.com&oq=Armbian+Customization+site%3Aarmbian.com

The NEO is Fast Ethernet only. You need the NEO2 at least (FriendlyELEC's NAS Bay is compatible with both NEO and NEO2). Both have 2 USB2 ports on pin headers, one connects to the SATA bridge on the NAS bay, the other is exposed as an additional type A receptacle. But you won't get better 'NAS performance' compared to the Banana you already use. For this other variants (either using USB3 or relying on fast and not slow Allwinner 'native SATA') are needed. BTW: I just checked Pine's 'USB to SATA cable' containing a good JMS578 bridge and featuring the ability to attach a 12V PSU to be combined with 3.5" disks. Fits very tightly so could even cure ODROID-XU4's USB3 receptacle problems with

I don't think so.

At least not for HC1 use cases. Usually those older 'vendor' kernels are the only ones with support for advanced graphics stuff (HW accelerated video being the best example) but this shouldn't matter on a headless device. If I remember correctly with the Exynos 5422 we're dealing here it's also possible to make use of this stuff with mainline or the 4.9LTS kernel we use (I read about HW accelerated transcoding on XU4 with emby some weeks ago). Anyway: the most important feature of HC1 is fast storage access which means that 'USB Attached SCSI' (UAS) is a must (twice the performance with SSDs, not that huge gains with HDDs) so forget about the old kernel for this use case anyway since UAS started to work on Exynos 5422 IIRC with kernel 4.8. Sure. Ambient temperature is 22°C. Below 'armbianmonitor -m' output using the SoC's internal thermal sensor: it starts with the HC1 being idle 5 minutes after booting. The heatsink is still cold and therefore SoC temperature in idle is just ~15"C above ambient. After some time +20"C above ambient are more realistic then I fired up a 'NAS test' LanTest with connected SSD, that's already 'worst case' wrt NAS workloads. Temperature gets up to 58"C but after benchmark finished decreases rather quick then I fired up 'minerd --benchmark' (cpuminer 2.4.5 making heavy use of NEON instructions), the Exynos immediately throttles down to 1.8 GHz, after some time it's then 1.5GHz/1.3GHz with SoC temp close to 90°C and when the benchmark stopped it takes some time for temperatures to lower since now the giant heatsink dissipates heat back into the SoC. 13:04:17: 600/ 600MHz 0.27 6% 1% 4% 0% 0% 0% 35.0°C 13:04:22: 600/ 600MHz 0.25 6% 1% 4% 0% 0% 0% 38.0°C Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU 13:04:27: 2000/ 600MHz 0.23 6% 1% 4% 0% 0% 0% 40.0°C 13:04:32: 2000/ 600MHz 0.45 6% 1% 4% 0% 0% 0% 44.0°C 13:04:37: 2000/ 600MHz 0.49 6% 1% 4% 0% 0% 0% 47.0°C 13:04:42: 2000/ 600MHz 0.45 6% 1% 4% 0% 0% 0% 50.0°C 13:04:47: 2000/ 600MHz 0.50 6% 1% 4% 0% 0% 0% 51.0°C 13:04:52: 2000/ 600MHz 0.54 6% 1% 4% 0% 0% 0% 53.0°C 13:04:58: 2000/ 600MHz 0.58 6% 1% 4% 0% 0% 0% 53.0°C ... 13:08:47: 2000/ 600MHz 0.80 7% 2% 3% 0% 0% 1% 55.0°C 13:08:52: 2000/ 600MHz 0.90 7% 2% 3% 0% 0% 1% 57.0°C 13:08:57: 2000/ 600MHz 0.91 7% 2% 3% 0% 0% 1% 58.0°C 13:09:02: 2000/ 600MHz 0.83 7% 2% 3% 0% 0% 1% 49.0°C 13:09:08: 2000/ 600MHz 0.77 7% 2% 3% 0% 0% 1% 48.0°C 13:09:13: 2000/ 600MHz 0.70 7% 2% 3% 0% 0% 1% 48.0°C 13:09:18: 600/ 600MHz 0.65 7% 2% 3% 0% 0% 1% 44.0°C 13:09:23: 600/ 600MHz 0.68 7% 2% 3% 0% 0% 1% 41.0°C 13:09:28: 600/ 600MHz 0.62 7% 2% 3% 0% 0% 1% 40.0°C ... 13:12:02: 600/ 600MHz 0.60 6% 2% 3% 0% 0% 1% 42.0°C 13:12:07: 1800/1400MHz 1.20 7% 2% 3% 0% 0% 1% 77.0°C 13:12:12: 1700/1400MHz 1.74 7% 2% 3% 0% 0% 1% 79.0°C 13:12:18: 1700/1400MHz 2.24 8% 2% 4% 0% 0% 1% 80.0°C 13:12:23: 1700/1400MHz 2.70 8% 2% 4% 0% 0% 1% 81.0°C 13:12:29: 1600/1400MHz 3.21 9% 2% 5% 0% 0% 1% 81.0°C ... 13:22:40: 1500/1300MHz 9.24 42% 1% 39% 0% 0% 0% 87.0°C 13:22:45: 1500/1300MHz 9.38 42% 1% 39% 0% 0% 0% 84.0°C 13:22:51: 1500/1300MHz 9.35 42% 1% 39% 0% 0% 0% 76.0°C 13:22:56: 2000/ 600MHz 8.68 42% 1% 39% 0% 0% 0% 70.0°C 13:23:01: 2000/1400MHz 8.06 42% 1% 39% 0% 0% 0% 69.0°C 13:23:06: 2000/ 600MHz 7.50 42% 1% 39% 0% 0% 0% 66.0°C 13:23:11: 600/ 600MHz 7.06 42% 1% 39% 0% 0% 0% 58.0°C 13:23:16: 600/ 600MHz 6.49 41% 1% 39% 0% 0% 0% 53.0°C 13:23:21: 600/ 600MHz 5.97 41% 1% 39% 0% 0% 0% 52.0°C 13:23:26: 600/ 600MHz 5.49 41% 1% 39% 0% 0% 0% 53.0°C 13:23:32: 600/ 600MHz 5.05 41% 1% 38% 0% 0% 0% 50.0°C Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU 13:23:37: 600/ 600MHz 4.65 41% 1% 38% 0% 0% 0% 51.0°C 13:23:42: 600/ 600MHz 4.28 41% 1% 38% 0% 0% 0% 49.0°C 13:23:47: 600/ 600MHz 3.93 41% 1% 38% 0% 0% 0% 49.0°C 13:23:52: 600/ 600MHz 3.62 41% 1% 38% 0% 0% 0% 49.0°C 13:23:57: 600/ 600MHz 3.49 40% 1% 38% 0% 0% 0% 50.0°C 13:24:02: 600/ 600MHz 2.95 40% 1% 38% 0% 0% 0% 51.0°C 13:24:08: 600/ 600MHz 2.87 40% 1% 38% 0% 0% 0% 50.0°C 13:24:13: 600/ 600MHz 2.64 40% 1% 38% 0% 0% 0% 49.0°C 13:24:18: 600/ 600MHz 2.43 40% 1% 37% 0% 0% 0% 48.0°C 13:24:23: 600/ 600MHz 2.40 40% 1% 37% 0% 0% 0% 48.0°C 13:24:28: 600/ 600MHz 2.21 40% 1% 37% 0% 0% 0% 48.0°C 13:24:33: 600/ 600MHz 2.03 40% 1% 37% 0% 0% 0% 47.0°C 13:24:38: 600/ 600MHz 1.87 40% 1% 37% 0% 0% 0% 47.0°C 13:24:44: 600/ 600MHz 1.72 39% 1% 37% 0% 0% 0% 49.0°C 13:24:49: 600/ 600MHz 1.74 39% 1% 37% 0% 0% 0% 47.0°C Armbianmonitor -u output: http://sprunge.us/HjEg

https://github.com/Icenowy/linux/commit/e2afcd761e80862e3dc5ae3f4011a460fdca3dc4

There were a lot of insanely stupid complaints about this but besides that there are/were also real issues like dropped frames and no way to cure this back then (due to lack of documentation and software). Since this NanoPi Duo image will run on every H2+/H3 board around I simply booted it and had a look. root@NanoPi-M1:/lib/firmware/xr819# ls -la -rw-r--r-- 1 root root 2308 Aug 29 06:37 boot_xr819.bin -rw-r--r-- 1 root root 975 Aug 29 06:37 device-xradio.mk -rw-r--r-- 1 root root 126416 Aug 29 06:37 fw_xr819.bin -rw-r--r-- 1 root root 744 Aug 29 06:37 sdd_xr819.bin root@NanoPi-M1:/lib/firmware/xr819# md5sum * 049abcb4768e92490f9fcafff114d1eb boot_xr819.bin 01a5e63ddf60e2a4af5b073cec783bb7 device-xradio.mk 7a313e6957e635d9c1cd0d6902739d14 fw_xr819.bin e5d4afaf1a8c24f79f6764c289f1102f sdd_xr819.bin That's at least no new firmware (contents identical as what ships with Armbian's firmware package). Let's look at the driver: root@NanoPi-M1:~# modinfo xradio_wlan filename: /lib/modules/4.11.2/extra/xradio_wlan.ko alias: xradio_core license: GPL description: XRadioTech WLAN driver core author: XRadioTech alias: sdio:c*v0020d2281* depends: vermagic: 4.11.2 SMP mod_unload ARMv7 p2v8 Interested OPi Zero users could simply give the nanopi-duo_ubuntu-core-xenial_4.11.2_20170829.img a try and on the other hand NanoPi Duo is that inexpensive that interested persons simply should order one and try it out themselve (reporting back of course).

Of course. And to try to remain on-topic here: this was just meant as an example what to check on HC1 if a connected EVO840 SSD shows dog slow performance (on HC1 it can only be related to underpowering or using the old crappy 3.x kernel not being UAS capable, on XU4 it's always possible to choose a crappy USB-to-SATA bridge too). I'm preparing a tutorial like post about RAID on SBC within the next weeks where these issues (underpowering affecting performance and realibility) are covered. But I was surprised that my very first test already sucked that much.

No time wasted! I thought today a little bit about why Armbian ships with such an anachronistic default configuration and whether it would be worth a try with more recent kernels to switch from swap to zram (and adjust vm swappiness since with vm.swappiness=0 most probably no one will ever see a difference). An interesting test would be sed -i 's/vm.swappiness=0/vm.swappiness=60/' /etc/sysctl.conf FILE=$(mktemp) wget https://mirrors.kernel.org/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb -qO $FILE && dpkg -i $FILE reboot But I've to admit that I don't know how to test whether something changes since I know swapping only as problem of the past. I've now 3 ROCK64 with different DRAM sizes. Maybe someone has an idea how a useful 'benchmark' could look like comparing different DRAM sizes?

HK's kernel is in sync since 10 hours: https://github.com/hardkernel/linux/commits/odroidxu4-4.9.y BTW: with my EVO840 I get 240MB/s write on both XU4 and HC1 (with an UAS capable USB-to-SATA bridge of course! JMS567, JMS578 and ASM1153 successfully tested). If performance is that low as the 120MB/s you reported I would check 'lsusb -t' output whether you're using UAS or not and I would also check dmesg output for underpowering symptoms. I prepared a test with the fastest USB3 thingie we currently support (ROCK64) where we usually get +380 MB/s with fast SSDs random random kB reclen write rewrite read reread read write 102400 4 698 2538 1457 1577 1052 30803 102400 16 2732 84156 2697 3284 74365 572 102400 512 255254 265324 270608 279494 271598 1382 102400 1024 274236 1377 288145 296826 285552 1387 102400 16384 298959 298371 318954 326778 326171 1000 My test setup was an external VIA812B hub with an integrated RTL8153 Ethernet chip, to one hub port a JMS578 with EVO840 connected to another port a JMS578 with a Transcend TS120GMTS420 connected) and when I started the usual iozone benchmark underpowering (this time I would suspect undercurrent and not undervoltage as it's usual with XU4) happened. Problems/benchmark started at '239.752135': http://sprunge.us/JOMC (these are no UAS problems but just the usual symptoms of underpowering with loaded uas driver)

And that's the mistake. Simply FORGET about swap. It doesn't increase your useable memory and as soon as your board would start to swap it's already over since performance will suck so horribly that it's time to think about a board with more DRAM. Do you need more DRAM? NO according to 'free' output above. You RAM is mostly used for buffers/caches which would be freed immediately once really needed by the kernel or an application. You do NOT have to worry about swap, swap doesn't help with 'increasing memory' and 'more memory' is also useless for your use case. So simply stop thinking about swap (and if you would need swap since you're running out of physical memory increasing a swap file/partition is close to stupid since swapping on SD card is slow as hell -- use zram instead IF it would be necessary which is it NOT). The only reasonable answer we as Armbian team should give to people asking about 'increasing swap?' is 'forget about, it's useless!'. And if users are running out of physical memory the only reasonable recommendations are 1) try zram and 2) try a board with more physical memory.

No, this is wrong in many ways (due to 'tutorials/recommendations on the Internet' being copy&paste of horribly outdated stuff again and again). You're not running out of physical memory (0 bytes swap used out of 128MB before and now 512MB) so why do you care at all? Use fallocate and not dd to create a swapfile Use zram instead of swap (it's 2017 and swap on SD cards is insane anyway)

That page is obviously wrong (copy&paste from another page and a first round search&replace done). Before device pages aren't referenced from here I wouldn't trust that much in contents. Searching here for commits with 'core' in their name seem currently more sufficient (and confusing: Core is said to use 'phy-handle = <&int_mii_phy>;' while Core2 is said to use GbE: 'phy-handle = <&ext_rgmii_phy>;') Anyway... it seems both don't use Wi-Fi so there's some hope they get FCC/CE certifications and can be used in industrial and DIN Rail enclosures providing internal reliable storage (booting from SPI NOR flash and then switching over to rootfs on M.2 SSD).

Thanks for 'announcing' NEO Core/Core2 now somewhat officially (my scripts monitoring this and that here and there spotted them already some time ago since fortunately you develop in the open). So with Core/Core2 we get a H3/H5 base module that exposes RGMII and all 3 USB host ports on GPIO headers to be combined with this 'Mini shield' providing Gigabit Ethernet, an M.2 SATA 2242 slot behind a JMS567 or JMS578, two USB2 receptacles that do not have to share bandwidth with full mechanical RPi compatibility so RPi enclosures will fit and even many/most RPi HATs relying on the original 26 pin GPIO header. Very well done

Use next kernel, don't think about USB3 issues any more (that's a XU4 problem), don't expect serial console problems (that was an Armbian problem) and please overthink 'rootfs on HDD' (on SSD that's great, HDDs are too slow and you prevent them from sleeping when moving the rootfs on them). @Igor: how are download pages generated (focus on preventing misleading/wrong infomation)?

Well, being told we're 'apart of the next biggest thing' (and not being 'a part' of it) is one thing, the other is Playing the role of the 'wrong' Steve isn't a great idea anyway especially since you're asking for the impossible (a Linux kernel running as app inside a sandboxed environment on top of a XNU kernel having any access to low level stuff)

Only relevant difference is kernel version (mainline vs. legacy -- see Igor's explanation above) and since @Fireball already uses Xenial I would recommend to simply give the appropriate 'Xenial next' image from here a try: https://dl.armbian.com/bananapipro/

Depends on the settings you use (given power design is as efficient as Xunlong's for the OPi Zero, ingredients -- H2+ and XR819 Wi-Fi and using H2+'s internal Ethernet PHY -- are the same):

Helping with what? BTW: I build custom debian (not raspian) images for the RPi for NAS projects (even if Raspberries are such lousy devices for this use case) and I try to ensure that this never will destroy the Armbian project.

Can anyone running a recent kernel please provide /proc/cpuinfo contents or even better output from 'sudo armbianmonitor -u' when running an image based on Armbian? I'm interested in differentiation strategies for the two CPU clusters.

Can anyone running a recent kernel please provide /proc/cpuinfo contents or even better output from 'sudo armbianmonitor -u' when running an image based on Armbian? I'm interested in differentiation strategies for the two CPU clusters.

Well, this one is about NEO Plus 2 and not NEO 2 (and there's also explained what happened and why they re-designed NEO Plus 2), so maybe this is all a misunderstanding? I won't check their site for the 1.5GHz claim since pretty useless, especially simce we know that with proper voltage regulation you can overvolt H3/H5 devices and then 1.5 GHz are most probably possible (though I never understood why people buy the slowest devices on earth if they're looking for performance ) 'Comparable' might be an Orange Pi PC2 -- also H5 but with an I2C capable voltage regulator so you're free to fry H5 with the voltage you want and can then allow the CPU cores to clock higher, also higher DRAM bandwidth which might be important for certain types of workloads. But IIRC with Armbian currently dvfs/cpufreq scaling isn't working on H5 boards anyway so you'll have fun tweaking an FriendlyELEC image (they use a 4.11.2 kernel with all necessary patches applied) to run on an Orange Pi As Zador suggested: please describe the 'problem' and your limits...

Hard to tell what's going on or what the differences are compared to your other Xenial box. I've also not the slightest idea how recent Windows versions behave as SMB clients (I touch Windows only in the server variants from time to time). You could provide 'sudo armbianmonitor -u' output in any case so others might look into. In case you've two networking connections active on the Zero (Ethernet and Wi-Fi) this might be part of the problem. You could also fire up 'smbclient -L lala -I $ip-address' from both of your Linux hosts scanning each other to get an idea about differences.

That's not possible Armbian is a build system creating also OS images that rely on either Debian Jessie, Stretch or Ubuntu Xenial. All normal packages are coming from these distributions (applies to Samba too of course). So in case you use a brand new Windows release and try to combine this with a horribly outdated Samba release (Debian Jessie flavour) then some problems might occur. I would check which distribution you use (that's not Armbian but either Jessie or Ubuntu) and then do a web search for 'win 10 $distro samba not visible'.

Nope. Software doesn't know that much about hardware in this case. NEO2 has no voltage regulation and H5 is fed with 1.1V which limits maximum cpufreq on this board to 812 MHz (maybe 864 MHz). FriendlyELEC learned from a conversation with open source community that with mainline kernel they could make use of DVFS (dynamic voltage frequency scaling), something that still seems not possible with Allwinner's BSP. As a consequenze they dropped Allwinner's software offerings, rely on mainline u-boot/kernel now, have DVFS working and even re-designed a few H5 boards to implement better voltage regulation (eg NanoPi M1 Plus 2, NEO Plus2 or the new NEO Core2 which are both equipped with an I2C accessible voltage regulator). What limits cpufreq is DVFS (the higher the clockspeeds the higher VDD_CPUX voltage provided). With NEO2 you're out of luck since this board remains at 1.1V all the time. All fixes in software (adjusting cpufreq OPP or thermal trip points) will only result in instabilities, freezes, crashes but not in higher performance. It's slightly larger sibling NEO Plus2 can switch up to 1.3V (~1200 MHz) and M1 Plus 2 as well as NEO Core2 can theoretically be fed with +1.4V which would allow for slightly higher clockspeeds (increasing temperature and consumption a lot). On small boards like these NEOs this is of course absolutely useless unless since heat dissipation is a huge problem. Without huge heatsink(s) plus additional fan(s) don't think about running any load at 1 GHz clockspeed or above over longer periods of time (read as: few minutes).

Since I'm playing around with a M.2/2242 SSD currently (overheating badly when operating at 'native speeds' connected to a SATA or USB3 port) I just checked in Photoshop whether another 'Mini Shield' could provide the ability to use M.2 instead of mSATA: 2242 seems to fit, with 2230 it shouldn't be a problem at all. I added also a little DS1307 based RTC module on the pin header.