Active threads

Quick preface: I'm a noob in many ways, though I'm trying to learn. I may make obvious mistakes and may need clearer instructions than most. Would really appreciate someone working with me here! So I realized earlier this year that I was still on Buster and that there were two newer OSs that I could upgrade to. I upgraded to Bullseye with support from ChatGPT which worked nicely. The upgrade to Bookworm hosed my system and it now fails to reboot. System Info (prior to failure): - Helios64 board - Armbian with OMV - Originally running Buster, then upgraded in sequence: first to Bullseye (worked fine), then to Bookworm - System was always booted from an SD card, not eMMC - Upgrade was done via `apt` commands, no manual flashing of U-Boot Current Symptoms: - After Bookworm upgrade, the system fails to boot. - Via USB-C serial connection (using `screen`), I get mostly garbled output like: �`���x�f������������f�������f��~�怘����怘� Or: ZZ���B>��^�������������N��f�&F�goFFWFWGGG�oo{{q�{{{{z{{����_G_�#g�_WN�o.���wgG�WwwwWw�NWN�W�_ow_fW�Wo�v�oNogoWffOgFGFONNfFOW^Wf_G�~gg� - Occasionally, I saw more verbose output including: SetTTY (fd 5): ioctl failed: Invalid argument Sorry, could not find a PTY - No SSH access; connection refused (network stack never comes up). - The fans spin up for a few seconds and the Ethernet LED blinks briefly, then stalls. What I've Tried: - Reflashed several SD cards (Verbatim Premium and Sandisk Extreme Pro) with the latest Armbian Bookworm images (Minimal, OMV, and Noble). - I still have my old SD card that was Buster and got upgraded to Bullseye and then Bookworm, also made a backup image of it. - Repeated all tests on my second, so-far unused Helios64 — same symptoms. - Changed power cables and tried both UPS and direct plugging to wall socket. - Verified serial setup with `screen /dev/tty.usbserial 1500000`. SD Card Behavior: - After flashing via `dd`, macOS warns “Cannot initialize disk” — I believe this is expected. - On insertion and power-up: usually fans spin and LEDs blink, but no consistent or successful boot. Desired Outcome: - I'd like to use Bookworm on Helios 64. If not possible, then I'd like to use Bullseye I guess, but I wasn't able to find an image online. Only Bookworm, Jammy, and Noble. - I'm aware of firmware and DTB tweaks recommended on here to make Bookworm stable — but I can’t try these yet because I never reach a usable system. Questions: 1. Is there any place where I can download an official or community-maintained Bullseye image for Helios64? Should I even try to use Bullseye? 2. Is the serial output I’m seeing a sign of a bootloader issue (U-Boot or DDR init)? 3. Can the Bookworm image be made to boot reliably with certain tweaks *before* boot (e.g. editing partitions manually)? ChatGPT suggested to boot the system without eMMC and this is certainly territory where I don't trust AI anymore. I think I need to try fixing the server with help from you and understanding the process myself. Since my main Helios64 is offsite, I took my second Helios64 home with me until I figure out what the issue is and I'm able to boot it up and get it running. Then I'll hopefully be able to fix my offsite machine during one of my visits there. I should also say that it would occasionally get "stuck" on a reboot attempt and I needed to physically turn it off and an again to boot successfully. This never happened twice in a row, i.e. the manual reboot always fixed it. Regular reboots worked with roughly a 80-90% success rate but it didn't have to reboot very often at all. Still, this makes me believe that maaaybe there is some hardware issue present. Then again, the second Helios experiencing the same issues makes this more unlikely I suppose.

CRDA is deprecated, not needed since Linux 4.15, hence the package removed with Debian Bookworm. Problem is the default regulatory database on Debian works with Debian kernel only, not with Armbian kernel. But wireless-regdb provides the upstream database as well, so you only need to switch: sudo update-alternatives --set regulatory.db /lib/firmware/regulatory.db-upstream

You could try to create chromium.conf yourself. Here's what I have here: cat /etc/armbian/chromium.conf # Default settings for chromium-browser. This file is sourced by /bin/sh from # /usr/bin/chromium-browser # Options to pass to chromium-browser CHROMIUM_FLAGS="--disable-smooth-scrolling \ --disable-low-res-tiling \ --enable-low-end-device-mode \ --num-raster-threads=$(grep -c processor /proc/cpuinfo) \ --profiler-timing=0 \ --disable-composited-antialiasing \ --disk-cache-dir=/tmp/${USER}-cache \ --disk-cache-size=$(findmnt --target /tmp -n -o AVAIL -b | awk '{printf ("%0.0f",$1*0.3); }') \ --no-sandbox \ --test-type"

Armbian already is! uname -a Linux orangepi5-plus 6.15.0-edge-rockchip64 #1 SMP PREEMPT Sun May 25 23:09:23 UTC 2025 aarch64 GNU/Linux Itś on edge, but it's working fine here, apart from the analog audio...

Its 64bit, but support quality (tl;dr;) of Allwinner is behind Rockchip.

Created another standalone version of script for this ... https://gist.github.com/avatar21/e0deca347665bd620d0ea3f9f299028e I believe we need to compile our own armbian/ Kernel 6.13 (or above? because as @elvis claimed user driver is only 1/2 of the equation) before running this script ya? all copy/ flatten to a temp/fake root folder (where I understand the chroot sdcard means, build to a fakeroot not patching existing OS) and repackage as an img file ya? Or better still, can someone compile the whole thing? start from burning image ...

Thanks for your help, and I found the official image not support NPU, only Joshua-Riek image support? @Hqnicolas root@h96-tvbox-3566:~# ls /dev/dri/ by-path card0 card1 renderD128

During the first few boots on my Orange Pi Zero 3 1GB, RAM size seemed to be detected correctly. Yesterday I saw RAM size being reported as 2GB, also after a reboot. As soon as the fixed U-Boot is available to install I am happy to provide test results or other test procedures when needed!

Glade to see you back @sicxnull. Thanks for the shoutout! Tried my best while you were gone. I don’t own one of these boxes. But I guess it doesn’t matter which one I get because theirs so many variations of the same box.

I try your prebuild image, and no luck with wifi/Bluetooth. My tv box new revision and have YC8800D wifi chip. Can i do something to get work WiFi?

Thanks for this!

Rockchip devices generally cannot be bricked. Short the maskrom pin i showed you and reflash. You can build the image from source or from here https://github.com/armbian/community/releases

I have T95Z Plus w/ H618 and my TV box new revision. It has another wifi chip YC8800D. tried to run this build https://github.com/LYU4662/t95zplus-h618-build It work fine but no wifi and Bluetooth. Looks like it made already with 8800 driver, but system does recognize any wireless interfaces. Also try to run community build Armbian-unofficial_25.05.0-trunk_Vontar-h618_bookworm_edge_6.12.11_server Its running good, but still no wifi and Bluetooth. In android /vendor/lib/modules found attached modules. Can i use them to get work wifi? aic8800_bsp.ko aic8800_btlpm.ko aic8800_fdrv.ko

Try looking for hints here: https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/rockchip/ They use mali blobs for hw en-/decoding.

seems like the config should be distinguishing by models, not by .. idk even what it is. let say config->OrangePi2->hardware->peripherals->i2c->i2's enumerate.

All the kernel panic options that you have shown here occur on v6.12.23. It all happens randomly. I suspect that this may be due to the presence of broken (faulty) blocks on the memory device. It's easy to check this.If you connect the SD card via an adapter to a Linux computer: sudo fsck.ext4 /dev/sdX1

I assume should work with vendor. Maybe missing node in device tree. Maybe missing firmware blobs or same as above. Expected since neither SPI nor eMMC are present by default. Direct boot from NVMe isn't support by any Rockchip soc.

does anyone know how to get maskrom and uart on this rk3228a board from mxq pro 4k 5G since pushing the little button shows up as armlogic devices on device manager but the actual chip is rockchip and sorry for bad quality images

Seems it is an option for timer resolution in the measurement of duration. But the topic is about CPU usage precision returned by getrusage function. it is hardcoded interval of time when kernel updates CPU usage of particular thread/process.

All Armbian board configurations files live in build/config/board/ Besides the Pcduino2 Cubieboard and OlinuXino-lime board, I don't know what other A10 boards still have some level of support. After that the next step would probably be to confirm that it works with uboot. Here you have another config file and dts. For any tweaks to uboot you will need to pass uboot-patch when running compile.sh. Note that when you do this you will need to open a new tab and navigate to cache/sources/u-boot-worktree/ Similiarly for the kernel you would navigate to cache/sources/kernel/ currently 6.12 is "current" while 6.14 is "edge" Hope this helps Ryzer

For production, boxes are much more interesting than boards. We just need to deal with a honest manufacturer. The last dtb from @mmie4jbcu worked very well for me in a x88 pro 20.

That solves it thank you very much for your time! If I want to change between boards like Rockpro64, Raspberry Pi4, etc. is there anything that needs to be considered as far as "reset" to a fresh state. For the guide I am writing I would like to make sure there is no lingering configuration that could cause problems when switching between builds for different boards.

All things being equal....... steve@fedora43:~$ uname -a Linux fedora43 6.16.0-0.rc0.250528gfeacb1774bd5.5.fc43.aarch64 #1 SMP PREEMPT_DYNAMIC Wed May 28 19:45:02 UTC 2025 aarch64 GNU/Linux kernel-6.16.0-0.rc0.250529g90b83efa6701.6.fc43. created by jforbes 6 hours ago for Fedora 43 .

Hello. I wonder if this issue is connected to my issue - to show something on i2c, while there is nothing, and not be able to communicate on it ?

Beta repository. - should be on servers where we push on directly and this error can't occur (unless something broke down) - is the same quality as other Linux distributions (there is no other distro that would maintain those custom devices) - currently assembly is broken as some patches are failing and thus (beta) repo is not getting any updates until its fixed https://github.com/armbian/os/actions/runs/15337468717/job/43160986093