Active threads

@humanus I would argue that if you build your own image with your own u-boot that uses the vendor versions of BL31 Elf and DDR Bin plus some rootfs, you can test very quickly different kernel versions to see if latest mainline kernel 6.18 or 6.19-rc is working. U-Boot is quickly to build # extract u-boot cd u-boot-2026.01-rc5 # Get bl31 and ddr. Maybe even try newer versions of BL31 and DDR curl -LO https://raw.githubusercontent.com/rockchip-linux/rkbin/0b3e87afc2abd8dd6eb0052cd1be00de94a96637/bin/rk35/rk3528_ddr_1056MHz_v1.09.bin curl -LO https://raw.githubusercontent.com/rockchip-linux/rkbin/bf63f186b9d6ffeca758278f8cadb5d5e5dc7f86/bin/rk35/rk3528_bl31_v1.17.elf # Create the u-boot config make rock-2-rk3528_defconfig # Enable more config options like this, ONLY if really needed scripts/config --enable CONFIG_USE_PREBOOT scripts/config --set-str CONFIG_PREBOOT 'led green on; sleep 0.1; led green off' scripts/config --set-val CONFIG_LOGLEVEL '7' scripts/config --set-val CONFIG_SPL_LOGLEVEL '7' # If you enabled more than default, update the config make olddefconfig # Build u-boot make EXTRAVERSION=-MyAwesomeUboot-1 BL31=rk3528_bl31_v1.17.elf ROCKCHIP_TPL=rk3528_ddr_1056MHz_v1.09.bin # use u-boot files to flash - idbloader.img - u-boot.itb sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/idbloader.img seek=64 sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/u-boot.itb seek=16384 # or the combined file - u-boot-rockchip.bin sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/u-boot-rockchip.bin seek=64 This is just an idea to get you started and created relative quickly a base image for a boot test. If you have a process to build that quickly, flash it and try to boot. Hook up a serial console and if it boots interrupt the u-boot to get to the u-boot prompt. If you get there, you don't need to think about to much about the boot loader in the image. Because at that prompt you can test various boot options live, instead of editing something on the sdcard or to whatever medium you flashed it. Here are some thoughts and notes on how you can debug and try to boot from the u-boot prompt. # Lets assume device 1 is the SDCARD with the system on it # Check you disks (sdcard / emmc) mmc list mmc dev 1 mmc list mmc part # Maybe that will show you something like this. => mmc list sdhci@2a330000: 0 (eMMC) mmc@2a310000: 1 (SD) mmc@2a320000: 2 (SDIO) # 'dev part' will show you the partitions. # Lets assume you have 3 partitions on and part 3 is your system # Check if you can read files ls mmc 1:3 ls mmc 1:3 /boot/ # Now if you know your Linux kernel image, initrd and DTB name, you can try to boot load the files and boot # You get the PARTUUID from the 'mmc part' above load mmc 1:3 ${kernel_addr_r} /boot/Image load mmc 1:3 ${fdt_addr_r} /boot/dtbs/rockchip/rk3528-rock-2f.dtb load mmc 1:3 ${ramdisk_addr_r} /boot/initramfs-linux.img setenv bootargs 'root=PARTUUID=ab3ede6d-b4b9-4368-80a9-a029b67cca29 console=ttyS0,1500000 rootwait' booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r} Most important is you need to figure out what the serial console really is. If it is not ttyS0, try ttyS1 or ttyS2. The above "bootargs" at very basic. If you don't see much, try adding more. Here are some example you can add. Not all at ones! earlycon=uart8250,mmio32,0xfeb50000 console=tty1 console=ttyS2,1500000 console=both consoleblank=0 loglevel=7 panic=10 rootwait rw init=/sbin/init rootfstype=ext4 The "earlycon" parameter is also board specific. Not sure if it is valid for a Rock 2F or what the correct address would be. Again, this is not a working step by step guide but something that I would try to use for development and debugging. Once you have something working, I would think about integrating it into the Armbian config files.

Mainline 6.18 or 6.19 does only decoding accelerated, not encoding (yet) what is to great benefit of Jellyfin. Also for that transcoding, Jellyfin uses RKMPP, not V4l2. So 6.1.115 vendor kernel is what I use on the Jellyfin server (headless). For desktop RK3588, I use mainline 6.18.2 at the moment, brute force SW decoding, that works for me as content is max 1080p60 (HEVC or VP9 or H264).

Hello everybody, My Box is a oxtagon shaped t95z plus 2 mb 16 mb I try to install armbian_community_26_2 _0-trunk.100 aml-s9xx-box_noble_current_6.12.63_cinnamon_dektop.img.xz I use meson-gxm-vega-s96.dtb And u-boot-s905x-s912.dtb copy and rename as u-boot.ext It boots to ash then it stops No asking for password and user I have no clue what to do next I have entered armbian-confug but this returns a error Any tips?

@robertoj I apologize, perhaps you missed the message.

Looking at transpeed-8k618-t-allwinner-h6.dtso, you may need these flags instead of 0/1: (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)

On internet i can't find any image for this tv box. Anyone have build for this?

Today investigated, why BCM Bluetooth was not working with my image. What a rabbit hole 🙄 Also added OrangePi R2S board. Smaller brother of RV2 (I have no board but it's probably working). For the Bluetooth: everyone is obviously happy to hack the BCM firmware file instead of implementing bcm init into hciattach. The brcm_patchram_plus firmware hacking tool was added for this arch and that arch as a binary under BSP for different boards. Not very Debian-style. I grabbed the working source, compared to the one avail in Android AOSP and added it to my branch, added lib6-dev-riscv64-cross to the Docker image and now have a working image with BT. LG && HTH // Sven-Ola

See here, HW description bulletpoint 17 https://www.hardkernel.com/shop/odroid-m1s-with-4gbyte-ram/ Maybe it is also available on the 40-pins or 14-pins I/O headers, so a simple generic USB serial cable with jumper wires can be connected.

Actually, I was able to find that IC but in chinese version.. https://datasheet4u.com/datasheets/I-CORE/AiP1628/1571692 Looks like its some kind of low level chip that probably transforms low voltage signals into higher voltage, like the ones used on ethernet ports. Probably to power up the LCD leds.

To get the ethernet working you have no option but to build an image with kernel support for mae621. See these posts :

@PH Ph Ask Google AI mode... I haven't played with 4G CPE routers.

So far, the best working images I have found for the LonganPi 3H are those developed for the BananaPi M4 Zero. Only issues I have encountered are wifi-related. Hopefully this helps someone.

Hi all, I found where the problem was... My SD-card was not working correctly. My apologies. The system could not read/find ext4 partition on SD-card (because of "unknown" type and mounting point). I guess this happened when I erased my previous ext4 partitions by Windows disk manager and re-wrote Armbian image later. Problem was resolved as soon as I reformatted/recorded new image by Ubuntu. Thank you all.

Hello! I'm new to this forum but i follow the SBC comunity for a long time. I have a Pine 64, a bunch of raspberryies, 2 nanopies and some "japanese" arm64 tablet. Now i have bought a Radxa 5 Mini-ITX and i'm very happy with it. I was capable to compile ffmpeg with the rockchip extensions and exploit the RK3588 VPU and the NPU with face recognition. Now i was testing the HDMI Input of the board and unfortunaly discovered that the video is capturing just fine but i'm out of luck with the audio side. On the kernel 6.1.115 (last BSP at the moment i think) the recording device of the audio input is not visible in arecode -l This is what i see: **** List of CAPTURE Hardware Devices **** card 4: rockchipes8316 [rockchip-es8316], device 0: dailink-multicodecs ES8316 HiFi-0 [dailink-multicodecs ES8316 HiFi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 But the hdmi input audio card is still found under /proc/asound/cards: root@rock-5-itx:~# cat /proc/asound/cards 0 [rockchiphdmi1 ]: rockchip-hdmi1 - rockchip-hdmi1 rockchip-hdmi1 1 [rockchiphdmi0 ]: rockchip-hdmi0 - rockchip-hdmi0 rockchip-hdmi0 2 [rockchiphdmi2 ]: rockchip-hdmi2 - rockchip-hdmi2 rockchip-hdmi2 3 [rockchiphdmiin ]: rockchip-hdmiin - rockchip-hdmiin rockchip-hdmiin 4 [rockchipes8316 ]: rockchip-es8316 - rockchip-es8316 rockchip-es8316 5 [rockchipspdiftx]: simple-card - rockchip,spdif-tx1 rockchip,spdif-tx1 Furthermore if i go under /proc/asound/pcm: root@rock-5-itx:~# cat /proc/asound/pcm 00-00: rockchip-hdmi1 i2s-hifi-0 : rockchip-hdmi1 i2s-hifi-0 : playback 1 01-00: rockchip-hdmi0 spdif-hifi-0 : rockchip-hdmi0 spdif-hifi-0 : playback 1 02-00: rockchip-hdmi2 spdif-hifi-0 : rockchip-hdmi2 spdif-hifi-0 : playback 1 03-00: rockchip-hdmiin i2s-hifi-0 : 04-00: dailink-multicodecs ES8316 HiFi-0 : dailink-multicodecs ES8316 HiFi-0 : playback 1 : capture 1 05-00: fe4f0000.spdif-tx-dit-hifi dit-hifi-0 : fe4f0000.spdif-tx-dit-hifi dit-hifi-0 : playback 1 So the HDMI Input is still found (rockchip-hdmiin) but is not exposing any playback or capture jack So i tried to investigate and found that rockchip as changed the sound driver at some point as i found out here: https://zhuanlan.zhihu.com/p/664345417 (Link in Chinese) (I don't know if i can post link so let me know) Now i found that if i manualy install the 6.1.75 Kernel i found the device and i am able to record the audio: root@rock-5-itx:~# arecord -l **** List of CAPTURE Hardware Devices **** card 0: rockchiphdmiin [rockchip-hdmiin], device 0: rockchip-hdmiin i2s-hifi-0 [rockchip-hdmiin i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: rockchipes8316 [rockchip-es8316], device 0: dailink-multicodecs ES8316 HiFi-0 [dailink-multicodecs ES8316 HiFi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 Anyone can't test this? Maybe is for all the RK3588 or only the Radxa 5 ITX.

Latest armbian firmwares fail to boot on vim3 and graphical desktop do not start. As a workaround I installed old armbian image from August 2024 which booted and worked fine but sudo apt upgrade installed new firmware and it fails to boot to desktop again. Fails on all images Xfce and gnome available on website.

I have only recently been able to get my LaFrite 512, no EMMC to boot armbian. My errors were legion. Might I suggest: 1. write the spi update image with the dd command, I had used etcher to no avail 2. make sure you use the USB port nearer the gpio pins 3. connect the hdmi output on the board to a monitor or use the serial header pins so that you'll have visual confirmations of what is going on 4. if the spi update image is newer than the board's image the update should be applied. My board was out of date and the image was applied. I've no idea what happens if the board has the same or newer image. I wasn't patient or thorough enough to check. 5. Use etcher to write any of the currently posted minimal images to a usb drive of 8, 16, or 32 GB - don't use a larger usb drive. Do not use the Ubuntu server image - the apt sources are bad on that one. 6. put the usb drive with the linux image in the usb port further from the gpio pins -- the opposite of what is needed for the spi update. Again make user you can see what is going on when you boot - hdmi to monitor is fine. Plug a usb keyboard in the other usb port to make things easy. 7. Power on the board. I used an el-cheapo power supply and it worked just fine. If you have a good usb drive the board should boot fairly quickly. There shouldn't be any or many failures on the way up. Again let me reiterate -- a small usb drive. Every 64GB and larger drive I tried failed during the boot process. You may have better luck, but start small to see it things work. I had decided some months ago that my board was defective, it wasn't, my brain was (or is). Hopefully some of my experiences will help. BTW make sure you use the forky rolling release for your Radxa-2F, because unless Armbian has fixed the older releases, your wireless card's drivers will be deleted on an apt upgrade or an Armbian-upgrade. Hope this helps.

I've noticed that since yesterday the `server` Armbian images disappeared from the product pages. Example: https://www.armbian.com/radxa-rock-5-itx/ I can no longer see them. Is it a bug, or something expected from now on. I also noticed the https://armbian.chi.auroradev.org/dl/rock-5-itx/ folder is empty.

I try FEX today and it is the same. I will try hangover tomorrow

I've been using the Helios64 since launch, still going strong 👍 A couple of years back I had to limit the CPU frequency to avoid crashes until the last clean install of bulleyes. Since then stock clock and no custom dtb. Looking forward to my next holidays, planning on a clean install of Trixie. I'm planning on keeping using it as long as this thing wants to stay alive. An really nice piece of hardware, and I'm too cheap to move to something else 😄

Nothing to read on input. Maybe this is the real error, the keyboard input or console has issues. The console param on boot remained unchanged after update ?

use system resolver instead of default:https://github.com/armbian/build/blob/60e869c42c03af0428d9983750eb766a7a846d43/config/templates/config-example.conf.template#L25

If this is something with languages: I remember Armbian has a preferences option in apt config somewhere 'no languages'. Is old memory, maybe changed nowadays. Maybe a hint where to look and what to try. It would actually be a Cinnamon issue then.

There we go https://github.com/armbian/build/pull/9106

Thank you @Nick A

Duplicate