Thank God. I had the same problem as you. It seems like the only way is to write the Armbian boot disk from another system. I’ve been struggling with it for a long time and kept getting into BusyBox. I’ll try your method in a bit.

Chips: Amlogic S805 SOC Hynix H5TQ4G63AFR-PBC - DDR3 RAM -2x IP101GR - 10/100Mbps transceiver MT29F64G08CBABA - NAND Flash Memory RTL8189ETV - Wifi module

@Rodrigo Campos have you tried my latest images? There’s a new patch for dram detection.

It sounds like you're having a bit of a tough time getting that LCD screen to work with your Orange Pi. The fact that the manufacturer only provides drivers for Arduino and RP2040 is definitely limiting, but there are a few things you can try to get it up and running. Check the display's controller chip: The key to getting an LCD screen to work with any board is knowing what controller chip the screen uses. Often, drivers are not provided for specific boards, but if you can identify the chip (it could be something like an ILI9341, ST7789, etc.), you can search for libraries or drivers that support it on Linux-based systems like your Orange Pi. Linux Framebuffer or SPI Libraries: If it’s an SPI-based LCD, you might be able to use Linux framebuffer support or libraries like fbcp (framebuffer copy) or fbtft (framebuffer to TFT) which are often used for connecting LCDs to Raspberry Pi-like devices. These libraries could potentially work with your Orange Pi if the wiring is correct. Using Klipper with an LCD: Since you're trying to use this for a Klipper setup, check if there are any custom firmware or configurations in the Klipper community for connecting LCD screens to Orange Pi devices. Sometimes, other users will have created patches or drivers specifically for non-standard setups. Try finding alternative drivers: Even if the GitHub repository you found didn’t work, check if there are forks or alternative branches of that repository. It’s also worth checking out other forums or user groups that focus on 3D printing or Orange Pi setups. You might find someone who has already solved this issue. Wiring Check: Make sure that your wiring matches the expected configuration for your board. Sometimes, the issue can be as simple as a misconnected pin. Hope this helps! Let me know what controller the screen uses or if you need help with any specific steps.

Found an appropriate workaround: Add the `brcmfmac_wcc` module to `/etc/initramfs-tools/modules`, and the wireless interface will be instantiated during initramfs loading and the netplan generator won't be confused by its absence. Also found another issue where the extra `brcmfmac43456-sdio.clm_blob` firmware file isn't properly registered by the module code, so mkinitramfs skips it. That's inherited from the Raspberry Pi firmware files which introduced the extra `clm_blob`. I filed it for the Pi kernel here: https://github.com/raspberrypi/linux/issues/6828, but the same issue affects the Armbian kernel + firmware combination. The fix is either a kernel patch or an initramfs hack like the following hook: #!/bin/sh -e # Copy missing firmware files for brcmfmac driver PREREQ="" prereqs () { echo "${PREREQ}"; } case "${1}" in prereqs) prereqs; exit 0 ;; esac ; . /usr/share/initramfs-tools/hook-functions echo "Copying missing firmware files for brcmfmac..." cp /lib/firmware/brcm/brcmfmac43456-sdio.clm_blob ${DESTDIR}/lib/firmware/brcm/ The hack is unaware of any firmware file platform variants like `radxa,zero` or `radxa,rockpi4b` and such - it just turns out the `brcmfmac43456-sdio.clm_blob` file doesn't have any.