tkaiser

Why? I explained a few times in the meantime that with NanoPi NEO usbhost1 is needed while usbhost3 is enabled by default anyway. And please remember what @zador.blood.stained said:

This is a great recipe to get no Ethernet at all (since OS images for the Plus result in working Ethernet only on Gigabit Ethernet equipped H3 boards with external PHY while Orange Pi One uses the chip's internal Fast Ethernet PHY). Maybe things improve if you use OS images for Orange Pi One on an Orange Pi One?

This can only happen if /var/log/armhwinfo.log is either missing or empty. Did you also start to delete log files? Since it just works? This thread now has 23 posts and all that would've been needed is Booting Armbian image Insert wireless dongle (2 seconds waiting) nmtui-connect If driver is contained in the kernel and if firmware is contained in armbian-firmware package (as in your case) Wi-Fi is up and running after this (and if not 'armbianmonitor -u' output is needed). No need to fiddle around in config files and with interface names people seem to hate (and not understand). If you love to configure Linux networking the anachronistic way (you call this 'standard' for reasons unknown to me) you can always do so. Just waste some hours of your live to get an idea how to get back primitive interface names (wlan0), how/why some wireless network adapters appear as more than 1 device by default (RealTek's p2p0 you see above for example), how/why network manager and Debian's/Ubuntu's 'classical' interfaces stuff interfere and how to deal properly with link status changes. As with every task you can spend hours on stuff that could be done within seconds --> nmtui/nmtui-connect. BTW: the driver contained for the dongle spits out an awful lot of messages. Might be worth to open an issue at https://github.com/ayufan-rock64/linux-kernel to lower verbosity for drivers below drivers/net/wireless/rockchip_wlan/

A web search for 'wd lcc issue' is sufficient to get the idea why WD drives connected to Linux boxes should be accessible with hdparm/wdidle3.

Fine with this!

You're right, totally forgot about this. What about an ugly workaround in armhwinfo's stop case adjusting cpufreq to 1008MHz based on ${LINUXFAMILY} to ensure 1.1V at startup? Due to release date that soon I vote for this as 'hack' that can be removed once SY8106A SPL driver works later. Hmm... but this would be only a reboot workaround but you reported cold boot issues being gone... I was talking one year ago shortly with jemk about DRAM initialization comparing BSP stuff with mainline and almost forgot everything already. But IIRC he mentioned that BSP does a lot more here and I wouldn't be surprised if there's even some sort of auto calibration (to allow TV box vendors sourcing DRAM chips from the bin and then letting the bootloader do the job to downclock everything until the board does not crash any more). Anyway: IMO a waste of time to look what the BSP stuff is doing. Though if you want to spend some more time on this I would be interested in tinymembench numbers done with BSP and mainline (cpufreq set to exactly 816 MHz with both tries)

Can then be only cpufreq reducation since there was no DRAM change for these two boards? And where's the problem if these boards boot with 816 MHz instead of 1008 MHz, as soon as kernel + cpufrequtils take over it's not an issue any more and 200 MHz difference in early boot stage were negligible when I did some tests on H3 boards last year. Ah, ok. You decreased DRAM clockspeed slightly on the Orange Pi boards too...

Sorry, but besides all this WD marketing BS (targetting the most clueless SBC users on this planet: Raspberry Pi users) the only real 'invention' is the 'WD PiDrive Cable' since preventing underpowering issues with SBC that are broken by design like Raspberry Pis relying on crappy Micro USB to be powered. LOL, these are SATA drives with an integrated USB to SATA bridge with branded firmware to masquerade the origin (GL, JMicron, ASMedia, Prolific, Initio as in the past) Few info: https://community.wd.com/t/technical-questions-regarding-pidrive/142658/7, though smartmontools works with -d sat' but hdparm still doesn't work: https://discourse.osmc.tv/t/wd-pidrive-squicky-sounds/18311/3 (I don't trust in any WD drive I'm not able to configure wrt 'WD LCC problem' since I don't like HDDs dying too early. The WD forum is full of underpowering issues, maybe that's the reason WD currently has a 50% discount... They also needed to provide a firmware fix for a lot of the old models reporting wrong capacity. Maybe the USB-to-SATA bridge used here is an attempt to sell broken 2.5" HDDs (way too slow and with a lot of bad sectors that are remapped by the firmware)? Would explain the low prices... (nope, stupid thought) Edit: well, other people also thought about WD just re-using HDDs with broken platters: "The 314GB HDD — an internal drive manufactured for WD’s MyPassport 2.5-inch external HDD series but presumably rejected for that role because of one or two failed platters, hence the odd, non-standard capacity". Well, maybe it's just a single platter drive with tons of remapped sectors and instead of throwing away the stuff they sell it now to Pi users with a firmware hiding what happened

That's bad. Thanks for reporting. Unfortunately I'm close to clueless wrt the overlay implementation so maybe we get some insights once @zador.blood.stained might look into. No, that was just adding usbhost1 to armbianEnv.txt so if your manual change followed by a reboot doesn't work the 'fix' is none (or just a preparation)

Hmm... the u-boot package included now both the cpufreq decrease from 1008 MHz to 816 MHz and DRAM from 672 MHz to 408 MHz. Would be interesting to test this stuff individually but on the other hand there's really no need to drop sane defaults (and that's 816 MHz -- or maybe 912MHz -- cpufreq and 408 MHz DRAM) And BTW: I still think your assumption from above is wrong: Allwinner's BSP u-boot most probably ignores these settings since the sys_config.fex has higher priority (never looked into details, I had the H5 BSP on my disk a year ago but deleted it pretty fast when Xunlong's 'Buddy drama' started)

Hardkernel/Jmicron released a firmware update tool here https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update (archived and contents mirrored at http://kaiser-edv.de/tmp/tAm6om/jms578fwupdater.tgz) It seems this firmware update does NOT solve the real problem (the bridge not behaving SAT -- SCSI / ATA translation -- compliant but doing its own thing). I checked firmware versions of the onboard JMS578 on my HC1 (/dev/sdb) and on ROCK64 SATA cable (/dev/sda): root@odroidxu4:~/JMS578FwUpdater# for i in /dev/sd? ; do echo -e "$i: \c" ;./JMS578FwUpdate -d $i -v; done /dev/sda: Bridge Firmware Version: v0.4.0.5 /dev/sdb: Bridge Firmware Version: v0.1.0.5 So JMS578 firmware version on the ROCK64 thingie is way higher than HC1's internal but firmware update does only provide a new 'JMS578-v0.1.0.5.bin' version. Now updating firmware on HC1 with newer 0.1.0.5 firmware, setting 5 min spindown timeout and backing up old firmware: root@odroidxu4:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -f JMS578-v0.1.0.5.bin -b ./backup.bin -t 5 Update Firmware file name: JMS578-v0.1.0.5.bin Backup Firmware file name: ./backup.bin Auto spin-down timer: 5 min. Backup the ROM code sucessfully. Programming & Compare Success!! Backing up the ROCK64 SATA cable firmware seems to work too: root@odroidxu4:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -b ./backup_0405.bin Backup Firmware file name: ./backup_0405.bin Backup the ROM code sucessfully. Open File Error!! root@odroidxu4:~/JMS578FwUpdater# ls -la backup* -rw-r--r-- 1 root root 50688 Nov 1 19:34 backup_0405.bin -rw-r--r-- 1 root root 50688 Nov 1 19:31 backup.bin I think I'll wait for the next firmware update that contains a real fix (JMS578 becoming SAT compliant) since with this firmware the chip is still broken: root@odroidxu4:~/JMS578FwUpdater# hdparm -C /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: 70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drive state is: unknown

Built with latest commit to decrease DRAM clock to 408 MHz from 672 MHz: http://kaiser-edv.de/tmp/NumpU8/linux-u-boot-next-nanopineo2_5.34_arm64.deb (dpkg -i)

Sorry, I'm not talking about what we think the kernel uses but Allwinner BSP stuff (sys_config.fex -- there's also a tool to convert this proprietary crap to the Allwinner proprietary DT format we've to deal with 3.10 BSP kernel and of course other BSP components also use this) https://github.com/friendlyarm/h5_lichee/search?utf8=✓&q=dram_clk&type= (u-boot, ATF, 'basic loader'... and also kernel of course) https://github.com/friendlyarm/h5_lichee/search?utf8=✓&q=dram_para1&type= (just another example how/whether this sys_config.fex stuff is used) So sorry, I still don't understand what you're testing. Maybe provide a boot log?

What's this for an image? AFAIK Allwinner legacy u-boot relies on sys_config.fex stuff (at least with H3 legacy u-boot it's like that) and DRAM initialization code uses all the settings encoded in sys_config.fex as well as cpufreq information (boot_clock and dvfs_table and if present/defined the ths/cooler_table as well being able to limit max cpufreq)

Can you elaborate on that? What does 'old u-boot' mean? Do you have a full boot log from FriendlyELEC image?

Well, both DRAM and CPU 'overclocking' can cause instabilities. And we had CPU overclocking until today and we still have DRAM overclocking (FriendlyELEC's first setting for NEO2 DRAM clockspeed was 504 MHz while we and the rest of the world use 672 MHz for exactly no reason other than dealing with upstream ignorance/weirdness -- for the same reason upstream u-boot defconfig uses 408 MHz DRAM clockspeed on NanoPi M1 Plus while it should be 576 MHz in reality but device maintainer does not even answer to emails) IMO it's just a waste of time babbling about instabilities unless DRAM overclocking is also fixed. I think we should use 576 MHz for all NanoPi with dual bank DRAM config and 408 MHz for single bank devices (following FriendlyELEC's own defaults)

Main difference wrt stability between NEO2 and NEO Plus 2 is: no voltage regulation on the former (all the time at 1.1V) while the latter can switch between 1.1V and 1.3V. Since Icenowy reported instabilities with NEO2 when exceeding 816 MHz (that's according to Allwinner the H5 limit at 1.1V) we should limit max cpufreq to this value everywhere: part 1: this is the cpufreq used until cpufrequtils take over part 2: these are new cpufrequtils settings FriendlyELEC allows 1008 MHz with their kernel, no idea whether they did any reliability testing so far... I think Armbian could also use 912 MHz but that would require extensive testing with a lot of users and since this usually does not happen IMO we should stick with Allwinner defaults and limit NEO2 to 816 MHz from now on. @zador.blood.stained I fail to find where we lower DRAM clockspeed for NEO2 to 408 MHz (for whatever reasons 672MHz are set in upstream u-boot)

https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm/boot/dts/sunxi-h3-h5.dtsi#L281-L290 https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm/boot/dts/sunxi-h3-h5.dtsi#L292-L302 That's usb1 and for whatever reasons neither @Lope nor you want to load the respective usbhost1 DT overlay in /boot/armbianEnv.txt. BTW: I hope with latest commit this will be fixed on future Armbian images. Edit: Though usb1 is disabled in sunxi-h3-h5.dtsi (as requested by sunxi kernel maintainers for reasons I really don't understand) it's enabled by FriendlyELEC in the device DT settings: https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts (and the same can be done using the usbhost1 DT overlay in Armbian)

Which is the case for all those boards currently available and announced (NanoPi Core/Core2) Why host mode? I think I still don't understand... let's try it the other way around. What to do if I want 'legacy behaviour' back? With 3.4 kernel on all H3 boards the Micro USB is set to host mode by default (on bananapim2plus and orangepiplus by accident fixed [1] on all other devices it's OTG/host configurable defaulting to host mode unless /sys/bus/platform/devices/sunxi_usb_udc/otg_role has been touched). What to do with mainline kernel to attach an USB disk or any other 'normal' USB peripheral to the Micro USB port to have it working in real host mode (with legacy kernel and our default settings that's as easy as using an adapter cable and works out of the box). IMO that would be the desirable setting especially on boards like NanoPi Duo or Zero Plus 2 where without expansion boards only Micro USB is available to attach USB peripherals. [1] default settings wrt usb0 and legacy kernel: bananapim2plus.fex:usb_port_type = 1 bananapim2plus.fex-usb_detect_type = 0 -- beelinkx2.fex:usb_port_type = 2 beelinkx2.fex-usb_detect_type = 0 -- nanopiair.fex:usb_port_type = 2 nanopiair.fex-usb_detect_type = 0 -- nanopim1.fex:usb_port_type = 2 nanopim1.fex-usb_detect_type = 0 -- nanopim1plus.fex:usb_port_type = 2 nanopim1plus.fex-usb_detect_type = 0 -- nanopineo.fex:usb_port_type = 2 nanopineo.fex-usb_detect_type = 0 -- orangepi2.fex:usb_port_type = 2 orangepi2.fex-usb_detect_type = 0 -- orangepilite.fex:usb_port_type = 2 orangepilite.fex-usb_detect_type = 0 -- orangepione.fex:usb_port_type = 2 orangepione.fex-usb_detect_type = 0 -- orangepipc.fex:usb_port_type = 2 orangepipc.fex-usb_detect_type = 0 -- orangepipcplus.fex:usb_port_type = 2 orangepipcplus.fex-usb_detect_type = 0 -- orangepiplus.fex:usb_port_type = 1 orangepiplus.fex-usb_detect_type = 0 -- orangepiplus2e.fex:usb_port_type = 2 orangepiplus2e.fex-usb_detect_type = 0 -- orangepizero.fex:usb_port_type = 2 orangepizero.fex-usb_detect_type = 0 -- orangepizeroplus2-h3.fex:usb_port_type = 2 orangepizeroplus2-h3.fex-usb_detect_type = 0 -- sunvell-r69.fex:usb_port_type = 1 sunvell-r69.fex-usb_detect_type = 0

I agree but would make the 'USB data lines on pin headers' the first accepted exception. Any objections against adding DEFAULT_OVERLAYS="usbhost1 usbhost2" to nanopiair.conf, nanopineo.conf, nanopineo2.conf and nanopineoplus2.wip and DEFAULT_OVERLAYS="usbhost2 usbhost3" to nanopiduo.conf, orangepizero.conf, orangepizeroplus2-h3.conf and orangepizeroplus2-h5.conf (I would add usbhost3 already to NanoPi Duo config since once the board will land upstream and we remove our deprecated patches commited yesterday usb3 needs to be added anyway and so there's less chance that we accidentally forget this switch later). So we don't need to add usbhost0 but need to point out that in default mode usb0 needs something else to appear (or just to work -- sorry, I really lost track wrt everything USB related and mainline kernel in the meantime). When g_serial is in /etc/modules the port will work in OTG mode? But how to let it work in (real) host mode? And on a related note: With NanoPi NEO Plus 2 AFAIK usb0 is routed to another type A receptacle. In this case the best configuration would be to configure the port directly as real host port using the dedicated ehci/ohci controller pair and not otg/musb?

The above is what you would do on an Orange Pi Zero or on a NanoPi Duo. On a NEO usb3 is already active so you need overlays=usbhost1 usbhost2 to get the 2 USB ports on pin headers working. For the Micro USB port please follow discussion here: https://forum.armbian.com/topic/5558-default-overlays/?tab=comments#comment-42525

Huh? I don't get what you're talking about. The issue we're talking here about is that some small H3 and H5 boards by default expose only 2 USB ports (usb0 == OTG/MicroUSB and usb1 on OrangePi Zero variants while it's usb3 NanoPi NEO/NEO2/NEO Plus 2 -- man, how I hate these shitty names!). So all that's needed is either first line (for Orange Pi Zeroes or NanoPi Duo) or 2nd line for NanoPi NEO variants: overlays=usbhost2 usbhost3 overlays=usbhost1 usbhost2 And as @zador.blood.stained explained over there an USB gadget driver is needed for usb0 to work with mainline kernel. In other words: Using USB on these little gems with stinky Allwinner legacy kernel is a nice and flawless experience while with mainline kernel it's just PITA since kernel devs decided so (IMO there's a reason why Apple as company is successful: since there product development is not driven by engineers trying to solve technical problems but folks who think about stuff from the 'user perspective')

In general IMO we should introduce such a DEFAULT_OVERLAYS setting to address the mismatch between what the kernel folks want and what users expect (the device working the way it's supposed to do). With NanoPi Duo for now we can do it either way since currently the submitted DT patches won't be accepted upstream anyway (since upstream policy will forbid including sun8i-h3-nanopi.dtsi where usb3 is active by default. Haha, nice mess created since not even board makers care about kernel developer's conventions). So to prepare for upstream NanoPi Duo support I would suggest introducing the variable and setting it already to DEFAULT_OVERLAYS="usbhost2 usbhost3"

IMO we should consider shipping with overlays=usbhost2 added to /boot/armbianEnv.txt by default for this board since zero disadvantages but only avoiding support efforts and 'reviews' ('With Armbian mSATA does not work'). Users don't read the fineprint, so let's fix this now and not later. On a related note: I did some tests with zram and vm.swappiness=100 and this really looks promising. Could be a real improvement on those boards with low memory where we can ensure that no legacy kernels will be used. Edit: Or maybe it's better to add ohci2/ehci2 nodes to the DT patch since referencing sun8i-h3-nanopi.dtsi there and activating usb3 by default can already be considered 'wrong' from a kernel dev's perspective (for reasons unknown to me these guys want to reduce 'user experience')

usb0 is OTG and IIRC Armbian's next kernel still not enables this port (TBC -- should be easy trying out the Micro USB port) usb3 is activated in sun8i-h3-nanopi.dtsi and this is obviously the port the Terminus USB hub is connected to So overlays=usbhost1 usbhost2 should be sufficient for 'Shield operation' (though no idea whether both are needed and if only one which one -- @Igor can you do two reboots and find out?) Edit: Should be usbhost2 since @raschid wrote 'USB lines (2&3)' above.