grixm

Thanks for the reply @laibsch . I looked for alternative solutions and it seems to be possible to only disable certain parts of PAM instead of the whole thing. Specifically it seems like the armbian dynamic MOTD is the biggest part of the problem. I opened /etc/pam.d/sshd , and commented out these lines to disable the motd: session optional pam_motd.so motd=/run/motd.dynamic session optional pam_motd.so noupdate And rebooted. This drastically improved the speed, from 5 seconds to around 2-3 seconds on first login and 1 second on subsequent logins. Still pretty bad though, what is there that needs to take one whole second or more to do to open a simple shell connection?

@usual user The USB and Ethernet ports are exposed, but how would that work exactly? I don't know how to make the software boot from USB or Ethernet and even if I did I don't know what to boot into that can write an image file to the emmc chip. I can find no info on this on radxa or armbian sources.

Every time I tried to log on to ssh on my rock-s0 with armbian, there would be a delay of like 5 seconds. I found a solution that fixes this problem. This thread is partly a PSA about this solution, and a question about whether this solution is a good idea or not. The trick is to change UsePAM=yes , to UsePAM=no , in the /etc/ssh/sshd_config file. But I heard some people online say this is a bad idea, but I don't understand PAM enough to know why. I am only going to use ssh in a basic password-authenticated, LAN environment. Do I really need PAM? The only side-effect I noticed is that it no longer shows the MOTD when logging in.

@usual user I don't think there is any storage device on the rock s0 other than the emmc that I can boot from. Other than SD card but that negates the point of not having the customer disassemble the device.

Hi. I have Rock Pi S0 boards that I install in an enclosure. It works, but it is conceivable that some critical bug or change with the image is discovered in the future so that customers later need to flash a new image to the emmc. But for them to do this, they would have to open the enclosure and locate the maskrom button, very inconvenient. Is there a way to trigger rebooting into maskrom from software instead of pushing the button? Apparently this is possible on the official radxa OS image by running command "reboot loader" instead of just "reboot", but not on armbian it seems. After investigating I see linux patches made by the rockchip team for kernel modules like “syscon-reboot-mode” and from the code I see something like that it’s supposed to write the value 0x5242C301 to the RK3308’s GRF OS register 0, and I guess this is supposed to be read by the bootloader to direct the boot to bootmask mode instead of the OS? But the armbian distribution is already built with this kernel module by default, and I even tried to manually write this value to the appropriate registers and then rebooting, and yet nothing works, it just boots to Linux like usual. Anyone have any ideas?

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.