

grixm
Members-
Posts
19 -
Joined
-
Last visited
-
Real-time Armbian, now that it is part of kernel 6.12?
grixm replied to grixm's topic in Advanced users - Development
Ooh okay, I see now. Thanks again! -
Real-time Armbian, now that it is part of kernel 6.12?
grixm replied to grixm's topic in Advanced users - Development
Thanks! Indeed I was able to compile it with a custom kernel, the preemption method option was in the system settings in the menu, and for good measure I also changed the system time slice resolution from 250Hz to 1000Hz in the power settings. It boots and seems stable so far, but I need to test more. And yes, also thanks for the tip regarding freezing the updates. Because after an "apt upgrade" it was indeed overwritten by a non-RT kernel. However I have one question regarding this, @Igor. How can I build Armbian for the latest possible version, since I'm not able to update it after building? When building, I checkout out branch v25.02, but it resulted in building 25.2.1, not 25.2.3 which is the latest. Small difference but still... -
Never mind, turns out it wasn't the overlays failing to be recognized after all, one of the overlays were simply wrong, because the base device tree had changed ("acodec" node had changed name to just "codec"). And if even just one of the user overlays was invalid, they all failed to load.
-
Turns out it wasn't the overlays failing to be recognized after all, one of the overlays were simply wrong, because the base device tree had changed. And if even just one of the user overlays was invalid, they all failed to load. If anyone reads this with the same problem after using my overlay: In rk3308-spi1-spidev.dts, you need to change the word "acodec" (in fragment@2 near the bottom) to just "codec".
-
@Meestor_X I see, unfortunately it doesn't seem to work for me. I don't use official overlays, just user overlays. Tried every combination of with or without prefix in the filename and in armbianEnv.txt and none of them work. I tried to monitor the boot process but I found that my TTL->USB adapter seems to be about 10x too slow for the baudrate used. In addition, I don't know if this is something you saw too, but armbian-config crashed when I try to enter the overlay config menu, with the message "Invalid overlay_prefix rk3308". Guess I'm stuck on 24.11 for the time being. Or I can try installing 25.2 from scratch rather than update, maybe it will be different.
-
Linux 6.12 mainlined PREEMPT_RT, real-time preemption. As far as I understand, one no longer needs to muck about with patches, the kernel can simply be compiled for real-time use with normal compiler flags on any common architecture. This makes Linux suitable for tasks with precise latency requirements, of which there is a lot of in the embedded space. Has anyone tried this on Armbian 25.2 now that it uses the 6.12 kernel? Does it work? How would one compile Armbian with it?
-
Hi. I have a Rock S0 that used to have Armbian 24.11 that I build from source, with these options: BRANCH=current BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=bookworm NETWORKING_STACK=network-manager ROOTFS_TYPE=btrfs I have installed three device overlays on this board for SPIdev and LED GPIOs. I shared these overlays in the Rock S0 subforum. They worked fine on 24.11 and earlier. But then I updated to 25.2 using apt upgrade. Now, my user overlays seem to be ignored. They don't do anything and it doesn't look like they were even attempted to be loaded, because I cannot find any reference to them in dmesg or anything. I tried removing them and reinstalling them using armbian-add-overlay, no difference. There may be a more deep problem with overlays here, because when I run armbian-config and try to navigate to the "manage device overlays" menu, the config utility crashes with the following message: Invalid overlay_prefix rk3308 Is this a problem with this Armbian version, or my specific system? How can I begin troubleshooting this? This is my armbianEnv.txt if it helps: cat /boot/armbianEnv.txt verbosity=1 bootlogo=false console=serial overlay_prefix=rk3308 fdtfile=rockchip/rk3308-rock-s0.dtb extraargs=cma=16M rootdev=UUID=4a1ebb0e-983c-4a88-9eff-cd80f5427d6c rootfstype=btrfs user_overlays=rk3308-spi1-spidev rk3308-spi2-spidev rk3308-user-leds usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
-
What did you do? I am also experiencing all my overlays breaking after updating the armbian version.
-
Guess I misread the schematic in that case. If the LED is already defined in linux and you know it works because you can change trigger to heartbeat, then you don't need the device tree overlay, the LED device is already defined correctly. I don't know what is wrong with the network trigger module in your case, but focus on that. You ran all the other commands in my first post too? It's not enough to set the trigger, you also need to write 1 to tx/rx/link etc and also write the network adapter name like "end0" or "eht0" or whatever you have to device_name. Check the actual device name with "ip addr" command.
-
@Meestor_X From what I can see in the schematic for the E20C, the Ethernet LEDs are wired directly to the Ethernet controller chip. Can not be accessed by the SoC/OS via GPIO, therefore there is nothing you can do to control their behavior. However I would think that it should just work out of the box, so there is nothing you need to do either. If it doesn't work then I dunno, ask Radxa or something
-
No I don't think it has ADC. But you can use the numerous SPI or i2c ports to connect an external adc.
-
They are not on the board, you must connect to the header. If you want to use the led on the board, you don't need the overlay
-
And here is one for SPI1: rk3308-spi1-spidev.dts
-
Hi guys, I created another device tree overlay that I needed, to enable two user leds on GPIO. Specifically GPIO0_B7 and GPIO0_C0, which is pins 27 and 28 on the header. Posting it here in case someone needs it, like I did with with the SPIdev overlay too. Here it is: rk3308-user-leds.dts What I needed this for is ethernet port LEDs, since the original connector does not include them. To get standard ethernet LED behavior on these newly defined LEDs, you can do this (you need su access): modprobe ledtrig-netdev echo "netdev" > /sys/class/leds/rock-s0\:orange\:user1/trigger echo "netdev" > /sys/class/leds/rock-s0\:green\:user2/trigger echo "1" > /sys/class/leds/rock-s0\:orange\:user1/rx echo "1" > /sys/class/leds/rock-s0\:green\:user2/link echo "end0" > /sys/class/leds/rock-s0\:orange\:user1/device_name echo "end0" > /sys/class/leds/rock-s0\:green\:user2/device_name (Change end0 to eth0 in the last two lines if you use ubuntu-based image instead of debian-based (minimal).
-
Hi guys, I got a SPIdev overlay to work on the rock S0, figured I'd just share it here for the record, since I could have used this info myself (I spent days trying to figure it out since I had no experience with device trees or whatnot). Basically, download the attached .dts file, then run sudo armbian-add-overlay rk3308-spi2-spidev.dts I also edited /boot/armbianEnv.txt and added this line, but I'm unsure if that's actually necessary? param_spidev_spi_bus=2 This worked on Armbian 24.5.1 Noble, creating /dev/spidev2.0. You can verify that it works using this tool: https://github.com/rm-hull/spidev-test The dts file is based on this one from radxa, however changed to "fragment@" syntax like other armbian overlays: https://github.com/radxa-pkg/radxa-overlays/blob/main/arch/arm64/boot/dts/rockchip/overlays/rk3308-spi2-spidev.dts Maybe this will also work on Rock Pi S, but haven't tested. rk3308-spi2-spidev.dts