Jump to content

Lope

Members
  • Posts

    41
  • Joined

  • Last visited

Posts 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.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]

  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 :)

    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

     

  3. 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

  4. 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

  5. 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

     

    giphy.gif&f=1

     

    Wow! I'm impressed with the sound quality!!!

  6. 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

     

  7. 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

     

  8. 2 minutes ago, martinayotte said:

    Yes, by removing this R63 and solder tiny wire on the floating pad. But usually those SMT resistors are so small, I wouldn't try myself ... :wacko:

    It is much easier to use MCP3221 ...

    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?

     

    1 minute ago, martinayotte said:

    Audio port are usually AC coupled, so no way to measure DC voltage level...

    Yes, I just thought of that, thanks.

  9. @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?

  10. 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.

  11.  

    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)

    Spoiler

     

    
    wiringPi Build script
    =====================
    
    
    WiringPi Library
    [UnInstall]
    [Compile] boardtype_friendlyelec.c
    boardtype_friendlyelec.c: In function ‘getFieldValueInCpuInfo’:
    boardtype_friendlyelec.c:134:43: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
                     GetKeyValue(isGotHardware,p,"Hardware",hardware,hardwareMaxLen);
                                               ^
    boardtype_friendlyelec.c:123:25: note: in definition of macro ‘GetKeyValue’
                         if (valP=strtok(line2, ":")) { \
                             ^~~~
    boardtype_friendlyelec.c:134:43: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
                     GetKeyValue(isGotHardware,p,"Hardware",hardware,hardwareMaxLen);
                                               ^
    boardtype_friendlyelec.c:125:33: note: in definition of macro ‘GetKeyValue’
                                 if (valP=strtok(0, ":")) { \
                                     ^~~~
    boardtype_friendlyelec.c:135:43: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
                     GetKeyValue(isGotRevision,p2,"Revision",revision,revisionMaxLen);
                                               ^
    boardtype_friendlyelec.c:123:25: note: in definition of macro ‘GetKeyValue’
                         if (valP=strtok(line2, ":")) { \
                             ^~~~
    boardtype_friendlyelec.c:135:43: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
                     GetKeyValue(isGotRevision,p2,"Revision",revision,revisionMaxLen);
                                               ^
    boardtype_friendlyelec.c:125:33: note: in definition of macro ‘GetKeyValue’
                                 if (valP=strtok(0, ":")) { \
                                     ^~~~
    boardtype_friendlyelec.c:136:65: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
                     if (isGotRevision==0) GetKeyValue(isGotRevision,p2,"CPURevision",revision,revisionMaxLen);
                                                                     ^
    boardtype_friendlyelec.c:123:25: note: in definition of macro ‘GetKeyValue’
                         if (valP=strtok(line2, ":")) { \
                             ^~~~
    boardtype_friendlyelec.c:136:65: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
                     if (isGotRevision==0) GetKeyValue(isGotRevision,p2,"CPURevision",revision,revisionMaxLen);
                                                                     ^
    boardtype_friendlyelec.c:125:33: note: in definition of macro ‘GetKeyValue’
                                 if (valP=strtok(0, ":")) { \
                                     ^~~~
    boardtype_friendlyelec.c: In function ‘getAllwinnerBoardID’:
    boardtype_friendlyelec.c:178:21: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
                     if (p = strtok(line, ":")) {
                         ^
    boardtype_friendlyelec.c:181:29: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
                             if (p = strtok(0, ":")) {
                                 ^
    [Link (Dynamic)]
    [Install Headers]
    [Install Dynamic Lib]
    
    WiringPi Devices Library
    [UnInstall]
    make: Nothing to be done for 'all'.
    [Install Headers]
    [Install Dynamic Lib]
    
    GPIO Utility
    [Compile] readall.c
    readall.c: In function ‘readallPhys’:
    readall.c:562:16: warning: implicit declaration of function ‘getAltSilence’; did you mean ‘getline’? [-Wimplicit-function-declaration]
          int alt = getAltSilence (pin);
                    ^~~~~~~~~~~~~
                    getline
    readall.c:569:23: warning: implicit declaration of function ‘digitalReadSilence’; did you mean ‘digitalRead’? [-Wimplicit-function-declaration]
          printf (" | %d", digitalReadSilence (pin)) ;
                           ^~~~~~~~~~~~~~~~~~
                           digitalRead
    [Link]
    [Install]
    
    All Done.
    
    NOTE: To compile programs with wiringNP, you need to add:
        -lwiringPi
      to your compile line(s).
    
    WiringNP Installed
    The user `root' is already a member of `i2c'.
     
    Install smbus for python
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    python-smbus is already the newest version (4.0-2).
    0 upgraded, 0 newly installed, 0 to remove and 27 not upgraded.
     
    Making libraries global . . .
    

     

     

    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.

     

     

  12. Armbianmonitor:

    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
    2.1.4.9.KEYADC
    * 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

  13. 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.

  14. 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.


     

  15. 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.

  16. 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 :angry:
    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. :P

    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.
     

     

    Crappy_HDMI-DVI_adapter2.jpg

  17. 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.
     

  18. @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.

  19. 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?

  20. 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.

  21. 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.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines