clockworkpi

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

GameShell Firmware and Apps
#33

Hi @i4s33u, thanks for trying.

Just yesterday I committed a new code for auto expand. I could have added to the version 0.2 but I missed the opportunity :frowning: This will be out when I have enough new things to explain a new version. Maybe in 2 weeksā€¦

what you need first is to install fdisk. If you have the internet configured, you can use:

apt update
apt install fdisk

and then you can run (If you didnā€™t change the partitions, it should work):

echo -e "d\n2\nn\np\n2\n94208\n\nN\nw\n" | fdisk /dev/mmcblk0
resize2fs /dev/mmcblk0p2

and reboot with:

systemctl reboot

You need to install some dependencies tor that. Can you be more specific? Where the compiation is stopping?

I am working in a RetroArch Lakka version for the GameShell. It has battery monitoring, screen brightness, and other small things. If you are interested I can send it to you before making a proper release. It still need to polish some things and enable the wifi configuration.

To be honest, this minimal Debian is to be the base of small projects like the Lakka. Today, Iā€™m probably the person who worked more on it. On the version 0.3 I will think more on the user experience, and ship the customized RetroArch Iā€™m developing.

Here are some screenshots (not well focused :frowning: ):

You can see the battery information at the top right of the picture:

image
image1668Ɨ1084 550 KB

image
image1713Ɨ1070 638 KB

image
image1830Ɨ1225 690 KB

3 Likes
#34

Hi @Petrakis,

very nice project! I saw that it needs Qt for running. This Debian version doesnā€™t have X11 installed, I donā€™t know if Qt can run without Xā€¦

#35

thanks you, lakka build is very aprriciated :smiley:
Iā€™ve just tried compiled RetroArch 1.8.8 myself but finally messed up with Lima driver, I guess :frowning:
It launched fine but whenever pressing Enter, screen got freezed with error:
lima 1c40000.gpu: gp error irq state=4 status=2b

1 Like
#36

What does it have? wayland? Qt works on wayland too.

It can also work without X11 nor Wayland https://doc.qt.io/qt-5/embedded-linux.html

#37

Oh my goodness this is amazing!! I am super keen on this. This is probably as close to an official Lakka pure gaming device experience as weā€™re going to get!
I am going to download this right away.
This is the kind of image that Iā€™d be happy to hand to someone as a gift, as a person who purely wants to play games on their gameshell.
Iā€™ve been a huge fan of your work. Canā€™t wait to see more updates to it! :smiley:

As for the auto expand, the one Iā€™m currently using on my images is the one from @guu

There was also one that I got from @hpcodecraft that automatically downloads all the tools required to expand, expands, then removes the tools.

#!/bin/bash

GREEN='\033[1;32m'
NC='\033[0m'

printf "${GREEN}Installing dependencies...${NC}\n"

# Install growpart util
export DEBIAN_FRONTEND=noninteractive
sudo apt-get -y install cloud-guest-utils

printf "${GREEN}Growing partition...${NC}\n"

# Grow root partition
sudo growpart /dev/mmcblk0 2

printf "${GREEN}Resizing file system...${NC}\n"

# Resize file system
sudo resize2fs /dev/mmcblk0p2

printf "${GREEN}Cleaning up...${NC}\n"

# Uninstall growpart package again
sudo apt-get -y remove cloud-guest-utils

printf "\n${GREEN}Done! Reload UI and Check Settings->Storage šŸ˜Š ${NC}\n\n"

Also, on another note, given the simplicity of the OS, this could work as a great base to use something like Emulation Station as a front end. It would be a lot more visually appealing, and about as close to having a RetroPie like experience in a handheld console. There was some talk of it here:

That would at least make using standalone emulators that donā€™t depend on Retroarch easy to access.

3 Likes
#38

OMG, I re-compiled and it worked now.
First time I uninstalled retroarch before compiling
Now I just compile without remove RetroArch 1.7.3
:smiley:

1 Like
#39

Nothing, jusk KMS. No window system or window manager. RetroArch can work without it and have direct access to the GPU. I find this a bit faster than using X11 protocol, consumes less memory, and load faster. Very good that Qt also doesnā€™t need. Iā€™ll check it :slight_smile:

Very good :smiley: You probably removed some dependencies when you removed RetroArch.

Thanks a lot for your kind words, Iā€™m very happy if I can contribute a bit :smiley: Maybe one day we can put your efforts on the DEOT image and transfer your work to this image.

The main reason for this image was to have a clean minimal setup that we all understand what was installed and how it was made from the ground so anybody can use it and build something on top *for gamming or developer). On the official image, we have a lot of binaries/libraries that a normal user doesnā€™t need. I understand that this was necessary when lima was getting support, but now we have everything from Debian working out of the box.

For the expand I like very much these 2 lines:

echo -e "d\n2\nn\np\n2\n94208\n\nN\nw\n" | fdisk /dev/mmcblk0
resize2fs /dev/mmcblk0p2

It deletes the partition and creates another one starting from the same start point than the older. Everything with a pipeline | to fdisk.

4 Likes
#40

Hey @Joao_Manoel I will be very interested by your version with battery info and brightness control ! :slight_smile:

1 Like
#41

This is extremely exciting. Canā€™t believe I only just now found this thread. Iā€™m a developer and was wondering about a clean start like this ever since v0.5 came out and I saw how upgrading goes.

I donā€™t do much by means of emulating, but using your instructions I could build an image to just run other games :smiley:
Iā€™m very curious how Pico-8 would do with your image :wink: though Iā€™m sure that would require Xorg.

2 Likes
#42

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

2 Likes
#43

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 ?

2 Likes
#44

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
#45

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

#46

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

1 Like
#47

Hello,

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:

https://wiki.archlinux.org/index.php/Bluetooth_headset#Switch_between_HSP/HFP_and_A2DP_setting

Iā€™ll try to release a new image in some weeks.

BR

6 Likes
Bluetooth Scan finds nothing?
#48

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:

4 Likes
#49

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.

#50

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.

2 Likes
#51

Updating first post, with new release!

Thanks to everybody.

2 Likes
#52

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

1 Like