grixm

I have long struggled with a problem with my Rock S0: If using the USB OTG port in device mode, the connection would suddenly drop randomly, minutes or sometimes hours after initialization. I spent months on and off looking for solutions, and I finally found one, so here it is if you ever find yourself having the same problem. Basically, it is caused by the SoC being very sensitive to voltage drops before the USB controller interprets it as the connection being lost. It's far more sensitive than it needs to be, given that my device is bus-powered and so the OS never actually needs to worry about a connection loss. If the connection is lost it is because I have unplugged the cable and so the device would be shut off regardless. Anyway, the solution lies deep within the RK3308's control registers, where I found the following: Three bits named "B_validsession reference tuning". There's no other explanation on what these bits does in the manual, but it sounded vaguely promising since I had been able to establish that "b-session valid" is actually the name of the status/interrupt that the vbus voltage affects in OTG device mode. Other registers related to the b-session valid status didn't work, however, including filter times, interrupt masks, force high bits, etc. But luckily this one register finally did the trick. The default value of these three bits are 000. Without any documentation I basically just had to guess what to do, so I tried setting them to 111 instead. And that seemed to work. It significantly lowered the voltage on the vbus pin required to trigger a disconnect signal. My connection was finally stable. Here's how you can do it yourself. First install memtool via apt, then run: memtool mw 0xFF008018 0x1C001C00

Ooh okay, I see now. Thanks again!

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).