Nick A

@billymore The "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" error indicates that the Linux kernel could not locate or mount the root file system during startup. . This is commonly caused by a missing or corrupted initial RAM filesystem (initramfs), an incorrect root= boot parameter write 0x4ff00000 rootfs.cpio.lzma.uboot

@Jain Ziad I'm currently working on hardware acceleration, though I can't say yet if it will outperform the official Radxa builds since it uses the same drivers. I'll keep the community updated on the results.

@marcosdsdba I would compile this on the box. Install kernel headers. Post the errors you are getting. https://github.com/NickAlilovic/build/releases/download/20250306/linux-headers-edge-sunxi64_25.05.0-trunk_arm64__6.12.11-S62b2-Da873-P8a5c-C1abcH02eb-HK01ba-Vc222-B9bbb-R448a.deb

@sicxnull

@Kevin su Excellent work! Porting the SV6256P driver all the way to kernel 6.12 is a huge achievement. Most users usually just give up and plug in a USB Wi-Fi adapter to avoid the headache of legacy drivers.

@marcosdsdba

@zcrself Your board might be missing some components for UART to work properly. Have you tested your TTL to USB adaptor on other boards to see if it works?

@marcosdsdba the only driver that works is from kernel 4.4. Unless someone figures out a way to port this to a modern kernel, your only option is to use a usb wifi adapter.

@zcrselfhttps://github.com/NickAlilovic/build/releases/tag/Mainline try this image.

@alexc Thanks for your patch and suggestions. It turns out the DRM heap isn't strictly required for DisplayPort Alt mode, but I'm sure it resolved other issues within the 6.6 kernel. I assumed it was the DRM heap because it was the only missing kernel configuration option. I suppose the kernel doesn't report missing source code drivers, or I simply didn't notice. It’s great to have your help getting this Armbian BSP build function. At least until a mainline version is released

@Brow Mosh AI is wrong. Mainline supports - Your PMIC - Your DRAM timing - Your HDMI (Patches have been around for years but not accepted in mainline yet. I included it in my builds.) - Your regulators Supported in mainline but might need some dts changes. - Your weird SD wiring - Your eMMC layout ( Could be a gpio# issue) If you are booting into the kernel then I believe your SD is somewhat working. Maybe you need few tweaks to your dts or your DRAM settings are off. A failing or cheap SD card could also be your issue. Kernel boots Reaches userspace Shows login banner Without a DTS I can’t help you much. Also, can you post some boot logs. FEL over USB is your last option. It is possible. But I don't think your AI model will help much. I noticed with some AI models they will encourage you to quit when they can't find the correct information. The owner of the AI model wants you to pay for their deep learning version.

@Bones558 I made a custom U-Boot to fix the boot splash, but so far it only works on micro-HDMI. This patch fixed the U-Boot splash for HDMI on the A7A. It also fixes the splash on the A7Z via micro-HDMI. However, when using DisplayPort Alt Mode, there is a different disp0_hdmi0 node that I need to apply the fix to. I'll play around with it tomorrow.

@marcosdsdba Can you take a picture or just tell us the Wi-Fi chip you have on your board?

@Rodrigo Campos The 20251226 build uses a newer kernel, but audio through the A/V out port is currently broken. I haven't had time to fix it yet, so if you don't need that port, feel free to use this version.

@Robin Hoo I don't have UFS so I can't test it. But I think if you add enable_extension "ufs" to https://raw.githubusercontent.com/NickAlilovic/build/refs/heads/Radxa-A7A/config/boards/radxa-cubie-a7a.csc it might work. git clone https://github.com/NickAlilovic/build.git --branch Radxa-A7A cd build echo 'enable_extension "ufs" ' >> config/boards/radxa-cubie-a7a.csc or echo 'enable_extension "ufs" ' >> config/boards/radxa-cubie-a7z.csc ./compile.sh

@billymore I was able to detect my transpeed box using the toothpick trick. Here are some links that might help figure it out. Maybe even going on irc and asking the sunxi guys. https://oftc.catirclogs.org/linux-sunxi/search?q=tx1 https://groups.google.com/g/linux-sunxi/c/OrktE3duFDA

@billymore https://linux-sunxi.org/Tanix_TX1 Use a toothpick or any other non-conductive stick to push the button inside the A/V connector when powering up the box. Connect a USB-A/USB-A cable to the only USB port and a host PC. https://www.slashinit.com/posts/boot-uboot-orange-pi-zero-2-using-usb-mode/ https://linux-sunxi.org/FEL/USBBoot

@Brow Mosh Have you tried extracting your arndroid dts to find the gpio settings for emmc? The only other thing I can suggest at this point is trying mainline U-Boot booted over USB (FEL). Booting mainline U-Boot via FEL completely bypasses SD.

@Bones558 Try these images. No boot splash on a7z yet. I'll look into it when I have time. https://github.com/NickAlilovic/build/releases/tag/Radxa-a7a-a7z-v0.6

@Kevin su Armbian uses one kernel config for both server and desktop images. You could compile your own server image and enable this option. I can help you with build errors. SBCs often have relatively weak single-core performance compared to x86 servers. Full preemption prevents a single long-running kernel task from causing noticeable "stutter" in network responses or shell interaction.

@Kevin su I wouldn’t call fully preemptive scheduling “not suitable” for server use, especially on ARM SBCs. On modern kernels, CONFIG_PREEMPT=y has low overhead and is widely used by Armbian even for headless/server images. For a purely headless system under sustained, throughput-focused load, CONFIG_PREEMPT_VOLUNTARY can be a reasonable alternative, but the difference is usually small. It’s more a tuning preference than a correctness issue.

@Kevin suIf the build error was due to a base files installation error, rerun the build with the same options. It should complete the image compilation. I haven't found a proper fix yet, but rerunning the build should resolve it. I'll update the server image soon.

@Bones558 @alexc I noticed that a few USB-C drivers are missing in the 6.6 kernel. While the Makefile and Kconfig files are present, they have changed. In the 5.15 BSP, the bsp/drivers/usb/typec/tcpm directory contains tcpci_et7304.c and tcpci_husb311.c, but in 6.6, this directory is empty. 6.6: bsp/drivers/usb/typec/tcpm$ ls Kconfig Makefile 5.15: bsp/drivers/usb/typec/tcpm$ ls Kconfig Makefile tcpci_et7304.c tcpci_husb311.c

@BoringName Looks right. You can decompile the dtb into a dts.. edit the dts and compile it again. You will find it in the /boot directory. dtc -I dtb -O dts -o mainline_edit.dts your_mainline_file.dtb dtc -I dts -O dtb -o modified_mainline.dtb mainline_edit.dts

If this is AW869A chip then it uses the AIC 8800 Linux Driver. My X98H TV box has a AIC8800 chip in it. https://linux-sunxi.org/Wifi#AW869A AW869A The AW869A is a highly integrated module with Dual band WiFi6 combination solution to support 1 × 1 IEEE 802.11b/g/n/ac/ax WLAN standards It uses the aic8800 firmware. A driver can be found at AIC 8800 Linux Driver. You'll need to compare the GPIO settings. Your Android dts uses HEX the mainline kernel is using DEC. https://www.rapidtables.com/convert/number/hex-to-decimal.html?x=12 rfkill { compatible = "allwinner,sunxi-rfkill"; status = "okay"; chip_en; power_en; pinctrl-0 = <0x63>; pinctrl-names = "default"; phandle = <0xcc>; wlan { compatible = "allwinner,sunxi-wlan"; clocks = <0x0e 0x04>; clock-names = "osc32k-out"; wlan_busnum = <0x01>; wlan_power; wlan_regon = <0x23 0x06 0x12 0x00>; wlan_hostwake = <0x23 0x06 0x0f 0x00>; wakeup-source; phandle = <0xcd>; }; bt { compatible = "allwinner,sunxi-bt"; clocks = <0x0e 0x04>; clock-names = "osc32k-out"; bt_power; bt_rst_n = <0x23 0x06 0x13 0x01>; phandle = <0xce>; }; }; btlpm { compatible = "allwinner,sunxi-btlpm"; status = "okay"; uart_index = <0x01>; bt_wake = <0x23 0x06 0x11 0x00>; bt_hostwake = <0x23 0x06 0x10 0x01>; wakeup-source; phandle = <0xd0>; }; Mainline dts: https://github.com/NickAlilovic/build/blob/666dc0fabd8a284ccf50d784f6bd0bf948dd073d/patch/kernel/archive/warpme-6.12/2001-arm64-dts-allwinner-h618-add-x98h.patch#L87-L95 https://github.com/NickAlilovic/build/blob/666dc0fabd8a284ccf50d784f6bd0bf948dd073d/patch/kernel/archive/warpme-6.12/2001-arm64-dts-allwinner-h618-add-x98h.patch#L182-L200 https://github.com/NickAlilovic/build/blob/666dc0fabd8a284ccf50d784f6bd0bf948dd073d/patch/kernel/archive/warpme-6.12/2001-arm64-dts-allwinner-h618-add-x98h.patch#L278-L297 The specific values <0x23 0x06 0x12 0x00> generally map to: 0x23: The controller or bank ID: pinctrl@300b000 { phandle = <0x23>; 0x06: The specific GPIO pin number: In Allwinner's pinctrl driver, banks are 32 pins wide. The formula is: (Bank_Letter_Index * 32) + Pin_Number 1. The Bank Index Map Bank Index PA 0 PB 1 PC 2 PD 3 PE 4 PF 5 PG 6 PH 7 PI 8 0x12: The active-high/low flags or drive strength. In the 3-cell GPIO format used by Allwinner (sunxi), the third cell (e.g., 0x12) is a bitmask that defines the electrical properties of the pin. To decode 0x12 (which is binary 0001 0010), you break it down into bits: 1. Bitmask Breakdown for 0x12 Bit 0 (0x01): Active Polarity. 0 = Active High. 1 = Active Low (Our bit 0 is 0, so this is Active High). Bit 1 (0x02): Open Drain / Open Source. 0 = Push-Pull. 1 = Single-ended/Open-Drain (Our bit 1 is 1, so this is Open-Drain). Bit 4 (0x10): Internal Pull-up. 0 = No pull-up. 1 = Pull-up Enabled (Our bit 4 is 1, so this is Pull-up Enabled). Summary of 0x12: This pin is configured as Active High, with an Open-Drain output and an internal Pull-up resistor enabled. 0x00: Reserved or additional configuration. In Allwinner-based systems (like the H6 or H616), this value is defined in the GPIO controller's device tree binding documentation within the Linux kernel source code. The structure is documented in the kernel under Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml