All Activity

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.

Has anyone activated the ov13855 camera on Orange Pi 5 (kernel 6.1.x)? If so, can you share your experience?

On Armbian 25.2.1, I can't find package tags. In contrast, on a pure Debian host (non-armbian), the command "apt-cache show gcc" says in part: Tag: devel::compiler, devel::lang:c, devel::library, implemented-in::c, interface::commandline, role::devel-lib, role::metapackage, role::program, suite::gnu, works-with::software:source I'd also like to see tags on Armbian so I can search for packages based on their tags. Thanks.

What steps are you doing to get this working manually? What is the overlay file you are loading (trying to load), and where does that file exist on the system?

armbianEnv.txt seem is not being loaded. I am trying to get i2c-1 up and I have it checked in armbian-config but all I get is i2c-2 showing. Loading the overlay manually gets the device to show up but not after a reboot. What am I doing wrong? ChatGPT sends me on a wild ride trying to fix. /boot/armbianEnv.txt rootfstype=ext4 overlays=i2c1 i2c-rtc ds3231 ds1307 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

5) Control a flight vehicle with real time input and outputs. [jgauthier@gamma build]$ diff -u config/kernel/linux-sunxi64-edge.config userpatches/linux-sunxi64-edge.config [jgauthier@gamma build]$ I'm not sure why it's expected that those would be different. I made the configuration with 'make menuconfig' and then copied to to userpatches. I did this because, at the time, I thought it was being overwritten. It was, but that was due to armbian-kernel.sh.

1) Play (decode) video audio 2) Read the status of multiple sensors at regular intervals 3) Generate pulses on GPIO 4) Transmit the packet at the right time over Ethernet, UART ... 5) .......? diff -u config/kernel/linux-sunxi64-edge.config userpatches/linux-sunxi64-edge.config

I have exactly the same issue. Cannot boot after upgrade, also newly flashed image won't boot with exactly the same trace. I compiled latest upstream U-Boot v2025.04 as described here (Pre-Built FIP variant). https://docs.u-boot.org/en/latest/board/amlogic/odroid-c2.html Then I patched Armbian image with latest U-Boot. dd if=u-boot.bin.sd.bin of=Armbian_25.2.1_Odroidc2_bookworm_current_6.12.13_minimal.img conv=notrunc bs=512 skip=1 seek=1 And that works for me, system boots just fine

Looks like 23.5.1 with U-Boot 2022.7 works as well (23.5.1 Bookworm 6.1.30). Spoke too soon. It never loaded the kernel.

Have you tried applying this to the 6.12 kernel?

@going I can, yes. But at the moment I don't want to distract from the wifi issue I am trying to solve. I am building a test application that must perform real time operations. I have previously done this with other ARM boards/distributions, but for this small project I am trying to go with "simplicity" (nothing is ever simple) I can provide the 'duff -u' for your interest, but I don't know what you want me to compare it against. i have linux-sunxi64-edge.config in my userpatches/ folder. It's generated from make menuconfig, and then I removed 'CGROUP_SCHED' from armbian-kernel.sh. Real-time applications work fine now. (They do not with group scheduling) root:~/# ./cyclictest --mlockall --smp --priority=80 --interval=200 --distance=0 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.30 0.37 0.17 2/200 1471 T: 0 ( 1468) P:80 I:200 C: 379209 Min: 7 Act: 18 Avg: 10 Max: 83 T: 1 ( 1469) P:80 I:200 C: 379008 Min: 6 Act: 19 Avg: 10 Max: 68 T: 2 ( 1470) P:80 I:200 C: 378802 Min: 7 Act: 19 Avg: 10 Max: 79 T: 3 ( 1471) P:80 I:200 C: 378595 Min: 7 Act: 20 Avg: 10 Max: 75

What is your goal? 25.02 is a stable release. There is no 25.05 stable release yet (that will happen towards the end of next month). So what is out there now are daily development rolling builds of 20.05. So if you want to track development then this would make sense (note the use 0f the word 'daily' there, things can change that often, and these changes aren't well tested yet), but if you want tested stability then you should wait until the next stable release comes out.

What is the purpose of using this core? Several people have already tried to build a real-time kernel here on the forum. They all face some challenges. Perhaps, if the tasks that such a core should perform are of a general nature, we can provide a configuration for its assembly. You built it yourself. Can you provide a difference in the configuration file for the same kernel version? As diff -u command.

Thank you for your response. I pulled down one of the "Standard Support" images. I enabled the overlay, and brought the interface up, but scanning does not return anything: root@bananapim4zero:~# iw dev wlan0 scan root@bananapim4zero:~# I wanted a 6.12 kernel that had real time extensions built in. I didn't realize 'current' would handle that. I will end up replacing this with a current kernel. I can't remember how anything < 6.12 handles real time patches. Maybe Armbian does it automatically as part of its patch set.

Configuring WirePlumber on embedded Linux systems can be somewhat confusing. We take a moment to demystify this process for a particular use case. View the full article

I used this image as base and from there did in-place full-upgrade: It used to lock-up with a kernel crash after 2 - 3 days, kernel 6.6.44 till 6.6.75. I have no HDMI connected anymore, only serial console cable, SD-card, microUSB power, RJ45 and SATA 8T HDD. Now with kernel 6.12.20-current-sunxi uptime already 6 days. I have radically modified partition setup, use Btrfs for rootfs, I do not use Armbian initial repartition scripts, that seems to be the point where your M1 fails. You need serial console cable and post clear text output where it fail. Still then, it might be too complicated to or time consuming fix. You could prepare/create/build a new own image using Armbian build. Or just stick to that older working image. It could be that the GUI drivers like it was in older kernels is dropped after 5.10 kernels or so, that happens to older hardware unfortunately. What is the kernel version where it still does work?

I have installed Armbian 25.02 via an official Armbian image for Armbian 25.02 (Debian 12) Vendor Kernel 6.1.xx, is it possible (and sane) to upgrade to Armbian 25.05 (Debian 12) Vendor Kernel 6.1.xx? If so besides downloading the new image and installing fresh what are one's options?

A little clarification. Just install the EDGE core. The version must be 6.13.11 or higher.

OK .... baud rate was too low ... I went up to 1500000 and I now have a serial connection using those debug pins a a orangepi 4 lts terminal on my desktop

I'm new to the Orange Pi 4 LTS. I work SBC's headless and have installed using UART many times on RP Zero's, BananaPi's and most recently on a RockPro64. However, I am not sure if I should be using. Is there another set of UART pins besides the "debug ins"? Booted the image on an sdcard connected to the debug pins and just got 8 lines of this stuff <��6v��Ή9�.�����goO

Several patches add I2S digital output on I2S3 channel. Tested with branch 25.02 / 6.6.72 .

Sorry to bring this back up but I'm having exact same issue on latest releases. I'm able to boot an older 21.05.1 release for the PineCube but the 25.5.0-trunk.87 and 25.5.0-trunk.444 have the same issue. Upgrading the 21.05.1 via apt update && apt upgrade broke it once again with the same overlap issue. ## Loading init Ramdisk from Legacy Image at 41b00000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 11237905 Bytes = 10.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 41800000 Booting using the fdt blob at 0x41800000 ERROR: FDT image overlaps OS image (OS=0x41000000..0x41a72768)