grixm

Due to the shortage of memory chips these days, Radxa is using different emmc models in their boards. For example, I recently ordered a big batch of Rock S0 boards, but they had to be delivered with Sandisk iNAND 32GB emmc drives instead of the typical 8GB option. The problem is that Armbian did not reliably boot on these new boards. It randomly gets stuck during initialization with the onboard LED endlessly blinking. Some boards works, some did not, some only works sometimes. Long story short, in case other people also have this problem: I found the solution. I believe it is caused by Armbian's Rock S0 device tree enabling the HS200 high speed mode for the emmc device. (source) I guess not all emmc chips reliably support this. To fix it, I had to remove the line in the device tree linked in the source above. Actually this should probably be done with a proper device tree modification, but in my case, just to test, I modified the boot scripts. In /boot/boot.cmd, add these lines near the bottom, but ABOVE the "booti ..." line: fdt rm /mmc@ff490000 mmc-hs200-1_8v fdt set /mmc@ff490000 max-frequency <0x02faf080> Then recompile in terminal with: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr If you update the kernel/armbian distro these script will probably get overwritten, hence why it should preferably done with a custom device tree instead. But in my case I have frozen updates, and either way this will serve as a starting point for others having the same issue. Actually, I cannot see this troublesome patch on the 6.18 distro source, so maybe this is old news and no longer a problem on modern images anyway. But my image is still on 6.12, so I figured I'd share anyway.

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.