Lope
Members-
Posts
41 -
Joined
-
Last visited
-
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.3_Nanopineo2_buster_current_5.10.21.img.xz.asc # gpg --verify Armbian_21.02.3_Nanopineo2_buster_current_5.10.21.img.xz.asc gpg: assuming signed data in 'Armbian_21.02.3_Nanopineo2_buster_current_5.10.21.img.xz' gpg: Signature made Tue 09 Mar 2021 04:19:15 SAST gpg: using RSA key DF00FAF1C577104B50BF1D0093D6889F9F0E78D5 gpg: BAD signature from "Igor Pecovnik <igor@armbian.com>" [unknown]
-
@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 192.168.0.6 is the server's IP) iperf -c 192.168.0.6 -t 30 -u -b 1000000000
-
@data Brilliant, thanks for letting us know. Can you please test max throughput with a SSD connected via USB3? hdparm -t /dev/sda
-
@Devroots What would you Virtualize? Android?
-
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=10.1.1.140.2835&rep=rep1&type=pdf 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
-
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
-
[SOLVED] Orange Pi Zero analog audio not working (using expansion board)
Lope replied to Lope's topic in Allwinner sunxi
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!!! -
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
-
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?
-
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
-
@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?
-
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.
-
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.