5kft

Members
  • Content Count

    103
  • Joined

  • Last visited


Reputation Activity

  1. Like
    5kft reacted to Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    Images are building and uploading at this moment. A few more tests and repository will also be updated, so you will be able to upgrade your current build to 4.19.y
  2. Like
    5kft reacted to Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    You already helped a LOT! 
     

    Indeed! Let's fix this Pinebook's troubles and we might slowly switch 4.19.y to nightly NEXT building ...
  3. Like
    5kft got a reaction from Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    Hi @Igor, I just tested both I2C and SPI on the Plus2 H5 and both appear to work.  Both tests were to devices connected to the pin header.  The SPI test was using a 4MB SPI flash part, and the I2C test was just to detect an SH1106 OLED display connected to TWI0-SDA/SCK (display is configured at I2C address 0x3c):
    root@orangepizeroplus2:~/tmp# dd if=/dev/random of=test.dat bs=1024 count=4096 iflag=fullblock 4096+0 records in 4096+0 records out 4194304 bytes (4.2 MB, 4.0 MiB) copied, 8.29973 s, 505 kB/s root@orangepizeroplus2:~/tmp# root@orangepizeroplus2:~/tmp# flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=16000 -w test.dat flashrom v0.9.9-r1954 on Linux 4.19.4-sunxi64 (aarch64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on linux_spi. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED. root@orangepizeroplus2:~/tmp# flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=16000 -r test2.dat flashrom v0.9.9-r1954 on Linux 4.19.4-sunxi64 (aarch64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on linux_spi. Reading flash... done. root@orangepizeroplus2:~/tmp# md5sum test*.dat 979776e45a0b9fd7caf154f4f1bbbbf4 test2.dat 979776e45a0b9fd7caf154f4f1bbbbf4 test.dat root@orangepizeroplus2:~/tmp# root@orangepizeroplus2:~/tmp# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@orangepizeroplus2:~/tmp# root@orangepizeroplus2:~/tmp# cat /boot/armbianEnv.txt verbosity=1 console=both overlay_prefix=sun50i-h5 overlays=usbhost2 usbhost3 spi-spidev i2c0 param_spidev_spi_bus=1 rootdev=UUID=2b29fd0a-3553-4999-be20-f3175d84e624 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u root@orangepizeroplus2:~/tmp# Very nice how well it all is working!
     
  4. Like
    5kft got a reaction from Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    Hi, this should now be fixed with https://github.com/armbian/build/commit/e0f27fff66220e56b6419879957af28fa46ff84f.  I tested this on an unmodified Plus2 H5 (i.e., missing MOSFET in the regulator switching circuit).  Without this change the boot would fail as @guidol noted (heartbeat, then stops, and the board hangs); with this change it boots and runs just fine, and the maximum CPU clock rate is properly limited.
  5. Like
    5kft got a reaction from Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    Hi, this should now be fixed with https://github.com/armbian/build/commit/e0f27fff66220e56b6419879957af28fa46ff84f.  I tested this on an unmodified Plus2 H5 (i.e., missing MOSFET in the regulator switching circuit).  Without this change the boot would fail as @guidol noted (heartbeat, then stops, and the board hangs); with this change it boots and runs just fine, and the maximum CPU clock rate is properly limited.
  6. Like
    5kft reacted to guidol in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    I did also compile for the OPi R1 - I could also successfully test the USB via the OPi NAS AddOn.
    A report has been created (dont know if @5kft did this also)
    I do have some lacking at the SSH-connection via eth0  like on a "bad" WiFi-Connection because of:
     
    [ 1439.605021] ==> rtl8188e_iol_efuse_patch [ 1501.258078] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 1523.785870] dwmac-sun8i 1c30000.ethernet eth0: Link is Down [ 1524.810021] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 1528.905843] dwmac-sun8i 1c30000.ethernet eth0: Link is Down [ 1529.930016] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 1538.121820] dwmac-sun8i 1c30000.ethernet eth0: Link is Down [ 1539.146029] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 1628.389288] ==> rtl8188e_iol_efuse_patch [ 1691.429555] ==> rtl8188e_iol_efuse_patch [ 1754.554618] ==> rtl8188e_iol_efuse_patch the second ethernet-port enxc0742bffxxxx didnt seem to have this lacking
  7. Like
    5kft got a reaction from shaun27 in Quick review of NanoPi Fire3   
    Hi @shaun27, I just implemented support for this for the Fire3 and have pushed the changes into Armbian (see https://github.com/armbian/build/commit/1301f9f8c254d8408b9136948c786dffa5007acd).  The power button/PWRKEY now works for both powering up the board as well as powering it down 
     
  8. Like
    5kft got a reaction from Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    Hi @Igor, just a quick note - I had to make a small fix for Orange Pi Zero Plus (https://github.com/armbian/build/commit/b0f92ee58c6cbefbbcd52dcb93e1128c7528cb54); with this change this board seems to work fine now as well with the new 4.19.y kernel.
  9. Like
    5kft got a reaction from Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    Hi @Igor, I've tried a top-of-tree H5 build so far on:
    Neo2 v1.1 512MB Neo2 v1.1 1GB Orange Pi Zero Plus2 H5 Nano Pi Neo Plus2 ...and all works well.  Very nice!!    (These are all dumb regulator boards BTW)
     
    Tests include USB (Wi-Fi and Ethernet dongles), H/W SPI interface (via spidev), multiple GPIOs (via libgpiod).  I've switched to 4.19.y for all of these now.
     
    (I still have a few more boards that I'll dig up and try it on...)
     
  10. Like
    5kft reacted to guidol in RunCPM on armbian - CP/M Weekend fun   
    https://github.com/MockbaTheBorg/RunCPM
    there is a nice little CP/M emulator which do compile fine under armbian.
    (There is also a version for the Arduino DUE with SD-Hat or a ESP32/Teensy)
     
    With that you can run many CP/M-Software like Wordstar, dBase II and so on
     
    Special on this emulation is that it do use directorys as drives
    The directory A (or A/0/) would be Drive A>
     
    Maybe you also want do something retro this weekend?
     
    Here is how I did compile/install it on my OPi One:
     
    compile RunCPM: =============== install ncurses-dev and lua: ============================ apt install libncurses5-dev liblua5.3-dev git make cd /home/guido/ git clone https://github.com/MockbaTheBorg/RunCPM RunCPM_git cd RunCPM_git/RunCPM make posix clean make posix build mkdir /home/guido/RunCPM mkdir /home/guido/RunCPM/A mkdir /home/guido/RunCPM/A/0 cp RunCPM /home/guido/RunCPM cp /home/guido/RunCPM_git/CCP/* /home/guido/RunCPM cp /home/guido/RunCPM_git/DISK/A.ZIP /home/guido/RunCPM/A/0 cd /home/guido/RunCPM/A/0 unzip A.ZIP cd /home/guido/RunCPM To start the Emulation: ======================= ./RunCPM To exit the emulation: ====================== a> exit  

  11. Like
    5kft reacted to chwe in Boot and dmesg errors   
    bumping is normally the best way to get a warning... 
     
    that's why h5 is marked testing.. nobody knows..
     
    nothing to care about... that's normal.. 
     
     
    probably related to this one:
    no idea, I don't follow H5 development close enough....
     

    and a lot of reading might give you a clue what's and how stable things are working on h5 for *random usecase*.. H5 and H6 are in development phase. 
     
    @Igor I think our download-page here is 'part of the problem'. 

     
    I suggest that we mark those images as wip not supported. The only kernel we provide is in experimental or at least testing phase.. The exceptions from supported are higher than WIP.. 
  12. Like
    5kft got a reaction from Igor_K in NanoPi NEO4   
    FYI - the NEO4 is now available - see https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=241
     
    I just placed my order 
     
     
  13. Like
    5kft got a reaction from Igor_K in NanoPi NEO4   
    FYI - the NEO4 is now available - see https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=241
     
    I just placed my order 
     
     
  14. Like
    5kft reacted to cmoski in Quick review of NanoPi Fire3   
    @5kft -- Thanks for this, worked like a charm! For anyone looking for more -- all I had to do was grab the device tree tools and run the following on the existing dtb in the boot directory:
     
    dtc -O dts s5p6818-nanopi-fire3.dtb > fire3-devicetreetxt.dts #[Modify frequencies on dts file, too lazy to build a sed command] dtc -O dtb fire3-devicetreetxt.dts > s5p6818-nanopi-fire3.dtb I think on the FriendlyArm provided distro this would be the 05.dtb file as @wtarreau mentioned. No recompilation of the kernel required, just a reboot.
     
    It seems that for any overclock a small voltage bump is required. I am still looking into if this will push my 10 port USB hub (60w anker) past its rated capacity when all 10 Fire3's are loaded to 100%.
     
    @wtarreau -- If you have a chance I'd love to take a look at your thermal throttling point configuration. Standard disclaimer of course noted :-)
     
    Thank you both!
     
  15. Like
    5kft got a reaction from chwe in Quick review of NanoPi Fire3   
    Hi @cmoski, in case it is helpful to you:  If you are using the "nanopifire3" board configuration ("next" target), you can build the kernel, specifying the "CREATE_PATCHES=yes" option, and then modify the generated DT in "cache/sources/linux-4.14.y/arch/arm64/boot/dts/nexell/s5p6818-nanopi-fire3.dts".  Look for "dvfs-tables" in this DT file and edit/add the higher frequency:
    dvfs:dynamic-freq@bb000 { supply_name = "vdd_arm_spu"; supply_optional = "vdd_arm_axp"; vdd_arm_spu-supply = <&VCC1P1_ARM_SPU>; vdd_arm_axp-supply = <&VCC1P1_ARM_PMIC>; status = "okay"; dvfs-tables = < 1400000 1200000 1300000 1140000 1200000 1100000 1100000 1040000 1000000 1040000 900000 1000000 800000 1000000 700000 980000 600000 980000 500000 940000 400000 940000>; }; In this table the first column is the frequency, and the second is the voltage provided by the SPU1705 regulator for that frequency.  Note that the maximum voltage that this regulator can output is 1.265v (please see ".../drivers/regulator/spu1705.c" for details).
     
    My Fire3 could run fine at 1.5GHz using 1.265v, but 1.6GHz was too unstable (random crashes).  The original FriendlyELEC kernel tree sets the maximum to 1.4GHz at 1.2v, so this is what I brought over to Armbian.
     
    I hope this helps...!
     
  16. Like
    5kft reacted to lrrr in Keep cpufrequtils settings when linux-root upgrades   
    Does dpkg-divert not work for some reason?
    dpkg-divert --add /etc/default/cpufrequtils
  17. Like
    5kft got a reaction from chwe in Quick review of NanoPi Fire3   
    Hi @cmoski, in case it is helpful to you:  If you are using the "nanopifire3" board configuration ("next" target), you can build the kernel, specifying the "CREATE_PATCHES=yes" option, and then modify the generated DT in "cache/sources/linux-4.14.y/arch/arm64/boot/dts/nexell/s5p6818-nanopi-fire3.dts".  Look for "dvfs-tables" in this DT file and edit/add the higher frequency:
    dvfs:dynamic-freq@bb000 { supply_name = "vdd_arm_spu"; supply_optional = "vdd_arm_axp"; vdd_arm_spu-supply = <&VCC1P1_ARM_SPU>; vdd_arm_axp-supply = <&VCC1P1_ARM_PMIC>; status = "okay"; dvfs-tables = < 1400000 1200000 1300000 1140000 1200000 1100000 1100000 1040000 1000000 1040000 900000 1000000 800000 1000000 700000 980000 600000 980000 500000 940000 400000 940000>; }; In this table the first column is the frequency, and the second is the voltage provided by the SPU1705 regulator for that frequency.  Note that the maximum voltage that this regulator can output is 1.265v (please see ".../drivers/regulator/spu1705.c" for details).
     
    My Fire3 could run fine at 1.5GHz using 1.265v, but 1.6GHz was too unstable (random crashes).  The original FriendlyELEC kernel tree sets the maximum to 1.4GHz at 1.2v, so this is what I brought over to Armbian.
     
    I hope this helps...!
     
  18. Like
    5kft got a reaction from chwe in Quick review of NanoPi Fire3   
    Hi @cmoski, in case it is helpful to you:  If you are using the "nanopifire3" board configuration ("next" target), you can build the kernel, specifying the "CREATE_PATCHES=yes" option, and then modify the generated DT in "cache/sources/linux-4.14.y/arch/arm64/boot/dts/nexell/s5p6818-nanopi-fire3.dts".  Look for "dvfs-tables" in this DT file and edit/add the higher frequency:
    dvfs:dynamic-freq@bb000 { supply_name = "vdd_arm_spu"; supply_optional = "vdd_arm_axp"; vdd_arm_spu-supply = <&VCC1P1_ARM_SPU>; vdd_arm_axp-supply = <&VCC1P1_ARM_PMIC>; status = "okay"; dvfs-tables = < 1400000 1200000 1300000 1140000 1200000 1100000 1100000 1040000 1000000 1040000 900000 1000000 800000 1000000 700000 980000 600000 980000 500000 940000 400000 940000>; }; In this table the first column is the frequency, and the second is the voltage provided by the SPU1705 regulator for that frequency.  Note that the maximum voltage that this regulator can output is 1.265v (please see ".../drivers/regulator/spu1705.c" for details).
     
    My Fire3 could run fine at 1.5GHz using 1.265v, but 1.6GHz was too unstable (random crashes).  The original FriendlyELEC kernel tree sets the maximum to 1.4GHz at 1.2v, so this is what I brought over to Armbian.
     
    I hope this helps...!
     
  19. Like
    5kft reacted to chwe in Keep cpufrequtils settings when linux-root upgrades   
    one more and you can set up a punk band.. 
     
    still think that putting something like this in rc6.d just asks for trouble.. 
  20. Like
    5kft reacted to hjc in NanoPi NEO4   
    Now FriendlyARM has a wiki page for NEO4.
  21. Like
    5kft got a reaction from Igor in btrfs root images are currently broken...?   
    Yes, that change introduced the problem...  I just pushed a fix:  https://github.com/armbian/build/commit/c1530db4820320a1e837901196d846b0ef71ee4c
  22. Like
    5kft got a reaction from Igor in btrfs root images are currently broken...?   
    Yes, that change introduced the problem...  I just pushed a fix:  https://github.com/armbian/build/commit/c1530db4820320a1e837901196d846b0ef71ee4c
  23. Like
    5kft got a reaction from allen_key in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    Yes...+1 to what Igor said...  Unfortunately as much as I wished wasn't the case I don't have any spare time to help with this currently...  My advice right now is that you take a look at my overlay additions for these two overlays (in the DEV branch now) - they are very small - and you could try manually building them for your 4.14 kernel.  This should be fairly straightforward (e.g., take a look at "armbian-add-overlay" on-device).  I hope this helps - good luck!
  24. Like
    5kft reacted to allen_key in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    I have done a simple openssl benchmark for Allwinner H5 @ 816Mhz vs 1296MHz.
    Just for all your information, I saw huge performance improvement @ 1296MHz.
     
    Command: openssl speed -elapsed -evp aes-128-cbc
     
    Thanks, 5kft bring us such useful information again.

  25. Like
    5kft got a reaction from vortigont in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    Hi @rusatch - yes, however this is actually even easier to enable now; no patching and custom kernels should be needed   If you build Armbian from the latest top-of-tree for a sunxi device (starting with the 4.17.y kernel), two new DT overlays are provided that you can load via "/boot/armbianEnv.txt" that provide this regulator and will enable higher clock speeds to be used.  The original thread regarding this (with instructions) can be found here:  https://forum.armbian.com/topic/5051-nanopi-neo2-cpu-frequency-issue/?do=findComment&comment=58181.  I'll repeat these instructions here for others:
     
    If you would like to try to run your board at 1.3GHz, and your board has a regulator on GPIO PL6 that supports 1.3v (e.g., Orange Pi Zero Plus2 H5 with Q5 MOSFET present, Orange Pi Zero Plus with Q5 MOSFET present, etc.), then all you would have to do is the following:
     
    1.  Make sure that you know what you are doing (!).  If you enable the following on a board that does not properly have access to the CPU regulator - i.e., unmodified OrangePi board with missing Q5 MOSFET, or a board that does not have a compatible 1.1v/1.3v regulator controlled via GPIO PL6 - then your board will almost certainly crash on boot!
     
    2.  Edit /boot/armbianEnv.txt, and add these lines:
    overlay_prefix=sun50i-h5 overlays=gpio-regulator-1.3v cpu-clock-1.3GHz If you have other overlays specified in your /boot/armbianEnv.txt, simply append these two new ones following them, for example:
    overlay_prefix=sun50i-h5 overlays=spi-spidev usbhost2 usbhost3 gpio-regulator-1.3v cpu-clock-1.3GHz  
    3.  Edit /etc/default/cpufrequtils, and set the MAX_SPEED definition to 1300000:
    # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1300000 GOVERNOR=ondemand  
    4.  Reboot the board
     
    That should be it!  Following reboot, you can verify proper operation at the higher CPU clock speeds using "cpufreq-info" (for example).