clockworkpi

Custom D.E.O.T. V1.0+/Clockwork OS v0.4 image - With Updated Kernel 5.3.6, Latest Lima Drivers, RA1.8.1, Mupen64+ and much more! (Current version: 191122)

AND it’s up. (finally)

If anyone used the previous DEOT v1+ 191019, and can comment on the stability of the lima driver, I’d be curious to hear back.
The main thing I changed was just updating the kernel to 5.3.6.
I’m personally finding that I can run a lot of the Retroarch emulators without the video freezing, and I’ve had to do A LOT less hard resets.
This could also just be due to using the Neon emulators too.

2 Likes

I just compiled version 1.8.1 today. Seemingly it isn’t having the same problems as 1.8.0.
No idea what the problems are; just that they’re not there now.

Here’s a freshly baked config file, with a few other tweaks here and there. It’s running on my current custom image, with an updated kernel, but should basically be 0.4. I’m also using the Lima driver with it.

See how you go. Hmm, this is a bit off topic, but I guess I’m using this as an overall testing bed for a whole heap of things that could be beneficial in this image.

(rename it to just retroarch.cfg, and put it in .config/retroarch)

I downloaded the 5gb file will test when I get home tonight

1 Like

https://mega.nz/#!gUlxHaRL!GCcY30kb7pURIwgcT1i5hFhhEuU4hC09DPzoWQvFRjU

Here is the same image deot_v1+ 20191111.img.bz2 with smaller size(2.7G) and added the auto expand_rootfs

8df90a238896868ad022c3d1e5620788 deot_v1+ 191111.img.gz.1

what a great job @javelinface

After download the image, rename it from deot_v1+ 191111.img.gz.1 to deot_v1+ 191111.img.gz
and use gunzip deot_v1+ 191111.img.gz to uncompress it

2 Likes

@guu You absolute champion!! I’ve been meaning to ask about how you implemented the expander!

If you have a link to where you’ve got any instructions on how to do it, please let me know!; both your auto expand rootfs and how to zero the unused space. They’re both things on my todo list!

I’m trying to keep this also as a hub for educational purposes, so people can easily find all the things I used to make their own image in the future. Your work is always super appreciated!

I’m just in the process of uploading another image with a few more features/updates/tweaks, so for now I’ve removed my original 191111 link; since guu’s modification is exactly what I would have needed to have (plus I’m running out of google drive space lol)

Mainly, it’s just Retroarch 1.8.1 installed, and a bunch of small fixes here and there, eg chai love restored. Another thing I noticed was the crackling sound issues no longer being present, ie a side effect of the 5.3.6 kernel some people reported. Specifically, Nyan cat was a good example to test audio issues. I’ve experimented with a higher bit rate and lower latency in this build, and haven’t come into problems (via Retroarch) yet.

Give it an hour to upload from the time this was posted. Australia = Slow internet.

ok

take the deot_v1+ 191111.img as example

First use https://github.com/Drewsif/PiShrink to do a simple shrink
sudo pishrink.sh -s deot_v1+\ 191111.img
that will shrink your image to be like 6.8G ,don’t forget the -s , without -s, it will add raspberrypi’s auto_expand into the /etc/rc.local

then follow the instructions https://gist.github.com/cuu/b11109f2197cd482fe8d2c61b8d409c6
to add the expander into the img

sudo mount  -o loop,offset=48234496  deot_v1+\ 191111.img /media/sdb2/
cd /media/sdb2/etc/init.d
sudo wget https://gist.githubusercontent.com/cuu/b11109f2197cd482fe8d2c61b8d409c6/raw/672971991633283eaf8cdc0263a99472371b508d/expand_rootfs
sudo chmod +x expand_rootfs 
cd ../rc3.d/
sudo ln -s ../init.d/expand_rootfs S01expand_rootfs
cd && sudo umount /media/sdb2

last is little bit complex
use losetup to setup the img to a loop device, then dd a zero file to fill the unused space with zero and delete it in the last

here is what I did

sudo mkdir /mnt/p2
sudo losetup -P /dev/loop21 deot_v1+\ 191111.img
sudo mount /dev/loop21p2 /mnt/p2/
sudo dd if=/dev/zero of=/mnt/p2/zero
sudo rm /mnt/p2/zero
sudo umount /mnt/p2/
sudo losetup -d /dev/loop21

under your /dev ,there are a lot of loop devices, like loop1 loop2…
just find loop+number not existed under /dev, in my computer , I choose loop21

the /mnt/p2 is a mount folder I create for mounting, you can chose whatever the name you want
just make sure it’s an empty folder, same as the /media/sdb2 above

PS
it took 6 hours to download your image here, so your network is fast :slight_smile:

2 Likes

This is such a fantastic tutorial! Including descriptions of how and why you did things was exactly what I wanted! Thank you so much @guu

As for internet, wow! 6 hours is … yeah, much slower than me! I shall count my blessings! the file is at about 50% uploaded now. It should go fine; fingers crossed. Gotta go to work now, but yeah! Thank you again for your contribution! Let me know if there’s anything you think should be added/removed/optimised - I always trust your opinion! (I’m still on the fence re: updating to the 5.3.6 kernel)

1 Like

you are welcome
you did a lot contributions to the community, we thank you

1 Like

Just wanting to run a poll, mainly pertaining to what settings I use etc. for future updates.
I didn’t want to make multiple polls, so just answer to any that are applicable to you. You can vote more than once.

The first two are to do with how you have your hardware setup on your game shell. This will determine what I set the keys to in future releases.

The next three pertain to the launchers. Since it’s a pain having to cross check and cross update the pages.py file etc for each launcher, and Go Launcher uses a completely different … well… everything, I may just omit updating it in future; removing the launcher switch option to it. That depends on what people want however.

The final two questions are to do with how thoroughly I clear out all of my settings/history etc. I test the images I upload myself, and use them day to day. Different emulators leave stuff behind in different directories, and it can become a pain to find all of them. I can just keep them there between releases if people don’t really care either way. But let me know!

  • SNES Style ABXY
  • XBOX Style BAYX
  • I use the Go Launcher
  • I don’t use the Go Launcher it, but have interest in keeping it
  • I don’t use the Go Launcher, and won’t miss it if it’s gone
  • I don’t like having your old save files, and bash history present in my game shell
  • I don’t mind if you leave your save games/bash history in future releases

0 voters

I’m going to be starting a new image from scratch, only using the mainstream 0.4 image as the base (instead of DEOT); since the DEOT OS is falling behind, but implementing the DEOT interface as a separate launcher, ie the reverse of what t currently is. This is going to have to be a complete overhaul, and I want to make sure I get things the way people want things from the beginning.

As usual, report any problems, or provide suggestions and I’ll see what I can do with them. There’s a list in the original post of things I intend to do, and bugs that need to be removed. I’ll add whatever people suggest, and see what I can do.

Kernel 5.3.6 is a stable mainline kernel with lima driver included.So it’s possible to get ride of the mesa lima driver. It should has performance benefit because lima is now a kernel space driver.But if lima is stable than v0.4 is still need to be tested.
May be:
1: Update libdrm
2: Update mesa
3: Rebuild app depends on mesa
should be done to figure out the problem.

1 Like

That would possibly explain why Retroarch and all dependent cores are far more stable and fast now, since rebuilding to 1.8.1.

I’m currently using your kernel implementation @shell - was the included Lima drivers implemented when you compiled it? I haven’t actually looked into it too much, and was considering compiling one myself; even if it was to have the DEOT boot screen.

I’ll add the above suggestions to my todo list. If you have any resources that can help with it, please let me know and I’ll add it to the resource list for future users.

lima needs general mesa at version 19.1 least

but debian stable only has 18.3 right now.

so we need to wait a while to get rid of the lima-mesa

2 Likes

Lima driver is included.
Before you can use the Lima driver included in the kernel,the following things you should do:

  1. disable the mesa lib which compiled with mesa_lima driver:
    sudo mv /usr/lib/lima /usr/lib/lima_back
    sudo mkdir /usr/lib/lima

  2. edit the x11 config file:
    vim ~/launcher/.xorg_lima.conf

Section "Device"
        Identifier      "Allwinner A10/A13 FBDEV"
        Driver          "lima"
        Option         "fbdev" "/dev/fb0"
        Option         "SwapbuffersWait" "true"
EndSection
  1. change GPU Driver to Lima in launcher and reboot

then you should be able to use the kernel Lima driver.
PS:you can use the following commands to check that you have Lima driver devices initialized.

dmesg|grep lima

it outputs something like:

[    0.932738] lima 1c40000.gpu: bus rate = 200000000
[    0.937530] lima 1c40000.gpu: mod rate = 384000000
[    0.942735] lima 1c40000.gpu: gp - mali400 version major 1 minor 1
[    0.948982] lima 1c40000.gpu: pp0 - mali400 version major 1 minor 1
[    0.955280] lima 1c40000.gpu: pp1 - mali400 version major 1 minor 1
[    0.961585] lima 1c40000.gpu: l2 cache 64K, 4-way, 64byte cache line, 64bit external bus
[    0.970371] [drm] Initialized lima 1.0.0 20190217 for 1c40000.gpu on minor 0
cat /sys/class/drm/card0/device/uevent

it outputs:

DRIVER=lima
OF_NAME=gpu
OF_FULLNAME=/soc/gpu@1c40000
OF_COMPATIBLE_0=allwinner,sun8i-a23-mali
OF_COMPATIBLE_1=allwinner,sun7i-a20-mali
OF_COMPATIBLE_2=arm,mali-400
OF_COMPATIBLE_N=3
MODALIAS=of:NgpuT(null)Callwinner,sun8i-a23-maliCallwinner,sun7i-a20-maliCarm,mali-400

hope it would be helpful.

2 Likes

I think to use launcher to switch to the FBturbo will save the steps of

launcher will edit the /etc/ld.so.conf.d/00-arm…conf and run the ldconfig
so that the lima-mesa will be totally disabled

but the content of

is definitely need to change

And according to
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-19.1-Picks-Up-Lima

the general mesa library also needs to update to 19.1 which currently only available in the sid of debian now

2 Likes

So what need to be done is trying to figure out is it possible to just compile a new version of mesa to replace the old one for a temporary solution before we can use it directly in stable debian.Will using a new version of mesa leads dependence issues.

2 Likes

Re: Debian stable, is this referring to Debian 9 currently on 0.4? Last time I messed around with Debian 10, the only thing that really broke was the Lima driver. If we can compile from scratch using buster, that could be something I’m willing to try.

For ABXY I changed the keypad https://github.com/Mihaylov93/Keypad/tree/abxy

1 Like

According to https://packages.debian.org/source/buster/mesa,the version of mesa in debian buster is 18.3.6-2.
Mesa is an implementation of OpenGL which is an industry standard,so I think if applications don’t use some mesa’s private api(most don’t,in my opinion),and the new mesa support OpenGL’s major version is the same as current version(v0.4 os image included),it would be fine to replace the old version with a newer one.

1 Like

any debian release is just a “stable”

The stable distribution contains the latest officially released distribution of Debian.

This is the production release of Debian, the one which we primarily recommend using.

The current stable distribution of Debian is version 10, codenamed buster. It was initially released as version 10 on July 6th, 2019 and its latest update, version 10.1, was released on September 7th, 2019.

quote from
https://www.debian.org/releases/

since clockworkpi os image v0.4 we changed the /etc/apt/source.list to use stable
so that we can always upgrade the system through apt-get update && apt-get upgrade

right now we just have the last problem , mali 400 gpu driver

1 Like

@petrakis This is EXACTLY what I was planning on using, if the majority of people preferred the SNES ABXY format. For certain apps that don’t let you easily change the defined accept/back button, and have it set to the opposite of what your launcher uses.
Thanks for the link! I’ll add it to the resources list.

@shell this is super helpful, and just what I wanted to try and look into! Definitely a weekend task.
If the sid release of Debian has the required 19.1 Lima drivers, I’d be curious to try out a purely testing image to the world did people to try out and report back. A strong emphasis on it being a super unstable version.

@guu I wonder why the initial release of buster that people were upgrading in October made the Lima/fbturbo driver switch break? Perhaps a kernel mismatch? Or the dependence mismatch mentioned above? Although this was before the kernel upgrade. Either way, thanks for the break down re: how the driver switcher works.