zador.blood.stained

Super moderator
  • Content Count

    3608
  • Joined

  • Last visited

About zador.blood.stained

  • Rank
    Embedded member

Profile Information

  • Gender
    Male

Recent Profile Visitors

3853 profile views
  1. zador.blood.stained

    board support - general discussion / project aims

    Yes, but is it still manufactured? Is it still sold worldwide? And what will you do if you are an "interested developer" and your board dies? Buy another one (if it would be even possible) or move it to "community supported"? I'm not saying that we should drop support for this particular board right now (I'm sure that @tkaiser would have a different opinion) but any device will fade out in time, regardless of the history.
  2. zador.blood.stained

    board support - general discussion / project aims

    No need to be surprised, absolutely any device can be dropped based on objective reasons, mainly lack of an interested developer or persisting HW or SW issues that we can't solve. or quite the opposite - do not enforce things unless absolutely necessary, to cut support efforts on "Armbian-specific" tweaks that sometimes break. We are talking about KISS but still piling up unnecessary tweaks like DNS servers (if only there was some mechanism to automatically get a DNS server preferred by the user address among other things, I think we could even call it a "dynamic host configuration protocol") or rather an "unmarketing manager" to reduce the attention to the project to help developers catch their breath
  3. zador.blood.stained

    board support - general discussion / project aims

    Things to add IMO, some general forum rules to let moderators make decisions based on written rules instead of personal opinions (yes, I think we already discussed this more than a year ago): - primary forum language is English, messages in other languages without translation outside of "General chit chat" section may be hidden or deleted - don't bump topics too often and don't create duplicate messages and topics to bring attention to your issue - be respectful to each other, follow the nettiquette - don't abuse private messaging for tech support - don't abuse forum for self-promotion and don't spam - breaking the rules will result in a warning, getting multiple warnings will result in a ban
  4. zador.blood.stained

    board support - general discussion / project aims

    Then the project should be scaled back to the point where it is sustainable? If a problem requires too much time to solve then it should be ignored until someone more knowledgeable or more resourceful solves it? Then maybe "we" should not try to satisfy everyone? This includes answering to topics if you don't know the answer or can't solve the problem right now, includes providing nightly images and images for community supported devices (let people build images by themselves and share them without using the project infrastructure (i.e. via MEGA or Google Drive) since disk space and traffic costs money that doesn't come from nothing). Also includes working on and especially providing any images already for H6 which is (IMO) > 6 months away from getting enough green squares in the sunxi status matrix for making images suitable for everyday use. Includes providing "better" wireless drivers if integrating and testing them takes too much time. I think this would help too, I don't want to wash my eyes with a soap after reading some threads.
  5. zador.blood.stained

    why does passing KEY=value args to compile.sh work?

    https://github.com/armbian/build/blob/master/compile.sh#L51-L59 # 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.
  6. 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.
  7. 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.
  8. zador.blood.stained

    spi gpio chip select support

    "cs-gpios" are handled by the spi-bus core: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/devicetree/bindings/spi/spi-bus.txt 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?
  9. 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.
  10. zador.blood.stained

    Benchmarking CPUs

    I thought 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.
  11. 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?
  12. zador.blood.stained

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

    I already started the cleanup: https://github.com/armbian/sunxi-DT-overlays/commits/linux-4.17.y For now it should be enough to check .dtsi files to figure out changes first, and let people test everything later.
  13. 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.
  14. 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: http://ix.io/1iLy
  15. 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.