tkaiser

Members
  • Content count

    4307
  • Joined

  • Last visited


Reputation Activity

  1. manuti liked a post in a topic by tkaiser in H6 boards: Orange Pi 3 Plus and PineH64   
     
    Nah, but let's try another 'joke'. Can you imagine how the lower PCB side of the new small Xunlong H6 boards might look like if checking the size of a mPCIe Marvell SATA controller and OPi One/Lite:

     
    (disclaimer: I've really no idea what Xunlong is planning, just a thought since H6 has PCIe so why not trying to expose the interface? Maybe just routing/preparing the 52 pins and not soldering the connector by default?)
  2. tkaiser liked a post in a topic by zador.blood.stained in Bananapi suddenly powers off   
    Not to me. USB hub by itself is a very light load but it results in a measurable voltage drop on DC IN. And I have a couple of USB hubs that can reboot a microUSB powered RPi if you connect them - most likely because of a filtering capacitor on the input causing a large enough current spike.
  3. tkaiser liked a post in a topic by TonyMac32 in NanoPi Duo (plus Mini Shield)   
     
    I tested this out, I can control those pins.  Is the issue that the SPI driver can show up and smash everything?  And if so, is this possible accidentally, or would it have to be triggered by an unsuspecting user?
     
    Side note for @tkaiser I was getting about 160-190 mA consumption (varied widely) on the vendor image, with the nightly Armbian I get about 150.
     
     
  4. tkaiser liked a post in a topic by MMGen in Full root filesystem encryption on an Armbian/Orange Pi PC 2 system   
    Revised and re-tested tutorial with current Armbian OPi PC2 images, removed unneeded kernel compilation section.
  5. DEHN.IO liked a post in a topic by tkaiser in Orange Pi Zero Plus / H5 Chip   
     
    Doesn't matter, that's what the '### Installed packages' entry is for
     
    Since I don't understand what's happening on your installation I don't think so. You're running off eMMC, there's no SD card present, the boot environment doesn't look right and there's an older nand-sata-install.log lying around. I would need to understand this first...
  6. willmore liked a post in a topic by tkaiser in Orange Pi Zero Plus / H5 Chip   
    Ok, switching from 408 MHz DRAM clock to 624 MHz on OPi Zero Plus (still cpufreq limited since DVFS not working, I'm running at 1008 MHz but can consider myself lucky since we've seen H5 boards that get instable at 1008 MHz with 1.1V VDD_CPUX for sure):
    Test BSP Armbian old Armbian new std memcpy MB/s: 887.9 634.8 875.1 std memset MB/s: 2037.9 1553.0 2252.7 7z comp 22: 1288 1234 1515 7z comp 23: 1344 1279 1637 7z decomp 22: 3296 3329 3832 7z decomp 23: 3215 3317 3768 sysbench 648 (s): 14.4798 14.1447 14.1378 sysbench 816 (s): 11.4151 11.2191 11.1106 sysbench 1008 (s): 9.2395 9.0787 8.9818 openssl speed aes: almost identical So once DVFS is working there will be another slight performance increase in a few weeks.
  7. tkaiser liked a post in a topic by guidol in Orange Pi Zero Plus / H5 Chip   
     
    @tkaiser NanoPi Neo2 with debian stretch:
    Linux nanopineo22 4.13.13-sunxi64 #214 SMP Thu Nov 16 01:52:21 CET 2017 aarch64 GNU/Linux
    as attachment
     
    NanoPi_Neo2_tinymembench.txt
  8. tkaiser liked a post in a topic by zador.blood.stained in Network Manager not working - Armbian 5.34 Debian Stretch Desktop Bananapipro   
    ... and will never be supported. It wasn't supposed to be buildable at all but the condition was implemented in wrong place.
  9. tkaiser liked a post in a topic by willmore in Orange Pi Zero Plus / H5 Chip   
    PC2: http://sprunge.us/jVAH
  10. willmore liked a post in a topic by tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    Since I prepare a little NAS test with Orange Pi Zero Plus today I upgraded the firmware of the other JMS578 on the NAS Expansion board. Side effect: with the more recent firmware the USB-to-SATA bridge also provides more real information from the connected disk instead of itself.
     
    Prior to the firmware upgrade only /dev/sda shows nice information:

     
    After I upgraded the 2nd JMS578 (needs a full shutdown and removing power after the upgrade!) now /dev/sdb also reveals more information (though the drive's serial still bogus):

  11. DEHN.IO liked a post in a topic by tkaiser in Orange Pi Zero Plus / H5 Chip   
    Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them).
     
    So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD
     
    Test BSP Armbian std memcpy MB/s: 887.9 634.8 std memset MB/s: 2037.9 1553.0 7z comp 22: 1288 1234 7z comp 23: 1344 1279 7z decomp 22: 3296 3329 7z decomp 23: 3215 3317 sysbench 648 (s): 14.4798 14.1447 sysbench 816 (s): 11.4151 11.2191 sysbench 1008 (s): 9.2395 9.0787 openssl speed aes: identical The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM
     
    So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.
  12. willmore liked a post in a topic by tkaiser in Orange Pi Zero Plus / H5 Chip   
    To prepare next steps I booted with vendor OS image once (obviously no tuning at all for this board, it seems that's generic Allwinner H5 BSP stuff already used for Orange Pi PC 2 before, at least this is /boot/orangepi/OrangePiH5orangepi.dtb being decompiled).
     
    Performance results here: https://pastebin.com/TZhEPrqs (64-bit kernel 3.10.65, settings limiting cpufreq to 1008 MHz and clocking DRAM at 624 MHz)
     
    Then I thought I take FriendlyELEC's Xenial image for their NEO Plus 2 (since same voltage regulation, switching between 1.1V and 1.3V toggled by PL06 pin) but to no avail. IIRC they implement some board detection logic and I ended up with no cpufreq support but running at 816 MHz, DRAM clocked at 672 MHz: https://pastebin.com/8wEaPiUp (quick note wrt iperf3 tests: with Armbian IRQ affinitiy settings numbers improve from 844/922 Mbits/sec to 895/940 Mbits/sec so once we have voltage regulation configured correctly on this board and can exceed 816 MHz cpufreq full GbE saturation will be possible)
     
    With BSP kernel and without heatsink this thing idles at 55°C according to sysfs so it now wears a heatsink (and all tests above were made with a fan running in parallel). 
  13. willmore liked a post in a topic by tkaiser in Orange Pi Zero Plus / H5 Chip   
    Just created the wiki page for the device: http://linux-sunxi.org/Orange_Pi_Zero_Plus
  14. tkaiser liked a post in a topic by Igor in Orange Pi Zero Plus / H5 Chip   
    And updated wifi driver with fixed MAC address is coming later on to beta repository. 
  15. DEHN.IO liked a post in a topic by tkaiser in Orange Pi Zero Plus / H5 Chip   
    Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them).
     
    So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD
     
    Test BSP Armbian std memcpy MB/s: 887.9 634.8 std memset MB/s: 2037.9 1553.0 7z comp 22: 1288 1234 7z comp 23: 1344 1279 7z decomp 22: 3296 3329 7z decomp 23: 3215 3317 sysbench 648 (s): 14.4798 14.1447 sysbench 816 (s): 11.4151 11.2191 sysbench 1008 (s): 9.2395 9.0787 openssl speed aes: identical The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM
     
    So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.
  16. DEHN.IO liked a post in a topic by tkaiser in Orange Pi Zero Plus / H5 Chip   
    Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them).
     
    So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD
     
    Test BSP Armbian std memcpy MB/s: 887.9 634.8 std memset MB/s: 2037.9 1553.0 7z comp 22: 1288 1234 7z comp 23: 1344 1279 7z decomp 22: 3296 3329 7z decomp 23: 3215 3317 sysbench 648 (s): 14.4798 14.1447 sysbench 816 (s): 11.4151 11.2191 sysbench 1008 (s): 9.2395 9.0787 openssl speed aes: identical The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM
     
    So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.
  17. willmore liked a post in a topic by tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    Got some nice feedback from JMicron explaining firmware versions.
    0.1.x is for self-powered SATA HDD/SSD device 0.2.x is for bus-powered SATA HDD/SSD device  0.4.x is for self-powered SATA HDD/SSD/ODD device application (ODD --> optical disk) $higher-number.x means custom firmware (enclosure maker) I only asked for the firmware revisions of a couple of devices I've access to so not all possible variations are listed above (eg. 0.3.x or 0.5.x could mean 'bus-powered HDD/SSD/ODD device). But at least this explains a lot already.
     
    When comparing 0.1.0.5 on ODROID HC1 and 0.4.0.5 with ROCK64 SATA cable the firmware revision (x.x.0.5) is the same while the ROCK64 cable firmware should also deal with optical drives. And the 0.2.x firmware being meant for bus-powered vs. self-powered suddenly explains the different behaviour I observed wrt JMS chip being present on the USB bus or not depending on whether there's a SATA drive connected or not (different consumption in different modes).
     
    Anyway that needs some more understanding and testing but at least we don't need to be concerned about one JMS578 device (ODROID HC1) having a horribly outdated firmware 0.1.0.5 while ROCK64 SATA cable has a way higher (0.4.0.5) since FW revision is actually the same.
     
    JMicron is still busy testing with a newer firmware revision solving the HDD spindown issues, once I get news or something to test I'll update this thread.
  18. DEHN.IO liked a post in a topic by tkaiser in Orange Pi Zero Plus / H5 Chip   
    Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them).
     
    So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD
     
    Test BSP Armbian std memcpy MB/s: 887.9 634.8 std memset MB/s: 2037.9 1553.0 7z comp 22: 1288 1234 7z comp 23: 1344 1279 7z decomp 22: 3296 3329 7z decomp 23: 3215 3317 sysbench 648 (s): 14.4798 14.1447 sysbench 816 (s): 11.4151 11.2191 sysbench 1008 (s): 9.2395 9.0787 openssl speed aes: identical The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM
     
    So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.
  19. willmore liked a post in a topic by tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    Got some nice feedback from JMicron explaining firmware versions.
    0.1.x is for self-powered SATA HDD/SSD device 0.2.x is for bus-powered SATA HDD/SSD device  0.4.x is for self-powered SATA HDD/SSD/ODD device application (ODD --> optical disk) $higher-number.x means custom firmware (enclosure maker) I only asked for the firmware revisions of a couple of devices I've access to so not all possible variations are listed above (eg. 0.3.x or 0.5.x could mean 'bus-powered HDD/SSD/ODD device). But at least this explains a lot already.
     
    When comparing 0.1.0.5 on ODROID HC1 and 0.4.0.5 with ROCK64 SATA cable the firmware revision (x.x.0.5) is the same while the ROCK64 cable firmware should also deal with optical drives. And the 0.2.x firmware being meant for bus-powered vs. self-powered suddenly explains the different behaviour I observed wrt JMS chip being present on the USB bus or not depending on whether there's a SATA drive connected or not (different consumption in different modes).
     
    Anyway that needs some more understanding and testing but at least we don't need to be concerned about one JMS578 device (ODROID HC1) having a horribly outdated firmware 0.1.0.5 while ROCK64 SATA cable has a way higher (0.4.0.5) since FW revision is actually the same.
     
    JMicron is still busy testing with a newer firmware revision solving the HDD spindown issues, once I get news or something to test I'll update this thread.
  20. tkaiser liked a post in a topic by guidol in NanoPi Neo2 and Neo Station NS-120B with armbian   
    Yes, the lsusb ID is "Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp."
    but IT IS a JMS567 like noted at the FriendlyElec-page for the NAS:
    http://www.friendlyarm.com/index.php?route=product/product&product_id=192
     
    And as attachment the proof as a picture
     
     

  21. zador.blood.stained liked a post in a topic by tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t):
    /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with:
    root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success!
    /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.
  22. manuti liked a post in a topic by tkaiser in H6 boards: Orange Pi 3 Plus and PineH64   
     
    Well, I thought I was joking but in fact this does exist. An industrial i.MX6 design with 40 pin header does exactly that. Exposing the needed PCIe pins on the header:
     

  23. willmore liked a post in a topic by tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
     
    Just a little bit: https://forum.armbian.com/topic/4921-orange-pi-zero-plus-h5-chip/?do=findComment&comment=43667 (but with UAS active also CPU utilization slightly decreases so it's good anyway)
     
  24. zador.blood.stained liked a post in a topic by tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t):
    /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with:
    root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success!
    /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.
  25. zador.blood.stained liked a post in a topic by tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t):
    /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with:
    root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success!
    /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.