clockworkpi

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 may do what i done on arch, write some packages and keep system minimal and clean,
actually release a new os image on each upgrade is not a long term viable option

kernel, mesa, xorg, retroarch, cores, emulators, launcher, … each one could be released as a deb package

system on upgrade will properly and cleanly remove old files and set up new ones
also it could replace original debian packages with your custom one, meaning you will put your system in an update proof state with not any incompatible package installed

optionally to distribute them you could also make a debian ppa server like i was make for first compo, that’s not trivial but it’s not hard to do

for the /boot, just auto mount it, have a look at fstab, in arch it’s auto mounted so the system upgrade the kernel like any other packages without any manual intervention

2 Likes

100% Agreed! I’ve provided instructions on how to do each update I did, and provide a script for how to do it when possible, which although isn’t a simple package to install, is a start.

The problem for me was, knowing exactly what people have done when asking for help. Having things done in a ready made image was just easier, and let me know exactly the place where people started experiencing problems.

I could/should package the files into upgradeable packages, but like you said it’s not trivial, and I’d have to start again from scratch, using the 0.5 image as a base.

Maintaining a server to have current updated files for me is a fair bit of work, since it’s not something I usually do. I’d have to learn to do it essentially. If someone could assist in doing so, that would be great! Physically being able to do it for me as opposed to just providing information on how to do it.

I suppose if I ever have to go into quarantine/lockdown I could dedicate time to do it myself. But as it stands now, I’m just doing this as a pet project of my own to help out people.

Anyway, I’ve put up a link for and earlier build 200313, for people who are having troubles with the flickering screen. It’s in the first post of this thread.

I think you’re right. I might start a DEOT v3+ thread soon, instead focussing on being a package based install process, based on a stock 0.5 image. The only thing I wouldn’t be able to change is the first boot screen. But that isn’t the biggest of problems to deal with. Also the next biggest problem is the time it would take. It’s such a big balancing act between convenience and viability.

On another note, @r043v Thanks for the info re: the sun4i_tcon.c file, and the recent changes to the lima driver. I’ll definitely be trying it out. Again though, there’s no way to tell if what I’ve tested will work for everyone. I’m hoping that the flickering is the same thing that you’ve referenced here: [kernel] mainline support evolution

@1115 - Great to know it worked. It’s a Kernel only problem.
The scripts I included with the OS to change the kernel are just the same things you typed to get it working. By invoking them, you have returned the Kernel to the one that causes your screen to flicker. For now, just keep the old 5.3.6 Kernel. :slight_smile:

@shell - Thanks for getting back to me. Interesting to know that you’re using a R16-J board. I’m using two R-16 boards, and have no problems. It would have been clear cut if one board had problems and another didn’t. Perhaps it’s to do with some other component of the CPI 3.1 board? I’m curious to know what the image works perfectly fine on some boards, but not others. Hopefully I’ll get a reply from someone.

@Veronica - You mentioned previously that there is no difference between the R16 and R16-J boards. Is there possibly some other difference between batches produced of the clockwork 3.1 board that could be taken into account when compiling a kernel, in order for someone to write one that is more universally compatible? We are currently assuming that every gameshell is made equally.

For those experiencing problems with screen flickering, I shall reiterate these instructions provided above.

After doing this, don’t run the kernel changing script, unless you want to experience the flickering again.

For those of you not experiencing the flickering, please disregard this post. It appears to be a problem only affecting 1 in 3 users, according to a recent poll.

2 Likes

the stock image worked perfectly but its just the custom image that isn’t working and is flashing for some reason. it was the same card you have the SanDisk Ultra PLUS 128 GB micro SD XC V10 A1

Right. I think I misread your previous post, thinking you meant that one SD card you flashed the custom image to worked wonders. Could you clarify and confirm this?

I’ll start work on an emergency image update after work today, as well as provide a simple script to apply the fix.

It looks like it’s just the kernel that’s the problem, which is a relief troubleshooting wise.

Can I confirm whether or not this ended up fixing the screen flashing problems?

  • It fixed the flashing.
  • It didn’t fix the flashing.
  • There are other problems.
  • I don’t know how to follow the instructions.

0 voters

Update to resolve the above issues, and a few more changes.

DEOT v2+ Build 200323
23th of March 2020

Current changes:

  1. Resolved screen flicker issue.
  2. Provided updated kernel options.
  3. Changed sources.list to use a standardised location (http://deb.debian.org/debian) pointing to buster.
  4. Performed an apt-get upgrade.
  5. Replaced UI elements to allow DEOT Fonts.
  6. Restored DEOT Style Brightness and Sound volume settings pages.
  7. Removed Launcher Go settings page, and removed Launcher Go.
  8. Removed OP-1 and Canis Minor themes. (for now)
  9. Cleaned up Games directories, and moved DEOT Extras folder closer to utilities.
  10. Moved the xbindkeys scripts to their respective directories.
  11. u-boot-tools and flex installed for self kernel compiling.
More info

Flickering problem resolved. (Hopefully?) I have no way of testing if it’s fixed. If someone could report back regarding it, that would be great.

I’ve included a kernel option to change to 5.3.6. This is the stock kernel included with Clockwork OS 0.5. This will now be the default kernel upon booting up. This is the one that should solve your screen flickering issues.

Since 5.3.6 is @shell’s work, I have also provided 5.4.24 (replacing 5.4.21), which is the progression from their original work.

To avoid problems, I’ve removed the 5.5.90 kernel.

Get the updated utilities here:

https://drive.google.com/open?id=17CK8OBwhnB7ibgsVW8dAbwbKbFbwI0w0

(delete the existing 08_Kernel directory, and give the executable bit to the bash scripts as needed.)

Updated sources.list. The stock tsinghua tuna one doesn’t seem to work anymore. I think I just happened to be trying to use it during maintenance. (Archive-Update-in-Progress-nanomirrors.tuna.tsinghua.edu.cn)

Here is what I changed it to.


deb http://deb.debian.org/debian buster main contrib non-free

deb-src http://deb.debian.org/debian buster main contrib non-free

deb http://deb.debian.org/debian-security/ buster/updates main contrib non-free

deb-src http://deb.debian.org/debian-security/ buster/updates main contrib non-free

deb http://deb.debian.org/debian buster-updates main contrib non-free

deb-src http://deb.debian.org/debian buster-updates main contrib non-free

deb http://deb.debian.org/debian buster-backports main contrib non-free

deb-src http://deb.debian.org/debian buster-backports main contrib non-free

Performed an apt-get upgrade. Checked to make sure graphics drivers are functioning correctly.

Replaced UI elements: scroller.py, skin_manager.py, slider.py with stock DEOT versions.

Replaced Settings menu items: Brightness, Sound with stock DEOT versions, removed Launcher Go list item, and replaced modified list_page.py commenting out Launcher Go. Launcher Go also removed from home directory.

Unfortunately, the OP-1 and Canis Minor themes no longer behave due to the above changes. That’s something I’ll work on for the next update. For now, just use the DEOT theme.

Removed strangely redundant games directories. Eg, the old MAME, MGBA, PCSX etc. They have since changed to ARCADE, GBA, PSX to reflect the console name, as opposed to the emulator name. This was done a while ago, so I have no idea why or how they came back. Also, moved the DEOT Extras directory to be next to the Utils, since it made more sense to have the games together.

Moved the xbindkeys scripts to their respective directories. Just for the sake of cleaning up the user home directory. This applies to Samplerbox and SCUMMVM.

u-boot-tools and flex have been left installed, in case you want to compile your own kernels, and admittedly, so I don’t have to keep reinstalling it every time I flash a new card.

As usual, the links will be uploaded in a few hours to my google drive, then I’ll upload it to mega. When I have a bit of time, I’ll also make a zeroed empty space and auto expanding image.

1 Like

Hi! Thanks, the flikering is out, but, the image is broken :sob:

After the image of the DEOT start, there the announce of the happy hacking, but then it shows:

-bash: /tmp/X.log: Read-only file system

and on and on, and nothing after…then if I restart, just the start image then nothing.

1 Like

Hang on. It shouldn’t actually say happy hacking at all. The boot screen was changed to the DEOT custom splash at kernel compilation.
Was this using the new image I just uploaded, or the instruction to copy the older kernel to the boot partition? If it was the latter, that would explain why it would have the happy hacking screen.

It’s midnight now, so I unfortunately need to sleep. The clean image I uploaded is running fine on my gameshell. I’ll try and write the image to a spare SD to see how it goes tomorrow.

Thanks for letting me know! :slight_smile:

Ah. I think I know what you may have done. There is an extremely old 191122 build in the same google drive directory. It has the Happy Hacking boot splash screen. You may have downloaded this mistakenly. That one has an auto expand script and would be based on the initial stock 0.4 DEOT v1. I kept it there for historical reasons, in case anyone wanted to have an image based on a stock DEOT image. I probably should delete it.
Can you confirm that you have downloaded build 200323, before I check things and re-upload the image?

Ok I did flash it twice, same thing, sorry about my bad explantion about what was happening in the image.

Image name: deot_v2+ 200323.img.bz2

I put some pictures, and the last line -bash: /tmp/X.log: Read-only file system, goes on and on…

Just rest, tomorrow will be another day hehe, you already do some hard work with it, you don’t have to stay up to solve this now :slight_smile:

1 Like

Another thought! You may have downloaded a partially uploaded file. Uploading takes an eternity in Australia. That said, it probably wouldn’t have decompressed properly if it was incomplete or corrupted. My guess is, something went wrong when I wrote the image.

This is getting exciting!

On a side note, there’s a bit of extra flash plastic on your d-pad. You’ll get less clicking if you sand it off. :wink:
(It’s messing with my ocd hahaha!!)

not sure if this has come up, on this build I loose wifi, as in I get wifi when I set up, but a day later when I turn it on it cant see wifi at all (but my old sd loadout works fine)

On this build? As in the 200323? Have you gotten it to work? Unless you’re meaning an older one, since you mentioned leaving it for a day and then having it fix itself.

There have been quite a few cases of wifi dropouts, separate from the custom image. It seems that it’s just a very fragile flaky part of the console. There was a thread showing the tiny ceramic antenna, and a hard fix to improve this. There are also a lot of other threads simply documenting the wifi dropping out. It can be due to far too many factors, no doubt separate from the image.

Re: wifi drivers etc, that would no doubt be kernel dependent. I’m not the maintainer of the kernel, so can’t really comment on it, other than to say that the most recent build contains the original 5.3.6 kernel which the stock 0.5 image uses. If you’re having trouble with wifi, try using that.

The kernel option in the current build is the one here:


It’s by the same coder as the stock 5.3.6 kernel, so I thought it a good spiritual successor candidate.

Initially I did write my own kernel while mucking around with optimisations; including some extra governors, sensors, usb otg etc. I decided against including it, since it might cause more problems.

Anyway in short, try changing the kernel via the utility included.

i will, its not tje 323 build, the one before it

Incoming new image being uploaded. I also removed all of the old images from my google drive, so as to not cause any confusion about which version to download. I will upload it to a mega upload soon.
Edit: The Mega link is now in the first post.

Last night, I made the image and uploaded via my macbook pro in Mac OS. It shouldn’t have been a problem, but regardless, I’ve made it “properly” from a debian machine, zeroed the empty space, and made the image filesystem self expanding.

It should be about 2GB compressed. As usual, decompress it (it should be about 6.4GB) then write it to your SD as per normal.

I’ve maintained the same build number, 200323. Assuming that the 200323 never worked for anyone, it shouldn’t be a versioning problem, since the only change is the above zeroing and filesystem expansion. (and I just like the way 323 rolls off my tongue :P)

I am yet to actually test writing it to an SD card. I will do that after I’ve finished uploading the image. It “should” work, but that’s what I thought Re: my initial upload.
Edit: I’ve tested it. It works for me on a fresh card. Let me re-iterate that you will need to let it sit there doing its “thing” for about 60 seconds on the initial boot up. It’s doing a file system expand. Unfortunately there’s no verbose printout on the screen. May I also recommend that you have it plugged into power, in case there is a power failure while it’s happening.

Fwiw, I wrote it to my SD card using dd as follows:

sudo dd if=deot.img of=/dev/sda bs=1M

I’m so very sorry for all of the lost time people had trying this! Good luck with this current build!

1 Like

I flashed this image and everything is just fine. Again, thanks for your work :smiley:

1 Like

THANK GOODNESS! I was dreading hearing back from a post saying that this one was flickering, or showing some other error! Thank you so much for letting me know!

FYI, since you’re interested in Kernel development, you will need to manually change your kernel to one of the different ones. I’ve provided a bunch for you to mess around with. The 5.5.9 one in particular has a few extra CPU governors which I was messing with. Initially I was going to put a 5.5.11 one to mess with, but when compiling it yesterday, i forgot to enable sound. Oops!

OK it’s great, thanks, now it’s working, the only thing that is not working, is Blood hehe

I did this: https://gitlab.com/Oet/nblood/-/tags/v1.21gameshell

And this time it’s not working, can you know why?

1 Like

No screen flickering in latest DEOT build.
Thank you for your effort. :+1:

1 Like

Thanks so much for reporting back @jarze! Hopefully this will be a good check point image to sit on for a while.

The only other thing I would have liked do have updated was Retroarch to 1.8.5, but that would be something I’d prefer to thoroughly test before making live.

@jimfaker From memory, wasn’t Shadow Warrior and Blood two games that needed for be set to the Fbturbo drivers? And on that note, I actually forgot to test fbturbo on the latest images, since I was so caught up doing other things! I forgot some things didn’t work with Lima.

Getting Shadow Warrior and Blood to work with Lima would be another fun thing to work out for sure. For now, try running the overclock script. That should pump out a 40% increase in performance. It scales pretty well for CPU intensive applications.

Also, reading the notes there’s mention of midi buffer under runs. The good news is, I no longer experience buffer under runs with audio in other applications that used to, ie duke nukem, some Mame games and pretty much anything with extended synchronised audio. Try one of the other kernels. 5.4.24 seems to be a good bet, and hopefully shouldn’t have flickering. 5.5.90 will have a few extra tweaks, possibly at the expense of flickering. Let me know your results.

Indeed Shadow Warrior and Blood don’t work on Lima, but I’ve changed it to fbturbo and Shadow Warrior worked. But Blood, is in black screen 3 seconds or so, and goes back to the “desktop”.

I tried all the kernels and just the first one (5306) doesn’t have the flickering, all the others flickering time hehe. Also I tried Blood on all of them and is a no go. :frowning:

Any clue what could it be?