• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map






Everything posted by Lope

  1. @Igor Interesting thanks, I've never used iozone before. I see in your command you have not specified a specific device it will test? Is your command safe? does it only perform reads? I must say I've gotten useful information about the max device (and bus) read speed using (the command reads raw from the device as fast as possible, bypassing cache) It has been very useful for me, for quick tests. hdparm -t /dev/sda @data I saw in another thread you mentioned that you're using USB3 gigabit ethernet with your H6... I would be very interested in seeing iperf test results Setup iperf server that listens for UDP iperf -s -i 1 -u Run iperf client (where is the server's IP) iperf -c -t 30 -u -b 1000000000
  2. @data Brilliant, thanks for letting us know. Can you please test max throughput with a SSD connected via USB3? hdparm -t /dev/sda
  3. @Devroots What would you Virtualize? Android?
  4. AES has some major weaknesses, keys are breakable through timing attacks (dependent on implementation) due to it's design flaws http://citeseerx.ist.psu.edu/viewdoc/download?doi= I'm not sure if hardware accelerated AES-NI is vulnerable to timing attacks. But the bottom line is that AES is very complicated and easy to screw up in the implementation such that it's vulnerable to various attacks. ChaCha20 on the other hand (XChaCha20 in newer kernels) is simple to implement, (much faster than AES when implemented purely in software) and easy to reason about. The most secure cipher available seems to be DJB's XChaCha20. XChaCha20 performs almost as well as AES, even though there is no hardware acceleration for it. Due to the performance being really good on Embedded devices, Google has selected XChaCha as the default algorithm for devices without AES acceleration. For interest's sake I ran a cryptsetup benchmark of the available ciphers on my orange Pi Zero and got these results enc dec (MiB/s) aes-xts 256b 24 21 twofish-xts 512b 19 19 aes-xts 512b 19 16 twofish-xts 256b 19 19 aes-cbc 128b 18 19 twofish-cbc 256b 17 19 twofish-cbc 128b 17 19 aes-cbc 256b 14 15 serpent-xts 512b 12 13 serpent-xts 256b 12 13 serpent-cbc 256b 11 13 serpent-cbc 128b 11 13 I was not able to test XChaCha20 / adiantum because my Orange Pi Zero is only running Kernel 4.19. XChaCha20 support will is available from Kernel 4.21 onwards https://www.spinics.net/lists/dm-crypt/msg07821.html On all the devices I've tested (even powerful x86_64 CPUs (that have AES-NI of course)) the performance of XChaCha20 was close enough that it can be used without impacting performance (for example even on my old Haswell I get >1400MB/s for enc and dec with XChaCha20) Yes AES is faster, but if it's not actually doing it's job properly, it's not apples vs apples comparison. Anyway, whether you think AES is good enough or not, XChaCha20 will continue to see increased adoption. I'd love to try it out on the H3, H5 and so on. It seems that most Armbian builds have a 4.19 Kernel, likely because Debian Stable (Buster) uses this kernel. But a as I understand it, these SoCs are running "mainline" kernels. So in theory, a 4.21 Kernel could probably be compiled with ease and hopefully would not break anything? The alternative is waiting for Debian 11, which could take a very long time (at least 1-2 years) Kernel config tip (Source https://www.reddit.com/r/crypto/comments/b3we04/aesadiantum_new_mode_in_linux_kernel_5/ ) Apparently there are ARM kernel options equivalent to the X86 options CONFIG_CRYPTO_CHACHA20_X86_64 CONFIG_CRYPTO_NHPOLY1305_AVX2 That should be enabled for best performance. I see in https://github.com/torvalds/linux/blob/master/arch/arm/crypto/Kconfig There are options like CRYPTO_CHACHA20_NEON CRYPTO_NHPOLY1305_NEON which should definitely be enabled. How to run a benchmark #possible with >=4.21 kernel and >=2.0 cryptsetup cryptsetup benchmark --cipher xchacha20,aes-adiantum-plain64 #default cipher benchmarks cryptsetup benchmark #note these benchmark results are not entirely realistic vs real-world performance due to userspace/kernelspace and initialization issues, but gives an approximation. Bottom line So I'm just mentioning this stuff incase maintainers are interested It would be cool to have a >=4.21 Kernel, and cryptsetup > 2.0.0 to take advantage of XChaCha20 aka Adiantum
  5. I ran the poweroff command on Orange Pi Zero 1.4 with latest mainline Armbian image and kernel updated etc. On the OrangePi Zero 1.4 5.75 Ubuntu 18.04.2 LTS 4.19.20-sunxi, poweroff should be renamed to ignite-inferno It got so hot that it burned the OEM label that was stuck to the back of the board. (little white sticker with barcode and Orange Pi Zero 256MB written on it) Then I found that halt didn't create the same inferno. Curious behavior. I need to do more testing. I found that my Orange Pi Zero idled at about 80mA, maybe that was with the powersave governor. Normal operation it jumped between 80-350mA. But I really didn't test anything thoroughly. I recommend getting one of these. Cheap and gives you excellent visibility into what's going on. https://www.ebay.com/itm/USB-Charger-Doctor-Current-Voltage-Detector-Battery-Voltmeter-Ammeter-Tester/172274610835
  6. Hi @guidol Thank you I just did some more searching and found your very useful forum posts about audio issues you had with orange pi zero I did try making /etc/asound.conf as per examples on the orange pi forums, which didn't help. I'm going to see if I've got all the modules loaded. I've edited my first post with more commands and outputs. I added sun4i_codec sun8i_codec_analog to /etc/modules YES, progress!!! $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 YES!!! IT WORKS. IT WORKS!!! It's ALIVE!!!!! (demented laughter) Muahahahah Wow! I'm impressed with the sound quality!!!
  7. I just installed the latest Ubuntu Bionic Image with 4.x kernel, fully updated and upgraded. On Orange Pi Zero 1.4 512MB + IO expansion kit board Armbian 5.75 Ubuntu 18.04.2 LTS Linux orangepizero 4.19.20-sunxi #5.75 SMP Sat Feb 9 19:02:47 CET 2019 armv7l armv7l armv7l GNU/Linux `cat /proc/asound/cards` "No sound cards" In armbian-config, I enabled analog-codec, `update-initramfs, rebooted, but there's still no sound card. mocp complains there is no driver. speaker-test (starts like this) Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise ALSA lib confmisc.c:767:(parse_card) cannot find card '0' Anyone know what the issue is? $ cat /boot/armbianEnv.txt verbosity=1 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=analog-codec usbhost2 usbhost3 w1-gpio rootdev=UUID=4cf6b202-4b00-45d6-b06a-8e235506621e rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u $ cat /etc/asound.conf pcm.!default{ type hw card 0 } ctl.!default{ type hw card 0 } After the above and a reboot, I didn't have any codec modules loaded So I did this $ modprobe sun8i-codec-analog sun4i-codec $ aplay -l aplay: device_list:270: no soundcards found... $ cat /proc/asound/cards --- no soundcards --- $ ls -lah /dev/snd total 0 drwxr-xr-x 2 root root 60 Mar 20 06:04 . drwxr-xr-x 13 root root 14K Mar 20 06:04 .. crw-rw---- 1 root audio 116, 33 Mar 20 06:05 timer
  8. My (directly) above post got moved here from the Armbian H5 forum Please note: 1. I experienced the issue on a NanoPi Neo2 v1.0 (H5) board. 2. I did not experience the issue on a Rockchip SoC. Nowhere does this thread mention Neo2 or H5, so I'm mentioning this here so it can at least come up in a search. Maybe my above post got moved here in error?
  9. To reproduce issue git clone --depth 1 https://github.com/gordboy/rtl8812au.git cd rtl8812au make -j 4 #you'll see that it fails to do modpost with the stock 4.19.20 kernel. # #Previously I had compiled a custom kernel for 4.19.13. #I downgraded to my 4.19.13 custom kernel and was able to complete the above without any issue. #Kernel headers seem to be broken. #If you're going to run the next step, you should backup your armbian 8812au.ko kernel module. #next step I couldn't get to sudo make install
  10. Strange how they connected the ADC to 3.3v. Seems so unnecessary? I wonder why they bothered running a trace at all? Is it to prevent issues if it's left floating? Yes, I just thought of that, thanks.
  11. @martinayotte when you say R63 do you mean it's possible to modify the board to use AA5? Thanks for the recommendations of ADC's. What about using one of the audio inputs for measuring my analog voltage? The Audio connector has these 2 pins: 1 MICIN1P Microphone Positive Input 2 MICIN1N Microphone Negative Input Do you know if anyone has used a microphone successfully with this SoC or Neo2 kernel?
  12. Thanks @martinayotte friendly arm WiringNP ref: http://wiki.friendlyarm.com/wiki/index.php/WiringNP:_NanoPi_NEO/NEO2/Air_GPIO_Programming_with_C#Shell_Script I debugged WiringNP. Either my kernel is showing wrong info, or WiringNP code doesn't work. When I `cat /proc/cpuinfo` I get this processor : 0 Processor : AArch64 Processor rev 4 (aarch64) Hardware : sun50iw1p1 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 You see my NanoPi Neo2 with H5 SoC reports Hardware is sun50iw1p1 But on line 61 of WiringNP/wiringPi/boardtype_friendlyelec.c it says: {"sun50iw1p1", 0, NanoPi_A64, "NanoPi-A64", "0"}, So the code says that CPU name corresponds to the A64 SoC... So just to get WiringNG working, I changed the line to: {"sun50iw1p1", 4, NanoPi_NEO2, "NanoPi-NEO2", "1(0)"}, Then underneath line 135: GetKeyValue(isGotRevision,p2,"Revision",revision,revisionMaxLen); I added line 136: if (isGotRevision==0) GetKeyValue(isGotRevision,p2,"CPURevision",revision,revisionMaxLen); (just hax to make it work) Now `gpio readall` gives me +-----+-----+----------+------+---+-NanoPi-NEO2--+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | | | 3.3V | | | 1 || 2 | | | 5V | | | | 12 | 8 | GPIOA12 | OFF | 0 | 3 || 4 | | | 5V | | | | 11 | 9 | GPIOA11 | OFF | 0 | 5 || 6 | | | 0v | | | | 203 | 7 | GPIOG11 | OFF | 0 | 7 || 8 | 0 | OFF | GPIOG6 | 15 | 198 | | | | 0v | | | 9 || 10 | 0 | OFF | GPIOG7 | 16 | 199 | | 0 | 0 | GPIOA0 | OFF | 0 | 11 || 12 | 0 | OFF | GPIOA6 | 1 | 6 | | 2 | 2 | GPIOA2 | OFF | 0 | 13 || 14 | | | 0v | | | | 3 | 3 | GPIOA3 | OFF | 0 | 15 || 16 | 0 | OFF | GPIOG8 | 4 | 200 | | | | 3.3v | | | 17 || 18 | 0 | OFF | GPIOG9 | 5 | 201 | | 64 | 12 | GPIOC0 | OFF | 0 | 19 || 20 | | | 0v | | | | 65 | 13 | GPIOC1 | OFF | 0 | 21 || 22 | 0 | OFF | GPIOA1 | 6 | 1 | | 66 | 14 | GPIOC2 | OFF | 0 | 23 || 24 | 0 | OFF | GPIOC3 | 10 | 67 | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+-NanoPi-NEO2--+------+----------+-----+-----+ +-----+----NanoPi-NEO2 USB/Audio-+----+ | BCM | wPi | Name | Mode | V | Ph | +-----+-----+----------+------+---+----+ | | | 5V | | | 25 | | | | USB-DP1 | | | 26 | | | | USB-DM1 | | | 27 | | | | USB-DP2 | | | 28 | | | | USB-DM2 | | | 29 | | | | IR-RX | | | 30 | | 17 | 19 | GPIOA17 | OFF | 0 | 31 | | | | PCM/I2C | | | 32 | | | | PCM/I2C | | | 33 | | | | PCM/I2C | | | 34 | | | | PCM/I2C | | | 35 | | | | 0V | | | 36 | +-----+-----+----------+------+---+----+ +-----+----NanoPi-NEO2 Debug UART-+----+ | BCM | wPi | Name | Mode | V | Ph | +-----+-----+----------+------+---+----+ | 4 | 17 | GPIOA4 | ALT5 | 0 | 37 | | 5 | 18 | GPIOA5 | ALT5 | 0 | 38 | +-----+-----+----------+------+---+----+ Which is all well and nice. But WiringNP doesn't contain any code for doing an ADC capture from the H5. On page 69 of https://linux-sunxi.org/images/a/a3/Allwinner_H5_Manual_v1.0.pdf It shows the KEYADC pin name/number is AA5. It doesn't look like NanoPi Neo2 has exposed pin AA5. If so, that's incredibly lame. It's one of the strengths H3/H5 have over RbPi (having ADC) would be such a shame if we can't use it. On the Neo2 Pinout I don't see AA5 http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2#Access_GPIO_Pins.2FWirings_with_WiringNP It looks like the simplest GPIO pin to use for my first objective (read a digital input pin) is GPIOA6, because it has no other function (no serial ports etc) it's linux pin 6. I tried `gpio export 6` in successfully. `gpio readall` changes it from OFF to IN.
  13. I'm not sure I even want BakeBit. I'm trying to use the GPIO in my NanoPi Neo2. Specifically I want to read a digital I/O pin on/off state. And if possible I'd like to read an analog voltage from the H5's built in ADC. Now that I've looked deeper into BakeBit, it seems like the entire purpose of BakeBit is to do GPIO with an Arduino, and read the information remotely on a RbPi/NanoPi or whatever ON the Arduino's GPIO pins. If that is really what BakeBit is, then BakeBit doesn't interest me. The H5 already has GPIO and an ADC. We just need to get that working. For interest's sake, here is the progress I made with BakeBit. ADC Python example in Bakebit http://wiki.friendlyarm.com/wiki/index.php/BakeBit_-_Light_Sensor i had to `apt-get install libjpeg-dev zlib1g-dev` to get pillow to install properly, which is a dependency of BakeBit. Bakebit installed without errors, but it tries to compile WiringNP which complained with a lot of warnings. In the following thread I got WiringNP to run. This was semi useful BTW https://www.cnx-software.com/2017/05/21/using-gpios-on-nanopi-neo-2-board-with-bakebit-starter-kit/ Now when I `rm -rf the bakebit dir` then do a fresh clone and `/scripts/BakeBit/Script/install.sh` it installs without errors except warnings for WiringNP. (which I don't actually get when I build it myself) With the hax I did to get WiringNP to work on my Neo2. I deleted Bakebit/Scripts/WiringNP and replaced it with the version that I modified and built successfully.
  14. Hi all, Running Armbian Ubuntu 18.04 with stock neo2 4.19.20 kernel I tried installing https://github.com/friendlyarm/WiringNP but after installation `gpio readall` says : "This NanoPi model is currently not supported." However all the wiki's and the Github page says it's supported.......? I can see GPIO in the sys fs at /sys/class/gpio/ but I was hoping to have an easier time with it than manually exporting each pin and calculating offsets for pins with scraps of info online etc. Objective 1: Read a high/low 3.3v/0v status from a GPIO Objective 2: Read an analog voltage, using an ADC. Does the H5 include an ADC? When I look in http://wiki.friendlyarm.com/wiki/images/d/de/Allwinner_H5_Datasheet_V1.0.pdf Page 13 says * Analog to digital converter with 6-bit resolution for key application * Maximum sampling frequency up to 250 Hz * Supports general key, hold key and already hold key * Supports single , normal and continuous work mode I don't need high speed sampling, don't need interrupts, the simpler and easier the implementation the better. Any help will be much appreciated PS: How to fix friendlyarm/WiringNP friendlyarm/WiringNP is not accepting issues on their github repo, but it seems to be the best fork out there. How can we get them to accept issues and how can we fix the issue? http://forked.yannick.io/friendlyarm/WiringNP
  15. These boards are well suited to routing/network traffic control functionality. Currently the kernel has been compiled with Traffic Control stuff disabled, which makes it impossible to perform traffic shaping on stock Armbian kernel. I'm busy recompiling the kernel as a temporary solution, but I will really appreciate it if the kernel build maintainer can please change the traffic control options from DISABLED to MODULE (at least)? I have a bunch of Armbian boards but I'm testing with NanoPi Neo 2 right now. --- I'll let you know the size of the modules once I've finished compiling.
  16. TL;DR: I'm not doing the hardware mod. I'll either wait until my decent adapters arrive, or do some kind of software mod. If anyone knows how to force the Orange Pi's to output a video signal on the HDMI port even when it thinks there's nothing connected, I'd love to know! ====== I was harvesting parts from a PCB with my hot air rework station, so I hit that semi-clear plastic with the hot air for a while. I tried 400C and 300C After about a minute, it became more transparent and moved away from the force of the air. It didn't smoke, liquify and drip off (like hot glue does at 240C). So I grabbed and pulled it with pliers. It wasn't very sticky at all. It had very strong surface tension and was more keen to stay together than stay on the PCB, so I pulled it off the PCB quite easily, it fit the definition of "hot snot" much better than hot glue. I realized it'll be much easier to modify the HDMI side because all pins are accessible. I saw pin 18 and 19 were already wired on the HDMI side, so I decided not to proceed with the mod. It's hard to tell exactly, but it looks like maybe the serial busses are not wired properly. I was happy to do the mod if 18 and 19 were not connected, but since they are, I'm just going to leave it alone. I'm not going to debug why the crappy adapter doesn't plug-and-play.
  17. Since some H2 and H3's run hotter than some people would like, and people are measuring voltages etc I thought I'd make the following warnings for your benefit in the hope that we collect quality data and solve all challenges quickly. Measuring voltage accurately Your DMM (digital multimeter) may lie to you. Measure the input voltage as well as the test voltages before posting voltage readings. Check with the resistance setting that the resistance of your probes touching each other is close to 0 ohms. I own many DMM's and one of them reports horribly inaccurate voltages when the 9v battery is near or less than 8v. If your DMM sucks, buy a better one (link at bottom) TL;DR Step 1. Check probes shorted is close to 0 ohms Step 2. Test and report 5v input voltage Step 3. Test and report whatever voltage is of interest to you. You need 3 DMM's to verify accuracy, from time to time You need to own 3 DMM's (preferably different brands/models) then you measure a voltage with all 3 meters to see if they agree. (or own 1 DMM and borrow 2 for the test) If you use 1 DMM: You cannot trust what it tells you. If you use 2 DMM's: You only know if you have a problem. If they disagree, you don't know which is right and which is wrong. If you use 3 DMM's: The 3rd DMM will arbitrate a discrepancy. Every few months or years you should repeat this test. A DMM's accuracy may depend on it's batteries being very fresh or it may corrode inside. Verify to trust. Measuring temperature accurately Temperature reported by some boards onboard sensors are horribly inaccurate. Do not believe these numbers. (eg: Orange Pi Zero) - For good temperature measurements, buy yourself some cheap and nice equipment. IR thermometer (note, the laser doesn't point in the exact same place as the IR sensor at all distances, best to turn the laser off, it's a gimmick, temperature sensing is only accurate when measuring matte dark coloured surfaces, it won't work well on shiny/bright coloured surfaces, to hack, add some black insulation tape or better: colour in with black permanent marker) DS18B20 1wire accurate digital thermometer IC's (there are lots of tutorials for hooking these up to RbPi etc, hopefully someone (maybe me) can do it for an Orange Pi etc and post pics/schematic/code) Digital LCD Temperature Probe (not an ideal probe shape probably, but very easy to use, this one's temp range goes up to 110C, some only go to 70C) Good quality DMM with temperature probe (reviewed by EEVlog) USB Doctor (with individual voltage and current in different colours is MUCH easier to use than the cheap crappy single display monochrome ones. Some of these claim a range of 3-9v and 3A. So it could technically be used on the 3.3v rail but you should confirm it's accuracy at different currents and voltages with a good DMM) USB Doctor 3-7.5V, 0-2.5A USB Doctor 3-8V, 0-3A USB Doctor 3-9V, 0-5A Fancy USB Doctor, 4-30V 0-5A shows power, time and mAh Measure current and voltage (calculate power) accurately Ammeters (digital or analog) have significant resistance and will cause a voltage drop. If you use one, measure voltage at the target device power inputs (after the ammeter). (if you use a USB Doctor for example, it's the same as using 2 DMM's, one for current, one for voltage) None of these links contain any affiliate references, I just searched eBay and chose good examples and I've bought the above DMM myself, buy whatever you want, I just want you to have good quality instruments and report accurate data.
  18. Hi, I'm using Orange Pi 2E+ with 3.4 Multimedia kernel (intend on using Kodi) I have a DVI monitor I want to use, and a crappy HDMI > DVI adapter which for some reason doesn't let computers know that the DVI monitor is connected to their HDMI port Confirmed on 2 different computers. The adapter probably lacks the hotplug-detect pin because computers don't know there's a screen connected, but the screen will show an image if I force my laptop to send a video signal out it's HDMI port using xrandr. Is there a way (using .fex files or whatever) to make the kernel assume that there's a monitor with 1920x1080 resolution on the Orange Pi 2E's HDMI port? Otherwise, something like this? http://distro.ibiblio.org/fatdog/web/faqs/boot-options.html Ramble Yes, I've already ordered 2 new adapters, and will bin the crappy one when they arrive, but it's going to take a long time to arrive (South African post office sucks) Hardware hax I found out how to fake hotplug for DVI: Tie Hotplug (pin 16) via 1k resistor to 5v (pin 14). I cut the connector open on the sides with side cutters, and can see they've not hooked up that many of the pins. (the connector might even lack EDID wires) If I'm in the mood on another day I might try melt off the plastic that the wires are sealed in (maybe it's hot glue) with a hot-air rework and see if melts and flows off easily. Unfortunately pin 14 and 16 are in the middle, so the sealant would need to be cleared.
  19. I'm testing the nightly image: Armbian_5.32.170704_Nanopineo2_Ubuntu_xenial_dev_4.11.8.img I've got it running nice and stable as a router and wifi AP, with 2 USB ports, one wifi adapter on each port. But when it's been off for a while and I power it on, it doesn't boot on the first powerup, only if I disconnect power and then wait a few seconds then power again. I've tried 2 different 2A 5v power supplies, one that I've successfully powered RbPi 2s and other Linux SBC's for months at a time, no problems. The voltage is good. I also tried a beast 10 port USB charger that has 6x 2A ports. Same behavior for all power supplies I've tried, and I've never experienced this problem with any other Linux SBC. Is anyone else experiencing this? I'm wondering if maybe it's a bug maybe with the watchdog or some special hardware registers, I'm theorizing that if it's not run recently it reads some value that causes an infinite loop of some kind. It happened with the image before I changed anything at all. I suppose I could also try different microSD cards.
  20. @guidol nice work. Don't be afraid of compiling the kernel. I've compiled kernels with modified drivers for x86_64 tons of times, never for ARM but it's just a matter of changing architecture. There must be tons of guides around. Once you've got the source tree it's a simple matter of finding the source and changing it, then compiling. It's best to cross compile from a fast PC because if you compile on an H5 etc it'll be a lot slower. On a crappy old dual core 2nd gen i7 I compiled the 4.x kernel in about 20 mins. I'd love to have 3/4 USB ports (instead of just 2/4) working but I can't get involved with it at the moment.
  21. I'm testing the nightly image: Armbian_5.32.170704_Nanopineo2_Ubuntu_xenial_dev_4.11.8.img for NanoPi Neo2 H5. Every time if my Neo2 has been off for many minutes, if I power it up it doesn't boot on the first attempt. If I unplug and replug power a few seconds later (either at the 220v end or the microUSB, it boots up flawlessly. Anyone experienced this? Any ideas? Maybe it's a power stabilization issue. I guess there should be a 2 second or whatever delay before it starts booting so it can be as reliable as other Linux SBC's. Other than that, surely there's a watchdog built in to make it reboot if it doesn't boot successfully?
  22. 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.
  23. Thanks for the quick reply Igor, amazing. I found /boot/dtb/allwinner/overlay sun50i-h5-usbhost0.dtbo sun50i-h5-usbhost2.dtbo sun50i-h5-usbhost3.dtbo These 3 files are all in binary format. Any more hints will be appreciated. Is there a similar board I can look at for an example? I'm busy working through the link you gave I've read through /boot/dtb/allwinner/overlay/README.sun50i-h5-overlays but just mentions the above 3 usb host ports (a bit strange because the h5 has at least 4 usb ports that I know of) ... unless the microUSB port is not included in these.
  24. I'm testing the nightly image: Armbian_5.32.170704_Nanopineo2_Ubuntu_xenial_dev_4.11.8.img I've soldered 2x female A USB ports to the NanoPi Neo2 as per the pinout http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2#Diagram.2C_Layout_and_Dimension When I plugged in wifi dongles or USB flash drives, their light comes on, but I get nothing on lsusb and dmesg. Then I realized I had D+ and D- reversed, so I swapped them for each port, but there's still absolutely nothing when connecting devices to these ports. (I know that having D+ and D- swapped doesn't cause any damage) Do I need to somehow enable the USB ports in a fex file or in the kernel etc?