All Activity

Hi everyone, Sorry to bother you with what may be a basic question. I’m not very experienced with the Armbian build system, and it’s been a while since I last built and deployed my own kernels. I’ve been trying to compile both the current and edge branches without success. I did get vendor working. I came across this post but I’m still unclear on the exact steps. Could someone please give me a simplified explanation of: What needs to be done to successfully compile these branches? Where I can get the latest patches, and how to apply them? Whether I also need to rebuild U-Boot with the Armbian build system. Thanks a lot in advance for your help!

HDMI output might be broken on this kernel - mainline support is still fragile, perhaps for this board there is no device tree yet and it fails early.

Connected via SSH. DHCP client is automatically getting IP, so you should be able to find the device on network after few minutes ... in case HDMI output is really broken. I can't test that as device is stashed to some rack.

follow http://debug.armbian.de

might be hard to find such an old image even from the archive why not one of the newer ones? https://www.armbian.com/cubox-i/

Hi, I have attempted to boot with edge and current branches with no success. I am now trying vendor since its what its running. My process is: ./compile.sh BOARD=orangepi5pro BRANCH=current kernel-config I enable tunneling GRE and some broadcom wifi drivers. ./compile.sh BOARD=orangepi5pro BRANCH=current kernel sudo dpkg -i output/debs/linux-image-*.deb sudo dpkg -i output/debs/linux-headers-*.deb sudo dpkg -i output/debs/linux-dtb-*.deb sudo reboot and after this the system does not boot or post through HDMI. I have to go back and erase /boot and restore a backup to be able to get it working again. What am I missing? P.S. I have /boot partition in SD card and the system partition is in an NVME drive.

armbianEnv.txt sets parameters for the U-Boot bootloader. In theory you can also manually type it all via serial console at U-Boot prompt. Separating boot and rootfs is independent of that. If you use Ext4 for bootfs, you can make hardlinks (or symlinks). That is also what is done by kernel install script if /boot is on Ext4, als copies are done (when FAT).

I have seen this many times on my ROCK3A and had to do with how the various 'PCI-E I/O' is operated. Some are multi-PHY SERDES, so can act also as SATA or USB3 or Mii. It very much matters which U-Boot and also overlays, which are kernel dependent. I now got 2-lane PCI-E for a Samsung 970 EVO 500MB (M-Key slot) and SATA3 (E-Key slot) working simultaneously. Is a Radxa U-Boot in SPI and vendor 6.1.115 kernel, else it won't work. For the RK3588 on my ROCK5B it works more flexible w.r.t. bootloader and kernel, 3 sets work, so also latest mainline generic distro Linux. The ROCK5Bplus has 2x M-2 M-key, so that is different from a ROCK5B. I am not sure how lanes are routed, but did once check a similar issue RK35xx board and there the bifurcation seemed to be the problem. There are options I think for lspci where you can see how many lanes and that should also be in kernel log. Might need loglevel=7 to see it. It might also be that the Crucial P310 just won't work reliably with the ROCK5Bplus, we have seen something this similar before for an other NVM-E + RK3588 SBC combinations (I think it was OPi5+ and same SSD as I have). Other NVM-E brand worked without issues.

./compile.sh And choose this:

Thanks for your replies! @Igor is that screen shot you've pastebinned from a connection to the usb TTY? I've ordered a new card reader / writer which should be here tomorrow. The only one I currently have is in my elderly System76 laptop and I'm not fully confident in its driver support (for example it doesn't eject or unmount, so my only recourse is to run sync a bunch of times and then shut the machine down). I don't think there's much point in building new cards with the Bookworm minimal version as that's what I currently have on my Cuboxes. I will report back. Thanks again!

@Chris C In case going's suggestion doesn't help, the kernel should be compatible with the Rock 5b. I don't think that you need to install the dtb if you're already running Armbian with vendor kernel 6.1.x. So just install with "sudo apt install ./linux-image*.deb and the headers if you need them to compile drivers that you need for testing. To be sure if the install went correct you should look if the symlinks are all to the correct kernel. "ls -l /boot" otherwise "sudo ln -sf correct-vmlinuz Image" and so on But adding a log is always helpful indeed. Send it after the nvme stopped working.

UART console log? In fact, only the u-boot version and the kernel version are interested. On my devices with rk3588 (s) chips, old versions of u-boot were originally installed and they did not allow loading Armbian images. I used the instructions from the manufacturer's official website and recorded the bootloader provided by Armbian on the SPI chip using special software. In other words, Armbian delivers his images from u-boot v2025.XX but my orangepi5plus was loaded using u-boot v2019 recorded on an SPI chip. And that may be the problem. After overwriting the new version, my device loads any images and PCI (NVME) devices register correctly. I checked several of these from different manufacturers. Hope this information helps with your problem.

Looking for Armbian_20.02.7_Cubox-i_bionic_current_5.4.28_desktop.7z – anyone can share a copy

Thanks @royk, Can you please elaborate a bit on how to try out the kernel you sent? Isn't it for orange pi 5? How do I build an image out of it for the rock 5b+?

@Chris C In the past there was a commit to fix sata issues with the Rock 5a, but this gave problems for nvme with Orange Pi. After that I also read some problems with nvme and the Rock 5B although I don't know if that was related. https://forum.armbian.com/topic/46601-2484-latest-apt-upgrade-breaks-multiple-things-including-the-gnome-desktop/?do=findComment&comment=204829 This is a bit older kernel with RT patch where I reverted that commit. If that works you could compile a "normal" kernel with that commit reverted. https://drive.google.com/drive/folders/1r76sUsfG_F8pq0pkzzPgEyzqdRG6fGcz?usp=drive_link

I've now exhausted all practical options. I guess that the 6.15.4-edge-sunxi kernel was built with GCC plugins and BTF settings that cannot be reproduced with out-of-tree module builds. Even using the cross-compiler (arm-linux-gnueabihf-gcc-13) did not help — because the issue is not the compiler binary, but the entire build environment: CONFIG_DEBUG_INFO_BTF_MODULES=y GCC_PLUGIN_RANDSTRUCT or STRUCTLEAK ftrivial-auto-var-init=zero TLS guard offset (-mstack-protector-guard-offset=1464) Kernel symbol versioning These change the binary layout of struct module, making any externally built module incompatible. The question now, how could a missing module be added to a running system ! It is almost improbable, that development path is completely blocked and requires enormous workload for adding a simple already existing module. In the meantime, while the right approach is being looked for, could somebody point to a "pull request" procedure?

So am I reading correctly from your post that separating boot and rootfs using armbianEnv.txt does work? Do you think the hardlink option inside the boot partition could work? I would most likely test this setup but would like to know before if there are issues why it never would work to avoid work, I know there are many other options including an initramfs with btrfs support to avoid partitions for different rootfs to then use subvolumes. Still I would like to stick for the time being with the original idea. Thanks.

If you mean an external directory within immich, then answering this is out of scope of the Armbian project. We provide a fairly easy way to install the software, but everything beyond is userspace. If you mean sharing a directory from the host into the docker container, then here you can check how armbian-config installed immich: https://github.com/armbian/configng/blob/37f091998d74b059c4302a91ca1f2c06a908297f/tools/modules/software/module_immich.sh#L16

It is already loaded : root@orangepiplus:~# lsmod Module Size Used by cfg80211 618496 2 mac80211,8189es Just one more time again : root@orangepiplus:/mnt/sda2/src/rtw88# sudo modprobe cfg80211 root@orangepiplus:/mnt/sda2/src/rtw88# sudo modprobe rtw_8821au modprobe: ERROR: could not insert 'rtw_8821au': Exec format error root@orangepiplus:/mnt/sda2/src/rtw88# sudo modprobe rtw_core modprobe: ERROR: could not insert 'rtw_core': Exec format error

How would one do that exactly?

The NanoPi R3S contains a hardware clock (HYM8563) with the possibility to connect a backup battery. However, the current kernel adds this clock as an additional one (RTC1). I tried to create a device tree overlay, but it does not work. As I understand it, this is because the default Rockchip clock is not included in the device tree. So, if I understand correctly, the only way to make the HYM8563 the default clock is to build the kernel with this option enabled. Please consider changing the default kernel options to make the HYM8563 the default RTC. If there’s another way to make the HYM8563 the default RTC, please advise.

Before loading the module `sudo modprobe cfg80211`

It has been tried several times with similar results : On stable 6.12.35 The lwfinger/rtl8821au driver causes kernel exceptions (oops/panics) It doesn't survive simple lsmod. On kernel 6.15.4 : It fails inserting : root@orangepiplus:~# sudo cp /var/lib/dkms/rtw88/0.6/build/*.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/rtw88/ root@orangepiplus:~# ls -al /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/rtw88 total 23744 drwxr-xr-x 2 root root 4096 Aug 24 15:13 . drwxr-xr-x 6 root root 4096 Aug 21 21:02 .. -rw-r--r-- 1 root root 961676 Aug 24 15:13 rtw_8703b.ko -rw-r--r-- 1 root root 415924 Aug 24 15:13 rtw_8723cs.ko -rw-r--r-- 1 root root 991580 Aug 24 15:13 rtw_8723d.ko -rw-r--r-- 1 root root 416088 Aug 24 15:13 rtw_8723ds.ko -rw-r--r-- 1 root root 419968 Aug 24 15:13 rtw_8723du.ko -rw-r--r-- 1 root root 492256 Aug 24 15:13 rtw_8723x.ko -rw-r--r-- 1 root root 929420 Aug 24 15:13 rtw_8812a.ko -rw-r--r-- 1 root root 424112 Aug 24 15:13 rtw_8812au.ko -rw-r--r-- 1 root root 1271964 Aug 24 15:13 rtw_8814a.ko -rw-r--r-- 1 root root 420676 Aug 24 15:13 rtw_8814au.ko -rw-r--r-- 1 root root 900128 Aug 24 15:13 rtw_8821a.ko -rw-r--r-- 1 root root 422752 Aug 24 15:13 rtw_8821au.ko -rw-r--r-- 1 root root 1025348 Aug 24 15:13 rtw_8821c.ko -rw-r--r-- 1 root root 415504 Aug 24 15:13 rtw_8821cs.ko -rw-r--r-- 1 root root 421624 Aug 24 15:13 rtw_8821cu.ko -rw-r--r-- 1 root root 1217480 Aug 24 15:13 rtw_8822b.ko -rw-r--r-- 1 root root 415504 Aug 24 15:13 rtw_8822bs.ko -rw-r--r-- 1 root root 425156 Aug 24 15:13 rtw_8822bu.ko -rw-r--r-- 1 root root 1734256 Aug 24 15:13 rtw_8822c.ko -rw-r--r-- 1 root root 415504 Aug 24 15:13 rtw_8822cs.ko -rw-r--r-- 1 root root 420196 Aug 24 15:13 rtw_8822cu.ko -rw-r--r-- 1 root root 666896 Aug 24 15:13 rtw_88xxa.ko -rw-r--r-- 1 root root 7900876 Aug 24 15:13 rtw_core.ko -rw-r--r-- 1 root root 575660 Aug 24 15:13 rtw_sdio.ko -rw-r--r-- 1 root root 560804 Aug 24 15:13 rtw_usb.ko root@orangepiplus:~# sudo depmod -a $(uname -r) root@orangepiplus:~# sudo modprobe rtw_8821au modprobe: ERROR: could not insert 'rtw_8821au': Exec format error Aug 24 15:14:25 orangepiplus kernel: module rtw_core: .gnu.linkonce.this_module section size must match the kernel's built struct module size at run time

hello @Nick A, have you read the last post i posted? When i was messing around on my box, i saw that the box only have 1200mhz freqency (note that this is allwinner h313) while h313 max freq is 1350mhz, and mine is 1200mhz, is the h313 nerfed by the firmware? Or anything else? edit: full cpu formation here

Find a DTS that uses compatible="waveshare,rpi-lcd-35" and try again (I don't use that LCD, so I am not sure... but I know it is special because it contains a SPI-to-parallel chip)