Hello @Jean-Francois Lessard, congratulations for the excellent driver! I stumbled here because I started making myself an fd6551 driver , and just after I discovered you already published a fully working product, which is way more polished than mine. Anyway, I did not have yet the chance to tm16xx driver, but will do soon and report here the result. I have a HK1 box with rk3318 and fd6551 chip on board.

Good morning, I am having some problems with the i2c-1 bus, as it sometimes gets stuck even though I have external pull-up resistors. I need to be able to reset the bus to fix it and check the status of the channels, but I don’t know which Linux GPIO corresponds to the physical pins that the kernel associates with PA18 and PA19. I have tried using wiringPi, but it doesn’t indicate this. Can anyone help me? Thanks!

FYI: git clone https://github.com/sicXnull/armbian-build.git --branch X96Q-TVBOX-LPDDR3 --single-branch cd armbian-build ./compile.sh build BOARD=x96q-v1-3 BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_CONFIGURE=no RELEASE=bookworm build.log

Hello armbian members ! i just signed up to thank u guys for ur efforts, i saw this post and i remembered that i had h96q box laying around, the board itself says its v5.1, tested the img @rafman provided its working perfectly boot from emmc working too wifi/lan all good just a quick noobish question, is everything cpu based on these images ? nothing can be used to accelerate graphics like video playback ? or how does these things work "technically" if there's any resources that i can read please point me again thank u all for the great efforts.

Hello, When choosing Boot from eMMC - system on SATA, USB or NVMe in armbian-install using the Armbian 24.8.3 Bookworm Minimal / IOT, Kernel: 6.1.75, Release date: Sep 14, 2024 image on my NanoPi R6C, I get the following error: The wird device name is also mentioned on the two preceeding dialogs ("it is highly recommended to wipe all partitions" and "this will wipe all data"). I took a look at the argmbian-install script and the check_partitions routine seems to assume that $diskcheck contains something that, when prefixed with /dev, can be used in the of parameter of the dd command. It is computed as root_uuid=$(sed -e 's/^.*root=//' -e 's/ .*$//' < /proc/cmdline) root_partition=$(blkid | tr -d '":' | grep "${root_uuid}" | awk '{print $1}') root_partition_name=$(echo $root_partition | sed 's/\/dev\///g') root_partition_device_name=$(lsblk -ndo pkname $root_partition) diskcheck=$(lsblk -l | awk -F" " '/ disk / {print $1}' | grep -E '^sd|^nvme|^mmc' | grep -v "$root_partition_device_name" | grep -v boot) With the following block devices (zram omitted) NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk0 179:0 0 28.9G 0 disk mmcblk0boot0 179:32 0 4M 1 disk mmcblk0boot1 179:64 0 4M 1 disk mmcblk1 179:96 0 29.7G 0 disk └─mmcblk1p1 179:97 0 29.4G 0 part /var/log.hdd nvme0n1 259:0 0 1.9T 0 disk this evaluates to root_uuid=UUID=be8e5867-07c9-4cae-842b-22fd411851ba root_partition=/dev/mmcblk1p1 root_partition_name=mmcblk1p1 root_partition_device_name=mmcblk1 diskcheck=mmcblk0 nvme0n1 To me it seems that the computation of diskcheck assumes that lsblk will return at most one "disk" that is not the root device and not a boot partition. On my system, which has an EMMC, an NVME SSD and is booting from an sdcard, this assumption does not hold. Or maybe, including ^sd and ^mmc in the check is not the right thing to do here? Am I doing something wrong here, do I have an unsupported block device layout or is this a bug in the armbian-install script? Is there maybe a workaround? Thank you!