guidol

@tkaiser NanoPi Neo2 with debian stretch:
Linux nanopineo22 4.13.13-sunxi64 #214 SMP Thu Nov 16 01:52:21 CET 2017 aarch64 GNU/Linux
as attachment
 
NanoPi_Neo2_tinymembench.txt

@tkaiser NanoPi Neo2 with debian stretch:
Linux nanopineo22 4.13.13-sunxi64 #214 SMP Thu Nov 16 01:52:21 CET 2017 aarch64 GNU/Linux
as attachment
 
NanoPi_Neo2_tinymembench.txt

Yes, the lsusb ID is "Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp."
but IT IS a JMS567 like noted at the FriendlyElec-page for the NAS:
http://www.friendlyarm.com/index.php?route=product/product&product_id=192
 
And as attachment the proof as a picture
 
 

without the case I got 35 degree while idle and 37 degree with the case
(dont know why - but I did lost my openshh-server installation - so I had to open the case and use the serial-TTL-port and did reinstall the openssh-server.)

Reboot doesnt seems to work like before.... while booting up the <5 appears then the Ubuntu-login-Screen.
After u-boot the screen seems to be initialized in another way (short dissorted image)

Thats right...they are from Sven Kayser...I asked him now on Facebook about the pictures.
 
[EDIT] He did say:
 
Please do.

Yes - for sure - if it do help
with the Fake-6.0.1 Android...its inly a Kitkat 4.4 - so no KODI 17.5 - only KODI 16.1
Her are pictures from @tkaiser - maybe you can use them also? what did you say Thomas?

To stop wasting my and other's time on this boring 'issue' here a final summary:
Close to unbelievable but after another 'evil tkaiser attacking us' event today the hardware vendor 'fixed' voltage regulation description. Just to remind you: this file has to be correct in the first place, there's no excuse for such wrong information there, it's simply the hardware vendor describing how the board works. So now that PL01 is used for voltage regulation (now in conflict with another active PL01 entry for s_rsb_sda -- good luck!) only all gmac* entries are still wrong and cooler_table not using the 912 MHz OPP is most probably a great recipe for poor performance when overheating occurs. So in case someone from SinoVoip wants to fix their pseudo Armbian build it would be wise to fix the fex first since afterwards Armbian's h3consumption tool can work without issues (today not due to still wrong fex file) On their Gitbook pages the size of M2 Zero increased by 5mm (now at least this most basic info is correct), most of the other 'information' is still sparse, wrong, missing, bogus. But fortunately the hardware is still too small on their product page and of course soon everywhere around the globe in advertisements and product listings since all resellers use the wrong dimensions they've been provided with back in July. So anyone interested in this board running with the outdated legacy kernel: chances are great that you get a working OS image over at bananapi.org (soon). As a reminder: Armbian follows the policy to not officially support Raspberry Pi boards which of course also applies to deliberately compatible looking but mostly incompatible RPi clones like this M2 Zero here (we don't want to see this forum/community dying when RPi users or fooled M2 Zero customers arrive) Armbian also tries to phase out legacy kernel support (3.4.113 which is not supported any longer since over half a year now). CSI/camera support with mainline kernel is still WiP so when switching from legacy to mainline camera functionality will also be missing. Again no reason to officially support such a device Third 'problem': dishonest advertising. Nowhere is mentioned by the vendor that M2 Zero is totally incompatible to RPi cameras (which is something average buyers expect) and RPi software (which is something clueless buyers expect from something that mimics the look of an RPi Zero and is said to run 'Raspberry Pi image'). There's really no reason for us here wasting our spare time with support efforts like this: https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=43088  
Exactly. @Lion Wang's problem is that he wants to sell hardware and his company earned a very negative reputation over the last years (believing this would be caused only by evil people outside and not related to their internal and pretty real problems). That's something where some idiots here at Armbian could help working for him in their spare time and doing his software and support work.
 
@lvmc has the problem that he wants to use this BPi board with his own camera modules. Should work now so let's please stop babbling about community and so on.
 
We have the problem that even if we wanted to support SinoVoip products they don't allow us. They refuse to cooperate, do not provide correct hardware descriptions, do not listen to community, delete community knowledge, ignore(d) even patches they got for free just due to ignorance, ignorance, ignorance.
 
A few people here suggested to give SinoVoip a final chance. I support this. The problem is... I and others are dealing with Banana madness now in the 3rd year. We have heard that so often that it simply got too boring. So let's step back now, give them 6 months of time to show that they're willing to improve, deal with their internal ignorance/stupidity problems and then let's have a look again.
 
In the meantime it would be great if people would stop asking us for anything Banana related. Thank you.
 
 

Its not about people or being personally - but about finding solutions for problems....

So I found these quotes better:
 
Coming together is a beginning; keeping together is progress; working together is success.   [Henry Ford]
or
Let's not forget it's you and me vs. the problem... NOT you vs. me.  [Steve Maraboli]

if the costs are rising to fast - how about installing a standard-eMMC socket like on the ODROID C2 or inside the Pinebook?
I think this would cost only a few cents?
For me that would be fine - then while I upgraded my Pinebook to 32GB eMMC I could use the old 16Gb eMMC on my ODROID C2
AND if the market will supply faster/bigger eMMC modules I can swap out the slower/smaller against a faster/bigger one

You're welcome! - if there is a thing in my possibilities i will try to help. 
But Iam glad that you and the others here could help me to get my different PIs running smoothly
 
Also to you: Thank you for your fast support! Many Users of the Orange Pi or H2(+)/H3 and H5 Boards will also thank you!

The only little catch with nmtui - I got sometimes is the subnet.
If you only insert a static IP in nmtui it will automatically add the subnet /32 ( 255.255.255.255 = LOCKUP  )
For a FAQ it would be nice to declare that the most users will have to add a /24 (255.255.255.0) after the IP to get the
communication working. (onlly IP-address of the Pi and not at the Gateway-/DNS-IP)
 
For my OPi R1 I had to ifconfig down the USB Ethernet (the port near the TTL-serial (RX,TX,GND) and wlan0
to get a a SSH-connect (or deactivate the connection via nmtui).
 
The real eth0-Ethernetport is near the WiFi-Chip 8189ETV and the 13-pin-row and named Wired Connection 2 (at install time)
 
PS: The OPi R1 Legacy Image is running much cooler on the R1 as the Opi Zero Image!

I think nobody has a complete "perfect" product....neither "Orange Pi" nor "Banana Pi" nor "Nano Pi" nor "Raspberry Pi".
Every product has some details that could be better (lower heat, better documentation, better linux-images, better cases, less binary blobs).
So I got some of every sort
But - I personally - like the wiki from FriendlyElec/FriendlyARM at
http://wiki.friendlyarm.com/wiki/index.php/Main_Page

Most - NOT ALL - pages does include very interesting and valuable informations for me (PinOuts and HowTos, FAQ).
OK some should be more actual - but there are many pages for many diffrent models and if ne page hasnt the information then I could find mostly the information at a page of a other model. 
 
The downside - their forum seems mostly supported from users to users. No technican seem to take a look here on a daily basis

tkaiser OPi R1 Image:
Linux orangepi 3.4.113-sun8i #13 SMP PREEMPT Sat Nov 4 07:45:43 PDT 2017 armv7l armv7l armv7l GNU/Linux
 
After resize-boot armbianmonitor/iwconfig:
root@orangepi:~# armbianmonitor -u /var/log/armhwinfo.log has been uploaded to http://sprunge.us/EVRd root@orangepi:~# iwconfig lo no wireless extensions. enxc0742bffe8ff no wireless extensions. wlan0 unassociated Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency=2.412 GHz Access Point: Not-Associated Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 eth0 no wireless extensions. after configuring the interfaces via nmtui - without problems:
root@orangepi:~# armbianmonitor -u /var/log/armhwinfo.log has been uploaded to http://sprunge.us/HOVb root@orangepi:~# iwconfig lo no wireless extensions. enxc0742bffe8ff no wireless extensions. wlan0 IEEE 802.11bgn ESSID:"MySSID" Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency:2.462 GHz Access Point: C0:25:E9:44:71:68 Bit Rate:72.2 Mb/s Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:****-****-****-****-****-****-****-**** Security mode:open Power Management:off Link Quality=100/100 Signal level=70/100 Noise level=0/100 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 eth0 no wireless extensions. root@orangepi:~# ifconfig enxc0742bffe8ff Link encap:Ethernet HWaddr c0:74:2b:ff:e8:ff inet addr:192.168.6.154 Bcast:192.168.6.255 Mask:255.255.255.0 inet6 addr: fe80::c274:2bff:feff:e8ff/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10302 errors:0 dropped:0 overruns:0 frame:0 TX packets:1086 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1316838 (1.3 MB) TX bytes:349868 (349.8 KB) eth0 Link encap:Ethernet HWaddr e2:fc:56:2f:d5:dc inet addr:192.168.6.101 Bcast:192.168.6.101 Mask:255.255.255.255 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:238 (238.0 B) Interrupt:114 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:388 errors:0 dropped:0 overruns:0 frame:0 TX packets:388 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:95697 (95.6 KB) TX bytes:95697 (95.6 KB) wlan0 Link encap:Ethernet HWaddr 08:ea:40:7c:02:ad inet addr:192.168.6.152 Bcast:192.168.6.255 Mask:255.255.255.0 inet6 addr: fe80::aea:40ff:fe7c:2ad/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8559 errors:0 dropped:0 overruns:0 frame:0 TX packets:24 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1553591 (1.5 MB) TX bytes:3347 (3.3 KB) root@orangepi:~# lsmod Module Size Used by 8189es 1075930 0 zram 8964 4 pcf8591 3363 0 bmp085 3487 0 cdc_ether 3679 0 usbnet 14096 1 cdc_ether g_serial 28549 0 btrfs 712409 0  

@tkaiser Dont be frustrated -  now that I got my R1 here is fex-file, lsmod, iwconfig and dmesg from their image for the R1: ubuntu_server_xenial_H2_R1_V0.1.img
ubuntu_server_xenial_H2_R1_V0.1.img: Linux OrangePizero 3.4.39 #2 SMP PREEMPT Fri Apr 14 14:05:55 CST 2017 armv7l armv7l armv7l GNU/Linux (running hot like the armbian legacy) root@OrangePizero:~# iwconfig gre0 no wireless extensions. lo no wireless extensions. tunl0 no wireless extensions. wlan1 unassociated Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency=2.412 GHz Access Point: Not-Associated Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=0/100 Signal level=0 dBm Noise level=0 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 eth1 no wireless extensions. wlan5 unassociated Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency=2.412 GHz Access Point: Not-Associated Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=0/100 Signal level=0 dBm Noise level=0 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 sit0 no wireless extensions. eth0 no wireless extensions. ip6tnl0 no wireless extensions. root@OrangePizero:~# lsmod Module Size Used by r8152 49914 0 cdc_ether 3187 0 usbnet 14152 1 cdc_ether sunxi_ir_rx 9150 0 gpio_sunxi 8265 0 8189es 996645 0 root@OrangePizero:~# ifconfig eth0 Link encap:Ethernet HWaddr 76:92:b2:d9:2d:6d inet6 addr: fe80::7492:b2ff:fed9:2d6d/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:510 (510.0 B) Interrupt:114 eth1 Link encap:Ethernet HWaddr c0:74:2b:ff:e8:ff inet addr:192.168.6.153 Bcast:192.168.6.255 Mask:255.255.255.0 inet6 addr: fe80::c274:2bff:feff:e8ff/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1253 errors:0 dropped:0 overruns:0 frame:0 TX packets:994 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:122366 (122.3 KB) TX bytes:133846 (133.8 KB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:142 errors:0 dropped:0 overruns:0 frame:0 TX packets:142 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11895 (11.8 KB) TX bytes:11895 (11.8 KB) wlan1 Link encap:Ethernet HWaddr 0e:ea:40:7c:02:ad UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) wlan5 Link encap:Ethernet HWaddr 08:ea:40:7c:02:ad UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) root@OrangePizero:~# find / -name script.bin /media/boot/script.bin root@OrangePizero:/media/boot# ls boot.scr script.bin System Volume Information uImage root@OrangePizero:/boot# ls boot0_OPI.fex script.bin.OPI-PC_1080p50 script.bin.OPI-PLUS_1080p60 uImage script.bin.OPI-2_1080p50 script.bin.OPI-PC_1080p60 script.bin.OPI-PLUS_720p50 uImage_OPI-2 script.bin.OPI-2_1080p60 script.bin.OPI-PC_720p50 script.bin.OPI-PLUS_720p60 uImage_OPI-2_NO_BUDGET_COOLING script.bin.OPI-2_720p50 script.bin.OPI-PC_720p60 u-boot_OPI-emmc.fex uImage_OPI-PLUS script.bin.OPI-2_720p60 script.bin.OPI-PLUS_1080p50 u-boot_OPI.fex uImage_OPI-PLUS_NO_BUDGET_COOLING  
dmesg_Opi_R1.txt
script.bin
script.fex

@zador.blood.stained 
 Ahhhhh  Well - All right! Now Iam VERY happy
some time ago I downloaded the Install-Image and then updated it until 5.34.171029 nightly Ubuntu 
(without getting  a usbhost1 via the update)
 
After your Message I updated to  5.34.171103 nightly Ubuntu  (normally I update often) and the usbhost1 is there - !and working! 
The frontright USB port is now working like on the FriendlyELEC Image
 
root@nanoneo2:/# uname -a Linux nanoneo2 4.13.10-sunxi64 #89 SMP Thu Nov 2 01:57:43 CET 2017 aarch64 aarch64 aarch64 GNU/Linux root@nanoneo2:/# cat /proc/device-tree/soc/usb@01c1b000/status; echo okay root@nanoneo2:/# cat /proc/device-tree/soc/usb@01c1b400/status; echo okay root@nanoneo2:/# lsusb -t /: Bus 09.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M [ 1.934068] ehci-platform 1c1b000.usb: EHCI Host Controller [ 1.934103] ehci-platform 1c1b000.usb: new USB bus registered, assigned bus number 3 [ 1.934356] ehci-platform 1c1b000.usb: irq 11, io mem 0x01c1b000 [ 1.948854] ehci-platform 1c1b000.usb: USB 2.0 started, EHCI 1.00 [ 1.981702] ohci-platform 1c1b400.usb: Generic Platform OHCI controller [ 1.981723] ohci-platform 1c1b400.usb: new USB bus registered, assigned bus number 6 [ 1.981850] ohci-platform 1c1b400.usb: irq 12, io mem 0x01c1b400 MANY MANY Thanks to all who have this made possible  
Now its time for me to spend AGAIN some money to the armbian-project  @Igor [DONE!]

 

Yes, it's planned in about two weeks. https://www.armbian.com/

Thanks,
 
I added
overlays=usbhost0 usbhost2 usbhost3
to /boot/armbianEnv.txt so it looks like this
verbosity=1 console=both overlay_prefix=sun50i-h5 rootdev=UUID=c9cfe2c8-bfa6-421a-badc-4e58e9288de2 rootfstype=ext4 overlays=usbhost0 usbhost2 usbhost3 And uboot showed
U-boot loaded from SD Boot script loaded from mmc 152 bytes read in 151 ms (1000 Bytes/s) 24232 bytes read in 354 ms (66.4 KiB/s) 385 bytes read in 407 ms (0 Bytes/s) Applying kernel provided DT overlay sun50i-h5-usbhost0.dtbo 385 bytes read in 399 ms (0 Bytes/s) Applying kernel provided DT overlay sun50i-h5-usbhost2.dtbo 385 bytes read in 390 ms (0 Bytes/s) Applying kernel provided DT overlay sun50i-h5-usbhost3.dtbo 4179 bytes read in 369 ms (10.7 KiB/s) Applying kernel provided DT fixup script (sun50i-h5-fixup.scr) ## Executing script at 44000000 5001817 bytes read in 440 ms (10.8 MiB/s) 12285960 bytes read in 869 ms (13.5 MiB/s) ## Loading init Ramdisk from Legacy Image at 4fe00000 ... And now when I plugin USB devices into the female USB A cables I've soldered to the PCB as per
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2#Diagram.2C_Layout_and_Dimension
to the port labelled "USB1" I get nothing, but for the port labelled "USB2" I get
[ 156.201286] usb 5-1: device descriptor read/64, error -62 [ 156.497302] usb 5-1: device descriptor read/64, error -62 [ 156.973314] usb 5-1: device descriptor read/64, error -62 [ 157.269327] usb 5-1: device descriptor read/64, error -62 [ 157.977369] usb 5-1: device not accepting address 20, error -62 [ 158.577391] usb 5-1: device not accepting address 21, error -62 [ 158.583375] usb usb5-port1: unable to enumerate USB device So at least there are signs of life for one USB port.
I'm going to check my solder joints again.
 
====

microUSB port didn't work
When powering the NanoPi2 via the UART 5v line from USB (it was a bit underpowered, voltage sagged down to 4.64)
I plugged a (tested working) USB OTG cable into the microUSB and nothing I connected showed up in dmesg.
(for all other tests, the board was powered with 2A microUSB)

The "USB1" (as shown in the pinout diagram) headers were unresponsive in all cases.
 
How to know that your D+ and D- are backwards
I noticed my soldering had left a bit of flux behind on the board, after scratching it off I got a different error in dmesg
[ 115.875561] usb 5-1: new low-speed USB device number 2 using ohci-platform [ 116.059563] usb 5-1: device descriptor read/64, error -62 [ 116.355565] usb 5-1: device descriptor read/64, error -62 [ 116.647578] usb 5-1: new low-speed USB device number 3 using ohci-platform [ 116.831581] usb 5-1: device descriptor read/64, error -62 [ 117.127593] usb 5-1: device descriptor read/64, error -62 [ 117.419605] usb 5-1: new low-speed USB device number 4 using ohci-platform [ 117.835618] usb 5-1: device not accepting address 4, error -62 [ 118.019628] usb 5-1: new low-speed USB device number 5 using ohci-platform [ 118.435638] usb 5-1: device not accepting address 5, error -62 [ 118.441516] usb usb5-port1: unable to enumerate USB device Then I swapped D+ and D- and the "USB2" port worked!
Having 2 working USB ports is enough progress for me, for now. I'm going to leave this issue as is for now.
 
====
 
BTW I also found that with a 5 meter USB extension cable and a hub on the end of it, I couldn't connect 2 wifi adapters to the female USB A port. But if I connect the hub directly to the port I can connect 2 wifi adapters.

Armbian is optimised for SD card usage - more caching is involved than on standard system - so I doubt there will be much speed increase for this particular case. If you don't use it already - check memcached: https://www.howtoforge.com/tutorial/ubuntu-apache-mod_pagespeed/ I was running this forum and few other webs (this way) on an SD card for about two years. It was smaller in size/traffic like today, but it was running good enough. What you gain for sure is reliability - SD card media is the worst of all and boot up speed.
 
 

Today I did try my very best... Opened the R69 (without breaking anything), solder the TTL-Pins, connecting USB-TTL -
BUT when I power on with the u-boot button pressed I didnt get any output to disable the u-boot boot-sequence
(normally counting 3.2.1 on other boards and you have to press a key)
 
So I can - today - only deliver the boot-log from android on the R69 and two find commands for *.bin and *.fex as android-root on the filesystem:
 
 

PS: be aware of the non-Sunvell R69 - which uses the same case, but a Rockchip-CPU and not a Allwinner H2 
https://www.alibaba.com/product-detail/New-Arrival-Cheapest-4K-Android-TV_60687195434.html