Active threads

@Sergioclr the H313, H616, H618, and IK316 are essentially the same SoC family. To successfully boot an image, you must match the correct AXP chip (the Power Management IC) and the specific DRAM version used on your board. Essentially, any thread discussing the H616/H618 (excluding older H3/H5/H6 chips) will contain relevant information for these SoCs. PMIC Information: http://linux-sunxi.org/AXP_PMICs DRAM Types: 3: DDR3 4: DDR4 7: LPDDR3 8: LPDDR4 You can try flashing various boot images until one successfully initializes your hardware. (If your box is secure boot enabled You will need to add secure boot modifications posted above.) https://github.com/NickAlilovic/build/releases/tag/20250306 Alternatively, for a more precise approach: Extract your Device Tree (DTS). Identify the specific AXP chip located on your board. Connect a USB-to-UART TTL device to the RX, TX, and GND pins on your board to monitor the boot sequence. https://forum.armbian.com/topic/29794-how-to-install-armbian-in-h618/#findComment-232411 https://forum.armbian.com/topic/29794-how-to-install-armbian-in-h618/page/4/#findComment-187672 https://forum.armbian.com/topic/29794-how-to-install-armbian-in-h618/page/23/#findComment-218660 https://linux-sunxi.org/UART Decompile your Device Tree Blob (DTB😞 dtc -I dtb -O dts -o source.dts source.dtb For a visual reference of a board using these specific chips, check out this hardware breakdown. http://nskhuman.ru/allwinner/krugh618.php?np=3

TL;DR: fsck /dev/sdb1 Looks like something corrupted the drive filesystem. I was able fsck repair the drive, and re-apply the image via armbian-imager. The fact that armbian-imager 'validated' the flashed contents multiple times is where things went sideways. Once i tried to manually delete the contents of the drive, and that failed, it became apparent that the drive had been corrupted. I'm not sure what the 'validation' that armbian-imager does is, though.

@Ducdanh Nguyen probably a real H313 SOC. You know this! You were on the other thread.

I have a 512 MB RAM, 4GB Toshiba NAND PocketCHIP with a custome u-boot supporting USB Booting and decided to test the latest armbian community image for the PocketCHIP (https://github.com/armbian/community/releases/download/26.2.0-trunk.668/Armbian_community_26.2.0-trunk.668_Pocketchip-sd_trixie_current_6.18.20_minimal.img.xz) Boot seems to start fine with all kernel files load confirmed by u-boot output (vmlinuz, ramdisk dtb, etc) but then it goes mute while starting the kernel @TheSnowfield, you are listed as the pocketchip board maintainer (thanks a lot for your contribution! 🙏), any ideas of what am I missing? Do you have a suggestion for a working build? Thanks! Serial UART output: U-Boot SPL 2016.01-00115-g5f814bb (Dec 09 2016 - 23:00:24) Fuel Gauge: 77% Battery Voltage: 3776mV DRAM: 512 MiB CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from NAND U-Boot 2021.10-rc5+ (Oct 21 2021 - 14:43:51 -0500) Allwinner Technology CPU: Allwinner A13 (SUN5I) Model: NextThing C.H.I.P. I2C: ready DRAM: sunxi SPL version mismatch: expected 3, got 1 512 MiB NAND: 4096 MiB Loading Environment from nowhere... OK Setting up a 480x272 lcd console (overscan 0x0) In: serial Out: vidconsole Err: vidconsole sunxi SPL version mismatch: expected 2, got 1 starting USB... Bus usb@1c14000: USB EHCI 1.00 Bus usb@1c14400: USB OHCI 1.0 scanning bus usb@1c14000 for devices... 5 USB Device(s) found scanning bus usb@1c14400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 DIP: PocketCHIP (0x1) from Next Thing Co. (0x9d011a) Found 1 extension board(s). Device 0: Vendor: Mass Rev: 1.00 Prod: Storage Device Type: Removable Hard Disk Capacity: 14832.0 MB = 14.4 GB (30375936 x 512) ... is now current device Scanning usb 0:1... Found U-Boot script /boot/boot.scr 5475 bytes read in 4 ms (1.3 MiB/s) ## Executing script at 43100000 U-boot loaded from NAND 154 bytes read in 4 ms (37.1 KiB/s) sun5i-r8-chip.dtb: No match Load fdt: /boot/dtb/sun5i-r8-chip.dtb 14474151 bytes read in 780 ms (17.7 MiB/s) 10539688 bytes read in 557 ms (18 MiB/s) Found mainline kernel configuration 25215 bytes read in 9 ms (2.7 MiB/s) 2146 bytes read in 7 ms (298.8 KiB/s) Applying kernel provided DT fixup script (sun5i-a13-fixup.scr) ## Executing script at 45000000 Kernel image @ 0x42000000 [ 0x000000 - 0xa0d2a8 ] ## Loading init Ramdisk from Legacy Image at 43400000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 14474087 Bytes = 13.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 49232000, end 49fffb67 ... OK Loading Device Tree to 491c3000, end 49231fff ... OK Starting kernel ...

Try sysctl vm.overcommit_memory=1 QEMU is probably trying to commit lots of virtual memory, but not using it. Don't know why it behaves like this.

Our multimedia engineering team delivered major improvements to GStreamer 1.28: hardware acceleration and zero-copy pipelines, HDR and color support for Wayland, AI inference integration, plus critical codec and RTP/WebRTC interoperability fixes. View the full article

OK I see, now I remember, HAOS aarch64 has been there for download for a long time, I even recommended it to some one on another forum who also only saw the Intel VM, but as I indicated, is a bit hidden on github: https://github.com/home-assistant/operating-system/releases/ and direct latest link: https://github.com/home-assistant/operating-system/releases/download/17.2/haos_generic-aarch64-17.2.img.xz I personally don't want the Proxmox stuff indicated by Markus, I just use the standard packages available In Debian (or Opensuse) for years, on both Intel and Arm. Like indicated install virt-manager. It is manual install, but at least then more control. I used/use a mix of LVM based block devices and also just raw images (like unxz the one referenced). I see on RPi4 I have the HAOS VM configured with 2 vCPUs and 1GB RAM. On RK3588, so OPi5+, you will need CPU pinning if you use the vendor kernel (6.1) as it does not support mixing big and little (Cortex-A76 and Cortex-A55). Or use just 1 vCPU for the VM, then de-facto no mixing. Mixing is no problem with mainline based kernel, so then you can just use 8 vCPU's if you want. I currently have my NanoPi-R6C running with kernel 6.19.10+deb14-arm64-16k (from Debian sid) and works fine with VM's and all 8 cores.

As a moderator having watched this thread, I'm going to close it down, as I don't think anything else productive will be said at this point. However I do want to thank both @bedna and @eselarm for their time and effort to help. Armbian appreciates all the volunteers who make these forums possible.

apply this patch for a working wifi: diff --git a/extensions/radxa-aic8800.sh b/extensions/radxa-aic8800.sh index e3e99eaa8..7ab721353 100644 --- a/extensions/radxa-aic8800.sh +++ b/extensions/radxa-aic8800.sh @@ -10,7 +10,7 @@ function extension_finish_config__install_kernel_headers_for_aic8800_dkms() { function post_install_kernel_debs__install_aic8800_dkms_package() { - if linux-version compare "${KERNEL_MAJOR_MINOR}" ge 6.20; then + if linux-version compare "${KERNEL_MAJOR_MINOR}" ge 7.1; then display_alert "Kernel version is too recent" "skipping aic8800 dkms for kernel v${KERNEL_MAJOR_MINOR}" "warn" return 0 fi

I have tested the latest build (26.2.0-trunk.668) and found that USB 3.0 is still not operational. Has anyone been able to get this working?

I have an H50-labeled tv box with a different board (T98-3318-V2.3) but with exactly the same problem - no HDMI even though all the software debug traces show that everything video-related gets called and works. I first tried to make it work 5 years ago and failed and a few months ago I revisited it just to see if I can make it work now in the age of AI. I made a really deep dive into reverse engineering it. I rooted the original Android firmware and dumped anything I could, extracted and analyzed with Ghidra the vendor u-boot and kernel (wasn't particularly helpful) and finally managed to execute the u-boot binary in Renode by emulating a lot of hardware stuff with code or by simply replacing functions with successful returns all the way to the point of u-boot displaying the splash screen and with various hooks and warnings about peripheral accesses I collected a comprehensive trace of everything that u-boot was doing, and in that trace, the AI noticed a certain GPIO access and suggested replacing this vcc-host-vbus { compatible = "regulator-fixed"; enable-active-high; gpio = <0x74 0x00 0x00>; pinctrl-names = "default"; pinctrl-0 = <0x76>; regulator-name = "vcc_host_vbus"; regulator-always-on; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; vin-supply = <0x77>; phandle = <0x100>; }; with this vcc-display-en { compatible = "regulator-fixed"; gpio = <0x74 0x00 0x01>; pinctrl-names = "default"; pinctrl-0 = <0x76>; regulator-name = "vcc_display_en"; regulator-always-on; regulator-boot-on; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; vin-supply = <0x77>; phandle = <0x100>; }; in the standard rk3318-box.dts which made HDMI work.

Hello, I made a buld with the vendor kernel for mekotronics R58SV2, and build ubutu desktop Gnome. I definately have no HW decoding since with fhd .mp4 h264 videos the beast runs on 100% cpu all cores what did I wrong? Help appreciated

After installing the latest update, my 3D printer warns about outdated instructions in the MCU and asks to recompile and flash it. What should I do?

This does not support f2fs I guess; standard in U-Boot is only FAT and Ext4 Some never U-Boot builds also include Btrfs. f2fs I have not seens working, but you will need to build a custom u-boot yourself then. Other option is at add Armbian argument to use an extra bootfs, tha will then be FAT or Ext4, so you can still use f2fs for rootfs. I would make U-Boot understand Btrfs and then use Btrfs for rootfs, as for several boards/platforms that is already default (likely only when you use newer/edge/mainline U-Boot).

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

@Werner I imagine there are plenty of people here who could help solve similar problems. In theory, I could provide a pair of an old RPI (master) and a 4A (slave), with the slave serial connected to the master and power controlled via the GPIO, and they are also on the same VLAN. However, if something goes wrong it needs control to the slave's SD card, all I've found is an SD card extender, and it needs something like an emulator that connects to the master via the same USB/SPI.

First: https://forum.armbian.com/terms Second: Provide full logs

Hey tparys! Thank you very much for your reply and apologies for my delay getting back to you. I haven't had much time to play with this board, but lately I've managed to do some very good progress. Basically I've got Armbian 20 Bullseye working with kernel 6.19. that was a victory! Versions that work/don't: [WORKS] Armbian_20.07_Arm-32_bullseye_current_5.7.7_desktop.img (From a MiQi board) [NOPE] Armbian_25.11.1_Tinkerboard_bookworm_current_6.12.58-homeassistant.img [NOPE] Armbian_25.11.1_Tinkerboard_noble_current_6.12.58_minimal.img [NOPE] Armbian_25.11.1_Tinkerboard_trixie_current_6.12.58_minimal.img [NOPE] Armbian_26.2.0-trunk.370_Tinkerboard_noble_current_6.18.8_xfce_desktop.img [NOPE] Armbian_26.2.1_Tinkerboard_trixie_current_6.18.8_minimal.img Armbians 25 up, some times hangs at Starting Kernel, and majority of the times stops at Loading Ramdisk, all of them tested with most of the DTBs provided The android that runs on the other working board has a kernel with version 4.4 Havent test that because I believe it stops earlier than that I have extracted the DTB from the working Android and got a frankenstein EVB DTS working with some of the features. So far I've got working: *4Cores *2GB Ram *Wifi (using rtw8723d_fw.bin ) *Status LED What doesn't work for sure: -Ethernet -FE2.1 USB Hub 2.0 Untested: ? LVDS 1/2 Panel ? EDP 1/2 Panel ? Speaker ? MIC ? SIM Card Module (Attached to the FE2.1 Hub, so defo not working) And maybe some other peripherals that I was not able to test. I'm still to make the FE2.1 USB Hub work as the 4 only USB physical ports are not working. Also ETH has an issue on stmmac that returns the reset value. and this was merged recently to the kernel. (I'm trying to build v6.19 from source with my patch, but thats being painful too ) Here is my stmmac patch: diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 01ede5148163..9f0ee9ea96fa --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -3208,8 +3208,7 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv) ret = stmmac_reset(priv); if (ret) { - netdev_err(priv->dev, "Failed to reset the dma\n"); - return ret; + netdev_warn(priv->dev, "Failed to reset the dma, device will work with reduced throughput\n"); } I have also attached my current DTS built on top of the EVB version based on the Android with logs from both. Once again, thank you very much for your help! Best Regards, Mauricio. Armbian 20 Bullseye booting log.txt Android Boot Full log.txt android_check.dts rk3288-evb-rk808-armbian-fixed36.dts

Finally managed to restore the box to stock official Android firmware, everything works as expected. I also tested a firmware for the H96 Max M1, with this one the WiFi is not working, they seem to use a different wifi chip. Any recommendations on where to start with flashing Armbian on this device?

OMV 8+ doesn't support 32bit architectures anymore (including Helios4). https://forum.openmediavault.org/index.php?thread/58798-helios4-omv-8/ Given it seems to be stuck on kernel 6.6, it does feel like it's on life support unfortunately.

just go threre: https://forum.friendlyelec.com/viewtopic.php?f=93&t=4691

The initrd might be missing needed drivers for you to continue getting console output. Kind of a pain to troubleshoot that. The kernel I linked above is configured so that it should actually boot with no initramfs at all (though that isn't recommended). It obviously can't hurt to try a different PSU if you have one. The device also will do PoE (on the WAN port I believe) which is a nice little feature so you could try that too. The device tree I use comes directly from the linux tree. It is built into U-Boot and then U-Boot provides it to the kernel via standard location as specified in UEFI. It is entirely possible that older kernels might be unhappy with a newer device tree but you really shouldn't be having any issues with 6.18 and newer but they do need to be configured to load the device tree from UEFI. I think that kernel config option is CONFIG_OF.

This week’s Armbian development saw significant enhancements across hardware support and system functionality. The Arduino UNO Q was officially added, along with new firmware and flash binaries for the QRB2210 and QCM2290 variants. HDMI CEC support was introduced for Rockchip RK3588/RK3576 SoCs, while panel compatibility expanded with updates for Raspberry Pi and Hardkernel ODROID-Vu8S. Key kernel improvements included a bump to version 7.0-rc6 and rewritten patches for Rockchip64-6.18. The release also featured workflow hardening, exclusion of unsupported boards, and fixes for USB-C OTG mode on Odroid-M2. These updates collectively strengthen Armbian’s platform stability and broaden its device coverage. ChangesAdd Arduino UNO Q. by @igorpecovnik in armbian/armbian.github.io#268Add firmware for Arduino UNO Q (QRB2210/QCM2290). by @SuperKali in armbian/firmware#123Add HDMI CEC support to Rockchip RK3588/RK3576 SoCs. by @chaitan3 in armbian/build#9622Agatti: add flash binaries for Arduino UNO Q (QRB2210). by @SuperKali in armbian/qcombin#1Arduino logo. by @igorpecovnik in armbian/armbian.github.io#269ch13726a: Added missing MIPI_DSI_MODE_VIDEO. by @kay-lambdadelta in armbian/build#9621config: rockchip64: build Motorcomm YT6801 drivers built-in for OOB Ethernet. by @c127dev in armbian/build#9625drm: add support for rpi panel v2. by @ackPeng in armbian/linux-rockchip#465Exclude end-of-support boards from armbian-images.json. by @igorpecovnik in armbian/armbian.github.io#271Harden data-update-partners workflow. by @igorpecovnik in armbian/armbian.github.io#270mainline: bump edge to 7.0-rc6. by @EvilOlaf in armbian/build#9618Odroid-M2: Add support for Hardkernel ODROID-Vu8S panel. by @mlegenovic in armbian/build#9627Odroid-M2: Fix USB-C port in OTG mode. by @mlegenovic in armbian/build#9633Remove radxa-dragon-q6a from targets-release-nightly blacklist. by @igorpecovnik in armbian/armbian.github.io#267rockchip-vendor: CONFIG_BT_HCIBTUSB=m. by @vidplace7 in armbian/build#9628rockchip64-6.18: rewrite kernel patches against 6.18.21. by @EvilOlaf in armbian/build#9629SpacemiT: Disable k1-usb: add disconnect function support. by @pyavitz in armbian/build#9620View the full article

Thanks for the info to try other options 🙂 Thanks for the tip, I'll try other options 🙂 It worked for: odroid-c4 ... basically, the settings are the same as for the OrangePI3LTS, I'm talking about connecting cables to a 40x2 / 20x2 LCD. The diagram for the BananapiM2pro is as follows: My Winstar 40x2 OLED LCD compatible with drivers: hd44780 / driver: WS0010 is detected in the system as: 3f .................................. sudo i2cdetect -y 0 [sudo] kris: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3f 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- .................................. You can also enter the appropriate values yourself in the file: sudo nano /boot/armbianEnv.txt verbosity=1 console=both overlay_prefix=meson fdtfile=amlogic/meson-sm1-bananapi-m2-pro.dtb rootdev=UUID=a4fb8074-c453-45da-ab31-4d61dca46cfa rootfstype=ext4 overlays=sm1-odroid-c4-i2c0 sm1-odroid-c4-i2c1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u regards