Halolo

I have used gpiod on a personal project, so I wrote a limited python class + flask API: https://github.com/lanefu/sbc-gpio-pcf857x/pull/2 It is limited to the use case I saw in the bash library

Hi, I have nothing "new" for this thread but I can add some feedback as I have a similar issue (as the one originally reported) I've a raid 1+0 array with 4 WD30EFAX, connected to ata1-4 ports. The system was running "Armbian 21.02.2 Buster with Linux 5.10.16-rockchip64" on emmc at the time I reported the issue to Kobol support. I have the enclosure kit, so I use the provided SATA harness. A file transfer (read ~15G) from an NFS client was enough to trigger a lot of occurrences of: [78707.655206] ata4.00: failed command: READ FPDMA QUEUED [78707.655231] ata4.00: cmd 60/80:f8:00:cc:bb/00:00:4f:01:00/40 tag 31 ncq dma 65536 in res 40/00:18:80:cf:e3/00:00:48:01:00/40 Emask 0x14 (ATA bus error) [78707.655242] ata4.00: status: { DRDY } [78707.655263] ata4: hard resetting link [78708.545911] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [78708.547161] ata4.00: configured for UDMA/133 [78708.548485] ata4: EH complete Happens on ata4 mostly, and also on ata3 but less, and never on ata1 and ata2. I also added a ssd on ata5 at one point and saw the issue on that port as well. Kobol sent me a new harness which looked very similar to the one I already had and I did the swap. Thought it was fixed because the file transfer was not triggering the issue anymore, but after the next occurence of the periodic scrub, it was back, mainly on ata4 and a few ata3 "hard resetting link". Since then I am using `extraargs=libata.force=3.0` with no issue (which is fine for my usage). I didn't try to use an external PSU + "standard" SATA cables but from what I've read here I'm confident it would fix the issue. I supposed it could be crosstalk in the harness, but could also be on the board when using the onboard HDD power plug for the disks as @ShadowDance was saying that it is still happening with standard SATA cables + power from the "mutilated" harness.

Hi, I just had a brief look at the script and I'm still unfamiliar with armbian-config tools and the image building process, but I see 3 options for nand-sata-install: GPT Capability checked against a hardcoded list of platform that supports it. GPT is preferred if available. An input/option for the script - but as to be validated with 1. The script replicates the partition table type of the running system If the sdcard images are now generated with GPT when it is supported, then I think #3 is a good option. What do you think?