The new RK3588/RK3588S boards have much more power than we’ve typically had available to us in the past on ARM boards. With a whopping 8 CPU cores and a Mali 610 GPU the Orange Pi 5 is capable of running Steam using Box64/Box86. It’s even able to play basic games pretty well (with some tinkering usually).
In this guide I’ll show you how to set up Steam on the Orange Pi 5 and run Stardew Valley on it. You should keep your expectations in line though because there is no native ARM client for Steam. We are using emulation and instruction translation. You will also likely be missing libraries for most games you try which will require some fiddling.
This guide is only for Armbian running the Ubuntu Jammy variant with the Gnome desktop installedonly (platinum support status). The Orange Pi official distributions will not have 3D support and I don’t care about whatever other flavor of Linux you are running either. I’m not going to install your preferred flavor of Linux and try to figure out how to do this on there nor am I interested in troubleshooting it. Please don’t ask.
With all of that being said let’s get started!
Hardware Used
Orange Pi 5
The Orange Pi 5 the latest release from Orange Pi and is the most powerful model yet. It has a 6 core CPU and options from 4GB of RAM all the way up to 32GB of RAM!
The Kioxia (Toshiba) 128GB M.2 2230 PCIe NVMe drive is much shorter than most NVMe drives (full size is 2280). It fits great with single board computers / tablets / other smaller form factors.
The Geekworm copper heat sink set is designed to fit many different single board computers. It uses thermal conductive adhesive which many “cheap” heat sink kits for SBCs don’t have. Eliminates hot spots and reduces throttling. Can be further enhanced by powered cooling over the heat sinks.
The Orange Pi monitor is meant to be a portable monitor you can take anywhere. It has a resolution of 1080P and features a hinge in the back that folds out to support the monitor.
Next we’re going to install Box64. Paste the following lines in your terminal:
git clone https://github.com/ptitSeb/box64
cd box64
mkdir build; cd build; cmake .. -DRK3588=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo
make -j4
sudo make install
We also need Box86:
cd ~
git clone https://github.com/ptitSeb/box86
cd box86
mkdir build; cd build; cmake .. -DRK3588=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo
make -j4
sudo make install
We also need to install the 3D support drivers with the following:
Next we’re going to use Box86’s install_steam.sh script like this:
cd ~/box86
./install_steam.sh
Installation is now finished!
Launching Steam
I highly recommend running Steam from a terminal/console like this so you can see the error messages (especially when launching new games):
Armbian running Steam from CLI
It’s not unexpected for it to crash right after you log in for the first time. Mine crashed after I entered my one-time e-mail code from Steam. Simply launch it again. I had to log in again but it remembered the PC and stuck the second time.
It also crashed once when I installed Stardew Valley. I then just launched Steam again and it downloaded the game and launched perfectly afterward:
Orange Pi 5 running Steam and Stardew Valley
Conclusion
This is only the beginning of your journey. I can get you this far. You should expect most games you try to launch to crash with missing libraries. You then typically will install those libraries through apt (or other means) to fix it. In fact Stardew Valley wouldn’t have worked if I hadn’t added several dependencies to the dependency section. It did crash at first when I tried this and it took several hours for me to figure out the right dependencies to install for it.
If you are encountering really strange errors launching other titles you will want to use the trick I shared earlier of launching Steam within your console. You can then report such issues to the developers here on the GitHub issues page for Box64. There is a *ton* of helpful information there (and people) that can help with getting stubborn titles to launch. The developer ptitSeb is an absolute legend as well.
My performance was very, very good on Stardew Valley. It takes a while to load the game for some reason but it runs perfectly smoothly on the Orange Pi 5. Obviously this is not an incredibly demanding game on your GPU and I would recommend sticking to those.
I would absolutely also recommend active cooling on your Orange Pi 5. You at a bare minimum need my recommended heat sinks but even with my heat sinks I managed to overheat my Orange Pi 5 (forcing a power cycle) several times writing this article. If I was going to be gaming a lot more regularly on this device I would put a powered fan on it. The few times my system locked up I touched my heat sink and they were *very hot*. If you are getting lock-ups touch your heat sink (carefully) and see if it’s absolutely burning up. That means you need a powered fan.
Overall I’m pretty impressed. You’re going to have technical problems with various titles but this absolutely works. You can run games that aren’t super demanding at full speed and enjoy them on a 64-bit ARM board / distribution. Great work to all of the projects involved that have led to this being a reality!
It can’t even read the Steam 32 bit file so that would indicate something is wrong with the Box86 installation. You may also be missing binfmt-utils. None of that should be happening though after following the instructions.
Is this perhaps the official Orange Pi 5 Ubuntu distribution instead of Armbian? The error is indicating you can’t execute 32 bit executables on your machine which would point toward binfmt-utils or box86.
I just found the problem. In reality, i didn’t have some libc6, i386, armhf and amd64 architecture packages, i discovered this after doing sudo apt-get update, i always got errors saying that couldn’t find the packages at some specific links and blablabla. The links for the apt thing where almost all broken, they couldn’t find where these packages where, so here i go, pasting every single apt link that i had and try to find these packages, see if it wasn’t just a bug. And well, they really where not there, lmao. Searched for loads and loads of other ubuntu ports to see if these packages where anywere, and didn’t find anything. The links i used initially where the default ones that came with the armbian, so i don’t know why everyone else, like you, got it. Been searching for new links for all day, and can’t find anything. I am almost completely hopeless, and thinking about just going back to emulation on chrome os android. Spent more than 50 dollars on steam games and now can’t play them lol.
That should definitely get you access to those packages. It sounds like apt might be broken though. Can you try with a newer image potentially / a fresh download of Armbian with the Gnome desktop?
Already tried downloading armbian again after your last reply, also didn’t miss any step. I’m gonna wait for someone out there create an modified version of a linux dist with steam and box86/64 already installed, the Rock Pi 5B already has one.
Exactly the same error happens to me.
I am using armbian and followed all the steps except the 3D drivers install section, as I had them installed already. No errors whatsover, but can’t execute steam cause the file format error.
@James, please could you try to follow your guide in a new armbian installation to see if is still working or something has changed to prevent it from working, thanks
Hey James, just to let you know I installed steam (over the previous broken installation) using this script and it worked. Actually I reinstalled box64, box86, winex86, winetricks and steam
Sad part is that I only wanted steam to stream games from my pc, but audio is cracking all the time (tried to change the sample rate on the client to 48khz as some people suggested with no luck tho)
Thanks for sharing the link! You’d think that streaming from your PC would require a lot less resources (it should). Hopefully that is something that becomes easier to do because streaming from your PC to an ARM platform would have a lot of great uses for a lot of people.
Dony Nomad
11 months ago
why after updating system like “sudo apt update && sudo apt upgrade” the launcher always can’t run? the upgrade was including box86 upgrade. But after reinstall from begin it always work again? any trick to avoid this unless I didnt do upgrade? thanks
This guide does not use apt to install box86 or box64. We build it from source. It should not be updating through apt or updating at all. You’d need to rebuild it from source to update it.
It sounds like you already installed box86 from apt before following this guide. Just remove it. Remove the box86 packages from apt as that is not how this guide works. After that it will no longer update it anymore.
Hopefully that helps!
Hste
1 year ago
Have you seen this
Fedora 39 Looks To Boost vm.max_map_count To Help Windows Games With Steam Play
Maybe setting up this value will help some games to run
By the way I’m seeing more Orange Pi 5B content shared online and I’ll admit its looking good as the preloaded Orange Pi Droid supports Wifi/BT yet still no GApps but I read that eMMC speeds are near those of the NVMe so well done to them and hopefully it gets the same support as the OPi 5 which has been a real success!
That is an awesome video, thanks for sharing that! I’m really glad to see people embracing alternative boards.
I still get a lot of resistance when people comment on my Raspberry Pi articles on SSD booting about how miserable of an experience it is to use SSDs with the Pi and I tell them that the Raspberry Pi is completely obsolete for that (and most things). Even for people using the 5B though the eMMC is pretty fast apparently (about as fast as any SSD setup on the Raspberry Pi). I can confirm those have been scoring really well on pibenchmarks.com.
Today is the last day of my first full work week as an IT engineer. It’s 8am-5pm though with about a 30-35 minute commute each way though so it’s a very long day and not leaving a lot of time for the site. I’m still going to try to make it work though with the site and keep doing content. I just need to get into a rhythm and probably try to publish an article on the weekends as I continue to get settled in.
Its thanks to people such as yourself and Lee who happily impart knowledge so average users such as myself grow to embrace alternatives outside of the Raspberry Pi so here’s hoping you find a perfect balance as I’ll admit I miss the regular content but totally understand time restraints so best of luck and hope to se new content soon, even if its the odd weekend post!
naron23vrn
1 year ago
orangepi@orangepi:~/box86$ mkdir build; cd build; cmake .. -DRK3588=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo
-- Found Python3: /usr/bin/python3.10 (found version "3.10.6") found components: Interpreter
-- The C compiler identification is unknown
-- The ASM compiler identification is unknown
-- Didn't find assembler
CMake Error at CMakeLists.txt:77 (project):
The CMAKE_C_COMPILER:
arm-linux-gnueabihf-gcc
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
CMake Error at CMakeLists.txt:77 (project):
No CMAKE_ASM_COMPILER could be found.
Tell CMake where to find the compiler by setting either the environment
variable "ASM" or the CMake cache entry CMAKE_ASM_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Warning: Did not find file Compiler/-ASM
-- Configuring incomplete, errors occurred!
See also "/home/orangepi/box86/build/CMakeFiles/CMakeOutput.log".
See also "/home/orangepi/box86/build/CMakeFiles/CMakeError.log".
You either skipped the dependencies section or ignored that these instructions are for Armbian only. Given that the username is orangepi I would assume you are using one of the official Orange Pi operating systems instead (and probably not Debian).
The error says you didn’t install any of the dependencies that I said to. I also said that these instructions are for Armbian and that I’m not interested in supporting whatever random operating system you decided to use (which you didn’t mention).
I suppose the answer is that you either ignored the operating system requirements, ignored installing the dependencies or both. Either way I can’t really help with this.
Romain M.
1 year ago
Hi James,
Woaw incredible … I’ve been trying to install Steam on my Orange Pi5 with Armbian Gnome for the whole week!!!
I think I was missing some of the dependencies and the DOTNET environment variable for Steam.
I totally understand. This isn’t one of my longer articles but it took me the entire day to get it going. I never found any guide or anything online saying how to do this. I had to piece it together from the developer’s GitHub issues pages. It was just passing references like you needed to have both Box86/Box64 installed but nobody really showing how you’d do that.
The most helpful part was that Box86 had that Steam helper installer script. That was the big breakthrough for me as I had quite a mess going before that. I had a Steam install so broken I ended up reimaging altogether and the helper script really smoothed out my next attempts. I could have easily been stuck on this for weeks if I didn’t happen to find an issue thread that the developer specifically mentioned that you should build both from source and then run the Box86 Steam installer script:
I don't have steam stability issue on my side.
Did you build box86 & box64 with the "-DRK3588" switch?
did you install steam using the steam_install.sh script for box86?
That was literally the breakthrough for me. After that I just had to spend a couple of hours finding some additional Stardew Valley dependencies (probably a lot of which will help with other games as well). The DOTNET variable got rid of a really nasty error related to locales and unicode. It doesn’t seem to have many negative consequences as apparently when you use that environment variable it just uses your local system’s timezones / locales (should be fine even for people not using English).
Thanks so much for leaving this comment, enjoy and take care!
Sorry for the delay … Yes I was compiling box86 and box64 from source too like it is indicated on box86 github page.
I was also using there script … even if a couple of days before I also tried to install it by myself from steam .deb installation file.
Lastly I tried to repeat the installation from you guide … it seems to work everytime … except with OrangePi5-ubuntu image I didn’t had success.
I tried 2 times with OrangePi5-debian-xfce and I think that I am going to keep this setup.
With Armbian It was working … but I didn’t had good results with “glmark2” benchmark and with “wirple” website benchmark … even if the panfork drivers were installed!
Chrome was also showing “Software Only. Hardware acceleration disabled.” in “chrome://gpu” page.
So I wasn’t sure if the running games on steam were using the hardware or the software acceleration.
And when chrome was showing “Harware accelerated.” and I was able to have good results with “glmark2” benchmark and “wirple” website benchmark on Armbian … then my steam games were not running at all (even with Proton).
With OrangePi5-debian-xfce, the panfork drivers are already installed … so the setup is a bit easier.
I noticed that Steam is more stable with it, but maybe because there was an update with box86 recently (2 days ago) for steam stability.
I don’t need to use Proton or subscribe to Steam Beta participation to run my steam games (I needed to use these 2 options with Armbian).
Were you using these settings (Proton, Steam Beta Participation) in order to run your games ?
Great questions and results! So no I didn’t use Proton or anything like that. It’s running completely natively through Box64/Box86. No betas enabled. I also did this on the Radxa Rock 5B and the process is pretty much identical. I did not have any crashes on the Rock 5B. That’s probably because of the stability update that happened like you suggested.
The results you are seeing in the synthetic benchmarks and browser acceleration are pretty interesting. Basically I think what you are running into is that there are a *lot* of different types of 3D acceleration. Each game is going to use different libraries and different technologies altogether. That’s why your browser can show unaccelerated for some categories but the games will still receive full acceleration or your benchmarks may be fine.
Even the browser has a bunch of different categories. There is OpenGL, Vulkan, rasterization, compositing, and a whole bunch of other categories. Games also use all of these technologies but not all games and each game will use different ones.
I did not need Proton or the Steam beta on either the Orange Pi 5 or Rock 5B with Armbian for what it’s worth. I did a clean image as I showed in the guide with the public release from Armbian’s site for both boards and only ran the commands I posted in the article. I’ll definitely check though because maybe my Proton settings carried over. Maybe it was on and I didn’t realize it.
I guess the question is which games are you running specifically? I tried running Portal on the Radxa Rock 5B and that didn’t work. Proton might have made it work. On my main x86_64 PC I use Proton (in Linux running PopOS!). I didn’t use it on ARM though. To get my games to work like Stardew Valley I showed in the guide involved installing additional dependencies for the games. I tried some other games like Pony Island and they ran fine as well. Portal was the one that I was thinking of trying to get to work next as if Portal will run I’d imagine most of the other Valve and Source engine ones would too.
If *all* of your games are working in Armbian when turning Proton on then I’d imagine that would be the next step most people would want to take trying to run more demanding games. That’s interesting that the xfce version already has the Panfork drivers installed. I didn’t see them on there running when I did a lsmod. I did try with the official Orange Pi 5 Debian distribution originally and it was so slow I wiped it and put Armbian on there. I might have had the KDE Plasma variant instead (I think it was). That one was definitely slow as molasses without the driver support.
To know if it’s really running do a lsmod and you should see Panfrost:
root@homeassistant:/boot# lsmod
Module Size Used by
gpu_sched 28672 1 panfrost
If you don’t see the driver loaded it’s not doing it (at least the Panfrost stuff). I’ve never seen Orange Pi package the firmware in one of their official images before. I will have to try that one and see if it’s really loading the driver. There are a *lot* of components to the driver that need to be present for sure for it all to work (including the firmware). On the Radxa Rock 5B there are even more packages available (such as kodi) that enable video hardware acceleration for example.
It’s honestly such a mess in Linux to get acceleration working. Even my main Linux desktop running a NVIDIA RTX 3090 shows a bunch of the Chrome acceleration methods as failing or disabled (such as Vulkan, WebGPU, Canvas out of process rendering, raw draw and direct rendering display compositor). There’s no doubt packages I could install on my main desktop that would fix some of these categories. Just installing the panfrost driver (or an NVIDIA driver in the case of a desktop) isn’t going to turn everything on. There’s a lot more to it than that.
I’d suggest comparing it with your Linux desktop on other things as well as some of this stuff is quite difficult to get enabled (and most people won’t notice it’s not present unless things are chopping). Take a look at my *desktop*’s failing components:
WebGPU has been disabled via blocklist or the command line.
Disabled Features: webgpu
Accelerated video encode has been disabled, either via blocklist, about:flags or the command line.
Disabled Features: video_encode
Program link fails in NVIDIA Linux if gl_Position is not set: 286468
Applied Workarounds: init_gl_position_in_vertex_shader
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Linux NVIDIA drivers don't have the correct defaults for vertex attributes: 351528
Applied Workarounds: init_vertex_attributes
MakeCurrent is slow on Linux with NVIDIA drivers: 449150, 514510
Applied Workarounds: use_virtualized_gl_contexts
NVIDIA fails glReadPixels from incomplete cube map texture: 518889
Applied Workarounds: force_cube_complete
Pack parameters work incorrectly with pack buffer bound: 563714
Applied Workarounds: pack_parameters_workaround_with_pack_buffer
Alignment works incorrectly with unpack buffer bound: 563714
Applied Workarounds: unpack_alignment_workaround_with_unpack_buffer
Framebuffer discarding can hurt performance on non-tilers: 570897
Applied Workarounds: disable_discard_framebuffer
Unpacking overlapping rows from unpack buffers is unstable on NVIDIA GL driver: 596774
Applied Workarounds: unpack_overlapping_rows_separately_unpack_buffer
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Expose WebGL's disjoint_timer_query extensions on platforms with site isolation: 808744, 870491
Applied Workarounds: enable_webgl_timer_query_extensions
glTexStorage* are buggy when base mipmap level is not 0: 877874
Applied Workarounds: reset_base_mipmap_level_before_texstorage
Some drivers can't recover after OUT_OF_MEM and context lost: 893177
Applied Workarounds: exit_on_context_lost
adjust src/dst region if blitting pixels outside framebuffer on Linux NVIDIA: 830046
Applied Workarounds: adjust_src_dst_region_for_blitframebuffer
Disable GL_MESA_framebuffer_flip_y for desktop GL: 964010
Applied Workarounds: disable(GL_MESA_framebuffer_flip_y)
Absolutely fantastic work and observations. I’m curious now if I turn Proton on if Portal will run without having to install additional dependencies. I’ve only tried a handful of games so far and I just assumed it would all be dependencies. Perhaps Proton is a really good answer for this though. Hopefully that helps!
This morning I tried to install Epic Games client inside Steam via the option “Add a Non-Steam Game to My Library”. But it seemed like I couldn’t not see my library on “Large Mode” on my Debian “OrangePi” version.
Also … the “Big Picture Mode” was not working at all!
So I told myself let’s get back on “Armbian” and do some test for James! haha
First test I did exactly what is written in your guide (like I did in the past) … same problem … everything works fine (installation, updates, upgrade) … but games do not work.
I am testing with “Despotism 3k” and “Totemori” as I doesn’t have “Stardew Valley” in my library. I also checked with the “lsmod” command and I have the exact same output as your were showing.
Then I did a second test … but this time in your “exports” section before installing steam I added this one to the list “export PAN_MESA_DEBUG=gl3”. I read on box86 github page that it could fix Unity games that do not starts.
It did not only fixed all my problems … but also improved my gpu performance x10 or x20!!!! (I think that it was in real running my games with software acceleration when I was testing with Debian or Armbian+Proton)
The 2 games I was testing are now running fast in fullscreen mode without touching to the graphical settings.
I put this setting because when launching these 2 games I remembered seeing the “Unity” logo on game starts.
I think I’m ready to test something like “Dirt” now ?! hahaha
By the way … do you also have better performance on your side if your add this environment variable ?
Great findings! So Stardew Valley uses OpenGL 2.0 which is likely why it’s not requiring additional parameters. It sounds like this setting fixes Unity games really well! Thanks for confirming the panfrost driver is indeed running on the xfce flavor of Debian as well. That is surprising as those are beta drivers/builds (which is why you need to add that weird PPA for most distros to get them). It sounds like Orange Pi did indeed build in a version of them into the xfce flavor though (a very good thing).
There’s a lot of variations of those settings you can use too. For example if you take a look at the Box86 list of compatible games you’ll see that they have tags for OpenGL 2.0, OpenGL 3.0+, and a whole bunch of other things. Neither of the games you mentioned have been reported on that site yet so those aren’t even in the 300 reported ones yet. It’s an extremely useful resource though as you can look for similar games on there and often people will give you hints/answers about what flags get those titles working.
I actually see a lot of people recommending this line for OpenGL 3.0 games in the issues threads:
PAN_MESA_DEBUG=gofaster,gl3
Perhaps this will increase the speed even more? In fact I can’t find anyone not recommending using both. I’ll definitely add this to the guide’s environment variables because I can just see in the issues thread that it will fix a ton of issues on various games to add that. Apparently even Valheim will run with these two flags enabled.
So honestly there is no setting that is going to make all games work. There’s a lot of games that just won’t work. You can see a list of about 300 games at the above link and there’s still quite a few that won’t work. That’s definitely why I asked which games specifically you were running. If you are looking for the perfect setting to fix everything there’s no such thing for sure. They all use too different of technologies. We *can* however knock out entire categories of game engines such as Unity and I think that you’ve just done that here!
It looks like “Dirt” uses the Ego engine. That sounds interesting. I don’t see any reports on it on the Box86/Box64 compatibility list issues thread so I’m not sure if this has been tried yet. I tried to search for what the Ego engine uses (OpenGL 2.0, OpenGL 3.0+, etc.) and there doesn’t seem to be a lot of information out there about it. That would definitely be an interesting one to try!
I suspect what is happening is that Stardew Valley uses OpenGL 2.0 and it’s definitely being accelerated without additional environment variables. If you have no acceleration it can’t run Stardew Valley at more than like 10 fps. Perhaps it will improve it even more by forcing OpenGL 3.0? I gave it a try but it’s hard to tell since it was already running at full speed.
I did try Portal to see if this would fix launching Source engine titles. It did not. I also tried Half Life 2 and Team Fortress 2 and also no dice. Source engine titles are still a no-go without more settings/dependencies of some kind. I think it’s fixable though. I saw someone got Portal 2 running but it was completely unplayable on their board (which was not a RK3588/RK3588S) but Portal 2 is a lot newer so that didn’t surprise me. I feel like Portal has a chance of running pretty decently since that’s quite an old title now at this point. I just haven’t cracked the setting/dependency for the Source titles to work yet here.
Interestingly the *original* Half Life (1998) did work. That is the only Valve title that I could launch that I’ve tried so far and it actually ran really well! It’s not that impressive though since it is a 1998 title but it’s fun that one is working on there now with these changes.
I did test Valheim though since people said that was working and Valheim did work! The FPS is extremely low on a Rock 5B or Orange Pi 5 but I wasn’t expecting otherwise for that title. Even regular PCs have a hard time with Valheim without a decent GPU (I wouldn’t call it a super optimized title). Skyrim Special Edition won’t even attempt to install on there saying invalid platform (interesting, since I run that one on my x86_64 PC in Linux just fine). I haven’t tried the original Skyrim yet but that game is so old now there’s a chance it may run.
I’m not sure how many games you own but if you have a fairly large SSD I would try just installing a bunch of them to find ones that aren’t working. I’d be very interested in how the Dirt title on the Ego engine goes since there’s no reports for that one yet that I could see. I’d imagine though that we’re probably only a few tweaks or dependencies away from 90%+ of these being able to run though. I think we are getting really close. The Box86/Box64 team has been doing a great job fixing these as they are found as Steam running as well as it does is a pretty recent development and took significant effort from the main Box86/Box64 developer. The recent stability update seems to have helped as well.
I’m extremely grateful to you for sharing this flag with me and keeping me in mind! Definitely let me know if you find more of these types of settings that improve performance or enable an entire branch/engine of games to start running. I think there’s still a few more flags/dependencies out there for us to find but it is a huge victory to have most (if not all) of the Unity games working with this flag. I’m happy to add anything like this to the guides as my goal is to get people up and running with as much compatibility as possible.
Hi there! Great guide! I bought the OPi5 mainly for server-purposes and maybe as a Kodi Media Player. But holy heck, I couldn’t resist testing this!
I’ve managed to get Half Life 2 and Counter-Strike Source working!
FYI: I followed your guide from scratch, then tried these and they didn’t work. Then tried the original Half Life and Counter-Strike, both worked with major texture/whatever-grafics issues. So I looked up the command line output and I installed a couple of libraries in hope to fix these issues. It didn’t fix them, but suddenly Half Life 2 and Counter-Strike Source worked! 😉 I’m not quite sure which library was needed, but I didn’t do anything else, so you can focus on that.
Apart from that Half Life 2 and Counter-Strike Source are performing really well with your instructions/configuration and a lot better than their original counterparts. In Counter-Strike Source I also get some texture issues, but they are less annoying than in the original. Sadly these games are always crashing after some short time which mostly seem to have to do with memory allocation. I have an 8GB OPi5 version, while in-game htop shows 6,XXGB used up ram for the most time. I’m not quite sure if it’s not enough or if it’s an panfrost/box86 memory allocation issue. Lowering the display resolution und texture quality only seems to help a bit.
Funnily, some of these issues/crashes I’m having are getting recognized by the Valve Anti-Cheat System and I got blocked multiple times for a short period.
Speaking of cheating, I want to ask you about this benchmark.
How is this result even possible? Compared to all the other scores it seems to be way outside of realistic results. What’s so special about that WDdrive/configuration? I wasn’t even able to reproduce my highest score at 23,782 which seemed to have been an outlier also, after that my results were always somewhat below and I didn’t send them in.
Thanks for letting me have some fun after years of abstinance!
Welcome back! That’s fantastic that you got HL2 and CS:Source working. That’s pretty much the process I used to get most of mine working. Do you remember which dependencies they were? If so I can add them to the guide for sure. Maybe my RAM is the issue since I’m only using the 4GB version. Perhaps that one doesn’t have enough RAM to even launch. If you happen to remember the dependencies though I’d love to try installing them on mine as well and see if I can get it to launch!
That’s wild that the anti-cheat is pretty unhappy. My guess is it’s because of the textures. It’s probably seeing that as some kind of x-ray vision/wallhacks. That’s a very traditional hack where people would delete textures or make them transparent so they can see people behind walls. I’d imagine the texture thing is what is throwing it.
So that’s a great question about the score that is much higher than everyone else. It’s the RK3588 (not RK3588S) version of the Orange Pi 5 (unreleased):
This board was apparently leaked on Discord. It’s not available yet or even announced but the score you are looking at is a RK3588 score. Look at the Radxa Rock 5B scores. It’s identical to them. The RK3588 has PCIe 3.0 while the RK3588S only has PCIe 2.0. That’s why it’s faster.
It does not surprise me to see that score in the slightest since the board is out there enough for those leaked pictures to make it to my site weeks ago (maybe even more than a month ago). It’s exactly where it should be for a RK3588 vs. a RK3588S. I bet we’ll continue to see more of these popping up. No, it’s not possible to get a score like that on the original Orange Pi 5 with PCIe 2.0. It has to be the RK3588 with PCIe 3.0.
Unfortunately it doesn’t look like the board is going to identify itself as anything other than an Orange Pi 5. This does not surprise me either as they’ve already released the Orange Pi 5B and it only identifies itself as the Orange Pi 5 as well. That’s probably because on most Orange Pi boards the operating system is what identifies the board. There definitely are not separate operating system downloads for the Orange Pi 5 vs. Orange Pi 5B and I doubt there will be for the Orange Pi 5 Plus either.
Your score is basically as good as it gets with PCIe 2.0. I wouldn’t lose sleep over that top score. There’s going to be more of them as more people get the beta version of the Orange Pi 5 Plus (however they’re getting it). They’re probably Orange Pi insiders / testers.
In other words are they cheating? Yes, they’re cheating. I know exactly how though in this case. Someone has their hands on the Orange Pi 5 Plus somehow. Orange Pi is making it easier for them by not distinguishing these boards in the model # and it’s already a problem with the Orange Pi 5B as well. The RK3588 always reports itself as a RK3588 whether it’s the RK3588 or RK3588S as well which is annoying. It makes it extremely difficult to detect what they’re really using. It’s also possible they installed the Orange Pi 5 operating system on a Radxa Rock 5B but that’s something I wouldn’t really expect to work without issues. I think it’s more likely someone with the Orange Pi 5 Plus took the benchmark.
Fantastic work! Let me know if you remember which dependencies you think may have fixed this. I’d love to try it and add them to the guide/article if you’re able to remember which ones they were.
Oh man, pinpointing the relevant library was easier said than done!
I did ‘apt remove’ all former installed packages sequentially and ‘apt automove’ their dependencies. The Source games still worked. I must have missed some installation.
To get rid of all armhf I did an ‘apt remove \*:armhf –allow-remove-essential’ and made a list of those packages. Then I reinstalled all packages via your instructions. After that a ‘apt install’ of the recorded list gave me a dozen remaining packages which I had to check individually until I figured out that the only additional armhf package needed for the Source games run is libudev-dev:armhf.
You might want to check it yourself first before you add it to your guide. I didn’t do a fresh install, so maybe a arm64 package might also be needed, I can’t be sure.
Your 4GB RAM vs my 8GB will most probably be an additional issue for you. I don’t know if that stuff can be swapped. I’ve never seen the usage of 7.XXGB RAM in htop while Steam-gaming because it always crashes/freezes before that (at ~6.XXGB). Maybe a 16GB version is needed to avoid this with the current configuration.
Disregarding the crashes/freezes of the Source games the texture/graphics issues still remain in HL,CS and CS:S, but HL2 works awesome!
Great info about the yet unreleased Orange Pi 5 and other possibilities.
But I’m not sure if you’re right about the potential RK3588 score (instead of RK3588S). If you compare this Top-OPi5 score with Top-ROCK5B scores like this or this you can see the major difference in DDwrite and HDParm results which is the indicative PCIe2/3 distinction and overall higher FIO/IOZ values in general. The Top-OPi5 score still looks like a PCIe2 in this regards. It’s quite strange that these have such similar end-results. I don’t know of the individual parts weighting.
Maybe the WD drive is just made of better quality parts or the score’s configuration is somewhat tweaked in other regards.
Anyways, testing all of this is a lot of fun. I’m eagerly expecting a main line kernel!
The DD write test is a pretty poor indicator. It’s the least weighed out of every single test. The random read/write tests are weighed literally 4x heavier and there’s a lot more of them. The main reason for this is that computers rarely have the benefit of doing giant sequential writes. Pretty much the only time that even happens is when you image the disk or perform some kind of backup. Sequential read/write performance isn’t very useful for daily usage though as the most common I/O operations on any drive running an operating system are random read/write. Writing to log files here, reading a config file there, etc. dozens of times per second. This is why raw DD write is weighed so low.
Manufacturers *love* to talk about their sequential read/write scores all day (which is exactly what DD write as well as HDParm both do, sequential block by block I/O only, and it’s why those aren’t serious storage benchmarking metrics). That’s because it’s easy and there’s all sorts of optimizations/tricks they can do to raise those scores. They really start to squirm if you ask about the random read/write performance though. Why? Because getting high random read/write performance requires a high quality storage controller as well as a large and high quality cache. Those are both expensive which means manufacturers don’t want to put them in the drive. Very few companies even give their random read/write performance scores and when they do it’s because they know they spent the money to put high enough quality components in it and are proud of it.
In other words you’re basically right that it’s the quality of parts that can make a difference here. The cache and storage controller explain a lot of the performance differences between many of these drives. It’s still a huge outlier though. The DD write won’t tell us much though about the performance. I can pick ones from all over that are way higher on the Orange Pi 5 and way lower on the Rock 5B and they’ll be pretty close to the average score since that test is the least weighted/important benchmark it runs.
The caching is also why your score goes down when you take it over and over again. That very first run tends to have a lot of caching going on. It doesn’t take the drive long to figure out though that caching that one-time sequential write operation wasn’t a very effective use of the cache. It starts to cache other things like the files/data your OS is really dealing with. The point of the cache is to speed up things that are frequently accessed over and over again. It learns from this while it’s running and the only way to make it “forget” is to power off the device completely so that the cache is completely lost. You can then trick it into caching aggressively one more time when you reboot it up and then the scores will progressively drop until you power cycle it again and the cycle repeats itself.
It’s actually a good sign of quality if the score is dropping on sequential runs. While it can be frustrating for benchmarking what it really means is that your storage controller and cache is smart and spending the limited resources on things that will make the system I/O much more responsive (think like your main OS files/logs/etc.). That’s why you’ll see drives that are clearly inferior to yours putting out high DD write scores a lot of the time. It means it probably has a pretty low quality cache that is spending way more time caching sequential I/O than it should be. The storage controller might not even be keeping track of what is effective to cache and is just throwing whatever in there. Those drives always have lower random read/write scores which is why they won’t outscore you overall. They can beat better drives on the DD write score (and HDParm) a lot of the time pretty consistently because they have a “dumb” storage controller / cache setup going on.
Time should tell if this is the Orange Pi 5 Plus. It sure looks like a RK3588 score to me though and looks a lot more like the average Rock 5B benchmark (DD write and all). There are way more tests for the Orange Pi 5 (902 for the Orange Pi 5 vs. 86 for the Rock 5B) and nobody else has ever come even close to this. DD write can’t answer this question for us though and neither can the inxi report unfortunately as since it’s not mainline kernel support right now this stuff is all whatever Orange Pi codes into their images and custom drivers (and they aren’t coding the model variations between their different models, more like just putting the family of Orange Pi 5).
I can say definitively it is not like the other 901 benchmarks we have so far and the only comparable ones belong to the Rock 5B. It might actually be a Rock 5B if it’s possible to install the Orange Pi 5 images on it but knowing that that the Orange Pi 5 Plus is out there (and getting leaked) that seems like the strongest possibility.
How do I know the Orange Pi 5 images override how the board is identified? Because I’ve seen it before. When I did my Mango Pi MQ Quad review I noticed that they are actually using (and linking to) the Orange Pi Zero 2 image (with no changes). They don’t even have one for themselves and literally link on their main page to the Orange Pi Zero 2 image. You can see what I mean in this benchmark here. To my surprise when I took the benchmark the board actually identified as an Orange Pi Zero 2.
Since none of it has mainline support anyway it’s just whatever they coded into their drivers/image. It’s not identifying it from the board and is just hard-coded. If it’s possible to use the Orange Pi 5 images on the Rock 5B the exact same thing would happen. It would insist until it’s blue in the face that it’s an Orange Pi 5 in every way just like the Orange Pi Zero 2 image does even when you use it on a board not even made by them such as the Mango Pi MQ Quad. Frankly I think even running the Orange Pi 5 image in a virtual machine capable of running ARM64 (which there aren’t very many of) would also report exactly as an Orange Pi 5 (even on x86_64 as the virtual machine will be invisible to the image if done correctly). It’s all hard-coded unfortunately and the scores would be INSANE running it through a PC even through virtualization. It would even report as the right architecture since from it’s perspective it is running ARM64.
Thanks a ton for testing the dependencies! I’m guessing from your findings that the problem is my 4GB of RAM on the board. I don’t really have any dependency related crashes in the console trying to run those titles so this makes sense. It seems that my board just doesn’t have the resources to run the game with the 4GB model. You’d probably have even better luck with the 16GB model from what you have found in your testing here (which you mentioned and I agree 100%).
I can’t wait for the mainline kernel as well! I’m sure that will lift all RK3588 boards to have mainline kernel support and I’m sure it’s going to come eventually. I think a lot of it may be done already (not sure what still needs to be done). I know some people do try to run the mainline kernel on there. I’m just not sure how difficult it is or how much trouble they have with it at. If you do try that let me know what the state of it is as I’m definitely interested.
Very informative explainations regarding the benchmarks, that puts everything into perspective! Thanks!
Just to clarify, I ‘didn’t really have any dependency related crashes in the console trying to run those titles’ either, it was just me trying to fix the textures stuff for HL and CS which didn’t help in this regard, but *magically* made HL2 and CS:S run all of a sudden. For me the package libudev-dev:armhf was a crucial part missing from your instructions/configuration to make them run. The Source games don’t work without it.
Because of the great performance of the Source games on this board, I was now even crazy enough to try CS:GO. On that front my efforts sadly ended directly by a common ‘segmentation fault’ issue which also effects normal x86_64 linux machines. This is now where I content myself, I can’t have everything 😉
Eureka! That is definitely the key dependency I was missing. I can now load Half Life 2 and after turning off antialiasing and a few other key settings the performance is very smooth. This is definitely what it was. I did get one crash after the G-Man intro played. Afterward I opened it up and reloaded a save instead and turned down the graphics settings (MSAA was set to 16X and things like that). It’s a very smooth and playable experience!
CS:GO would be a fun one to get going. I’ve been playing that again on my x86_64 PC lately as I’ve heard about the new version of CS coming out this summer and figured I’d sharpen up my skills and give the new one a try when it comes out.
You’ve done very well here. I honestly have no idea how you figured out that was the missing library as I didn’t spot console error messages related to this library in my output when launching. Maybe I didn’t read the console carefully enough though as launching the Source titles creates a lot more console spam than a lot of the other titles I’ve tried so it might have been in there somewhere.
Thank you for making my prediction I gave to Romain M. here come true that we were only one key flag or dependency away from 90% of games working fine with this setup. The Source titles were the one gaping hole that left me feeling like this was still incomplete. I’m sure there are more dependencies out there for certain key titles but it would be exactly that (fixing one or a few more titles at a time) rather than entire classes of games/engines.
CS:GO may be one of these or it might be something with Box64 itself that needs to be fixed for that one. I’m also very satisfied with where it’s at now. Thanks a ton for sharing this, I’m adding it to both guides immediately. If you find more that fix certain titles let me know. I did try a couple for CS:GO but still ended up with the same segmentation fault you did.
I didn’t forget to make some more tests. But Dirt needs 40gb of space! this insane … My SD is only 64gb lol
So for the moment I have 3 Games working (Despotism 3k, Totemori and Tricky Towers). And I will try some more games like (Figment, Guacamelee, Hitman Go, Lara Croft Go, Never Alone, maybe Bomber Crew). These are some interesting lightweight (under 3gb) native linux games I have in my library.
Since last time I have installed Heroic Launcher without any problem. Maybe your guide helped with that install. I don’t know if you want to create a guide for this software in a near future ? I’ve connected my Epic account and installed 2 games without any problem. But none of them work. I was trying to launch them with my steam experimental proton version. I will try with a dedicated stable proton version next time.
Other than I tried to install RPCS3 (PS3 emulator) but I don’t think running a game on top of 2 emulators is a good idea … I might try this when scrapping the OS would be an option.
That’s excellent, thanks for sharing the titles you got running as well as the Heroic Launcher! I added a dependency to the guide thanks to 032F which gets the Source engine titles running. It’s definitely worth installing that extra dependency I recently added if you haven’t already. It may help with other titles as well.
I’d imagine you are right about the PS3 emulator. It’s an emulator inside an emulator inside an emulator like you’ve said here. Each layer is going to sap some speed for sure so once there’s that many layers performance does get pretty tough.
Thanks for sharing your recent progress as well, definitely keep me posted and take care!
Since last time I’ve installed all the games listed un my previous message.
2 of them only worked. Guacamelee and Never Alone.
Guacamelee is not a demanding game. But Never Alone requires at least a GeForce GT 240.
And it sounds to be better working with low graphics profile.
These graphics might be the current limitation (without Vulkan support or better drivers) right ?
On the other hand, Hitman Go and Lara Croft Go were not launching at all.
I fixed it with the installation of libudev-dev:armhf library as explained previously by 032F.
But the 2 games are crashing just after launch.
This is weird as they seem to be using Unity Engine like Bomber Crew game (which crash before a window appears).
I think that they are using a different version of Unity 🙁
Thanks for sharing that video with me, I had not seen it! I like the link you’ve shared too for troubleshooting Steam. Let me know if you have any luck with the tips!
I’m glad that the fix 032F made an impact for some of your games as well. That’s fantastic! If you find any fixes that make those games work definitely let me know. It may be worth it to keep checking back as I’ll keep adding more dependencies/flags as people keep discovering them.
Enjoy and take care!
Razor Burn
1 year ago
Hi James,
Thanks for posting this super helpful tutorial as I’ve seen other examples of running Steam on the OPi 5 and they seemed super complicated and not worth the effort so your write up is greatly appreciated with the caveat that its still early days and don’t expect it to play all your games!
I’m happy using my OPi 5 for Home Assistant and might wait for the release of the rumoured OPi 5+ as some talk its under going testing and may be announced next month according to an insider? 2 Gb Ethernet ports, eMMC slot, full sized HDMI input next to dual HDMI output. Keeps the M.2 e-key and m-key slots plus heatsink mounts and if they can price it close to the Rock 5B it may convince me to go with it instead of the Rock 5A…?
Thanks so much! I didn’t mention this in the article but I actually did try it on the normal Orange Pi Debian distribution at first (where my Home Assistant install was). It was incredibly, incredibly slow without the 3D driver support but it did actually still work. It was a night and day difference though between having the 3D support installed. I was chopping like crazy with low FPS even in Stardew Valley without the 3D support then when I tried with Armbian with the 3D driver installed it was perfectly smooth.
I just moved my Home Assistant to Armbian using the dumbest trick. All I did was edit /etc/os-release and change PRETTY_NAME to “Debian GNU/Linux 11 (bullseye)”. I recently added this to the guide:
It then accepted my Home Assistant install on Armbian and is working 100%! Just something you can do if you wanted to get 3D support on the Orange Pi 5 (while not losing the ability to host Home Assistant supervised which is what I wanted and it did work). I then restored a full backup and was up and running again with a 3D-support-enabled Armbian Home Assistant supervised installation!
Holy smokes, those pictures look legit. It looks *exactly* like the Radxa Rock 5B (probably the idea). I modified your image URL and reuploaded them to get a much higher resolution picture than we were seeing from the Discord servers. You can actually read the Orange Pi 5 Plus on the board now in the reuploaded versions. We can see that it is indeed a RK3588 (proper, no S). We can also read the version as OPI5-PLUS v1.0. Very cool! I would bet that it is real. Everything looks exactly right (especially the things I wouldn’t expect someone faking these to get right).
Another funny but unimportant side note is that guy has *exactly* the same desk I do from Amazon. I would recognize it anywhere. He even got the same color!
That is a board that I would definitely pick up as well. I wonder what the pricing is going to be. If they can get it around $120-$130 that would be a *huge* advantage over Radxa as theirs now starts at $150 for the 4GB (pretty steep).
The reception for the Orange Pi 5 has been incredible. I thought about doing an article like this for the Radxa Rock 5B but it doesn’t seem to be nearly as popular as the Orange Pi 5 (I believe because of the price most likely, it’s at least 50% cheaper). I may still write one but the point is if they can undercut Radxa that would be a huge and very exciting launch (and would probably become very popular very fast). Thanks for sharing that with me!
Awesome job updating your HA guide as I’ll have to give it a go as much prefer having the option of running Armbian with 3D acceleration than Debian which is stable and I managed to add my first ESP32-CAM to my setup using your guide after some headache sorting the WiFi so thanks again!
I agree the OPi 5 has been a raging success and I look forward to seeing the OPi 5 Plus drop soon and if they price it competitively it should sell well which has me surprised that they even went with the OPi 5B as I just don’t see the same excitement from the community as the original OPi 5 runs well with NVMe and for most users they’ve found a solution for the missing wireless and the price was a big factor in seeing it become the RK3588S device to own.
Hopefully its affordable as once you get past the cost of a baseline Radxa Rock 5B it starts to creep into Intel and affordable Mini PC territory and although the RK3588 is a beast of a SOC its kinda let down by the GPU and adding the accessories just makes it unfeasible so time will tell what they do and if they manage to announce it before Radxa Rock 5A drops it might eat into those sales as many users like myself may just pay extra for a true budget friendly RK3588 SBC than owning multiple RK3588S boards that lack the I/O we want…!?
Thanks for the links and I hope to see some appreciation for this guide as seeing Steam run on the OPi 5 is really game changing so well done!
That’s awesome you got your first ESP32-CAM up, they’re a lot of fun! Mine has been working great in my utilities room. I even keep the light activated so when it’s dark I can see that everything is alright down there.
I completely agree about everything you’re saying about the pricing. It does start to get uncomfortable at $150+ because like you said you’re getting into Mini PC territory and even Chromebook territory almost with the higher end models. There’s definitely an opportunity here for Orange Pi here and there’s an opportunity for Radxa as well.
I can’t wait until we find out more details and see the pricing for it. It is very nice to get all of the I/O with the RK3588. It’s really quite dramatic how much more I/O it has and solves all of those wireless vs. NVMe issues and all of that.
zerosix@orangepi5:~$ steamsteam.sh[10729]: Running Steam on ubuntu 22.04 64-bit
steam.sh[10729]: STEAM_RUNTIME is enabled by the user
setup.sh[10791]: Steam runtime environment up-to-date!
steam.sh[10729]: Can't find 'steam-runtime-check-requirements', continuing anyway
/home/zerosix/.local/share/Steam/steam.sh: line 792: /home/zerosix/.local/share/Steam/ubuntu12_32/steam: cannot execute binary file: Exec format error
zerosix@orangepi5:~$
did every step without errors, this happened when launching steam.
Hey zerosix,
It can’t even read the Steam 32 bit file so that would indicate something is wrong with the Box86 installation. You may also be missing binfmt-utils. None of that should be happening though after following the instructions.
Is this perhaps the official Orange Pi 5 Ubuntu distribution instead of Armbian? The error is indicating you can’t execute 32 bit executables on your machine which would point toward binfmt-utils or box86.
Hopefully that helps!
I just found the problem. In reality, i didn’t have some libc6, i386, armhf and amd64 architecture packages, i discovered this after doing sudo apt-get update, i always got errors saying that couldn’t find the packages at some specific links and blablabla. The links for the apt thing where almost all broken, they couldn’t find where these packages where, so here i go, pasting every single apt link that i had and try to find these packages, see if it wasn’t just a bug. And well, they really where not there, lmao. Searched for loads and loads of other ubuntu ports to see if these packages where anywere, and didn’t find anything. The links i used initially where the default ones that came with the armbian, so i don’t know why everyone else, like you, got it. Been searching for new links for all day, and can’t find anything. I am almost completely hopeless, and thinking about just going back to emulation on chrome os android. Spent more than 50 dollars on steam games and now can’t play them lol.
Hey zerosix,
Did you make sure to get the line with:
sudo dpkg --add-architecture armhfThat should definitely get you access to those packages. It sounds like apt might be broken though. Can you try with a newer image potentially / a fresh download of Armbian with the Gnome desktop?
Already tried downloading armbian again after your last reply, also didn’t miss any step. I’m gonna wait for someone out there create an modified version of a linux dist with steam and box86/64 already installed, the Rock Pi 5B already has one.
Exactly the same error happens to me.
I am using armbian and followed all the steps except the 3D drivers install section, as I had them installed already. No errors whatsover, but can’t execute steam cause the file format error.
@James, please could you try to follow your guide in a new armbian installation to see if is still working or something has changed to prevent it from working, thanks
Hey Paj,
Thanks for the heads up, I’ll take a look when I get some time here!
Hey James, just to let you know I installed steam (over the previous broken installation) using this script and it worked. Actually I reinstalled box64, box86, winex86, winetricks and steam
Sad part is that I only wanted steam to stream games from my pc, but audio is cracking all the time (tried to change the sample rate on the client to 48khz as some people suggested with no luck tho)
Hey Paj,
Thanks for sharing the link! You’d think that streaming from your PC would require a lot less resources (it should). Hopefully that is something that becomes easier to do because streaming from your PC to an ARM platform would have a lot of great uses for a lot of people.
why after updating system like “sudo apt update && sudo apt upgrade” the launcher always can’t run? the upgrade was including box86 upgrade. But after reinstall from begin it always work again? any trick to avoid this unless I didnt do upgrade? thanks
Hey Dony,
This guide does not use apt to install box86 or box64. We build it from source. It should not be updating through apt or updating at all. You’d need to rebuild it from source to update it.
It sounds like you already installed box86 from apt before following this guide. Just remove it. Remove the box86 packages from apt as that is not how this guide works. After that it will no longer update it anymore.
Hopefully that helps!
Have you seen this
Fedora 39 Looks To Boost vm.max_map_count To Help Windows Games With Steam Play
Maybe setting up this value will help some games to run
Hste
Hi James,
Hope you’re doing well good sir. I see you got a shoutout on YouTube for this helpful guide so here’s hoping it attracts more readership to your awesome blog!
By the way I’m seeing more Orange Pi 5B content shared online and I’ll admit its looking good as the preloaded Orange Pi Droid supports Wifi/BT yet still no GApps but I read that eMMC speeds are near those of the NVMe so well done to them and hopefully it gets the same support as the OPi 5 which has been a real success!
Best regards from Australia
Hey Razor Burn,
That is an awesome video, thanks for sharing that! I’m really glad to see people embracing alternative boards.
I still get a lot of resistance when people comment on my Raspberry Pi articles on SSD booting about how miserable of an experience it is to use SSDs with the Pi and I tell them that the Raspberry Pi is completely obsolete for that (and most things). Even for people using the 5B though the eMMC is pretty fast apparently (about as fast as any SSD setup on the Raspberry Pi). I can confirm those have been scoring really well on pibenchmarks.com.
Today is the last day of my first full work week as an IT engineer. It’s 8am-5pm though with about a 30-35 minute commute each way though so it’s a very long day and not leaving a lot of time for the site. I’m still going to try to make it work though with the site and keep doing content. I just need to get into a rhythm and probably try to publish an article on the weekends as I continue to get settled in.
Great to see you again, take care!
Its thanks to people such as yourself and Lee who happily impart knowledge so average users such as myself grow to embrace alternatives outside of the Raspberry Pi so here’s hoping you find a perfect balance as I’ll admit I miss the regular content but totally understand time restraints so best of luck and hope to se new content soon, even if its the odd weekend post!
orangepi@orangepi:~/box86$ mkdir build; cd build; cmake .. -DRK3588=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo-- Found Python3: /usr/bin/python3.10 (found version "3.10.6") found components: Interpreter
-- The C compiler identification is unknown
-- The ASM compiler identification is unknown
-- Didn't find assembler
CMake Error at CMakeLists.txt:77 (project):
The CMAKE_C_COMPILER:
arm-linux-gnueabihf-gcc
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
CMake Error at CMakeLists.txt:77 (project):
No CMAKE_ASM_COMPILER could be found.
Tell CMake where to find the compiler by setting either the environment
variable "ASM" or the CMake cache entry CMAKE_ASM_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Warning: Did not find file Compiler/-ASM
-- Configuring incomplete, errors occurred!
See also "/home/orangepi/box86/build/CMakeFiles/CMakeOutput.log".
See also "/home/orangepi/box86/build/CMakeFiles/CMakeError.log".
You either skipped the dependencies section or ignored that these instructions are for Armbian only. Given that the username is orangepi I would assume you are using one of the official Orange Pi operating systems instead (and probably not Debian).
The error says you didn’t install any of the dependencies that I said to. I also said that these instructions are for Armbian and that I’m not interested in supporting whatever random operating system you decided to use (which you didn’t mention).
I suppose the answer is that you either ignored the operating system requirements, ignored installing the dependencies or both. Either way I can’t really help with this.
Hi James,
Woaw incredible … I’ve been trying to install Steam on my Orange Pi5 with Armbian Gnome for the whole week!!!
I think I was missing some of the dependencies and the DOTNET environment variable for Steam.
Regards,
Romain
Hey Romain,
I totally understand. This isn’t one of my longer articles but it took me the entire day to get it going. I never found any guide or anything online saying how to do this. I had to piece it together from the developer’s GitHub issues pages. It was just passing references like you needed to have both Box86/Box64 installed but nobody really showing how you’d do that.
The most helpful part was that Box86 had that Steam helper installer script. That was the big breakthrough for me as I had quite a mess going before that. I had a Steam install so broken I ended up reimaging altogether and the helper script really smoothed out my next attempts. I could have easily been stuck on this for weeks if I didn’t happen to find an issue thread that the developer specifically mentioned that you should build both from source and then run the Box86 Steam installer script:
I don't have steam stability issue on my side.Did you build box86 & box64 with the "-DRK3588" switch?
did you install steam using the steam_install.sh script for box86?
That was literally the breakthrough for me. After that I just had to spend a couple of hours finding some additional Stardew Valley dependencies (probably a lot of which will help with other games as well). The DOTNET variable got rid of a really nasty error related to locales and unicode. It doesn’t seem to have many negative consequences as apparently when you use that environment variable it just uses your local system’s timezones / locales (should be fine even for people not using English).
Thanks so much for leaving this comment, enjoy and take care!
Hi James,
Sorry for the delay … Yes I was compiling box86 and box64 from source too like it is indicated on box86 github page.
I was also using there script … even if a couple of days before I also tried to install it by myself from steam .deb installation file.
Lastly I tried to repeat the installation from you guide … it seems to work everytime … except with OrangePi5-ubuntu image I didn’t had success.
I tried 2 times with OrangePi5-debian-xfce and I think that I am going to keep this setup.
With Armbian It was working … but I didn’t had good results with “glmark2” benchmark and with “wirple” website benchmark … even if the panfork drivers were installed!
Chrome was also showing “Software Only. Hardware acceleration disabled.” in “chrome://gpu” page.
So I wasn’t sure if the running games on steam were using the hardware or the software acceleration.
And when chrome was showing “Harware accelerated.” and I was able to have good results with “glmark2” benchmark and “wirple” website benchmark on Armbian … then my steam games were not running at all (even with Proton).
With OrangePi5-debian-xfce, the panfork drivers are already installed … so the setup is a bit easier.
I noticed that Steam is more stable with it, but maybe because there was an update with box86 recently (2 days ago) for steam stability.
I don’t need to use Proton or subscribe to Steam Beta participation to run my steam games (I needed to use these 2 options with Armbian).
Were you using these settings (Proton, Steam Beta Participation) in order to run your games ?
Regards,
Romain
Hey Romain,
Great questions and results! So no I didn’t use Proton or anything like that. It’s running completely natively through Box64/Box86. No betas enabled. I also did this on the Radxa Rock 5B and the process is pretty much identical. I did not have any crashes on the Rock 5B. That’s probably because of the stability update that happened like you suggested.
The results you are seeing in the synthetic benchmarks and browser acceleration are pretty interesting. Basically I think what you are running into is that there are a *lot* of different types of 3D acceleration. Each game is going to use different libraries and different technologies altogether. That’s why your browser can show unaccelerated for some categories but the games will still receive full acceleration or your benchmarks may be fine.
Even the browser has a bunch of different categories. There is OpenGL, Vulkan, rasterization, compositing, and a whole bunch of other categories. Games also use all of these technologies but not all games and each game will use different ones.
I did not need Proton or the Steam beta on either the Orange Pi 5 or Rock 5B with Armbian for what it’s worth. I did a clean image as I showed in the guide with the public release from Armbian’s site for both boards and only ran the commands I posted in the article. I’ll definitely check though because maybe my Proton settings carried over. Maybe it was on and I didn’t realize it.
I guess the question is which games are you running specifically? I tried running Portal on the Radxa Rock 5B and that didn’t work. Proton might have made it work. On my main x86_64 PC I use Proton (in Linux running PopOS!). I didn’t use it on ARM though. To get my games to work like Stardew Valley I showed in the guide involved installing additional dependencies for the games. I tried some other games like Pony Island and they ran fine as well. Portal was the one that I was thinking of trying to get to work next as if Portal will run I’d imagine most of the other Valve and Source engine ones would too.
If *all* of your games are working in Armbian when turning Proton on then I’d imagine that would be the next step most people would want to take trying to run more demanding games. That’s interesting that the xfce version already has the Panfork drivers installed. I didn’t see them on there running when I did a lsmod. I did try with the official Orange Pi 5 Debian distribution originally and it was so slow I wiped it and put Armbian on there. I might have had the KDE Plasma variant instead (I think it was). That one was definitely slow as molasses without the driver support.
To know if it’s really running do a lsmod and you should see Panfrost:
root@homeassistant:/boot# lsmodModule Size Used by
gpu_sched 28672 1 panfrost
If you don’t see the driver loaded it’s not doing it (at least the Panfrost stuff). I’ve never seen Orange Pi package the firmware in one of their official images before. I will have to try that one and see if it’s really loading the driver. There are a *lot* of components to the driver that need to be present for sure for it all to work (including the firmware). On the Radxa Rock 5B there are even more packages available (such as kodi) that enable video hardware acceleration for example.
It’s honestly such a mess in Linux to get acceleration working. Even my main Linux desktop running a NVIDIA RTX 3090 shows a bunch of the Chrome acceleration methods as failing or disabled (such as Vulkan, WebGPU, Canvas out of process rendering, raw draw and direct rendering display compositor). There’s no doubt packages I could install on my main desktop that would fix some of these categories. Just installing the panfrost driver (or an NVIDIA driver in the case of a desktop) isn’t going to turn everything on. There’s a lot more to it than that.
I’d suggest comparing it with your Linux desktop on other things as well as some of this stuff is quite difficult to get enabled (and most people won’t notice it’s not present unless things are chopping). Take a look at my *desktop*’s failing components:
WebGPU has been disabled via blocklist or the command line.Disabled Features: webgpu
Accelerated video encode has been disabled, either via blocklist, about:flags or the command line.
Disabled Features: video_encode
Program link fails in NVIDIA Linux if gl_Position is not set: 286468
Applied Workarounds: init_gl_position_in_vertex_shader
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Linux NVIDIA drivers don't have the correct defaults for vertex attributes: 351528
Applied Workarounds: init_vertex_attributes
MakeCurrent is slow on Linux with NVIDIA drivers: 449150, 514510
Applied Workarounds: use_virtualized_gl_contexts
NVIDIA fails glReadPixels from incomplete cube map texture: 518889
Applied Workarounds: force_cube_complete
Pack parameters work incorrectly with pack buffer bound: 563714
Applied Workarounds: pack_parameters_workaround_with_pack_buffer
Alignment works incorrectly with unpack buffer bound: 563714
Applied Workarounds: unpack_alignment_workaround_with_unpack_buffer
Framebuffer discarding can hurt performance on non-tilers: 570897
Applied Workarounds: disable_discard_framebuffer
Unpacking overlapping rows from unpack buffers is unstable on NVIDIA GL driver: 596774
Applied Workarounds: unpack_overlapping_rows_separately_unpack_buffer
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Expose WebGL's disjoint_timer_query extensions on platforms with site isolation: 808744, 870491
Applied Workarounds: enable_webgl_timer_query_extensions
glTexStorage* are buggy when base mipmap level is not 0: 877874
Applied Workarounds: reset_base_mipmap_level_before_texstorage
Some drivers can't recover after OUT_OF_MEM and context lost: 893177
Applied Workarounds: exit_on_context_lost
adjust src/dst region if blitting pixels outside framebuffer on Linux NVIDIA: 830046
Applied Workarounds: adjust_src_dst_region_for_blitframebuffer
Disable GL_MESA_framebuffer_flip_y for desktop GL: 964010
Applied Workarounds: disable(GL_MESA_framebuffer_flip_y)
Absolutely fantastic work and observations. I’m curious now if I turn Proton on if Portal will run without having to install additional dependencies. I’ve only tried a handful of games so far and I just assumed it would all be dependencies. Perhaps Proton is a really good answer for this though. Hopefully that helps!
Hi James,
This morning I tried to install Epic Games client inside Steam via the option “Add a Non-Steam Game to My Library”. But it seemed like I couldn’t not see my library on “Large Mode” on my Debian “OrangePi” version.
Also … the “Big Picture Mode” was not working at all!
So I told myself let’s get back on “Armbian” and do some test for James! haha
First test I did exactly what is written in your guide (like I did in the past) … same problem … everything works fine (installation, updates, upgrade) … but games do not work.
I am testing with “Despotism 3k” and “Totemori” as I doesn’t have “Stardew Valley” in my library. I also checked with the “lsmod” command and I have the exact same output as your were showing.
Then I did a second test … but this time in your “exports” section before installing steam I added this one to the list “export PAN_MESA_DEBUG=gl3”. I read on box86 github page that it could fix Unity games that do not starts.
It did not only fixed all my problems … but also improved my gpu performance x10 or x20!!!! (I think that it was in real running my games with software acceleration when I was testing with Debian or Armbian+Proton)
The 2 games I was testing are now running fast in fullscreen mode without touching to the graphical settings.
I put this setting because when launching these 2 games I remembered seeing the “Unity” logo on game starts.
I think I’m ready to test something like “Dirt” now ?! hahaha
By the way … do you also have better performance on your side if your add this environment variable ?
Regards,
Romain
Hey Romain,
Great findings! So Stardew Valley uses OpenGL 2.0 which is likely why it’s not requiring additional parameters. It sounds like this setting fixes Unity games really well! Thanks for confirming the panfrost driver is indeed running on the xfce flavor of Debian as well. That is surprising as those are beta drivers/builds (which is why you need to add that weird PPA for most distros to get them). It sounds like Orange Pi did indeed build in a version of them into the xfce flavor though (a very good thing).
There’s a lot of variations of those settings you can use too. For example if you take a look at the Box86 list of compatible games you’ll see that they have tags for OpenGL 2.0, OpenGL 3.0+, and a whole bunch of other things. Neither of the games you mentioned have been reported on that site yet so those aren’t even in the 300 reported ones yet. It’s an extremely useful resource though as you can look for similar games on there and often people will give you hints/answers about what flags get those titles working.
I actually see a lot of people recommending this line for OpenGL 3.0 games in the issues threads:
PAN_MESA_DEBUG=gofaster,gl3Perhaps this will increase the speed even more? In fact I can’t find anyone not recommending using both. I’ll definitely add this to the guide’s environment variables because I can just see in the issues thread that it will fix a ton of issues on various games to add that. Apparently even Valheim will run with these two flags enabled.
So honestly there is no setting that is going to make all games work. There’s a lot of games that just won’t work. You can see a list of about 300 games at the above link and there’s still quite a few that won’t work. That’s definitely why I asked which games specifically you were running. If you are looking for the perfect setting to fix everything there’s no such thing for sure. They all use too different of technologies. We *can* however knock out entire categories of game engines such as Unity and I think that you’ve just done that here!
It looks like “Dirt” uses the Ego engine. That sounds interesting. I don’t see any reports on it on the Box86/Box64 compatibility list issues thread so I’m not sure if this has been tried yet. I tried to search for what the Ego engine uses (OpenGL 2.0, OpenGL 3.0+, etc.) and there doesn’t seem to be a lot of information out there about it. That would definitely be an interesting one to try!
I suspect what is happening is that Stardew Valley uses OpenGL 2.0 and it’s definitely being accelerated without additional environment variables. If you have no acceleration it can’t run Stardew Valley at more than like 10 fps. Perhaps it will improve it even more by forcing OpenGL 3.0? I gave it a try but it’s hard to tell since it was already running at full speed.
I did try Portal to see if this would fix launching Source engine titles. It did not. I also tried Half Life 2 and Team Fortress 2 and also no dice. Source engine titles are still a no-go without more settings/dependencies of some kind. I think it’s fixable though. I saw someone got Portal 2 running but it was completely unplayable on their board (which was not a RK3588/RK3588S) but Portal 2 is a lot newer so that didn’t surprise me. I feel like Portal has a chance of running pretty decently since that’s quite an old title now at this point. I just haven’t cracked the setting/dependency for the Source titles to work yet here.
Interestingly the *original* Half Life (1998) did work. That is the only Valve title that I could launch that I’ve tried so far and it actually ran really well! It’s not that impressive though since it is a 1998 title but it’s fun that one is working on there now with these changes.
I did test Valheim though since people said that was working and Valheim did work! The FPS is extremely low on a Rock 5B or Orange Pi 5 but I wasn’t expecting otherwise for that title. Even regular PCs have a hard time with Valheim without a decent GPU (I wouldn’t call it a super optimized title). Skyrim Special Edition won’t even attempt to install on there saying invalid platform (interesting, since I run that one on my x86_64 PC in Linux just fine). I haven’t tried the original Skyrim yet but that game is so old now there’s a chance it may run.
I’m not sure how many games you own but if you have a fairly large SSD I would try just installing a bunch of them to find ones that aren’t working. I’d be very interested in how the Dirt title on the Ego engine goes since there’s no reports for that one yet that I could see. I’d imagine though that we’re probably only a few tweaks or dependencies away from 90%+ of these being able to run though. I think we are getting really close. The Box86/Box64 team has been doing a great job fixing these as they are found as Steam running as well as it does is a pretty recent development and took significant effort from the main Box86/Box64 developer. The recent stability update seems to have helped as well.
I’m extremely grateful to you for sharing this flag with me and keeping me in mind! Definitely let me know if you find more of these types of settings that improve performance or enable an entire branch/engine of games to start running. I think there’s still a few more flags/dependencies out there for us to find but it is a huge victory to have most (if not all) of the Unity games working with this flag. I’m happy to add anything like this to the guides as my goal is to get people up and running with as much compatibility as possible.
Take care!
Hi there! Great guide! I bought the OPi5 mainly for server-purposes and maybe as a Kodi Media Player. But holy heck, I couldn’t resist testing this!
I’ve managed to get Half Life 2 and Counter-Strike Source working!
FYI: I followed your guide from scratch, then tried these and they didn’t work. Then tried the original Half Life and Counter-Strike, both worked with major texture/whatever-grafics issues. So I looked up the command line output and I installed a couple of libraries in hope to fix these issues. It didn’t fix them, but suddenly Half Life 2 and Counter-Strike Source worked! 😉 I’m not quite sure which library was needed, but I didn’t do anything else, so you can focus on that.
Apart from that Half Life 2 and Counter-Strike Source are performing really well with your instructions/configuration and a lot better than their original counterparts. In Counter-Strike Source I also get some texture issues, but they are less annoying than in the original. Sadly these games are always crashing after some short time which mostly seem to have to do with memory allocation. I have an 8GB OPi5 version, while in-game htop shows 6,XXGB used up ram for the most time. I’m not quite sure if it’s not enough or if it’s an panfrost/box86 memory allocation issue. Lowering the display resolution und texture quality only seems to help a bit.
Funnily, some of these issues/crashes I’m having are getting recognized by the Valve Anti-Cheat System and I got blocked multiple times for a short period.
Speaking of cheating, I want to ask you about this benchmark.
How is this result even possible? Compared to all the other scores it seems to be way outside of realistic results. What’s so special about that WDdrive/configuration? I wasn’t even able to reproduce my highest score at 23,782 which seemed to have been an outlier also, after that my results were always somewhat below and I didn’t send them in.
Thanks for letting me have some fun after years of abstinance!
Hey 032F,
Welcome back! That’s fantastic that you got HL2 and CS:Source working. That’s pretty much the process I used to get most of mine working. Do you remember which dependencies they were? If so I can add them to the guide for sure. Maybe my RAM is the issue since I’m only using the 4GB version. Perhaps that one doesn’t have enough RAM to even launch. If you happen to remember the dependencies though I’d love to try installing them on mine as well and see if I can get it to launch!
That’s wild that the anti-cheat is pretty unhappy. My guess is it’s because of the textures. It’s probably seeing that as some kind of x-ray vision/wallhacks. That’s a very traditional hack where people would delete textures or make them transparent so they can see people behind walls. I’d imagine the texture thing is what is throwing it.
So that’s a great question about the score that is much higher than everyone else. It’s the RK3588 (not RK3588S) version of the Orange Pi 5 (unreleased):
This board was apparently leaked on Discord. It’s not available yet or even announced but the score you are looking at is a RK3588 score. Look at the Radxa Rock 5B scores. It’s identical to them. The RK3588 has PCIe 3.0 while the RK3588S only has PCIe 2.0. That’s why it’s faster.
It does not surprise me to see that score in the slightest since the board is out there enough for those leaked pictures to make it to my site weeks ago (maybe even more than a month ago). It’s exactly where it should be for a RK3588 vs. a RK3588S. I bet we’ll continue to see more of these popping up. No, it’s not possible to get a score like that on the original Orange Pi 5 with PCIe 2.0. It has to be the RK3588 with PCIe 3.0.
Unfortunately it doesn’t look like the board is going to identify itself as anything other than an Orange Pi 5. This does not surprise me either as they’ve already released the Orange Pi 5B and it only identifies itself as the Orange Pi 5 as well. That’s probably because on most Orange Pi boards the operating system is what identifies the board. There definitely are not separate operating system downloads for the Orange Pi 5 vs. Orange Pi 5B and I doubt there will be for the Orange Pi 5 Plus either.
Your score is basically as good as it gets with PCIe 2.0. I wouldn’t lose sleep over that top score. There’s going to be more of them as more people get the beta version of the Orange Pi 5 Plus (however they’re getting it). They’re probably Orange Pi insiders / testers.
In other words are they cheating? Yes, they’re cheating. I know exactly how though in this case. Someone has their hands on the Orange Pi 5 Plus somehow. Orange Pi is making it easier for them by not distinguishing these boards in the model # and it’s already a problem with the Orange Pi 5B as well. The RK3588 always reports itself as a RK3588 whether it’s the RK3588 or RK3588S as well which is annoying. It makes it extremely difficult to detect what they’re really using. It’s also possible they installed the Orange Pi 5 operating system on a Radxa Rock 5B but that’s something I wouldn’t really expect to work without issues. I think it’s more likely someone with the Orange Pi 5 Plus took the benchmark.
Fantastic work! Let me know if you remember which dependencies you think may have fixed this. I’d love to try it and add them to the guide/article if you’re able to remember which ones they were.
Thanks and take care!
Oh man, pinpointing the relevant library was easier said than done!
I did ‘apt remove’ all former installed packages sequentially and ‘apt automove’ their dependencies. The Source games still worked. I must have missed some installation.
To get rid of all armhf I did an ‘apt remove \*:armhf –allow-remove-essential’ and made a list of those packages. Then I reinstalled all packages via your instructions. After that a ‘apt install’ of the recorded list gave me a dozen remaining packages which I had to check individually until I figured out that the only additional armhf package needed for the Source games run is libudev-dev:armhf.
You might want to check it yourself first before you add it to your guide. I didn’t do a fresh install, so maybe a arm64 package might also be needed, I can’t be sure.
Your 4GB RAM vs my 8GB will most probably be an additional issue for you. I don’t know if that stuff can be swapped. I’ve never seen the usage of 7.XXGB RAM in htop while Steam-gaming because it always crashes/freezes before that (at ~6.XXGB). Maybe a 16GB version is needed to avoid this with the current configuration.
Disregarding the crashes/freezes of the Source games the texture/graphics issues still remain in HL,CS and CS:S, but HL2 works awesome!
Great info about the yet unreleased Orange Pi 5 and other possibilities.
But I’m not sure if you’re right about the potential RK3588 score (instead of RK3588S). If you compare this Top-OPi5 score with Top-ROCK5B scores like this or this you can see the major difference in DDwrite and HDParm results which is the indicative PCIe2/3 distinction and overall higher FIO/IOZ values in general. The Top-OPi5 score still looks like a PCIe2 in this regards. It’s quite strange that these have such similar end-results. I don’t know of the individual parts weighting.
Maybe the WD drive is just made of better quality parts or the score’s configuration is somewhat tweaked in other regards.
Anyways, testing all of this is a lot of fun. I’m eagerly expecting a main line kernel!
Hey 032F,
So 250MB/s is actually PCIe 1.0 speeds. PCIe 2.0 is actually 500Mb/s limit and there’s plenty of Orange Pi 5 scores that approach that. The absolute top Rock 5B benchmark (#1) has a DD Write of only 259MB/s. There are plenty that are higher but it’s the same with the Orange Pi 5. The guy below your test on the top 10 hit way higher than this with DD write (369 MB/s). That smokes both yours and the Rock 5B’s top benchmark. It doesn’t matter (in the test or in real life). They still scored lower than you overall because of random read/write performance.
The DD write test is a pretty poor indicator. It’s the least weighed out of every single test. The random read/write tests are weighed literally 4x heavier and there’s a lot more of them. The main reason for this is that computers rarely have the benefit of doing giant sequential writes. Pretty much the only time that even happens is when you image the disk or perform some kind of backup. Sequential read/write performance isn’t very useful for daily usage though as the most common I/O operations on any drive running an operating system are random read/write. Writing to log files here, reading a config file there, etc. dozens of times per second. This is why raw DD write is weighed so low.
Manufacturers *love* to talk about their sequential read/write scores all day (which is exactly what DD write as well as HDParm both do, sequential block by block I/O only, and it’s why those aren’t serious storage benchmarking metrics). That’s because it’s easy and there’s all sorts of optimizations/tricks they can do to raise those scores. They really start to squirm if you ask about the random read/write performance though. Why? Because getting high random read/write performance requires a high quality storage controller as well as a large and high quality cache. Those are both expensive which means manufacturers don’t want to put them in the drive. Very few companies even give their random read/write performance scores and when they do it’s because they know they spent the money to put high enough quality components in it and are proud of it.
In other words you’re basically right that it’s the quality of parts that can make a difference here. The cache and storage controller explain a lot of the performance differences between many of these drives. It’s still a huge outlier though. The DD write won’t tell us much though about the performance. I can pick ones from all over that are way higher on the Orange Pi 5 and way lower on the Rock 5B and they’ll be pretty close to the average score since that test is the least weighted/important benchmark it runs.
The caching is also why your score goes down when you take it over and over again. That very first run tends to have a lot of caching going on. It doesn’t take the drive long to figure out though that caching that one-time sequential write operation wasn’t a very effective use of the cache. It starts to cache other things like the files/data your OS is really dealing with. The point of the cache is to speed up things that are frequently accessed over and over again. It learns from this while it’s running and the only way to make it “forget” is to power off the device completely so that the cache is completely lost. You can then trick it into caching aggressively one more time when you reboot it up and then the scores will progressively drop until you power cycle it again and the cycle repeats itself.
It’s actually a good sign of quality if the score is dropping on sequential runs. While it can be frustrating for benchmarking what it really means is that your storage controller and cache is smart and spending the limited resources on things that will make the system I/O much more responsive (think like your main OS files/logs/etc.). That’s why you’ll see drives that are clearly inferior to yours putting out high DD write scores a lot of the time. It means it probably has a pretty low quality cache that is spending way more time caching sequential I/O than it should be. The storage controller might not even be keeping track of what is effective to cache and is just throwing whatever in there. Those drives always have lower random read/write scores which is why they won’t outscore you overall. They can beat better drives on the DD write score (and HDParm) a lot of the time pretty consistently because they have a “dumb” storage controller / cache setup going on.
Time should tell if this is the Orange Pi 5 Plus. It sure looks like a RK3588 score to me though and looks a lot more like the average Rock 5B benchmark (DD write and all). There are way more tests for the Orange Pi 5 (902 for the Orange Pi 5 vs. 86 for the Rock 5B) and nobody else has ever come even close to this. DD write can’t answer this question for us though and neither can the inxi report unfortunately as since it’s not mainline kernel support right now this stuff is all whatever Orange Pi codes into their images and custom drivers (and they aren’t coding the model variations between their different models, more like just putting the family of Orange Pi 5).
I can say definitively it is not like the other 901 benchmarks we have so far and the only comparable ones belong to the Rock 5B. It might actually be a Rock 5B if it’s possible to install the Orange Pi 5 images on it but knowing that that the Orange Pi 5 Plus is out there (and getting leaked) that seems like the strongest possibility.
How do I know the Orange Pi 5 images override how the board is identified? Because I’ve seen it before. When I did my Mango Pi MQ Quad review I noticed that they are actually using (and linking to) the Orange Pi Zero 2 image (with no changes). They don’t even have one for themselves and literally link on their main page to the Orange Pi Zero 2 image. You can see what I mean in this benchmark here. To my surprise when I took the benchmark the board actually identified as an Orange Pi Zero 2.
Since none of it has mainline support anyway it’s just whatever they coded into their drivers/image. It’s not identifying it from the board and is just hard-coded. If it’s possible to use the Orange Pi 5 images on the Rock 5B the exact same thing would happen. It would insist until it’s blue in the face that it’s an Orange Pi 5 in every way just like the Orange Pi Zero 2 image does even when you use it on a board not even made by them such as the Mango Pi MQ Quad. Frankly I think even running the Orange Pi 5 image in a virtual machine capable of running ARM64 (which there aren’t very many of) would also report exactly as an Orange Pi 5 (even on x86_64 as the virtual machine will be invisible to the image if done correctly). It’s all hard-coded unfortunately and the scores would be INSANE running it through a PC even through virtualization. It would even report as the right architecture since from it’s perspective it is running ARM64.
Thanks a ton for testing the dependencies! I’m guessing from your findings that the problem is my 4GB of RAM on the board. I don’t really have any dependency related crashes in the console trying to run those titles so this makes sense. It seems that my board just doesn’t have the resources to run the game with the 4GB model. You’d probably have even better luck with the 16GB model from what you have found in your testing here (which you mentioned and I agree 100%).
I can’t wait for the mainline kernel as well! I’m sure that will lift all RK3588 boards to have mainline kernel support and I’m sure it’s going to come eventually. I think a lot of it may be done already (not sure what still needs to be done). I know some people do try to run the mainline kernel on there. I’m just not sure how difficult it is or how much trouble they have with it at. If you do try that let me know what the state of it is as I’m definitely interested.
Thanks for sharing your results, take care!
Very informative explainations regarding the benchmarks, that puts everything into perspective! Thanks!
Just to clarify, I ‘didn’t really have any dependency related crashes in the console trying to run those titles’ either, it was just me trying to fix the textures stuff for HL and CS which didn’t help in this regard, but *magically* made HL2 and CS:S run all of a sudden. For me the package libudev-dev:armhf was a crucial part missing from your instructions/configuration to make them run. The Source games don’t work without it.
Because of the great performance of the Source games on this board, I was now even crazy enough to try CS:GO. On that front my efforts sadly ended directly by a common ‘segmentation fault’ issue which also effects normal x86_64 linux machines. This is now where I content myself, I can’t have everything 😉
Hey 032F,
Eureka! That is definitely the key dependency I was missing. I can now load Half Life 2 and after turning off antialiasing and a few other key settings the performance is very smooth. This is definitely what it was. I did get one crash after the G-Man intro played. Afterward I opened it up and reloaded a save instead and turned down the graphics settings (MSAA was set to 16X and things like that). It’s a very smooth and playable experience!
CS:GO would be a fun one to get going. I’ve been playing that again on my x86_64 PC lately as I’ve heard about the new version of CS coming out this summer and figured I’d sharpen up my skills and give the new one a try when it comes out.
You’ve done very well here. I honestly have no idea how you figured out that was the missing library as I didn’t spot console error messages related to this library in my output when launching. Maybe I didn’t read the console carefully enough though as launching the Source titles creates a lot more console spam than a lot of the other titles I’ve tried so it might have been in there somewhere.
Thank you for making my prediction I gave to Romain M. here come true that we were only one key flag or dependency away from 90% of games working fine with this setup. The Source titles were the one gaping hole that left me feeling like this was still incomplete. I’m sure there are more dependencies out there for certain key titles but it would be exactly that (fixing one or a few more titles at a time) rather than entire classes of games/engines.
CS:GO may be one of these or it might be something with Box64 itself that needs to be fixed for that one. I’m also very satisfied with where it’s at now. Thanks a ton for sharing this, I’m adding it to both guides immediately. If you find more that fix certain titles let me know. I did try a couple for CS:GO but still ended up with the same segmentation fault you did.
Take care!
Hi James,
I didn’t forget to make some more tests. But Dirt needs 40gb of space! this insane … My SD is only 64gb lol
So for the moment I have 3 Games working (Despotism 3k, Totemori and Tricky Towers). And I will try some more games like (Figment, Guacamelee, Hitman Go, Lara Croft Go, Never Alone, maybe Bomber Crew). These are some interesting lightweight (under 3gb) native linux games I have in my library.
Since last time I have installed Heroic Launcher without any problem. Maybe your guide helped with that install. I don’t know if you want to create a guide for this software in a near future ? I’ve connected my Epic account and installed 2 games without any problem. But none of them work. I was trying to launch them with my steam experimental proton version. I will try with a dedicated stable proton version next time.
Other than I tried to install RPCS3 (PS3 emulator) but I don’t think running a game on top of 2 emulators is a good idea … I might try this when scrapping the OS would be an option.
Regards,
Romain
Hey Romain,
That’s excellent, thanks for sharing the titles you got running as well as the Heroic Launcher! I added a dependency to the guide thanks to 032F which gets the Source engine titles running. It’s definitely worth installing that extra dependency I recently added if you haven’t already. It may help with other titles as well.
I’d imagine you are right about the PS3 emulator. It’s an emulator inside an emulator inside an emulator like you’ve said here. Each layer is going to sap some speed for sure so once there’s that many layers performance does get pretty tough.
Thanks for sharing your recent progress as well, definitely keep me posted and take care!
Hi James,
Since last time I’ve installed all the games listed un my previous message.
2 of them only worked. Guacamelee and Never Alone.
Guacamelee is not a demanding game. But Never Alone requires at least a GeForce GT 240.
And it sounds to be better working with low graphics profile.
These graphics might be the current limitation (without Vulkan support or better drivers) right ?
On the other hand, Hitman Go and Lara Croft Go were not launching at all.
I fixed it with the installation of libudev-dev:armhf library as explained previously by 032F.
But the 2 games are crashing just after launch.
This is weird as they seem to be using Unity Engine like Bomber Crew game (which crash before a window appears).
I think that they are using a different version of Unity 🙁
I discovered this link : https://wiki.archlinux.org/title/Steam/Troubleshooting
Do you think it might be a good ressource link to add to tour guide ?
I will try 1 or 2 tips I think.
Finally have you seen this
You are getting Popular!
Regards,
Romain
Hey Romain,
Thanks for sharing that video with me, I had not seen it! I like the link you’ve shared too for troubleshooting Steam. Let me know if you have any luck with the tips!
I’m glad that the fix 032F made an impact for some of your games as well. That’s fantastic! If you find any fixes that make those games work definitely let me know. It may be worth it to keep checking back as I’ll keep adding more dependencies/flags as people keep discovering them.
Enjoy and take care!
Hi James,
Thanks for posting this super helpful tutorial as I’ve seen other examples of running Steam on the OPi 5 and they seemed super complicated and not worth the effort so your write up is greatly appreciated with the caveat that its still early days and don’t expect it to play all your games!
I’m happy using my OPi 5 for Home Assistant and might wait for the release of the rumoured OPi 5+ as some talk its under going testing and may be announced next month according to an insider? 2 Gb Ethernet ports, eMMC slot, full sized HDMI input next to dual HDMI output. Keeps the M.2 e-key and m-key slots plus heatsink mounts and if they can price it close to the Rock 5B it may convince me to go with it instead of the Rock 5A…?
https://jamesachambers.com/wp-content/uploads/2023/03/OrangePi5Plus.webp
https://jamesachambers.com/wp-content/uploads/2023/03/OrangePi5Plus2.webp
Hey Razor Burn,
Thanks so much! I didn’t mention this in the article but I actually did try it on the normal Orange Pi Debian distribution at first (where my Home Assistant install was). It was incredibly, incredibly slow without the 3D driver support but it did actually still work. It was a night and day difference though between having the 3D support installed. I was chopping like crazy with low FPS even in Stardew Valley without the 3D support then when I tried with Armbian with the 3D driver installed it was perfectly smooth.
I just moved my Home Assistant to Armbian using the dumbest trick. All I did was edit /etc/os-release and change PRETTY_NAME to “Debian GNU/Linux 11 (bullseye)”. I recently added this to the guide:
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
It then accepted my Home Assistant install on Armbian and is working 100%! Just something you can do if you wanted to get 3D support on the Orange Pi 5 (while not losing the ability to host Home Assistant supervised which is what I wanted and it did work). I then restored a full backup and was up and running again with a 3D-support-enabled Armbian Home Assistant supervised installation!
Holy smokes, those pictures look legit. It looks *exactly* like the Radxa Rock 5B (probably the idea). I modified your image URL and reuploaded them to get a much higher resolution picture than we were seeing from the Discord servers. You can actually read the Orange Pi 5 Plus on the board now in the reuploaded versions. We can see that it is indeed a RK3588 (proper, no S). We can also read the version as OPI5-PLUS v1.0. Very cool! I would bet that it is real. Everything looks exactly right (especially the things I wouldn’t expect someone faking these to get right).
Another funny but unimportant side note is that guy has *exactly* the same desk I do from Amazon. I would recognize it anywhere. He even got the same color!
That is a board that I would definitely pick up as well. I wonder what the pricing is going to be. If they can get it around $120-$130 that would be a *huge* advantage over Radxa as theirs now starts at $150 for the 4GB (pretty steep).
The reception for the Orange Pi 5 has been incredible. I thought about doing an article like this for the Radxa Rock 5B but it doesn’t seem to be nearly as popular as the Orange Pi 5 (I believe because of the price most likely, it’s at least 50% cheaper). I may still write one but the point is if they can undercut Radxa that would be a huge and very exciting launch (and would probably become very popular very fast). Thanks for sharing that with me!
HI James,
Awesome job updating your HA guide as I’ll have to give it a go as much prefer having the option of running Armbian with 3D acceleration than Debian which is stable and I managed to add my first ESP32-CAM to my setup using your guide after some headache sorting the WiFi so thanks again!
I agree the OPi 5 has been a raging success and I look forward to seeing the OPi 5 Plus drop soon and if they price it competitively it should sell well which has me surprised that they even went with the OPi 5B as I just don’t see the same excitement from the community as the original OPi 5 runs well with NVMe and for most users they’ve found a solution for the missing wireless and the price was a big factor in seeing it become the RK3588S device to own.
Hopefully its affordable as once you get past the cost of a baseline Radxa Rock 5B it starts to creep into Intel and affordable Mini PC territory and although the RK3588 is a beast of a SOC its kinda let down by the GPU and adding the accessories just makes it unfeasible so time will tell what they do and if they manage to announce it before Radxa Rock 5A drops it might eat into those sales as many users like myself may just pay extra for a true budget friendly RK3588 SBC than owning multiple RK3588S boards that lack the I/O we want…!?
Thanks for the links and I hope to see some appreciation for this guide as seeing Steam run on the OPi 5 is really game changing so well done!
Hey Razor Burn,
That’s awesome you got your first ESP32-CAM up, they’re a lot of fun! Mine has been working great in my utilities room. I even keep the light activated so when it’s dark I can see that everything is alright down there.
I completely agree about everything you’re saying about the pricing. It does start to get uncomfortable at $150+ because like you said you’re getting into Mini PC territory and even Chromebook territory almost with the higher end models. There’s definitely an opportunity here for Orange Pi here and there’s an opportunity for Radxa as well.
I can’t wait until we find out more details and see the pricing for it. It is very nice to get all of the I/O with the RK3588. It’s really quite dramatic how much more I/O it has and solves all of those wireless vs. NVMe issues and all of that.
Thanks and take care!