• Content Count

  • Joined

  • Last visited

Everything posted by Lope

  1. Hi Igor, did you change your sig? # gpg --keyserver ha.pool.sks-keyservers.net --recv-key DF00FAF1C577104B50BF1D0093D6889F9F0E78D5 gpg: key 93D6889F9F0E78D5: public key "Igor Pecovnik <igor@armbian.com>" imported gpg: Total number processed: 1 gpg: imported: 1 # ls -la total 384004 drwxr-x--- 2 dev dev 80 Mar 12 01:38 . drwxrwxrwt 21 root root 540 Mar 12 01:38 .. -rw-r--r-- 1 root root 396181864 Mar 12 01:12 Armbian_21.02.3_Nanopineo2_buster_current_5.10.21.img.xz -rw-r--r-- 1 dev dev 833 Mar 12 01:38 Armbian_21.02.
  2. @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 Setu
  3. @data Brilliant, thanks for letting us know. Can you please test max throughput with a SSD connected via USB3? hdparm -t /dev/sda
  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 re
  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
  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
  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 paramet
  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 :
  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
  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: R
  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 mo
  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
  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 bat
  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
  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 char
  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) worki
  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
  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
  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) ... unle