Active threads

@laibsch Hmmm, the current latest image seems to work OK. On the other hand, I tried to get the serial console working, but I did not manage to do so. I used an FTDI-based cable ( https://ftdichip.com/wp-content/uploads/2020/07/DS_TTL-232R_RPi.pdf ) with the recommended connection diagram, but nothing ever showed up on minicom's output. (It always showed it as Offline, and not even a single byte came through) I tried 9600 and 115200 baud for minicom, and also set `dtoverlay=uart0` in config.txt at some point. But neither helped in any way.

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.

@blood Thank you for documenting your progress. I recently got hold of a Helios4 and also want to get it to boot directly off SATA. I'm currently working on getting uboot for the Helios4 updated in Armbian. Let's collaborate and maybe do the same for the Clearfog?

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.

Thank you for that patch. Do you know how to use git and github? You don't necessarily need to open an issue first. You can go straight to pushing a PR. Just explain yourself enough so that a reviewer who may not understand your board can see why your patch should be merged in.

Anybody got PCF8563 configured and running on current armbian (25.8.2 noble aarch64) on a C2? i2cdetect -y 0 is seeing the device ID (0x51) and I have added module rtc-pcf8563 but no joy. HWCLOCK does not see the device. Any help would be appreciated. Scott

@ayoub-hs I don't own one of these boxes. I got the patches from warpme's miniarch/minimyth2. Supporting the x96q is a real PITA. https://github.com/warpme/miniarch/issues/102 Comparing the uboot DTS for both x96q lpddr3 and x96q lpddr3 v1.3. I don't see much difference other than wifi. Maybe you'll find something I missed. u-boot: https://github.com/NickAlilovic/build/blob/v20250306/patch/u-boot/u-boot-h616/159-add-x96-q-lpddr3-v1.3-defconfig.patch https://github.com/NickAlilovic/build/blob/v20250306/patch/u-boot/u-boot-h616/150-add-x96-q-lpddr3-defconfig.patch Kernel: https://github.com/NickAlilovic/build/blob/v20250306/patch/kernel/archive/warpme-6.12/0648-arm64-dts-allwinner-h313-add-x96q-lpddr3-TVbox.patch https://github.com/warpme/minimyth2/tree/master/script/bootloaders https://github.com/warpme/minimyth2/tree/master/script/bootloaders/u-boot-aw/files

I guess you need something similar to udev rule for Logitech Fn key: http:// https://github.com/sta-c0000/logitech-keyboard-udev-rules. IMHO it is more reliable and less resource hungry vs software package, but I have not seen alike for a Win key. So it might be necessary to spy on software doing this and develop udev rule for win key. May be someone on the forum having enough experience could help.

DDR Version V1.08 20210520 ln ddrconfig:3 DDR4, 324MHz BW=32 Col=10 Bk=4 BG=4 CS0 Row=16 CS=1 Die BW=8 Size=4096MB wrlvl:clk skew:0x80,0x80

Thanks but THIS is the question Can anyone provide a confirmed working ffmpeg command line for camera capture and hardware encoding? T.

Hi @Hqnicolas I have same issue with booting from SD card for a board (RK3399) . Can you please share the u-boot image or guide to compile for that chip?

@robertoj I use Nick's exact build (specify the branch) with bookworm. My tanix68 unit has a custom Hal and supplicant firmware, which I'm trying to integrate correctly, but LAN works just fine.

I've tried several recent releases back to bookworm, but the minute I turn apt loose to bring it up to date with a new kernel, in the last case 6.12.59, all /dev/sd* stuff disappears. WTH? I've been contributing to this project for several months

I tried on a RPI and it did indeed detect the OLED display. I forced the scan: # Force scan all addresses for i in {0..127}; do sudo i2cget -y 1 $i 2>/dev/null && echo "Device found at: 0x$(printf '%02x' $i)" done and it returned nothing

I've checked performance of my old rk322x-based box (H2O with 1.5G RAM/4G ROM) and compared it with fresh, h618-based. sysbench shows that rk322x is ~20x times slower in CPU (rk322x - 39 events, h618 - 700 events) and 6x times slower in RAM operations (216MB/s vs 1333 MB/s). in threads test rk3222x is just less than 2x times slower (4317 events vs 7563 events). are these values OK? or maybe something is mistuned?