Thank you @c0rnelius for guidelines regarding the tools. I was able to successfully get the device in mask rom mode after dozens of unsuccessful attempts, it's been like hell. Anyway, once I managed to get it in mask rom mode, I checked the tools you mentioned - the thing is https://github.com/natinusala/linux-amlogic-toolkit uses https://github.com/Stane1983/aml-linux-usb-burn under the hood, it's more specialized for unpacking, modifying and repacking android images. Then the other tools available such as https://github.com/mluis/aml-flash-tool and https://github.com/PowderLinux/Amlogic-Flash-Tools-Backup don't seem to support my box. I looked at the flash scripts and the --soc options and saw this --soc=<m8|axg|gxl|txlx|g12a> My board is s905x3, which is sm1. This repo https://github.com/PowderLinux/Amlogic-Flash-Tools-Backup even lists s905x3 as supported, but when I opened the flash tool, the script had this soc value check if [[ "$soc" != "m8" ]] && [[ "$soc" != "gxl" ]] && [[ "$soc" != "axg" ]] && [[ "$soc" != "txlx" ]] && [[ "$soc" != "g12a" ]]; then echo "Soc type is invalid, should be either m8,gxl,axg,txlx,g12a" exit 1 fi I mean, seriously - the README explicitly states s905x3 boards are supported, and if you put --soc=sm1 the flash script will probably fail (I didn't dare run that). @SteeManRegarding the install.sh script which I couldn't find - I mentioned I used dd instead of balena-etcher. I tried to install balena-etcher, just to see if the usb would be different, but then I remembered why I didn't do it with balena in the first place - package conflicts (node vs node-lts) on arch, I'd have to uninstall node, and switch to lts version... It was just too much of a hassle, so I didn't install it. With dd, the usb is partitioned in armb_boot and armbi_root, and instead of a /boot folder, I had a partition. The armbi_root partition contains the linux filesystem, /etc, /boot, /lib etc. But I did find a /root directory in the armbi_root partition. And of course, it contains the install-aml.sh script. I thought since /boot was a partition in my case, /root was the armbi_root partition, and the /root dir is hidden and inaccessible to normal users. So, my apologies, I should have been more thorough, and look better and ask instead of asking AI carelessly - should have known it wasn't safe to just follow AI's instructions for installing to emmc, it's too specific and delicate, and AIs are usually too general. I guess it's a very good lesson, one that cost me hours of work and nerves. Thank you again for your patience and all the help you provided. And then I searched with AI, to see if any at all linux tools are available for my board - no results. ChatGPT told me there was an option to flash parts of the android image - without touching the bootloader. So I ended up using https://github.com/Stane1983/aml-linux-usb-burn, to unpack the android image and to flash something. ChatGPT showed me which files and in what order to flash them (going from lowest risk possible supposedly). I managed to flash the dtb successfully but that was it - after that I couldn't flash boot, and the board probably lost contact # dtb flash - successful [user03@arch unpack]$ ./../update partition _aml_dtb _aml_dtb.PARTITION normal file size is 0x10306 AmlUsbTplCmd = download store _aml_dtb normal 0x10306 rettemp = 1 buffer = download store _aml_dtb normal 0x10306 AmlUsbReadStatus retusb = 1 Downloading.... [update]Cost time 0Sec [update]Transfer size 0x10306B(0MB) AmlUsbBulkCmd[download get_status] [update]mwrite success # 1. attempt boot flash - fail [user03@arch unpack]$ ./../update partition boot boot.PARTITION normal file size is 0x98d800 AmlUsbTplCmd = download store boot normal 0x98d800 rettemp = 1 buffer = download store boot normal 0x98d800 AmlUsbReadStatus retusb = 1 Downloading.... [AmlLibUsb]:IOCTL_WRITE_MEDIA_Handler,value=1,index=ffff,len=32,ret=-110 error_msg=Connection timed out Write media command 112 failed AmlWriteMedia failed [update]Cost time 5Sec [update]Transfer size 0x70000B(0MB) ERR:write data to media failed # 2. attempt boot flash - fail [user03@arch unpack]$ ./../update partition boot boot.PARTITION normal file size is 0x98d800 AmlUsbTplCmd = download store boot normal 0x98d800 IOCTL_TPL_CMD_Handler ret=-110,tpl_cmd=download store boot normal 0x98d800 error_msg=Connection timed out rettemp = 0 buffer = download store boot normal 0x98d800 # 3. attempt boot flash - fail [user03@arch unpack]$ ./../update partition boot boot.PARTITION normal file size is 0x98d800 AmlUsbTplCmd = download store boot normal 0x98d800 rettemp = 1 buffer = download store boot normal 0x98d800 AmlUsbReadStatus retusb = 1 [update]ERR(L298):cmdret=[] # test if board available - fail [user03@arch tools]$ ./update identify 7 AmlUsbIdentifyHost IOCTL_IDENTIFY_HOST_Handler ret=-110 error_msg=Connection timed out ERR: get info from device failed So I unplugged it, and tried to boot it, just to see what's the status... amazing, I was shocked when I saw the line ## Booting Android Image at 0x01080000 ... It worked! I mean, of course it didn't boot any android, since I didn't really manage to flash it, but it managed to get to that point. So, I reflashed my usb stick (fresh armbian trixie) and enabled multi-boot with toothpick, and well, it does boot now to amrbian from usb - hdmi working, usbs working, ethernet and wifi not tested, but probably working (ethernet). So, I guess, as long as I have the usb inserted, it should successfully boot:) I call it a day Also, should I even try to run the install-aml.sh script now? I really wanted to use the 32gb emmc, instead of the 8gb usb. If it's not a good idea, then I'll just add another one in the other usb port (which I don't use anyway) and setup fstab rule to load it automatically to be used as additional storage.

Klipper Load Cell Documentation The kx711 is specifically referenced near the bottom of the documentation. It needs slow speeds and I believe has been incorporated into recent Klipper releases. I posted the file output on graphics, framebuffer and drm to @Torte github link. Also found an informative YouTube video on adding a Klipper Touch Screen, over serial, and configuring it. I'm adverse to tossing electronics into landfills - motivation to invest some time into a build for the Sovol boards and tolerate the mksclient propriatary blob. If the touch screen proves to be a show stopper, I think the makerbase MKS-SKIPR board, A supported USB wifi dongle and an HDMI touch screen could be used.

In the meantime, I fixed internal audio for "edge" (was: missing headphone GPIO). And also investigated around the esos.elf RTOS firmware. There's a license for that, which I added to my tree. The license basically says: use but do not infect with GPL: https://gitee.com/spacemit-buildroot/buildroot-ext/blob/k1-bl-v2.2.y/board/spacemit/k1/target_overlay/lib/firmware/LICENSE.spacemit_esos. Continuing on kthread issue. LG // Sven-Ola

What happens if your start armbian-resize-filesystem.service manually? IE "sudo systemctl start armbian-resize-filesystem.service" and then check the log for the service?

You can create an extension including something like unset armbian_kernel_config__force_pa_va_48_bits_on_arm64