[OS] RetroArch - Debian OS image based on the minimal Debian (u-boot, kernel, and Debian from scratch) [v0.3]

Hi all,

I didn’t work on the image during the last two weeks, but want to know what would be relevant for a next release.

The auto expand feature for the SD card is already in the sources, and will work in the next release.

I want to have a feedback, and know what is the direction we should take for future releases, so I kindly ask you to answer the two survey in this post.

Regarding the HDMI, it is really a pity that we don’t have audio working, but I can say that the driver we have is much better (speaking of the video :slight_smile: ) than what we have on the original GameShell image because it is integrated inside the kernel, so I plan to keep it.

I took the HDMI driver source code from a developer that is trying to have this driver on mainline kernel. He was saying that he would try to enable the audio, not very clear though. I tried contact with him but he never replied. At this point I don’t know if I should try to work harder on it, or just wait for someone do it. I already spent days trying to fix this issue without success, I can say that having his driver working properly in the GameShell is already a big plus. Try to have this driver with sound myself will consume a lot of time (months…?) and I’m not sure if I would be able to get it in the end. I’m just a physicist that happens to like to code, and I’m doing it for hobby, I’m not a developer for any means :slight_smile: . Another thing that I though to ask you guys is how many of you think that the HDMI is relevant and you REALLY use it? So could, you answer it below?

  • HDMI is fundamental on GameShell, and I use it frequently.
  • I use HDMI but I don’t bother having the audio on the GameShell speaker/headphone for the time being.
  • I barely use HDMI.
  • I don’t use HDMI at all.

0 voters

I consider HDMI audio the biggest problem of the image right now, but let’s also think what else we can do. I prepared a list of things that I think I can do (no promises) and want to know what people are more interested.

  • The USB mass storage can enable the GameShell to appear as a storage disk on the computer for easier file transferring. I noticed in the forum that many people have difficulties to transfer files, this could help. The problem is that we need to create a new partition/file on the GameShell file system, this will consume some disk space, and the files cannot be accessed at the same time by the computer and GameShell.

  • Bluetooth audio could be possible if I can increase the transfer speed, but I don’t know. Also, this will decrease the performance in some demanding games since we need pulseaudio running all the time.

  • Custom RetroArch. With actual image I tried to not include any pre compiled binaries (besides the BT firmware loader). But I think I can include a custom made RetroArch with some useful features for GameShell like: screen brightness control, shutdown, restart, sleep, wifi control, hardware monitoring…

So, please answer below. Feel free to suggest things you want of course.

  • USB mass storage (GameShell will appear as a drive on the PC for file transfering).
  • Bluetooth audio.
  • Custom RetroArch.

0 voters


sorry i’m a bit busy, still no found any time to test your image, will try do it soon and also rework on my launcher to make it debian friendly

don’t bother your time on hdmi, having it work is already great, if the original dev still work on it it will come alone soon or later

usb storage could be a valuable addon, anyway use filezilla or other for lambda users is not a pain

bt audio could also be great but i see it more than a tiny plus, less than essential for now, any other dev could also work on it in the future
for bt while arch dev i spend some times trying to use the mainline btattach instead of the proprietary current method, not have luck yet

custom retroarch is pretty great and a perfect solution but could be limiting in the future, if by luck changes could be mainlined it will be awesome, else it could be difficult to update as your patch will also need be maintain along retroarch revisions

other possibility, as our platform is fixed we could directly read “keyboard” input file from a tiny deamon to manage volume & backlight globally (like the wm do into arch) ?
on the same spirit, it seem sdl2 could directly use kmsdrm and evdev, it may be possible on special key to show a gui would take hand over retroarch to allow system full control ?


Thanks for your comments!

This would be amazing :smiley: I believe that you don’t need to make a deb file which is a bit complicated. Maybe a Makefile with install, and uninstall options is more than enough.

I’m inclined to it mainly because apparently our kernel patch modify the allwinner i2s driver to talk directly to the HDMI chip without a proper configuration. In the official image the HDMI is configured when u-boot loads, and after that I couldn’t see any communication to the HDMI driver.

I’m afraid that even if I manage to get the HDMI driver working with audio, the modifications made in our i2s driver will prevent it to work and I would be in the darkness without knowing if the problem is in the HDMI driver, or if the i2s driver is not complete …

I agree, but I will probably add it in the future. I did some tests here and it worked nicely. The only problem I see is that we need to create a new partition/file because we cannot use the same file system the GameShell uses or it would probably corrupt the data. So the best I can think is for instance a 512 MB partition just for transfer files. For example: When you plug the GameShell to the computer it would appear a 512 MB drive on your PC, and you can just copy the files and the GameShell cannot see the files before you eject it from your computer. When the drive is ejected we mount the partition in the GameShell and we can run a small script to copy the files to a final directory inside the GameShell file system… FileZilla is very nice, but sometimes you don’t have it easily available and you just want to copy one single file. The other thing is that we transform the GameShell in a storage disk and we have another excuse to have it in our backpack :grin:

I tried this as well… No luck, but maybe there is a way… We have to find what is the difference between what the Rpi3 implements and the Ampak AP6212.

Precisely. RetroaArch has very active development and my patch needs to change frequently. Most of the cases it is a easy fix, but it require a bit of maintenance. My first suggestion is that we don’t need to have all the time the latest RetroArch. I barely see a big change for one version to the other, so maybe we can skip the last digit versions, let’s say we jump from 1.8.x to 1.9.0 and 2.0.0 instead of 1.9.1, 1.9.2, 1.93… This would give us some time to mature our version without losing much.

This is another possibility, maybe @Petrakis could help us.

1 Like

I believe that you don’t need to make a deb file which is a bit complicated. Maybe a Makefile with install, and uninstall options is more than enough.

on arch it auto update himself with a pacman package, will be same thing if i could work on an apt compatible release, i will do extend test with makedeb script

The only problem I see is that we need to create a new partition/file because we cannot use the same file system the GameShell uses or it would probably corrupt the data.

a full externalization of /home into a dedicated partition may solve the problem ?

My first suggestion is that we don’t need to have all the time the latest RetroArch.

true! (also from packages point of view, asset release check out some times days after the binary package, so a delayed release is not bad)

i see that retroarch include proper code to check batteries and ac state, having also wifi & brightness management could certainly interest official devs, making retroarch easier to be a standalone solution near anywhere

I would approach it differently, code it in the keypad. USB HID has volume and backlight keyboard control. Think of laptop keyboards.

1 Like


Thanks all for the votes. This was also to have feedback on the number of people interested in this project. thanks! :smile:

I have good news about my recent development.

The RetroArch is almost ready, I just want to do some tests before making it available. The main points are:

  • Screen Brightness control on the main menu.
  • Shutdown, and restart on the main menu.
  • wifi connection and management.
  • Bluetooth management.
  • Hardware monitoring option (temperature, and CPU frequency).
  • The on-screen keyboard from RetroArch works with the GameShell gamepad for text entry (so you can entry your wifi password).

On my quest to make all the modifications above, I needed to use connman daemon to manage the wifi connection, since RetroArch already has a drive using it to manage wifi. After spending a lot of time fixing all the problems and finally having the wifi working with RetroArch, I found that the RetroArch team released an experimental driver for Bluetooth as well, so I decided to implement it. On my way of implementing the new BT driver, I found that BT stopped working completely. After days of trying to find the problem, I found that connman disables the BT :unamused:.

To find out what was happening to the BT, I tried all sorts of things because even after removing connman I couldn’t get BT working again, so connman was not the obvious problem especially because I modified a lot the image at this stage. In this journey, I tried different ways to upload the BT firmware to the BT chip, compiled the firmware utility, read a lot about the UART implemented in our SOC, understand how everything was connected electrically and I finally saw that the only problem was that connman was blocking something even after complete removal. So a

rfkill unblock all

did the job and I was able to get BT working again.

The thing was that after all the learning about how everything was working and the BT<->SOC connection, I was convinced that there is no hardware limitation to have higher baudrates and make sound over BT possible. I managed to use a kernel driver to upload the BT firmware to the chip which is better than using the utility brcm_patchram_plus we have actually. The only thing that was bothering me was that I couldn’t increase the baudrate no matter what I tried: new brcm_patchram_plus compiled, original, hciattach utility, kernel driver, different UART configuration new kernel patches to change clock speeds …

I finally found (trial and error) that our BT chip works only with 3 different baudrates: 115200 bps, 500000 bps, and 1.5 Mbps. The 115200 bps is the default and it is what we have normally. 115200 bps is not enough for smooth audio over BT (the audio is stuttering), but 500000 bps, and 1.5 Mbps are enough. I’m actually testing 1.5 Mbps with audio and it is working perfectly. I had problems getting a stable connection when trying brcm_patchram_plus and 1.5 Mbps, but using the kernel driver seems to be working fine.

So even nobody voted for having audio over BT we will have it :crazy_face: It is experimental, and I still don’t know the stability or how well I managed to implement it, but I took it personally because of other problems, and because brcm_patchram_plus was the ugly part of my image.

Regarding the audio over HDMI, I will wait before going on this adventure. It is likely the driver developer will make it happen, and I’m sure it will be much better than what I could do. So, for next we should have:

  • Custom RetroArch
  • Audio over BT.

No guarantees yet because I’m testing it. The BT audio is a possibility, but maybe the user needs to tweak a bit since we still have problems with the A2DP profile in Linux. If you are lucky everything will just work, otherwise, a good source of learning to have the A2DP set correctly can be found here:


I’ll try to release a new image in some weeks.



This is all super exciting news! Great work!
I always wondered how the GPi Case (a different game device) has wifi on its lakka release integrated in the menu. Nice work finding it.
I am sure the Bluetooth would be extremely appreciated. My guess is that no one tied initially for it, because we aren’t used to having it so don’t realise it’s potential/nothing has been done with it.
Now that it’s got some functionality, I will definitely be using it! I guess if was more of a priority of where people would like to see your efforts going. Good on your for going above and beyond!

On a side note, I just want to commend your 5.7 kernel for its amazing power savings and efficiency. The throttling down of the CPU definitely makes my CPI run much cooler, and the option to quickly suspend via the top button is a fantastic optimisation that I now use frequently. I can’t live without it! :slight_smile:


Hello and thank you for this incredible work. Congratulations for all the effort so far.

I’m more or less a noob even though I own my clockwork for a while, i do not consider myself an “enthusiast” (my device actually started gathering some dust until I started lurking again on the forum and saw some good things happening).

My device is currently installed with the stock image (i believe is 0.2 or 0.3) and I was planning to update to 0.5 until I saw this thread. I think I understand what this is, having read all the comments, but I just want to know if i’m right:

It seems that this is a streamlined OS/image compared to the original img which gives you immediate and tangile wins such as: low power consumption, better performance, less storage occupied etc; But at the same time, you also lose the gameshell launcher. Apart from that, I’m unsure.

Is this wanting to be a daily driver for anyone that wants a cleaner rom that boots straight into retroarch and uses retroarch as it’s UI? Is this what it basically is? Because like I said i’m planning to update my console and figured I should install this if it’s better than the original img (i don’t care about BT or hdmi tbh but I cannot say I am a fan of retroarch menu either :D, but i’m all for the evident wins such as low power, performance etc).

Sorry for the long post.

Thanks for your support.

My main goal was to provide a clean untouched Debian (no manual compiled binaries) to developers, so they could use the GameShell board for other things, not just gaming. But also, this image could be good for the GameShell launcher if we install just the enough packages.

The GameShell launcher uses Xorg to work, I don’t want to use it because it takes some time to load, and require some dependecies. I’m pretty sure you can install the launcher with this Debian image and have everything from the official image working here.

The official image has a lot of developer libraries/manually compiled software and duplicated files. The normal user doesn’t need everything. When you try to uninstall a software using apt, (or even update the Debian) it is almost certain that something will break.

This image is intended to not break so easily, and use all the power of apt to keep it updated if you wish.

The only thing I want to do is to give a user-friendly menu using RetroArch. So this will be the only handcrafted software here, and I will provide the patch.

With the retroarch it can be a daily driver easily. This retroarch can connect to wifi from the menu, control brightness and I even already added a storage support to it so you can send your roms to the GameShell using the disk drive will appear when you connect the USB cable, like a memory stick.


Updating first post, with new release!

Thanks to everybody.


pretty nice ! you made an amazing work, well done ! :sunflower:


I installed the latest .3 version, and its only showing me 8gb when i connect to my windows computer, instead of the 256gb card i have. i have not yet installed the inf though

The size of the storage space is not the space you have in your SD card, it is a portion of it.

I limited to 8GB the image size because I think that this would be a good number for most users who wants to use the 16 GB SD card we got (8GB for storage + 8GB OS + software).

The 8GB space is just a file inside your system and you can enlarge it for your case.

Do you want to increase this space? Keep in mind that GameShell wouldn’t be able to write anything to this space, it is read only for the GameShell OS.

1 Like

I’m very interested in sleep function. How can I adapt it to default OS of Gameshell?


Welcome. You can try to use the kernel 5.7 binary that I uploaded sometime ago:


Place it on the FAT partition, remember to create a backup of your kernel before copying it. I’m not complete sure that it will work perfectly, but the chances are high. The only problem I see could be the wifi driver that I decided to compile as a module, instead to be built-in in the kernel (it helps to have more stable connection and reliability), and maybe you will have some problems with Lima driver, not sure. You can try, see, and if you are not happy you can use your old kernel.

If you are a bit familiar with compiling the kernel, you can check here (Enabling standby mode using the power key) the topic with all the explanations and how to enable it using the official kernel patch (https://github.com/clockworkpi/Kernel/blob/master/v0.4/52rc4.patch).

Let me know if you need further help.

I can confirm that I am using @Joao_Manoel’s 5.7 kernel with my custom image based on the clockwork OS 0.5, and the suspend function works.

These were the instructions @Joao_Manoel provided for me that allowed me to have wifi working:

Custom D.E.O.T. V2.0+/Clockwork OS v0.5 image - With customised DEOT interface, Kernel 5.7, Optional 1400MHz OC, Debian 10 Buster, Retroarch 1.8.9, Mupen64+ plus more! (Current build: 200626)

You will just need to know how to make the kernel, which is also provided as very simple and easy to follow instructions in @Joao_Manoel’s github pages.

The only downside with the custom 5.7 kernel is that some standalone emulator, such as gpsp and fceux end up running extremely “stuttery”. This isn’t too much of an issue however, since they run perfectly in Retroarch; something that suits this custom image very well!

I use ondemand by default. Have you tried to change the governor to performance before using the emulator?

1 Like

I have the same screen flickering many are reporting on DEOT with kernels >=5.4 with R16-J boards. Anyone have an idea what is causing this issue?

1 Like

Hello! Welcome to the forums.

I’ve been doing a bit of testing/troubleshooting with both an R16 and R16-J board.

I never had problems with my original two R16 boards, but intermittent problems with my R16-J. I THINK the J might be the older variant, HOWEVER I wouldn’t put it down to the chipset having any differences.

The strange thing that improved it was physically pushing down on the CPI casing. This obviously wouldn’t do anything, unless there were dry solder SMD points which I doubt.

My guess is the older models might exhibit some resistance in the ribbon connector, and pushing down simply reseated it slightly. I recall for the old GBA IPS screen mod, people were having screen pixel tearing issues, resolved by replacing the ribbon cable.

Potentially with the on demand governor, the throttled frequency and voltage mean less current being put through to the display, which may cause more resistance? I’m just guessing here, and haven’t looked anything up.

I’m going to be messing around with making a kernel with just the performance governor, based on 5.9. That is once I have some time. But if you know how to do that yourself, give that a go. @Joao_Manoel I completely forgot to respond to you! I was going to respond as soon as I tried it. Ha good old work/life!

See if you still get the screen distortion when plugged in via HDMI. If you don’t, then there’s a fairly high chance the problem lies somewhere between the CPI board and the LCD display.

1 Like

To try to understand what could be happening I would like to ask a few questions:

  • What OS/custom OS are you using?
  • Is this problem frequent, and does it happens all the time? If not, what application/emulator this issue is more noticed?