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.
@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.
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
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
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
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)
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
0voters
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.
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.
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
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.
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.
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.
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.
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
@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.
