zador.blood.stained

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.

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

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

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.

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.

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.

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.

"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?

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.

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.

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?

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.

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

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

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.

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

Which kernel version are we talking about - 4.14 or 4.17?

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

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

This script has CR+LF line endings, it needs to be converted to Unix format first

AFAIK newer DietPi for NanoPi boards is based on FriendlyARM images, so it may use different u-boot and kernel compared to Armbian (and Armbian based DietPi images were removed from their download servers).

This. Both overlays and fixup scripts need updates after migration from 4.14 to 4.17.

It also has a description config BTRFS_FS_CHECK_INTEGRITY bool "Btrfs with integrity check tool compiled in (DANGEROUS)" depends on BTRFS_FS help Adds code that examines all block write requests (including writes of the super block). The goal is to verify that the state of the filesystem on disk is always consistent, i.e., after a power-loss or kernel panic event the filesystem is in a consistent state. If the integrity check tool is included and activated in the mount options, plenty of kernel memory is used, and plenty of additional CPU cycles are spent. Enabling this functionality is not intended for normal use. In most cases, unless you are a btrfs developer who needs to verify the integrity of (super)-block write requests during the run of a regression test, say N You can read the btrfs FAQ to start with

Yes, we need to start working on 4.17 or 4.18 (which in addition has basic DVFS for H3), but I would prefer to do it in a separate repository branch (I already created one and cleaned up obviously obsolete patches there) rather than in the "dev" kernel target.

You may want to look at the legacy stack implementation: when power_start != 1 kernel reboots instead of shutting down, so you have to modify or replace the poweroff hook AXP209 PMIC "scratchpad" registers are used as a non-volatile storage to hold the suspend/wait for interrupts flag u-boot checks the PMIC scratchpad to differentiate between normal boot, normal reboot and reboot to suspend