Search the Community

Attempting to install ZFS. But it seems that the latest linux headers are linux-headers-5.10.0-31-arm64. I am not able to install ZFS. Pretty sure I need to lower the kernel to match. sudo modprobe zfs modprobe: FATAL: Module zfs not found in directory /lib/modules/6.6.39-current-rockchip64 Installed linux-image-5.10.0.31-arm64. I also sudo apt-mark hold linux-image-5.10.0.31-arm64. But I do not know how to set the kernel to boot. Search tells me to use armbian-config. Had to install it and after running it the "Other" option is missing. There isn't any options to change the kernel.

The mainline 5.11 patch "phy: rockchip: set pulldown for strobe line in dts" https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e (not backported to 5.10.y) seems to have broken most if not all rockchip board EMMC HS400 enhanced strobe support. This probably affects supported rockchip boards (at least rk3399 ones, but probably most). That is boards exhibit: [ 18.985162] mmc1: running CQE recovery [ 18.988056] ------------[ cut here ]------------ [ 18.988500] mmc1: cqhci: spurious TCN for tag 12 and the filesystem ends up corrupted on write attempt. Note that another bug about regulator core DEFERRED support (which might have produced the same issue hardware wise) was introduced in 5.10.43 (I had bisected it to https://github.com/torvalds/linux/commit/98e48cd9283dbac0e1445ee780889f10b3d1db6a "regulator: core: resolve supply for boot-on/always-on regulators"). But I was confident that it to be fixed in at least 6.1 by https://github.com/torvalds/linux/commit/8a866d527ac0441c0eb14a991fa11358b476b11d "regulator: core: Resolve supply name earlier to prevent double-init" (introduced in 6.1), still EMMC was still failing on me. Thanks to @RussianNeuroMancer telling me that not all rk339 boards had EMMC HS400es broken, I found that nanopc-t4 had https://github.com/torvalds/linux/commit/463be3cb357dab7d7e4d8dcc7c15c642e10c5bef arm64: dts: rockchip: add enable-strobe-pulldown to emmc phy on nanopi4 So the current way, from this nanopc-t4 commit, to fix EMMC HS400 on most rockchip is to add "rockchip,enable-strobe-pulldown;" to the "emmc_phy" node (at least this node alias for rk3399). &emmc_phy { + rockchip,enable-strobe-pulldown; status = "okay"; }; With this patch I can renable hs400es for rk3399 emmc on helios64 (it is already set for nanopc-t4 in mainline). Details in: I believe the https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e mainline commit was wrong in that it probably should have done the opposite (that is enable the pulldown) as most boards were hardwired so. As was done for rk3588 boards: "arm64: dts: rockchip: Fix eMMC Data Strobe PD on rk3588" https://github.com/torvalds/linux/commit/37f3d6108730713c411827ab4af764909f4dfc78 " JEDEC standard JESD84-B51 defines the eMMC Data Strobe line, which is currently used only in HS400 mode, as a device->host clock signal that "is used only in read operation. The Data Strobe is always High-Z (not driven by the device and pulled down by RDS) or Driven Low in write operation, except during CRC status response." RDS is a pull-down resistor specified in the 10K-100K ohm range. Thus per the standard, the Data Strobe is always pulled to ground (by the eMMC and/or RDS) during write operations. Evidently, the eMMC host controller in the RK3588 considers an active voltage on the eMMC-DS line during a write to be an error. The default (i.e. hardware reset, and Rockchip BSP) behavior for the RK3588 is to activate the eMMC-DS pin's builtin pull-down. As a result, many RK3588 board designers do not bother adding a dedicated RDS resistor, instead relying on the RK3588's internal bias. The current devicetree, however, disables this bias (`pcfg_pull_none`), breaking HS400-mode writes for boards without a dedicated RDS, but with an eMMC chip that chooses to High-Z (instead of drive-low) the eMMC-DS line. (The Turing RK1 is one such board.) Fix this by changing the bias in the (common) emmc_data_strobe case to reflect the expected hardware/BSP behavior. This is unlikely to cause regressions elsewhere: the pull-down is only relevant for High-Z eMMCs, and if this is redundant with a (dedicated) RDS resistor, the effective result is only a lower resistance to ground -- where the range of tolerance is quite high. If it does, it's better fixed in the specific devicetrees. Maybe one can confirm this is the case not only for rk5588 but for other rockchip boards? (about the default for hardware reset and rockchip BSP with regards to active that eMMC-DS pin's builtin pulldown if any, and board designers for other boards than rk5588 also not bothering to add a dedicated RDS resistor, instead relying on the rockchip internal bias, also if any on non rk5588) At least two other boards disabled hs400es in mainline probbaly due to this patch disabling the internal pulldown by default "phy: rockchip: set pulldown for strobe line in dts" https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e in 2023 in vanilla Linux: Rock 4C+ https://github.com/torvalds/linux/commit/2bd1d2dd808c60532283e9cf05110bf1bf2f9079 Rock Pi 4 https://github.com/torvalds/linux/commit/cee572756aa2cb46e959e9797ad4b730b78a050b

I'm new to SBC and tinkering with Rock 4C+ (plus) board and appreciate some support and guidance for blueooth setup. Installed Armbian 23.11.1 Bookworm CLI build. Enabled BT package from Armbian config utility as well tried installing bluez package from CLI using apt command afterwards. Started bluetooth service but seems not working. Command sequence I used: sudo apt install bluez sudo service bluetooth start sudo service bluetooth status (output says Loaded & Active). 'hcitool scan' command however returns message "Device is not available: No such device". When I installed Radxa's official Debian 11 desktop build, bluetooth works out of the box. I can see bluetooth connection icon in system tray and active. What I'm doing wrong or missing to setup bluetooth on Armbian bookworm build?

I have a project developed on Rock 4C+ v1.2 board. Now there is only v1.41 board available and Armbian is not booting on it at all, no matter it's compiled locally, or it's downloaded from the official sources. UART debug is producing unreadable sequence. So far, what I’ve tried: - I’ve built Armbian with the latest changes armbian build repo - hasn't helped - I’ve used rk3399-rock-4c-plus.dtb file instead of rk3399-rock-pi-4c-plus.dtb, dunno why there are two, but somewhere on the forum I read that this one without “pi” is the right one - hasn't helped - official Armbian images - not booting - Ubuntu and Debian - both booting fine can someone help?

I followed all online guides. I tried to flsh the SPI. I arrived to the point where the maskroom is well recognized by the computer (Linuxmint). After that I tried to flash it and the error code is that the write operation is impossible. Please do you have any suggestions? Thanks.

Hi. At first I'd like to apologize for the tone of this post, but there are things that I've been fighting with, without any success, for a long time. Problem 1. I have, as it seems, a very common problem with Armbian on RK3399. I burned Armbian 23.8.1 for the Rock Pi 4C+ onto an eMMC module, which booted, but there is no HDMI video output. I can't SSH into it over ethernet and provide more details because the server is disabled by default. I assume that the problem here is the same one as I often see coming back to all RK3399 boards and the solution is always the same - "libreelec patches for the HDMI subsystem" (whatever they are). If it's so common then why is it that Armbian releases never work out of the box? With all due respect for the maintainers of course. At this point wouldn't it be easier for RK3399 boards maintainers to just make a tutorial on how to patch the thing up so that new users could do it themselves without waiting or taking up their time? Problem 2 Also another thing I wanted to ask is why do Armbian people never care about providing overlays for interfaces and peripherals that manufacturers do support in their own images? I'm sorry for sounding arrogant and demanding even though I have no idea how to do things on my own (although I would if I knew how), but I've been tinkering with many different boards over the past months and there's always the dilemma - either use Armbian which has the most up-to-date kernel, often mainline support and graphics drivers but completely non-existent interface/peripheral support, or use the manufacturer provided images which have good interface/peripheral support, but are often quite inflexible and maybe a little outdated. Can't have both and it's all extremely annoying to deal with, especially since getting into building your own images and doing it right, figuring out all the quirks and actually creating support for features is extremely hard because it isn't exactly explained anywhere. As I said, I've been tinkering for months and I only scratched the surface so far. I really don't want to be the "somebody please" guy, but [...]. This is the problem with community-provided support. And it's just so natural for Linux to constantly have problems because of this development model... Not just on ARM SBCs... No structure, no clear goals, no group efforts, low funding... Just random people doing random stuff in their free time mostly (you're welcome to yell at me if I'm wrong)... In the end it's a coin toss if things work or not.

I use Armbian_23.8.1_Rockpi-4cplus_bookworm_current_6.1.50_xfce_desktop and need the current headers but could not find them sudo apt search linux-headers do not show them. I need them for the procedure described here https://github.com/glasgowneuro/comedi_raspberry_pi_bullseye/tree/main in order to install missing kernel drivers (comedi usbdux-sigma) Can anyone help please!

Hi, I have tried multiple Rock Pi 4+ (Plus) boards, all of them run regular Debian well, so the hardware should be good. But when I tried Armbian, the 2 USB 3.0 ports were not working with logitech USB dongle or Samsung USB drives (which did work in regular Debian), I searched and found maybe they were in OTG mode and needed to be in HOST mode. I tried armbian-config then System -> Hardware, then enabled: dwc3-0-host rockpi4cplus-usb-host After reboot, the bottom USB 3.0 port would start working, yet the top one still wouldn't work. Otherwise, Armbian was the most user-friendly, fast and stable build for Rock Pi 4+, I'm absolutely loving it! Thank you very much. P.S. the version I tried was: Armbian_23.8.1_Rockpi-4cplus_bookworm_current_6.1.50_xfce_desktop The bookworm gnome version has exactly the same issue. The ubuntu version works perfectly after armbian-config, although it's commandline only, it would be great to have a desktop preinstalled. https://armbian.lv.auroradev.org/dl/rockpi-4cplus/archive/

The rock pi 4 is no longer on the download page? https://www.armbian.com/download/?device_support=Supported&tx_maker=radxa&arch=aarch64 There is no rock pi 4 link any more?

I am trying to get a RPi camera (imx219) working on a RockPI 4C. I have been piecing together DTS files from various places trying to make sense of it, and I noticed that the rkisp kernel module isn't compiled on the Rockchip64 kernels. Is there a reason for this or am I missing something? Looking at the kernel menuconfig, only one of its dependencies isn't compiled: `V4L_PLATFORM_DRIVERS=n`.

Hi My problem is that armbian 6.0.7 kernel hasn't recognised my 28" samsung 4k monitor.It recognised like a 29" monitor.How can I fix this problem? and in 4k resolution right of the screen doesn't show properly.In this side of the screen is completely white. Another problem is that 4k video plays very slowly How can I fix this problem? Thank you for your answers!

I've installed Armbian_v22.05.2_Rockpi-4cplus_jammy_current_6.1.33_minimal and whatever I try to play a 1080p video via the performance is horrible with very slow refresh, totally unusable. Normally loki gives me acceptable performance on SBCs of similar performance but not in this case. The Rock 4c plus is quite powerful so I'm really shocked at how badly it's performing. Let me be clear, I understand that the issue I see is not that the Rock 4c plus isn't cable of playing video, clearly it is and I'm not complaining about the hardware of the device. It's just that the software being used clearly needs to be optimised for it and most things out there don't seem to be. So is there an optimised video player or a way of improving performance with configuration or patched software ?

Hi I just installed armbian on my rockpi 4c+ and wanted to check the temperature so I found that I should be able to run cat /etc/armbianmonitor/datasources/soctemp But that just gives the error cat: /etc/armbianmonitor/datasources/soctemp: No such file or directory It seems /etc/armbianmonitor/datasources/soctemp is a link to /sys/devices/virtual/thermal/thermal_zone0/temp but I have no /sys/devices/virtual/thermal/thermal_zone0 directory, under thermal I have ├── cooling_device0 │ ├── cur_state │ ├── max_state │ ├── power │ │ ├── autosuspend_delay_ms │ │ ├── control │ │ ├── runtime_active_time │ │ ├── runtime_status │ │ └── runtime_suspended_time │ ├── stats │ │ ├── reset │ │ ├── time_in_state_ms │ │ ├── total_trans │ │ └── trans_table │ ├── subsystem -> ../../../../class/thermal │ ├── type │ └── uevent └── cooling_device1 ├── cur_state ├── max_state ├── power │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_time │ ├── runtime_status │ └── runtime_suspended_time ├── stats │ ├── reset │ ├── time_in_state_ms │ ├── total_trans │ └── trans_table ├── subsystem -> ../../../../class/thermal ├── type └── uevent Guessing this is a bug? Both cur_state files yield 0 when cat them. https://paste.armbian.com/ekebicased I'm using the Armbian_v22.05.2_Rockpi-4cplus_bullseye_current_6.1.33_minimal.img image It seems I can find the same content under /sys/class/thermal/ as under /sys/devices/virtual/thermal/ I have also tried to install lm-sensors but it fails to find any sensors to read, after that i tried to use a rolling release, but it never fetched a IP, guessing the boot failed, but as I have no micro hdmi adapter I could not check what failed. Edit 2023-06-27 I downloaded the latest ubuntu server image from https://github.com/radxa/debos-radxa/releases/tag/20230201-0944 and there it seems to work, is there someway I can find what driver/process created the thermal_zone? After that I tested the latest armbian ubuntu minimal image, sadly it also lacks the /sys/devices/virtual/thermal/

Hi I found the following page https://www.armbian.com/rockpi4/ but I guess those files are for rock pi 4 and not rock pi 4 c? It has a link to 4 c plus images https://fi.mirror.armbian.de/dl/rockpi-4cplus/archive/ but they only contain bullseye? So are there any plans for rockpi 4 c plus to have a bookworm image? Are there any github pipelines that build them where I could send a pull request? (not that my c or c++ compilation skills are existing but I would be happy to give it a try).

Hi I have install the armbian system into my SSD device. But how can i manage to get it to start from that? The system dont seems to want to boot only from that SSD. I need to have the Micro SD inserted into the card reader for it to be able to boot. After that it seems to first boot up whit the SD card after that switch over to the SSD. How is that happening? NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 465.8G 0 disk └─sda1 8:1 0 461.1G 0 part /var/log.hdd / mmcblk0 179:0 0 29.8G 0 disk └─mmcblk0p1 179:1 0 29.5G 0 part zram0 252:0 0 1.9G 0 disk [SWAP] zram1 252:1 0 50M 0 disk /var/log zram2 252:2 0 0B 0 disk

Hello community, I am running Armbian taken from here on Radxa Rock 4c+. Everything I need seems to be in order (including wifi) but there appears to be no bluetooth device present (it is there using Radxa's images which have old kernels though). I tried to find out what could be the reason and noticed that dtb coming with Radxa has this: wireless-bluetooth { uart0-gpios { rockchip,pins = <0x02 0x13 0x00 0xd0>; phandle = <0xf1>; }; }; in pincntrl section and few other bluetooth/uart related bits while one coming with Armbian does not. I am not sure if this is the root cause and what the easiest way to fix it. I would appreciate any pointers on how to make bluetooth work. Thanks

Hello to everyone Trying to use armbian on RockPi 4C plus. Got kernel OOPS. Kernel crushes in different moments: mostly during systemd units starting or just after boot finished. Backtraces are different (no common). Faulty images: 1) From the https://www.armbian.com/rockpi4/ For Model C+ here: https://redirect.armbian.com/rockpi-4cplus https://mirrors.dotsrc.org/armbian-dl/rockpi-4cplus/archive/ Armbian_22.11.1_Rockpi-4cplus_bullseye_current_5.15.80_minimal.img 2) Built by myself Armbian_22.11.2_Rockpi-4cplus_bullseye_current_5.15.84_minimal.img Armbian_23.02.0-trunk_Rockpi-4cplus_bullseye_edge_6.1.8_minimal.img Armbian_23.02.0-trunk_Rockpi-4cplus_bullseye_edge_6.1.9_minimal.img Armbian_23.02.0-trunk_Rockpi-4cplus_bullseye_edge_6.1.10_minimal.img My image build script for the edge (6.1.x): #!/bin/bash BOARD_NAME_PARAM="rockpi-4cplus" LINUX_DISTRO_PARAM="bullseye" LOG_FILE="_armbian_build_${BOARD_NAME_PARAM}.log" BRANCH_VALUE="edge" log() { local currtime=`date +"%Y/%m/%d %H:%M:%S"` echo "$currtime: $*" echo "$currtime: $*" >> $LOG_FILE } log "$0 begin" ARMBIAN_BUILD_OPTIONS="\ BOARD=$BOARD_NAME_PARAM \ BRANCH=$BRANCH_VALUE \ FULL_DESKTOP=no \ BUILD_DESKTOP=no \ BUILD_MINIMAL=yes \ INSTALL_HEADERS=no \ KERNEL_ONLY=no \ KERNEL_CONFIGURE=no \ RELEASE=$LINUX_DISTRO_PARAM \ COMPRESS_OUTPUTIMAGE=\"sha,img,xz\" \ " log "ARMBIAN_BUILD_OPTIONS=$ARMBIAN_BUILD_OPTIONS" log log "====================================" log "Armbian build - starting ..." log "====================================" sudo ./compile.sh $ARMBIAN_BUILD_OPTIONS armbian_compile_result=$? if [ $armbian_compile_result -eq 0 ]; then log "====================================" log "Armbian build finished: SUCCESS" log "====================================" else log "====================================" log "Armbian build failed: ERROR" log "====================================" fi log "$0 end" exit 0 All the faulty images have common thing in /boot/armbianEnv.txt fdtfile=rockchip/rk3399-rock-pi-4c-plus.dtb As I found out there are 2 dtbs referring to rockpi 4cplus: /boot/dtb-6.1.10-rockchip64/rockchip/rk3399-rock-4c-plus.dtb /boot/dtb-6.1.10-rockchip64/rockchip/rk3399-rock-pi-4c-plus.dtb Vanilla kernel https://github.com/torvalds/linux/tree/master/arch/arm64/boot/dts/rockchip has rk3399-rock-4c-plus dts https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts and does not have rk3399-rock-pi-4c-plus I've changed /boot/armbianEnv.txt in the following way fdtfile=rockchip/rk3399-rock-4c-plus.dtb WIth rk3399-rock-4c-plus.dtb my RockPi 4C plus board boots fine and does not hang. I believe there is a mistake in dtb files. Why there are 2 dtbs /boot/dtb/rockchip/rk3399-rock-4c-plus.dtb /boot/dtb/rockchip/rk3399-rock-pi-4c-plus.dtb ?

Опубликовано: только что · Hidden - This content must be approved before it can be edited. HOT NEWS!!! With Armbian Armbian 23.02.2 Jammy with Linux 5.15.93-rockchip64 on (rockpi-4b plus v.1.72) Add (do it elso on all booting fevices = MMC, NVME, MPD, SD) the following lines to /boot/armbianEnv.txt overlays=spi-jedec-nor param_spinor_spi_bus=1 Reboot If you shorted 23-25 pins in 1.) then: disconnect them after the ROCK Pi 4 fully boot's enable spi-nor by executing (as root): echo spi1.0 > /sys/bus/spi/drivers/spi-nor/bind verify that the SPI mtd interface is enabled by running ls /dev/mtdblock0 if the last command does not list any file then something went wrong between 3.) and 5.) Run sudo nand-sata-install choose option: "Boot from SPI or MPD - system on SATA, USB or NVMe" choose NVMe partition, eg. /dev/nvme0n1p1 accept erasing of the choosen partition with "Yes" choose fs type (tested with ext4) wait a few minutes for rootfs transfer to chosen partition choose writing SPI bootloader with "Yes" confirm that you want to flash it with "Yes" wait ~60 seconds for writing choose Exit IN /boot/armbianEnv.txt choose your needing booting UUID, use command: sudo blkid it look like this: /dev/nvme0n1p1: UUID="ca927a6a-b2f0-4184-ab0f-5719e34172db" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="19354531-01" /dev/mmcblk1p1: LABEL="armbi_root" UUID="cfd67d21-5d00-4032-823e-b68830ca3543" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="22fbd54f-01" /dev/zram0: UUID="de7c0efa-e9cc-11ed-885d-c3fae5811b14" TYPE="swap" /dev/zram1: LABEL="log2ram" UUID="906b40da-e43c-4971-bff5-e9e402eada77" BLOCK_SIZE="4096" TYPE="ext4" in /boot/armbianEnv.txt look like it: sudo nano /boot/armbianEnv.txt verbosity=1 bootlogo=true overlay_prefix=rockchip fdtfile=rockchip/rk3399-rock-pi-4b.dtb rootdev=UUID=ca927a6a-b2f0-4184-ab0f-5719e34172db rootfstype=ext4 overlays=spi-jedec-nor param_spinor_spi_bus=1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Reboot Enjoy Armbian booting with SPI / NVMe sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash without pci2.0 in /boot/armbianEnv.txt verbosity=1 Category Test Result HDParm Disk Read 609.77 MB/s HDParm Cached Disk Read 726.72 MB/s DD Disk Write 232 MB/s FIO 4k random read 54613 IOPS (218453 KB/s) FIO 4k random write 16151 IOPS (64605 KB/s) IOZone 4k read 132479 KB/s IOZone 4k write 79127 KB/s IOZone 4k random read 54327 KB/s IOZone 4k random write 89006 KB/s Score: 19365 and with pci2.0 in sudo nano /boot/armbianEnv.txt verbosity=1 bootlogo=true overlay_prefix=rockchip fdtfile=rockchip/rk3399-rock-pi-4b.dtb rootdev=UUID=ca927a6a-b2f0-4184-ab0f-5719e34172db rootfstype=ext4 overlays=pcie-gen2 spi-jedec-nor param_spinor_spi_bus=1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Category Test Result HDParm Disk Read 579.83 MB/s HDParm Cached Disk Read 695.44 MB/s DD Disk Write 225 MB/s FIO 4k random read 57206 IOPS (228826 KB/s) FIO 4k random write 18720 IOPS (74881 KB/s) IOZone 4k read 131620 KB/s IOZone 4k write 79301 KB/s IOZone 4k random read 65461 KB/s IOZone 4k random write 117974 KB/s Score: 22989 All it tested on Brand:Samsung M.2 NVMe 980 Pro Board: Radxa ROCK Pi 4B plus v.1.72 hardware Device: Samsung SSD 980 PRO 1TB Class:SSD (M.2 NVMe) Изменено только что пользователем Cyrill PS. Создано с использованием материала от пользователя Igor, на этом же сайте и танцев с бубнами с материали RADXA. За что и благодарю, чем могу, сообщество и его верных пользователей.... на базе данного решения настроен NAS на базе urbackup server/client 2.5.31 - но это отдельная песня...

I have a Nebra hotspot with a Rockpi 4 plus v1.73 card. I can't find the Armbian image file to install Crankk mining. I only have 4A, 4B, 4C, and 4C+ img but no 4 plus. Help me! Is there a solution?

Hello, I am trying to boot my 4C+ from SPI. I soldered the chip and after adding "overlays=spi-jedec-nor" and "param_spinor_spi_bus=1" in "/boot/armbianEnv.txt", "ls /dev/mtdblock0" returns a result. After running "nand-sata-install" the entry "Boot from SPI - system on SATA, USB or NVMe" is missing.

I am using a Linux rockpi-4cplus with 5.15.93-rockchip64 (bullseye). I plan to use SPI1 (GPIO1_A7, GPIO1_B0, GPIO1_B1, GPIO1_B2), and then add in a 2nd device on this SPI bus via a custom CS GPIO pin (GPIO4_D5). I could not find the corresponding script file (.DTS) online (on Github) associated with the object file (rockchip-spi-spidev.dtbo). Please could someone point me to it - I can only find files for "sunxi-DT-overlays". So I decided to create my own DTS file, as follows: /dts-v1/; /plugin/; / { fragment@0 { target = <&spi1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; cs-gpio = <0>, <&gpio4 29 0>; status = "okay"; spidev@0 { reg = <0>; compatible = "spidev"; status = "okay"; spi-max-frequency = <5000000>; }; spidev@1 { reg = <1>; compatible = "spidev"; status = "okay"; spi-max-frequency = <50000000>; }; }; }; }; This compiles and I then added in my own DTBO reference inside armbianEnv.txt (under #overlays=). I also included param_spidev_spi_bus=1, as I discovered this is still needed (where is this check made, btw). When I reboot the following shows up for SPI in the device tree: /proc/device-tree/spi@ff1c0000/status: disabled /proc/device-tree/spi@ff1d0000/spidev@0/status: okay /proc/device-tree/spi@ff1d0000/status: okay /proc/device-tree/spi@ff1d0000/spidev@1/status: okay /proc/device-tree/spi@ff1e0000/status: disabled /proc/device-tree/spi@ff1f0000/status: disabled /proc/device-tree/spi@ff200000/status: disabled So far so good. Interestingly you have to use spidev@0 or spidev@1 in an overlay otherwise it won't compile. So already I am at odds with the current Armbian configuration setup logic (as per overlays readme text for using a different CS and armbian just relies on spidev and not spidev@...). I learnt from another Linux board that I can "bind" the spidev to the correct spi drivers and add in a script (e.g. within rc.local to automate). But first I needed to check what has been setup for the spi drivers. This is where I got a surprise. root@rockpi-4cplus:/boot$ ls -l /sys/bus/spi/devices total 0 lrwxrwxrwx 1 root root 0 Aug 5 2017 spi0.0 -> ../../../devices/platform/ff1d0000.spi/spi_master/spi0/spi0.0 lrwxrwxrwx 1 root root 0 Aug 5 2017 spi0.1 -> ../../../devices/platform/ff1d0000.spi/spi_master/spi0/spi0.1 My SPI1 reference in my device tree overlay (i.e. <&spi1>) was showing up here as spi0. How/ why so?? (In my opinion this messes other things up... as shown below when using Python). I assume you have done something similar as per sunxi-DT-overlays where you are using aliases (this really is unnecessary, IMHO) fragment@0 { target-path = "/aliases"; __overlay__ { spi0 = "/soc/spi@01c68000"; spi1 = "/soc/spi@01c69000"; }; }; I then bound these by using the following commands: echo spidev > /sys/bus/spi/devices/spi0.0/driver_override echo spi0.0 > /sys/bus/spi/drivers/spidev/bind echo spidev > /sys/bus/spi/devices/spi0.1/driver_override echo spi0.1 > /sys/bus/spi/drivers/spidev/bind Now after a reboot I get: root@rockpi-4cplus:~$ ls -l /dev/spi* crw------- 1 root root 153, 0 Apr 15 11:17 /dev/spidev0.0 crw------- 1 root root 153, 1 Apr 15 11:17 /dev/spidev0.1 I thought this was good enough. However, when I use Python3 together when SPI pin references it does not like it. It throws an error "OSError: /dev/spidev1.0 does not exist". Any suggestions.

Hi, An old problem, since I got the board which is 4C. Not a + - or whatever but the plain C. Symptoms: 1. HDMI worked randomly, maybe every 10th...15th boot lead to a working system, or rather to a visible HDMI-connection. But now switching on-off does not help at all. 2. Quite often one can get the board booting to the point where it asks for the password, and after clicking ok, it switches the screen off, and won't return. So the telly says that "no signal". 3. When switching on the board the tv set sees that there's someone on the hdmi port, and shows the booting sequence, and finally goes to Armbian's graphical mode asking for the password. Click "ok", and in 10 sec we are in the "no signal" -state. 4. And now guessing; when the board loses its connection to the tv set once, it will keep the hdmi feed down and it can not be woken up but by re-booting the board? Is there such a two-way feedback in-built? I mean, if the board does not recognize the tv, then it's stops sending video signal? And how to switch off this feature if there's one? Btw, I'm not a computer hobbyist so knowing not much about these, maybe just a (ab)user. I've been writing about this "feature" earlier to many platforms but no answer whether Armbian is programmed so that the board-whatever needs to "see" the receiving set all the time to keep its hdmi signal alive. This has 5.10.63-rockchip64 - kernel, the last one to have a working sound with this board. Well, not even sound now... And yes, this has a miniature hdmi -connector which maybe the culprit partly. It's very weak both mechanically, quite loose cable connection. If you twist-press the cable it may help to get the screen on, but now even this does not help anymore. And it's been tested with half a dozen cables so that's not the reason either.

I installed panfrost but glxinfo still lists the device as llvmpipe. I'm using Armbian_23.02.2_Rockpi-4cplus_jammy_current_5.15.93_gnome_desktop running wayland. This is how I built panfrost meson . build/ -Dvulkan-drivers= -Dgallium-drivers=panfrost -Dllvm=disabled ninja -C build/ ninja -C build/ install i have no idea what to do next because there is no errors that I can find and I was under the impression that with a kernel 5.1> it is supposed to work. Any help is appreciated

Having some issues here. I wrote the newest Ubuntu CLI to my SD card. I booted into the device and used Armbian-Install to move the root to the NVME. I fixed the UUID on the fstab file. I was able to boot up from the SD + NVME. I did an apt update + upgrade, that seemed to go well. I rebooted the device and it won't boot. I get this on the screen: 1.436035] Initranfs unpacking failed: broken padding 2.1982061 Kernel panic- not syncing: No working init found. Try passing init option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. 2.2177021 CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.93-rockchip64 #23.02.2 2.218474] Hardware name: Radxa ROCK Pi 4C+ (DT) 2.218962] Call trace: 2.2192211 dump_backtrace+0x0/0x210 2.219623] show_stack+0x18/0x28 2.219979] dump_stack_lul+0x68/0x84 2.220367] dump_stack+0x18/0x34 2.2207171 panic+0x190/0x368 2.2210441 _cpu_down+0x0/0x4e8 2 .221388] ret_from_fork+0x10/0x20 2.221769] SMP: stopping secondary CPUs 2.2221871 Kernel Offset: disabled 2.2225491 CPU features: 0x80082011,20000846 2.2230043 Memory Linit: none 2.223333]-I end Kernel panic- not syncing: No working init found. Try passing init option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.

I noticed today that there are no 23.02 images for the rockpi-4c. The images exist for the 4a, 4b and 4cplus variants but not the 4c. The 22.11 images are the latest for the 4c. The reason I noticed is that on the downloads page for the rockpi4 it is still showing 22.11 as the current images because that page is showing the 4c info, with links provided to the other variants. The fact that it still showed 22.11 caught my eye.