Could you please tell me how to configure my own UBOOT so that the console boots from a flash drive? Is there any wiki information on this? When I loaded various Armbian versions onto the flash drive, the memory wouldn't initialize... U-Boot SPL 2025.04 (Apr 19 2026 - 19:49:57 +0200) DRAM:This DRAM setup is currently not supported. resetting ... U-Boot SPL 2025.04 (Apr 19 2026 - 19:49:57 +0200) DRAM:This DRAM setup is currently not supported. resetting ... U-Boot SPL 2025.04 (Apr 19 2026 - 19:49:57 +0200) DRAM:This DRAM setup is currently not supported. resetting ... U-Boot SPL 2025.04 (Apr 19 2026 - 19:49:57 +0200) DRAM:This DRAM setup is currently not supported. resetting ... Category Parameter Log Value What it is and what it's for Processor (SoC) Model sun50iw9 This is an Allwinner H616. Specified in the build configuration. Memory (DRAM) DRAM Type 3 (DDR3) Memory type. DRAM SIZE 2048 MB Memory capacity. DRAM CLK 600 MHZ Memory frequency. para1 30fb Key timing parameter. para2 8000000 Key configuration parameter. dram_tpr13 6041 Another timing parameter. Power Management Unit (PMU) PMU AXP1530 Critical for stability! Requires driver or compatibility with AXP313. Integrated Memory MMC MMC 5.0, 15032 MB eMMC type and size. Ethernet No ethernet found No Ethernet. We work only via Wi-Fi. U-Boot SPL 2024.01-armbian-2024.01-S866c-P6135-Ha9af-V6d37-Bda0a-R448a (Sep 19 2024 - 19:48:11 -0400) This DRAM setup is currently not supported. resetting ... U-Boot SPL 2024.01-armbian-2024.01-S866c-P6135-Ha9af-V6d37-Bda0a-R448a (Sep 19 2024 - 19:48:11 -0400) This DRAM setup is currently not supported. resetting ... U-Boot SPL 2024.01-armbian-2024.01-S866c-P6135-Ha9af-V6d37-Bda0a-R448a (Sep 19 2024 - 19:48:11 -0400) This DRAM setup is currently not supported. resetting ...

Hello friends. I ask for help in creating firmware with TOC0. Unfortunately, I once launched Android firmware from a Teclast tablet on my A7A board, and apparently eFuse burned out. Now standard firmware with eGON.BT0 will not run on this board. Or tell me where to fix it so that the firmware from the sources is compiled with TOC0.

What is your plan with that camera? My latest try with raspbian (armv6) trixie based failed w.r.t. V4L2. So that is with start.elf, not start_x.elf. The latter works fine on bookworm based raspbian for camara v1. Camera v3 never worked with legacy firmware mode (start_x=1), so needs libcamera. For easy handling, the latest RPL variant of libcamera named rpicam should work, but then you'll be essentially back to RaspberryPiOS. If you have standard Debian Trixie based, all that modified libcamera is not there and more important, you will have other firmware files (bootcode.bin start.elf fixup.dat). Armbian takes the version from Ubuntu AFAIK, Debian is yet another version as is the latest from RaspberryPiOS (64-bit patched Debian or 32-bit patched and re-compiled Raspbian). The package name is raspi-frmware, check which versions there are with sudo apt list -a raspi-frmware and in addition, the 3 files themselves, I did timestamp or suffix them with sha256sum in the past on order to keep track of the various ones delivered for various OSses and images. I assume the Armbian kernel is compiled from same RPi kernel tree as RaspberryPiOS, so overlays for the v3 camera should be there and functionally the same. I currently have 1 camera v1 base RPI3B+ running, still bookworm, but I might boot it with Debian Trixie/Sid and see what mainline libcamera does. Probably then Armbian bcm2711 edge kernel, at least something that provides overlays as Debian kernels have almost none, at least not for camera sensors.

Hello, friends. After a long time, I managed to extract and compile a DTB file from this console. What version of Armbian should I use to run this technological marvel? I'm attaching the DTB file and logs before booting from a flash drive; maybe it'll be useful to someone... h616.txtu-boot-sunxi-with-spl.binsun50iw9.dtb

There is supposed to be a package that automatically handles building a (presumably patched) version of the kernel module for this wifi/bt chip, called `aic8800-usb-dkms`, but for some reason, a kernel upgrade doesn't auto-trigger it. During the last kernel upgrade, I was able to get it working by manually doing `sudo dpkg-reconfigure aic8800-usb-dkms`, but that also does not work since 26.5.1, as it gives Deleting module aic8800-usb-4.0+git20250410.b99ca8b6-3 completely from the DKMS tree. Loading new aic8800-usb-4.0+git20250410.b99ca8b6-3 DKMS files... Building for 6.18.2-current-qcs6490 Building initial module for 6.18.2-current-qcs6490 Error! Bad return status for module build on kernel: 6.18.2-current-qcs6490 (aarch64) Consult /var/lib/dkms/aic8800-usb/4.0+git20250410.b99ca8b6-3/build/make.log for more information. And that file basically says (a bunch is redacted for brevity): DKMS make.log for aic8800-usb-4.0+git20250410.b99ca8b6-3 for kernel 6.18.2-current-qcs6490 (aarch64) Sat Jun 20 06:36:14 PM PDT 2026 make: Entering directory '/usr/src/linux-headers-6.18.2-current-qcs6490' make[1]: Entering directory '/var/lib/dkms/aic8800-usb/4.0+git20250410.b99ca8b6-3/build/USB/driver_fw/drivers/aic8800' warning: the compiler differs from the one used to build the kernel The kernel was built by: aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0 You are using: gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 ... gcc: error: unrecognized command-line option ‘-fmin-function-alignment=8’; did you mean ‘-flimit-function-alignment’? gcc: error: unrecognized command-line option ‘-fmin-function-alignment=8’; did you mean ‘-flimit-function-alignment’? make[4]: *** [/usr/src/linux-headers-6.18.2-current-qcs6490/scripts/Makefile.build:287: aic_load_fw/aic_txrxif.o] Error 1 ... Apparently, the kernel is now built with gcc 14 (which matches the default in Debian Trixie images but not Ubuntu Noble images which have gcc 13). Not sure how to resolve that inconsistency. 1. Install & replace gcc 13 with gcc 14 (just installing won't work as this dkms module build doesn't respect CC env vars); not sure if this will break other things in Ubuntu 24.04 2. Rebuild the kernel with gcc 13; same issue will re-occur on the next kernel upgrade 3. Or something else Just out of curiosity, did you have to mess around with gcc versions to get it to compile (or are you using Debian Trixie images)?