I downloaded an image dated October 21st, and now it loads on the RG 34XX-SP, and even the “opening angle sensor” works, and Calamares doesn’t complain, but the D-pad doesn’t work, I tried restarting, but it didn’t help.
1 Like
Nice. I look mouse emulation with dpad later, somewhere should be differences with rg35xxh
Strangely, the d-pad buttons do not differ in designation, only the analog sticks were changed to 34xx-sp for some reason, including evsieve should work on the same config on all devices, which does not happen. I even decided to put the muOS from rg 35xx-h on 34xx-sp and all the buttons work. So the problem lies elsewhere… probably
Hello, I still don’t understand what could be causing the malfunction.
If the dpad works on rg35xxh, maybe you can figure out what the problem is as follows:
1. Set up the system on rg35xxh, connect to your home wifi
2. Change the dtb in extlinux to rg34
3. Connect the microsd to rg34
4. Connect to the console via ssh (ssh oem@ip-address).
5. Then you can check the service status (systemctl status evseive).
1 Like
hi, I was able to connect the device via ssh, but evseive.service is not installed on it, to check the status, I decided to install it through the git hub, but it wasn’t there, was that how I was supposed to do it?
Oh, now I found where is the problem was. Path for virtual mouse (/dev/input/by-id/) doesn’t exist if I not plug usb keyboard. You can replace path in evsieve service (/usr/lib/systemd/system/evsieve.service) to /dev/input/virt-mouse and restart evsieve service. After that dpad should work.
2 Likes
should I change the path in the evsieve.service document itself?
Yes, you can change in /usr/lib/systemd/system/evsieve.service from /dev/input/by-id/virt-mouse to /dev/input/virt-mouse
Then
sudo systemctl daemon-reload
and
sudo systemctl start evsieve.service
1 Like
I @junari Hello, I’m bothered by the installer crashing after starting the device. I tried to bypass the crashes, but nothing worked. I created a new image and it didn’t help. 20 days ago, I had a chance to launch without errors, but I didn’t pay attention to the crashes back then. Is there anything I can do about this?
1 Like
You can remove the installation program from autostart. I think, the resolution is too low for the calamares, you can try to connect to HDMI, and then you should complete the user configuration.
1 Like
-
Hello. I completed the OS installation, but I couldn’t install the Steam launcher. Previously, when launching Steam through Box64 (0.3.5), it gave an error about missing steamui.so components. When I updated Box64 (0.3.6), a different error appeared, for which I haven’t found a solution yet. I’ll attach the Bash logs for you to see. Please help me find a solution.
-
When using the device, the processor heats up to 80 degrees Celsius, which leads to throttling. Is there a way to cool the device, without the intervention of components?
-
[michael@anbernicrg34xxsp ~]$ box64 steam [BOX64] Box64 arm64 v0.3.6 nogit with Dynarec built on Jun 6 2025 17:12:23 [BOX64] Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL SHA1 SHA2 [BOX64] Running on Cortex-A53 with 4 cores, pagesize: 4096 [BOX64] Will use hardware counter measured at 24.0 MHz emulating 3.0 GHz [BOX64] steam detected [BOX64] Detected 48bits at least of address space [BOX64] Counted 81 Env var [BOX64] Library search path: [BOX64] Binary search path: ./:bin/:/bin/:/usr/bin/:/usr/local/bin/:/usr/local/sbin/:/usr/lib/jvm/default/bin/:/usr/bin/site_perl/:/usr/bin/vendor_perl/:/usr/bin/core_perl/ [BOX64] Looking for steam [BOX64] BOX64ENV: Variables overridden: BOX64_CRASHHANDLER=0 BOX64_EMULATED_LIBS=libudev.so.0 [BOX64] Cannot read ELF Header [BOX64] Error: Reading elf header of /usr/bin/steam-runtime, Try to launch natively instead [BOX64] Box64 arm64 v0.3.6 nogit with Dynarec built on Jun 6 2025 17:12:23 [BOX64] Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL SHA1 SHA2 [BOX64] Running on Cortex-A53 with 4 cores, pagesize: 4096 [BOX64] Will use hardware counter measured at 24.0 MHz emulating 3.0 GHz [BOX64] Detected 48bits at least of address space [BOX64] Counted 84 Env var [BOX64] Library search path: [BOX64] Binary search path: ./:bin/:/bin/:/usr/bin/:/usr/local/bin/:/usr/local/sbin/:/usr/lib/jvm/default/bin/:/usr/bin/site_perl/:/usr/bin/vendor_perl/:/usr/bin/core_perl/ [BOX64] Looking for /home/michael/.steam/root/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-steam-remote [BOX64] Rename process to "steam-runtime-steam-remote" [BOX64] Using native(wrapped) libglib-2.0.so.0 [BOX64] Using native(wrapped) libgobject-2.0.so.0 [BOX64] Using native(wrapped) libgio-2.0.so.0 [BOX64] Using native(wrapped) libgmodule-2.0.so.0 [BOX64] Using native(wrapped) libdl.so.2 [BOX64] Using native(wrapped) libpthread.so.0 [BOX64] Using native(wrapped) libc.so.6 [BOX64] Using native(wrapped) ld-linux-x86-64.so.2 [BOX64] Using native(wrapped) libutil.so.1 [BOX64] Using native(wrapped) librt.so.1 [BOX64] Using native(wrapped) libbsd.so.0 [BOX64] Error loading needed lib libsystemd.so.0 [BOX64] Warning: Cannot dlopen("libsystemd.so.0"/0x40e38a, 1002) steam.sh[2373]: Running Steam on manjaro-arm 24.04 64-bit steam.sh[2373]: STEAM_RUNTIME is enabled by the user setup.sh[2432]: Steam runtime environment up-to-date! steam.sh[2373]: Log already open steam.sh[2373]: Steam client's requirements are satisfied [BOX64] Error: Reading elf header of /home/michael/.local/share/Steam/ubuntu12_32/steam, Try to launch natively instead [BOX64] Error: Reading elf header of /home/michael/.local/share/Steam/ubuntu12_32/steam, Try to launch natively instead [BOX64] Error: Reading elf header of /home/michael/.local/share/Steam/ubuntu12_32/steam, Try to launch natively instead
Box64 from the repository does not contain box32, it definitely won’t work with Steam. I will compile a new version and test it with it.
You can try reducing the voltage, but this may cause the device to malfunction. In this case, the values are selected individually for each device. I can do this based on my device, but there is no guarantee that they will be suitable for your device.
I can also reduce the processor frequency, but the processor is already weak, so this will lead to a drop in performance.
1 Like
I tried cooling the device with a powerful phone cooler. I was able to reduce the peak temperature from 80°C to 65°C. I’m considering installing a thermal pad, but I’m not sure how effective it would be if placed between the battery.
I also have doubts about the correct operation of the temperature sensors. If you have an infrared thermometer, check it on your RG 35XX-H. I don’t believe that it’s 50°C when idle.
I would not recommend dissipating heat onto the battery, as this usually causes it to fail quickly.
dtbs with reduced core voltage: https://drive.google.com/file/d/1d6UN_86HyqAJxB2CYAuLySZQtLlsvhfX/view?usp=drive_link
You can try this. If device will stable I can reduce voltage more.
Also you can choose another governor (conservative or ondemand instead performance)
The temperature dropped by 10°C, meaning the maximum was 72°C without additional cooling (No artifacts or operational issues were found). What about the power mode selection, it’s locked for me.If you know which utilities are best for me to use for diagnostics, let me know and I’ll install them.
Nice, but we need more testing. Later I prepare another dtb.
You can chose governor something like this:
echo conservative | sudo tee /sys/device/system/cpu/cpufreq/policy0/scaling_governor
1 Like
after entering the command into bash wrote to me: tee: /sys/device/system/cpu/cpufreq/policy0/scaling_governor: There is no such file or directory conservative
I tried to assign echo [Performance, Powersave, Userspace, Ondemand, Schedutil, Conservative] | sudo /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor, but it was not written that there was no such file or directory, and the operation of the devices was unchanged.
Could governor not work due to missing dependency or incorrect file path?
Sometimes it happens that the device freezes completely after 10-30 seconds of startup (probably due to reduced power consumption)
Also installed Brave using yay, there are of course lighter browsers, but this one suits me completely satisfied with how it works.
Command should be: echo conservative | sudo tee /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
Yes, I also experience freezes. It seems that these bins require significantly more voltage at a frequency of 1.5 GHz. 1160 mV is the standard value for h700, while 1100 mV is sufficient for h618. Lowering it to 1100 mV causes freezes for me, as does 1120 mV. I’ll try other values. Another option for lowering the temperature is to fix the frequency to 1400 MHz. At this frequency, all CPUs in this family use a single voltage of 1100 mV and should work stably.
1 Like
Junari, hello! I tested six configurations and am ready to share. I tried to avoid inaccuracies as much as possible.
I’ll give sample recordings based on two tasks: idle: when the device is running without a single app open, only background utilities and the desktop. And during tasks: I couldn’t find a better benchmark than Java Minecraft, as I didn’t know how to test it in browser tasks, but I’ll try experimenting later. Under peak load, the device behaves identically (1512 MHz and 85 C). Except for Powersave, it simply chills under any load. I also found a pattern: the higher the frequency, the less load the processor experiences during idle.
- Performance: idle 57 C, 1.76 W, and 1.5 GHz. Operating: 78°C, 1.92W, and 1.5GHz.
- Powersave: Idle: 57°C, 1.79W, and a static frequency of 480MHz. At peak, the temperature remains at 60°C, and consumption is 1.79W. Performance has dropped, but not dramatically, by about 1.7-2X, no more.
- Conservative: Idle: 55°C, 1.73W, and 480MHz without spikes. During tasks: 77°C, 1.91W, and the frequency tries to hold at 1.5GHz.
- Ondemand (auto): Idle: 59°C, 1.81W, 480-720MHz with spikes. In tasks, 77C 1.89W and a fluctuating frequency of 720-1512 MHz, but tries to maintain 1 GHz, and core utilization fluctuates between 30-90%.
- Schedutil: 60C 1.81W and frequency fluctuations between 480-1512 MHz at idle. In tasks, 77C 1.89W and 720-1512 MHz, as in Ondemand mode.
- Userspace (1400 MHz): Idle 55C 1.77W at 1.4 GHz. In tasks, 67C 1.86W at 1.4 GHz. At peak load, 80C 1.83W at 1.4 GHz.
Hello! I tried flashing the latest plasma image using dd (sudo dd if=Manjaro-ARM-retroplasma-rg35xxh-25.11.img of=/dev/sda bs=4M status=progress conv=fsync) on my RG35XX-H but I can’t get it to boot with the default kernel and dtb. The green light turns on for a few seconds, but turns off shortly after without anything displaying on screen. Is there anything that I need to do other than flashing? I tried flashing uboot and ensured the dtb was pointed correctly. I could only get the screen to work (showed loading menu with the 4 Linux tux’s) when I replaced the default dtb & kernel with a prebuilt dtb and kernel from ROCKNIX, but the device turned off again shortly after. I think the issue is with the kernel & dtb, did you provide a different one than the one in the retroplasma image?
Quick note, I got NixOS working on this device using the ROCKNIX kernel & dtb but I couldn’t get the integrated gamepad to work, which is why I’m experimenting here with Manjaro in hopes of a working gamepad (joysticks & buttons)