Super moderator
  • Content Count

  • Joined

  • Last visited

About zador.blood.stained

  • Rank
    Embedded member

Profile Information

  • Gender

Recent Profile Visitors

3656 profile views
  1. zador.blood.stained

    why does passing KEY=value args to work? # Script parameters handling for i in "$@"; do if [[ $i == *=* ]]; then parameter=${i%%=*} value=${i##*=} display_alert "Command line: setting $parameter to" "${value:-(empty)}" "info" eval $parameter=$value fi done Not sure if this solution is 100% bullet-proof (i.e. for handling special characters and values with spaces) but it works for the build script needs.
  2. zador.blood.stained

    FEL mass storage or writing images directly to eMMC

    No, this is a standard initrd from Debian or Ubuntu with a custom script. Any kernel that supports OTG and mass storage gadget should work, but the script I linked was adjusted specifically for the sun8i legacy kernel, so it will need some rework for different kernels. In case of binaries provided for H3 in my repository I removed a lot of non-essential options from the kernel config (to minimize the binary size) and adjusted u-boot and script.bin to work on most boards regardless of CPU voltage regulation type. I would suggest looking into u-boot mass storage gadget support instead, this config suggests that is should be possible.
  3. zador.blood.stained

    spi gpio chip select support

    Again, it should be controlled by the bus, check the spi_set_cs function here. First it checks for valid GPIO properties, and if it doesn't look like a valid one, it falls back to the HW CS if the master controller provides a function pointer for setting one. As I understand it, CS handling is done entirely by the bus master subsystem so slave drivers should not know anything about it, as long as DT sets correct "reg" properties for the SPI slave nodes.
  4. zador.blood.stained

    spi gpio chip select support

    "cs-gpios" are handled by the spi-bus core: Last time I tested it (maybe a year ago?) it worked for me (and I tested it on H3 and H5 if I remember correctly). Please keep in mind that current overlays may be broken (you should at least try this branch if you are using anything kernel newer than 4.14). Is there anything suspicious in dmesg? I would suggest trying CS1 with dual spidev configuration as it is easier to debug. Out of 7? Are we talking about H3/H5 or A20?
  5. zador.blood.stained

    Benchmarking CPUs

    so most likely the syscall + data copy overhead for each block kills the performance with smaller block sizes. If I remember correctly I compared cryptodev with AF_ALG on some platform (most likely with cryptotest) and AF_ALG was slightly faster compared to cryptodev.
  6. zador.blood.stained

    Benchmarking CPUs

    I though more about this and also ran openssl and cryptsetup through strace and checked openssl build configuration in Ubuntu. Stock Ubuntu (and most likely Debian) OpenSSL will use userspace crypto. So if there are CPU instructions (NEON, ARMv8 CE) - it should use them, but it won't be using HW engines like sun4i-ss or CESA. At least we have some comparable numbers as long as we don't compare OpenSSL 1.0.x results with 1.1.x directly. This means that AES numbers in the table will not resemble performance in some real world scenarios that use in-kernel crypto (like disk and filesystem encryption) But people will still use your results table to compare boards, so IMO it's worth adding a note for boards where HW crypto engines are available. ARMv8 CE is not a crypto engine, its numbers should depend on CPU performance and should be affected by throttling, compared to, i.e., CESA that uses a fixed clock.
  7. zador.blood.stained

    Benchmarking CPUs

    Speaking of OpenSSL, I wonder if we are actually collecting useful data and not usual "numbers without meaning", as the performance may depend on several factors: OpenSSL version (versions lower than 1.1.0 don't support AF_ALG) AF_ALG actually enabled in the kernel Kernel crypto options (kernel mode NEON and NEON optimized AES) EDIT: not sure if OpenSSL uses AF_ALF by default, but pretty sure that cryptsetup does Though for me cpuminer silently failed to build even though I added the "neon" command line parameter. Maybe providing precompiled (and statically linked) cpuminer binaries for armhf and arm64 is a good idea to reduce the number of installed dependencies?
  8. zador.blood.stained

    OPZ+2 H5 enable SPi but no /dev/spi-dev

    I already started the cleanup: For now it should be enough to check .dtsi files to figure out changes first, and let people test everything later.
  9. zador.blood.stained

    OPZ+2 H5 enable SPi but no /dev/spi-dev

    It's more than just leading 0s, there are other node and label name changes too.
  10. zador.blood.stained

    Benchmarking CPUs

    Since I had this image installed on eMMC and the board was ready to use I ran a benchmark and it produced +/- similar to already present in the table results. Log:
  11. zador.blood.stained

    OPZ+2 H5 enable SPi but no /dev/spi-dev

    A64 SPI was added upstream only in 4.15 so it's possible that there are some inconsistencies between SPI DT patches and overlay patches. But since people added several overlays directly to kernel patches I'm not even sure which sunxi-DT-overlays revision we had and have right now in sunxi-next and sunxi-dev trees.
  12. zador.blood.stained

    OPZ+2 H5 enable SPi but no /dev/spi-dev

    Not surprising given the number of DT changes between 4.14 and 4.17. Almost all overlays need adjustments for newer kernel versions.
  13. zador.blood.stained

    OPZ+2 H5 enable SPi but no /dev/spi-dev

    Which kernel version are we talking about - 4.14 or 4.17?
  14. LUKS encryption was not merged to master as I tried to simplify and rework it, but did not finist it yet, not to mention that it needs more testing with different kernels. The only thing I didn't pull to a separate branch was resize2s modification, but we can get the code from here, no need to restore the "development" branch
  15. zador.blood.stained

    U-Boot saveenv issue

    "auto" is not implemented for the device identifier, only for the partition number. Though in theory it is possible to use (sunxi specific) boot device ID from the SPL header, but unless someone writes and tests this we are stuck with fixed device IDs.