Active threads

Error trying to run apt upgrade. Here is the error I receive: The following packages have unmet dependencies: armbian-bsp-cli-rpi4b-current : Depends: base-files (>= 25.8.2) but 25.8.1-12.4+deb12u11-bookworm is to be installed E: Unable to correct problems, you have held broken packages. I am not sure how to resolve this. Help will be greatly appreciated.

Just an FYI i just tried it with a different armbian version and it works fine. it works with Armbian_25.5.1_Orangepi5-plus_bookworm_current_6.12.28_xfce_desktop.img it doesn't work with Armbian_25.8.1_Orangepi5-plus_trixie_current_6.12.43_xfce_desktop.img

Hi, I am quite familiar with github, I'll submit a PR asap.

The /boot/firmware/cmdline.txt requires: console=serial0,115200 The /boot/firmware/config.txt requires: enable_uart=1 That's it.

@laibsch - I have my clearfog booting directly off SATA at this point. I achieved this a while ago by writing a "special" uboot binary to the very start of my SATA SSD, and later by writing an enhanced uboot image via `armbian-config` to SPI flash which doesn't require anything else. It's a very simple configuration now and much preferred over the old way. Good luck keeping your system operational and running well!

I just did a simple test that always worked on Intel CPUs with with logitech C310 on ROCK5B with 6.1.115 kernel /usr/share/jellyfin-ffmpeg/ffmpeg -y -hide_banner -f video4linux2 -input_format yuv420p -video_size 640x480 -framerate 30 -i /dev/v4l/by-id/usb-046d_081b_9061E8E0-video-index0 -map v -c:v h264_rkmpp -f mpegts webcam.ts Output file plays fine, good motion, same as if I use normal ffmpeg and just non-accel h264 codec, although CPU load is then about 20% for the ffmpeg process, while when using rkmpp it is below 1% For higher resolution, I think C310 internal MJPG is needed, but that is normal, USB2 has limited bandwidth.

As a trusted partner of industry leaders like CLAAS, Ag Leader, and CCI, we are delighted to exhibit for the first time at one of the world’s leading agricultural trade fairs, taking place November 9–15. Meet us at the Digital Farm Center in Hall 21! View the full article

@jock this is the user-overlay patch I am using to enable both leds on the board. The "working" led is as usual a couple of alternating leds of red/blue. The led-ir is a standalone blue, I have triggered one to the "timer" and the other to "activity" , both running. I can confirm bluetooth, IR remote receiver are also working. Bluetooth needs BCM.hd (I have used BCM43342.hcd). For the wifi 2/5G the correct overlay is rk3318-box-wlan-ap6334. HDMI, despite apparently is initialized correctly and answering to all commands still gives a black screen. rk3318-box-led-overlay-ledA.dtso.txt

Wow.. I don't know how that brainfart happened. Used the correct uboot I managed to get somewhere. I tried to use the meson-gxbb-p201 but seems that the FS cannot be found... will try others but wondering if I should be tweaking UUIDs given the errors I am seeing: https://photos.app.goo.gl/Y5GM3a6XUy6SZ6JA6 https://photos.app.goo.gl/Qq3EPGScPUFWfuQP6 I do seem to have mmcblk1 (and mmcblk1boot0, etc..) in /dev if I poke around. Not sure if trying new dtb is a good approach or should I try to add the delay like the error suggests.

Is i2c-1 actually mapped out to i2c-1? It should be if the aliases are setup correctly. Secondly even if the i2c bus is enabled, have the pins been successful muxed into i2c mode? You should be able to check by: sudo cat /sys/kernel/debug/pinctrl/300b000.pinctrl/pinmux-pins | grep i2c

I have a RK3228A TV Box which is able to properly boot armbian when flashed to its eMMC (no rknand) . However I don't use Armbian much often, probably a maximum of two to three times a month. I want to keep stock Android on eMMC, for video playback on the YouTube app is much faster compared to in firefox and Android has proper remote support which Armbian lacks. I tried flashing the armbian community image on the sdcard but the device didn't boot from sdcard unless the eMMC was wiped. I found that multitool is able to always boot from sdcard irrespective of whatever is in the emmc. After doing some research on the multitool build process, I think I need a properly configured idbloader, uboot and tee binary and then place them at proper offsets in the image, however the Armbian image already contains different data at those offsets. So, how can I build an Armbian image that can be booted from sdcard without wiping the eMMC ?

Hello everyone! Saw that some luckfox boards were getting supported and I was like: YES!!! Flashed an sd-card with the community image. Latest I could find is 25.11.0-trunk.413. And plonked in my working Luckfox Lyra Zero W and it failed to boot. From what I gather there seems to be a missing partition called "misc" and I think it is expected about after the current unallocated 16MB(16,777,216 bytes). I tried creating a 4MB partition after the current unallocated space but it complained about something called "Magic" and my limited u-boot/rockchip/embedded linux experience made me get lost there. This is the serial output: Where the "No misc partition" is where I began. My current board has buildroot flashed to the SPI and boots if i don't have any sd-card inserted. DDR 0ac6b06a19 typ 24/11/13-17:22:47,fwver: v1.04 tREFI:4x, sr_idle:93, pd_idle:13 PHY drv:clk:40,ca:48,DQ:40,odt:240 vrefinner:50%, vrefout:50% dram drv:40,odt:120 sr_dq:0, sr_ca:0, sr_clk:0 rg:0xc-0x1-0x2, 0x3d-0x0-0x2,status:a007 rdtrn:0x14-0x30-0x4c(0x38) wrtrn:0x3-0x20-0x3d(0x3a) DDR3, 750MHz BW=16 Col=10 Bk=8 CS0 Row=15 CS=1 Size=512MB out U-Boot SPL board init U-Boot SPL 2017.09-g4d88b0a #hxj (Jul 30 2025 - 20:08:42) sfc cmd=03H(6BH-x4) SPI Nand ID ef aa 22 unrecognized JEDEC id bytes: ff, ef, aa Trying to boot from MMC1 No misc partition spl: partition error Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking op-tee 0x00001000 ... sha256(93603ca22c...) + OK ## Checking u-boot 0x00100000 ... sha256(606b868a00...) + OK ## Checking fdt-1 0x0018baf0 ... sha256(6ae9f912c7...) + OK Jumping to U-Boot(0x00001000) I/TC: I/TC: OP-TEE version: 3.13.0-958-g46dcf51e88a #chenjh (gcc version 10.2.1 20201103 (GNU Toolchain for the A-profile Architecture 10.2-2020.11 (arm-10.16))) #2 Thu Mar 6 10:17:27 CST 2025 arm, fwver: v2.10 I/TC: Status: cluster=0xc00, core=0xe100, bootcpu=0 I/TC: Next entry point address: 0x03f011a7 I/TC: OP-TEE memory size: TEEOS 0x5e000 TA 0x1000 SHM 0x1000 I/TC: Primary CPU initializing I/TC: Primary CPU switching to normal world boot

I put it together, bumped kernels, uboot, briefly test. Anyone volunteer to become a maintainer? https://github.com/armbian/build/pull/8873 https://docs.armbian.com/User-Guide_Board-Support-Rules/#standard-support

Debian 12 and 13 have trouble establishing the correct EDID for the monitor, which is why it doesn't recognize resolutions correctly. I spent two weeks reading and testing everything until I found the solution. You need to connect the monitor to a Windows PC, install and run the CRU program. This program correctly reads the monitor's EDID. Simply export the data and save it as a BIN file. Then, reconnect the monitor to your Orange Pi device. Copy the exported .bin file to this directory: /lib/firmware/edid/ Next, you need to load the parameters into the kernel: Edit the armbianEnv.txt file and add: extraargs=drm.edid_firmware=HDMI-A-1:edid/you_file.bin video=HDMI-A-1:1024x600@60 Set your chosen resolution. Restart and verify: `cat /proc/cmdline` Check that the string loading your custom EDID appears.

Integrated with bump of uboot and kernel. https://github.com/armbian/build/pull/8873 Test image: https://k-space.ee.armbian.com/incoming/igorpecovnik/ebin/Armbian-unofficial_25.11.0-trunk_Espressobin_trixie_current_6.12.57_minimal.img.xz

Thanks for the effort and sharing! I'll do the testing in my device when I can get some time I'll probably need some help building or applying patches to the images.

As of now, the answer is no. Same CPU means very little in terms of ease of getting it supported.

Mangix, are you still around? Where is the code you are referring to in openwrt? I see exactly one commit in 2020 about the Helios4 and then nothing after that. I also don't see any specific patches applied.

@Sergey Lepeshkin thanks for the information.After a while search for soldering shops i didnt have any results, it seems like there is no soldering shop in my city (there are but very far away). I was expecting a alot of them since im in the center. What to do now? EDIT: I tried your modified update.zip, and it regonized it, i clicked the the Settings > device info > local update > mmcblk0 (the sd card with the update file) and it rebooted, after that that, the box didnt update anything 😕

Have you looked into hosting your own deb package cache locally? You can set the MANAGE_ACNG build switch for that purpose and have a prepopulated apt-cacher-ng proxy in your LAN. Let us know how it goes.

@Deoptimhow to build the current u-boot ? and how build MiniLoaderAll.bin?

In my opinion and experience, armbian-config is a horrible pile of hacks that are almost guaranteed to eventually eat your data. As such, in my opinion the only sane action is to stay far clear of it.

@Hqnicolas how to build the current u-boot RK356x ?

In the meantime I got HDMI also working through my AVR. I just changed the cable and that did the trick... One thing to mention: the system seems to be allergic to hot-plugging the HDMI cable. So if I connect/reconnect the cable during runtime, the HDMI output will be gone. It requires a reboot WITH CABLE CONNECTED. Not a big issue from my pov, but important to know...

Please prepend the commands with LC_ALL=C like "LC_ALL=C apt update" and post the output again.