First impressions -- A look at the OS


#1

@yong posted an OS image recently. I thought I’d crack it open and see what we’ve got going on in here!

Here’s just some general notes on what’s coming:

OS:

Debian 9 – The latest available version of Debian.

Apt:

3/4 repositories included in the main list are pointing at a Japanese mirror:

# deb http://debian-mirror.sakura.ne.jp/debian/ stretch main

deb http://debian-mirror.sakura.ne.jp/debian/ stretch main
deb-src http://debian-mirror.sakura.ne.jp/debian/ stretch main

deb http://security.debian.org/debian-security stretch/updates main
deb-src http://security.debian.org/debian-security stretch/updates main

# stretch-updates, previously known as 'volatile'
deb http://debian-mirror.sakura.ne.jp/debian/ stretch-updates main
deb-src http://debian-mirror.sakura.ne.jp/debian/ stretch-updates main

As you can see, updates are included but non-free and contrib are not. Which could be a good thing or a bad thing, depending on what side of the fence you’re on in regards to Free Software vs. compatibility and available software.

Kernel:

According to dpkg, the system will be running an up to date kernel:

root@thinkrad:/# dpkg -s linux-image-armmp
Package: linux-image-armmp
Status: install ok installed
Priority: optional
Section: kernel
Installed-Size: 16
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Architecture: armhf
Source: linux-latest (80+deb9u2)
Version: 4.9+80+deb9u2

I don’t know how to check to see if the uImage also reflects this package version, but if this thing is running mainline Linux, that’s awesome news!

Another thing to note here is that it’s armhf (32-bit).

Bootloader:
While we’re waiting for source on the bootloader, we can at least see that in the /boot partition we’ve got a custom .dtb, built on top of the sun8i-r16.dtb.

I’ve uploaded a copy of the .dts on Github

GPU:

Something worth noting is the entry here:

Which shows that the GPU should be exposed, at least in terms of hardware.

However, I don’t see the library traditionally present on Mali GPU systems which provides it’s GLES acceleration (libMali). Unless the Gameshell is now using the lima binaries, it would seem that GPU acceleration might not be available at launch.

There are GL* libraries installed though:

/usr/lib/arm-linux-gnueabihf# dpkg-query -l "libgl*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
un  libgl-dev      <none>       <none>       (no description available)
un  libgl1         <none>       <none>       (no description available)
ii  libgl1-mesa-de 13.0.6-1+b2  armhf        free implementation of the OpenGL
ii  libgl1-mesa-dr 13.0.6-1+b2  armhf        free implementation of the OpenGL
ii  libgl1-mesa-gl 13.0.6-1+b2  armhf        free implementation of the OpenGL
ii  libglade2-0:ar 1:2.6.4-2    armhf        library to load .glade files at r
ii  libglapi-mesa: 13.0.6-1+b2  armhf        free implementation of the GL API
un  libgles2       <none>       <none>       (no description available)
ii  libgles2-mesa: 13.0.6-1+b2  armhf        free implementation of the OpenGL
ii  libgles2-mesa- 13.0.6-1+b2  armhf        free implementation of the OpenGL
ii  libglew-dev:ar 2.0.0-3+b1   armhf        OpenGL Extension Wrangler - devel
un  libglew1.5-dev <none>       <none>       (no description available)
un  libglew1.6-dev <none>       <none>       (no description available)
ii  libglew2.0:arm 2.0.0-3+b1   armhf        OpenGL Extension Wrangler - runti
un  libglfw-dev    <none>       <none>       (no description available)
ii  libglfw3:armhf 3.2.1-1      armhf        portable library for OpenGL, wind
ii  libglfw3-dev:a 3.2.1-1      armhf        portable library for OpenGL, wind
un  libglfw3-wayla <none>       <none>       (no description available)
ii  libglib2.0-0:a 2.50.3-2     armhf        GLib library of C routines
ii  libglib2.0-bin 2.50.3-2     armhf        Programs for the GLib library
ii  libglib2.0-dat 2.50.3-2     all          Common files for GLib library
ii  libglib2.0-dev 2.50.3-2     armhf        Development files for the GLib li
un  libglib2.0-doc <none>       <none>       (no description available)
un  libglu-dev     <none>       <none>       (no description available)
un  libglu1        <none>       <none>       (no description available)
ii  libglu1-mesa:a 9.0.0-2.1    armhf        Mesa OpenGL utility library (GLU)
ii  libglu1-mesa-d 9.0.0-2.1    armhf        Mesa OpenGL utility library -- de

Though they’re all mesa provided. And since they’re coming from the upstream debian repositories:

/usr/lib/arm-linux-gnueabihf# apt-cache policy libgles2-mesa
libgles2-mesa:
  Installed: 13.0.6-1+b2
  Candidate: 13.0.6-1+b2
  Version table:
 *** 13.0.6-1+b2 500
        500 http://debian-mirror.sakura.ne.jp/debian stretch/main armhf Packages
        100 /var/lib/dpkg/status

It’s safe to say that all 3D applications will be software rendered.

Packages:

I’ve pushed up a list of all installed debian packages on Github as well.

It looks like the default window manager may be twm: https://gist.github.com/computermouth/705a18cf316ecd221f88696f82d52684#file-clockwork-package-list-L1056

I’m personally not familiar with twm, but it looks to be super old. Which could be good! Window managers have only grown more bloated over the years, and since the Gameshell really just launches one application, a small slim window manager would be a good choice.

Homedir:

The primary username is cpi.

In the home directory are three folders (outside the usual hidden configuration files and directories):

/home/cpi# ls
apps  games  music

Inside apps/ we have:

/home/cpi/apps# ls
emulators  launcher  twm.mod

twm.mod is an ELF binary. I suspect this is actually how the main UI is implemented, as a plugin to the twm window manager. If so, that’s great, because it will mean a tightly integrated user interface.

Drilling deeper, we can see that the launcher and it’s items are derived of python applications and shell scripts:

/home/cpi/apps/launcher/Menu/GameShell# ls
10_Settings  20_Retro Games  CaveStory.sh  freeDM.sh  Music Player  PowerOFF  RetroArch.sh  TinyCloud

From left to right, we have:
Settings
Retro Games (which looks like a launcher for emulators MAME, MGBA, NESTOPIA outside of retroarch)
Cave Story
Doom
A Music Player
Power controls
A retroarch launcher
TinyCloud ( looks like an app for transferring data to/from your gameshell using ssh, samba, etc)

So far, the only retroarch core I see on here is the Cave Story one. But if I remember correctly, they’re downloadable through the retroarch UI.

Overall, looking pretty good!

I had hoped for something a little more standardized for menu items than sourcing shell scripts and directories of Python libraries. But it’ll get the job done.

– Ben


#2

twm.mod is just the plain old twm, nothing new here, not sure what they changed here, it looks and behave the same as the original (BTW @yong / @hal if you have made any changes to twm you have to give us the changes)

The rest in /home/cpi is clearly explained in https://github.com/clockworkpi/launcher and the “main UI” is all done by the launcher. TWM have no purpose or nearly here.

And the kernel is probably somewhat custom so not related with the one that APT give you.


#3

Ah ok, I’m not too familiar with twm. Is it stock behavior for the window manager to create a binary in the user’s home directory?

I hope it isn’t. Because if it is, it would seem then that the custom kernel integration wasn’t done appropriately. Without proper integration, it’ll be difficult (as in not the normal procedure) to build and install a new kernel. Also, according to linux-sunxi the Soc is mainline enough to possibly not warrant a custom kernel beyond enabling a few drivers that are already in it for the display.

Additionally, since there are no apt repositories linked in the sources.list that are specific to the gameshell. As such, kernel updates would require a reflashing of the SD card, rather than an update through apt.

Though, this may have been intended behavior, given that the UI is custom, and will also have no update method through apt. However, it does look like there’s an update mechanism through the UI itself.

EDIT:
2018-06-25--1529940015_294x222_scrot

Visible at the bottom of the screen, it looks like the kernel is 4.14, and thus, was installed on top of a regular linux-image install from Debian.


#4

No, they’ve done that (by hand) for some unknown purposes.

Honestly for such device that is not surprising, even the Raspberry Pi using apt to update the kernel is NOT recommanded and most of the time will led to big issues.

Updating the kernel does not need extremely difficult changes as it is just a file in the /boot partition (uImage)


#5

Sure, it’ll be possible, but users will have to follow a custom process provided by clockwork, rather than following the standard documented Debian procedure.


#6

Well people are not really supposed to use APT, haven’t looked at their update process, but I doubt it is using apt in any way.


#7

is possible to run launcher on any unix? (mac or linux? trought ssh etc)


#8

Sure, but your mileage may vary. Others have already emulated it using qemu, if you haven’t used it yourself you can use this guide here that shows how to emulate a Raspberry Pi, but the same principle applies here.


#9

Glad I saw your comment, that would literally have been my first step (apt update && apt upgrade).
I’ll hold off on that until I read a lot more now!


#10

The biggest problem by far now is the low GPU performance…
Mali400 android devices have far better performance.

The next problem is the keypad (but it’s easy to workaround, most apps will allow binding)

Finally, the kernel, because it’s patched… weirdly I tried installing a few fuse filesystems and none worked, that’s a major annoyance imho.


#11

can you create a repo with all files and working script? this web page script dont working