All Activity

@robertojTheoretically it will, as H618 supports OpenGL and Vulkan. But do not expect the same performance as RK3588. This is off the topic here and you'd better ask someone who share the same chip with you.

Cool! I own this game as well, just didn't test it as I thought atlus put most their games under DRM. Definitely going to try it later. Also found that some games (probably CPU-intensive ones) work better on hangover compared with box64+proton/wine, if only the game was compatible.

Then stick with what you got going on.

But, now that I have a running linux on it, is there another way to flash the android image? I mean, I had to open the box, connect uart to see what's going on and short random resistors on the board to get it in usb burn mode and flash the android image - which didn't work as I mentioned before. I was receiving timeout errors, and after that the board became unresponsive (./update identify 7 - timeout). After a bit of research I found out it could be the usb 3.0 port on the device that I used (since I tried switching to usb 2.0, but I got it in mask rom mode only through usb 3.0 port the last time, and after that too, never on usb 2.0). Anyway, the point is - now that I'm booting from usb, I disconnected uart and closed the board back in it's case. It was a mess, and I'd rather not open it up just to install android to it. I mean, can I do it from a running linux? Or can I just run install-aml? At the end of the road, I could just use it as is - it will boot to usb, regardless of the garbage in the emmc. I know I mentioned I wanted to take advantage of the 32gb emmc, but now I'm just happy it's even alive.

@kingbecher Why do you believe this isn't an Amlogic s905w? Those cpus are also cortex-a53. I see Amlogic references throughout the boot log you posted

sm1 and g12 share the same common dtsi file. Use that aml flash tool along with --soc=g12a and flash the android img. That should bring you back to where you were. That would be a full recovery.

I didn't know g12 and sm1 were compatible enough for flashing - since I realized how easy it is to mess up by using the wrong soc type I grew very meticulous about everything - I just didn't want to brick my box. (after I soft bricked it already:) About the next step: how to run recovery? Could you please explain in more detail, or just point me in the right direction where to look? I mean, I'm really quite new to all of this, SoC linux installs etc, so I don't really understand a big portion of it. P.S. wifi and eth are also working

@user03 For sm1 devices use --soc=g12a Another option which is something I recently had to do with my BPI-CM4 "if I recall correctly, I've also done so on a tvbox i b0rked" is use pyamlboot. sudo pip3 install pyamlboot Short the board and run; sudo boot-g12.py u-boot.bin # if you have a functional u-boot binary This won't actually flash anything, "atleast it didn't in my case?" it will just force the unit to load that boot binary. From there you should be able to hit the SPACEBAR and check ur options using `print` and `help`. Should see options like usbboot, usb_update, etc. Not saying you should use one of these, but... You may be able to find one online or inside the Android img for ur unit. https://github.com/pyavitz/debian-image-builder/tree/feature/files/boot/uboot/ac2xx Anyway. At least you got it booting from USB. Next step would be running a recovery on it.

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.

Sven, I stumbled across this thread last night and have created this account to thank you. After purchasing this board some time ago, it was quite disappointing to discover how lacking software support was. Again, thank you for your fantastic work so far.

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

Hi everyone I Have an different Version of this Clones. The Cpu is has an weird printing. It has S905W engraved but DeviceInfoHW shows an CortexA53. Maybe an H313? Version 1.4 Not booting from SD Card from many Version of armbian tested with an genue Sandisk 16gb. Serial Output on normal Android boot: Have somebody an idea what iam missing ? The Rkdumper tool will not find this device. Thanks

@Werner I re-checked all my patches and custom configurations and performed a clean rebuild. I found clear evidence in the logs that `CONFIG_ARM64_VA_BITS` is being explicitly overwritten during the build process: ### kernel_config_initialize.log --> (9) INFO: Configuring kernel [ linux-rk35xx-vendor ] --> (9) INFO: Using kernel config provided by user [ userpatches/linux-rk35xx-vendor.config ] --> (9) COMMAND: cp -pv /armbian/userpatches/linux-rk35xx-vendor.config /armbian/cache/sources/linux-kernel-worktree/6.1__rk35xx__arm64/.config '/armbian/userpatches/linux-rk35xx-vendor.config' -> '/armbian/cache/sources/linux-kernel-worktree/6.1__rk35xx__arm64/.config' --> (9) INFO: Considering available RAM for BTF build [ 13082 MiB ] --> (9) INFO: Enabling eBPF and BTF info [ for fully BTF & CO-RE enabled kernel ] --> (9) COMMAND: ./scripts/config --disable SECURITY_LOCKDOWN_LSM ... --> (10) COMMAND: ./scripts/config --enable ARM64_VA_BITS_48 ... --> (12) COMMAND: ./scripts/config --set-val ARM64_PA_BITS 48 --> (12) COMMAND: env -i CCACHE_BASEDIR="/armbian/cache/sources/linux-kernel-worktree/6.1__rk35xx__arm64" CCACHE_TEMPDIR="/armbian/.tmp/work-907ace63-1eb7-43dc-ac17-503d457007a8/ccache_tmp" PATH="/usr/bin:/armbian/cache/pip/base/bin:/armbian/.tmp/work-907ace63-1eb7-43dc-ac17-503d457007a8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" PYTHONPATH="/armbian/cache/pip/base/lib/python3.12/site-packages:" DPKG_COLORS=always XZ_OPT='--threads=0' TERM='xterm-256color' COLUMNS='248' COLORFGBG='' CCACHE_DIR='/armbian/cache/ccache' make '-j6' 'ARCH=arm64' 'LOCALVERSION=-vendor-rk35xx' 'CROSS_COMPILE= aarch64-linux-gnu-' 'KCFLAGS=-fdiagnostics-color=always -Wno-error=misleading-indentation ' 'SOURCE_DATE_EPOCH=1768563629' 'KBUILD_BUILD_TIMESTAMP=Fri Jan 16 11:40:29 UTC 2026' 'KBUILD_BUILD_USER=build' 'KBUILD_BUILD_HOST=armbian' 'KGZIP=pigz' 'KBZIP2=pbzip2' olddefconfig HOSTCC scripts/basic/fixdep LEX scripts/kconfig/lexer.lex.c YACC scripts/kconfig/parser.tab.[ch] HOSTCC scripts/kconfig/lexer.lex.o HOSTCC scripts/kconfig/parser.tab.o HOSTLD scripts/kconfig/conf .config:2755:warning: override: reassigning to symbol ARM64_VA_BITS_39 .config:2789:warning: override: ARM64_VA_BITS_48 changes choice state # # configuration written to .config # --> (14) INFO: Kernel configuration [ linux-rk35xx-vendor ] I traced this behavior to the following function in `lib/functions/compilation/armbian-kernel.sh`: function armbian_kernel_config__force_pa_va_48_bits_on_arm64() { if [[ "${ARCH}" == "arm64" ]]; then opts_y+=("ARM64_VA_BITS_48") opts_val["ARM64_PA_BITS"]="48" fi } I manually modified this function (changing `48` to `39`), and the resulting kernel deb finally compiled with `CONFIG_ARM64_VA_BITS=39` successfully. Obviously, modifying the build framework source is not the proper solution. Is this enforcement intended for all arm64 builds? Is there a standard way to bypass this function?

Nevermind, got the answer from here.

If you can get the unit in the proper state by shorting, you can flash an android img or custom one using this tool; https://github.com/natinusala/linux-amlogic-toolkit Other repos that you may find useful: https://github.com/mluis/aml-flash-tool https://github.com/Stane1983/aml-linux-usb-burn

Hi While I thiknk your approach should have worked, a quick search revealed that something similar is done for a different family. Perhaps try this way:https://github.com/armbian/build/blob/9aa6e1e29ec2d397bbe223bebaa93bd13ef79818/patch/kernel/archive/filogic-6.16/patches.armbian/0007-build.sh-add-additional-build-script-config-defconfi.patch#L1909

Description: Hello everyone, I am encountering an issue where kernel configuration changes do not take effect when building an image for the Rock 5B using the Armbian Build system. Environment: Board: Rock 5B Kernel: Vendor Release: Noble Build Mode: Mini Build Tag/Branch: v25.11 Specific Issue: To ensure compatibility with Redroid containers, I need to change the kernel's CONFIG_ARM64_VA_BITS from the default 48-bit to 39-bit. What I have tried: I have attempted the following three methods, but none have worked: Ran the kernel configuration tool to change CONFIG_ARM64_VA_BITS, then copied the generated .config to userpatches/linux-rk35xx-vendor.config. Took the default config/kernel/linux-rk35xx-vendor.config, manually modified/added CONFIG_ARM64_VA_BITS=39 and CONFIG_ARM64_VA_BITS_39=y, and copied it to userpatches/linux-rk35xx-vendor.config. Created a kernel source patch in userpatches targeting arch/arm64/configs/rockchip_linux_defconfig and arch/arm64/configs/defconfig to force CONFIG_ARM64_VA_BITS=39 and CONFIG_ARM64_VA_BITS_39=y. Result: Regardless of the method used, the final Armbian-generated kernel remains at VA_BITS=48. It seems my configuration changes are being overwritten or ignored during the build process. Request: Is there specific logic in the Vendor/RK3588 build configuration that forcibly locks VA_BITS? What is the correct way to modify this parameter for this specific board/kernel combination? Thanks for your help!

Hi, I've read on here that you can apparently switch to a stable edge branch through Armbian Config, but the closest I can find is 'switch to rolling packages repository' and 'distribution upgrade to rolling unstable'. Are either of these correct? I'm running the Ubuntu Noble 6.12 kernel, btw. Many thanks.

@Dangrain There is a paragraph Partecipation and debugging with the suggested operations to let other people help you in a proper way and perhaps improve support for your board in the mainline armbian codebase. You may want to go your own way, but then helping will be much harder.

@HarleyyyuI don't have that exact model of board, mine's a ZQ01-V1.3 for which the unbricking pins are in a different place (but don't worry I figured it out). The issue I'm facing right now is that my frankenstein'd image is in pieces, pieces from two different OSes and Isn't in a single .img file so I'm not sure how to write it using multitool. Any help sure is appreciated.

Please read my reply at https://github.com/torte71/InsideSovolKlipperScreen/issues/8#issuecomment-3796412735 In short: I think the screen on this device is a proprietary smart-device that can't be used as a standard display. Thus KlipperScreen (and any other X or Wayland app) will not be able to run.

I would like to say thank you very much to @sicxnull for the latest images of X96Q V5.1. They work really well and allow me to install HA as well as use it like a PC. You really did a great job!