Wow…just like that you solve my hours upon hours of heartache lol…Stock Kernel works, after changing no flickering screen, after powering off and back on no flickering screen also. Not sure if it is the other Kernels that cause it, i can only assume, from what I can tell everything cord wise is installed correctly, the screen is in mint condition and the battery seems to be working perfectly. Given that changing the Kernel alone works and you have also stated that no flickering is reported with it, there has to be something with the other Kernels that are causing the issue. Then again I am not an expert. Question though, are there any real pros and cons with going stock kernel vs a different one? Everything for the most part seems to look and work the same.
Haha! Oh boy if you look up flickering, you can see yours not alone! I’m basically reciting rhetoric at this stage; but learning something new each time. The main thing is, yay! We got things working!
Here’s some info! It’s RIDICULOUSLY simplified, and at times is paraphrasing what has been said in @Joao_Manoel ’s custom image thread. He is the one who put together the kernel. I just implemented it in the kernel switched and includes the DEOT splash screen.
Stock kernel is running massively UNDERCLOCKED according to the specs of the R16 chipset. Stock is 1008MHz. This was possibly due to the early 0.2 and 0.3 OS’s being very unstable, susceptible to crashes, and lacking a dedicated GPU driver = crazy heat!
The standard specs for the R16 should be 1200MHz. So a 20% increase.
The overclock runs up to 1400MHz, and I can attest to it being stable, and not detrimental to the integrity of the board temperature wise. The Clockwork OS has come a long way since the early days, and can handle the extra grunt.
Other things the non stock kernels include are different governors. In a nutshell, it’s a set of rules for how the gameshell’s power management, clockspeed behave. The stock one uses Performance from memory. This means it runs at the max spec’d speed at all times; even when idle. This means it uses extra power when it’s doing nothing. Eg, browsing games.
The custom kernels use On Demand from memory. This runs at lower frequencies when no load is required, essentially meaning it uses less power/runs cooler it will ramp the clock speed up as it requires it at pre designated levels. This means that even though it’s overclocked, it actually spends more time at lower clocks speeds than stock.
Another interesting feature of the latest kernel is a sleep/suspend mode. It was initially excluded from the stock OS, since it wouldn’t last for more than 10 hours in suspend mode, but the community decided that being able to have ANY suspend (say, you need to quickly change trains but can’t save your game), and brought it back.
Another thing that was changed in the custom kernel is the inclusion of the wifi drivers in the kernel. There were far too many problems with the wifi simply not working on some boots when installed as an OS level driver. This helps make things far more stable.
Of course, just having a newer official stable kernel does also have its own sets of pros and cons. We just have to take them as they come. But I can say that I find that using the custom kernels gives far more gains than not. Then again, I am one of the lucky ones who doesn’t have flickering issues.
Hopefully this helps you make an informed choice, albeit slightly biased due to my own preferences.
As for battery being the possible suspect, there would be a slight manufacturing tolerances re: reported voltage etc. The overclock also needs a slight over volt to maintain stability. If the battery isn’t able to provide, perhaps flickering occurs? But since a reboot fixes it, conversely it could be unrelated, and more associated with clock synchronisation between different busses. See here re: tclock
I haven’t been able to apply this, since I’m not experiencing any problems, so wouldn’t notice any differences. It would just be an extra line added to the kernel config, so easy for anyone to try for themselves. But this also assumes they can compile a kernel.
Anyway! See if that helps!
The main reason I asked is that if I switch to another kernel alone the flickering will persist after reboot and of course power on. But if I use the stable kernel reboot or power on no flickering occurs. The other interesting this is that during the initial gameplay I can switch to the stable kernel and then switch to a different kernel no flickering happens but again if a reboot occurs or power off and on. It will flicker until I switch back to stable and then back to the other kernel, it is weird. I am curious when on any of the kernels I do go into the clock speed settings and set it to overclock, but is there a way to check to see that it indeed switched over to overclock? Or do I just trust that it was completed the same question goes for the kernels, other than the screen flicker I have no way of really knowing if it switched as most of the UI looks the same, at least I cannot tell any differences.
Also, my next thing is trying to figure out how to connect my 8bitdo pro gamepad via bluetooth to the gameshell. I never was able to figure it out on the original OS so maybe this one will be easier haha
by any luck could you try arch os image ? it have the dclock patch we suspect is a need for screen flickering issue.
also for your second question the arch dedicated launcher got < cpu mhz / enabled cpu cores / cpu governor > current visualization and you could change them at runtime.
Yesterday I decided to try out the Verbose (Ve) kernel inside the OS which is an upgraded boot/version from 5.7 not sure if that is good or bad, but that version did not give me any screen flickering issues just like the stock 5.3. The only way I can really tell that the OC is working for that version is just noticing that the chips do get significantly hotter than when I changed it from its stock setting lol Not sure if the Verbose 5.7 Kernel has any way of seeing the clock speeds.
If you go into the “about” section of settings, you can see which kernel you’re using, what the current frequency is (its dynamic, so could report as low as 700MHz at times) and what governors are present.
It’s strange that the overclock was hotter. It should have been the opposite.
On the note of the kernel switching scripts, they actually include a “sudo reboot” as a part of the script.
The different names shortcuts are just “optimal” combinations that happen to work well with one another. They are a combination of kernel and dtb files. Have a look at the first post for what they are.
Definitely try out the arch Linux OS mentioned above. See what happens re; flickers and performance. If you can verify it to be working, it would help narrow down the problem.
Interesting, well I take it back, somehow I am still on 5.3.6 per the about page, so the stock kernel, even though I selected verbose, the clock speed is 1400 so it is “overclocked” but now no matter what I do I cannot change the kernel or stock, anything I select after it does its thing I check back and it shows the stock 5.3.6 and 1400 oc.
Update: Correction, very weird before after a internal reboot it would change the kernel and stock without turning it off and on manually, but after doing so it changed. I am going to keep it OC but change it to every kernel I can and see what happens for each and report back.
thanks, @javelinface for your detailed reply
asking for a little more help on the pico8 (since that is my reason of dusting off the gameshell again)
from the desktop version, I was able to download a few carts (example picohot-0.p8.png)
now, on the gameshell, I am putting them under the directoy of /home/cpi/.lexaloffle/pico-8/carts
is this how to take carts and use them on another machine? if yes, then after doing this how do i use them?
also, does it matter that carts from pc to be put on gameshell? I mean, on pc it says press “x” and “c” buttons etc… which on gameshell is different buttons. are the carts the same version on all hardware or should I somehow get the gameshell version of carts (for compatibility, etc?)
1400 Mhz
5.3.6 - stock
stable
1400 Mhz
5.5.9 - overclocked
flickering
1400 Mhz
5.7.0 - suspend
flickering
1400 Mhz
5.3.6 - 5306
stable
1400 Mhz
5.4.6 - 5406
flickering
seem to get worse at this point
1400 Mhz
5.4.21 - 5421
flickering - excessive flickering - white flash at times
1400 Mhz
5.4.24 - 5424
flickering - excessive flickering
1400 Mhz
5.4.9 - 5409
flickering - excessive flickering
1400 Mhz
5.7.0 - 5700
flickering - excessive flickering
1400 Mhz
5.7.0 - silent
flickering - excessive flickering
1400 Mhz
5.7.0 - verbose
flickering - excessive flickering
What is weird is that anything switched away from stock needed a manual reboot, but when switching back to the stock it would do a hard reboot and would ultimately work. Not sure if that means anything but was interesting. The other things is that when moving to any other kernel it would keep the oc speed of 1400 Mhz, but when switching back to the stock it would revert it back to 1008 Mhz which is the stock clockspeed and I had to change it back to 1400 Mhz after.
The gameshell uses an arduino “keyboard” programmed for certain keys to be mapped a certain way. Since the pico-8 is a “fantasy” console with a defined pair of action buttons and a D-pad, the gameshell “version” has been mapped to follow this convention. In short, it should just work without needing a special gameshell version.
Try putting it in /home/cpi/.lexaloffle/pico-8/carts/, see if it works, and then if it doesn’t, put it in /home/cpi/.lexaloffle/pico-8/bbs/
That’s where you can find the majority of files. One of them is a cache, but it doesn’t actually ever flush. My guess is that it’s for where the games stores using the online are held.
Anyway, I’m just one guy, and not an expert on Pico-8. I didn’t write the installer for Pico-8, and to be honest, haven’t actually used it too much recently. I can provide help, but ultimately it might be better to start a new thread to get more help. Not everyone will be able to help out if it’s a reply to this custom OS’s thread.
@ajbrensike Hello! All of what you posted makes sense. The problem is, the stock kernel wasn’t written to go up to the higher speeds. It basically has a defined set of clock speeds if has under different loads. From memory, the stock one was an all or nothing affair of 1008MHz for everything. The other ones has tiered clock speeds. If you let the game she’ll sit idle for say 5 mins on one of the “custom” kernels, then do a clockspeed check, you will notice it’s lower.
I “thought” I put in a “sudo reboot” in my scripts, but I could be mistaken! I know for my own use, I removed it, so I can do multiple changes to my choices re: kernel/dtb and then reboot. I don’t actually ever use stock, so that could be why it still had the hard coded reboot present. There’s a chance it may have snuck into the final release the same way. Either way, whether it’s done automatically or not, the Gameshell needs to reboot before the kernel change is applied. That could be why it’s reporting as 5.3.6.
If you want to, you can read the contents of my script file. Is a super simple copy paste affair. I didn’t do any actual on screen menu selectors, since I didn’t expect people to really use it that often, and thought of it as a quick remedy for a few people having problem. I could potentially make one, similar to this:
But ideally, it would be better actually have a kernel that works for everyone that doesn’t need to have switching.
Ideally, just set it to one that gives you the most enjoyment and leave it. 1400MHz is nice, but realistically not many things make use of the full clockspeed, and you’ll enjoy the gameshell just as much without it.
Work has gone back for me, and I’m full on. I’m a musician, so it’s been teaching 7am-4pm, rehearsing/gigging 6pm-10pm on Mon-Fri, then weekend concert/recordings weekends. I’ll see what I can do in my spare time, and I’ll post something here if I come up with a better solution. If anything it will just be a replacement 5.7.0 kernel with the dclock patch applied.
Basically, I’ll be adding this before making the kernel:
sed -i 's/tcon->dclk_min_div = tcon->quirks->dclk_min_div/tcon->dclk_min_div = 6/' ./drivers/gpu/drm/sun4i/sun4i_tcon.c This is from @r043v 's suggestion above. Eh, I’ll just do it now. I’ll start compiling now and post in an hour or so. See if it helps!
NOTE: THIS IS FOR TESTING! THIS IS FOR ADDRESSING FLICKERING ISSUES!
Okay, try this at your own risk. Backup before trying this. Or wait for someone else to do it and report back.
As mentioned above, I added the sed -i 's/tcon->dclk_min_div = tcon->quirks->dclk_min_div/tcon->dclk_min_div = 6/' ./drivers/gpu/drm/sun4i/sun4i_tcon.c patch, and applied it to the 5.7.0 kernel; making new dtb files while I was at it.
I’ve tested it on my own Gameshell, and well. It boots, and works. Ie, it shouldn’t prevent your system from working.
(this problem was fixed - but I'll keep it here, in case anyone still has the problem)
HOWEVER I’ve tested Mupen and Retroarch Snes9x and they don’t appear to be running. Other standalone do work. I’ll try rebuilding mupen and Retroarch to see if it addresses things. But if you do have the flickering, please try out the standalone emulators that work, and see if it flickers.
The TEST script changes both the kernel AND the generated dtb files. It seems to be the newer dtb files that causes things to stop working. For now, you can restore functionality using one of the “clock speed settings”, such as “governed” or “overclocked”. Both of them will make Mupen and Retroarch run again. Whether or not the flickering gets resolved, I have no idea since I don’t have this problem. (See below for a small hot fix to the “overclocked” clock speed script.)
Mainly try this out to see if it addresses the flickering issues. If you accidentally try this, and some things stop working, you should be able to return to normal using one of the existing kernel changing scripts.
It makes an entry called “Test” in the utilities>kernel section of the launcher. (Oh, I made the translation file change “utilities” to “tools” to be in line with the stock DEOT OS, so look in “Tools>Kernel”)
If you want to go back to the other combinations, they should all still be there.
To install the update, SSH into your gameshell, then just copy paste everything into your session command line. If you do the last line as well, it should run the script, which includes restarting your gameshell with the new kernel applied.
IMPORTANT!! ENSURE THAT THE GAMESHELL IS CONNECTED TO THE INTERNET SO IT CAN DOWNLOAD ALL OF THE NEEDED FILES! IT WILL NOT BOOT UP IF YOU FAIL TO DO THIS! (Thanks @DJC4 for pointing this out!)
wget -O /home/cpi/apps/Menu/60_Utils/08_Kernel/4_Test.sh https://www.dropbox.com/s/vios5l1yl2kks4b/4_Test.sh?dl=1
chmod +x /home/cpi/apps/Menu/60_Utils/08_Kernel/4_Test.sh
wget -O /home/cpi/apps/Menu/60_Utils/08_Kernel/5.7.0b https://www.dropbox.com/s/3sdh7a7bcefmkdc/uImage?dl=1
chmod +x /home/cpi/apps/Menu/60_Utils/08_Kernel/5.7.0b
wget -O /home/cpi/apps/Menu/60_Utils/08_Kernel/bootb https://www.dropbox.com/s/eerxrdbsdve22dr/boot.scr?dl=1
chmod +x /home/cpi/apps/Menu/60_Utils/08_Kernel/bootb
wget -O /home/cpi/apps/Menu/60_Utils/07_Clockspeed/1200b https://www.dropbox.com/s/i26h9wlerwhkec8/sun8i-r16-clockworkpi-cpi3.dtb?dl=1
chmod +x /home/cpi/apps/Menu/60_Utils/07_Clockspeed/1200b
wget -O /home/cpi/apps/Menu/60_Utils/07_Clockspeed/1200HDMIb https://www.dropbox.com/s/4cqaixwujvgtcox/sun8i-r16-clockworkpi-cpi3-hdmi.dtb?dl=1
chmod +x /home/cpi/apps/Menu/60_Utils/07_Clockspeed/1200HDMIb
cd /home/cpi/apps/Menu/60_Utils/08_Kernel/
./4_Test.sh(this probably isn't a problem - and something I only noticed on my "day to day" machine. It wasn't present in my "deployment" machine, so probably isn't in the uploaded images. Again, i'll leave it here, just incase.)
While I’m here, I just noticed a typo in the “Overclocked” script!
It contains:
#!/bin/bash
sudo mount /dev/mmcblk0p1 /boot
sudo cp /home/cpi/apps/Menu/60_Utils/07_Clockspeed/Governed /boot/sun8i-r16-clockworkpi-cpi3.dtband should be
#!/bin/bash
sudo mount /dev/mmcblk0p1 /boot
sudo cp /home/cpi/apps/Menu/60_Utils/07_Clockspeed/1400 /boot/sun8i-r16-clockworkpi-cpi3.dtbHere’s the fix:
wget -O /home/cpi/apps/Menu/60_Utils/07_Clockspeed/03_Overclocked.sh
https://www.dropbox.com/s/ako44y2o4805ddq/03_Overclocked.sh?dl=1
chmod +x /home/cpi/apps/Menu/60_Utils/07_Clockspeed/03_Overclocked.shHere’s something else to try out, from here: Emulationstation on Gameshell - #56 by javelinface
Emulation Station.
Here is the original source: Install Emulationstation on Gameshell · clockworkpi/GameShellDocs Wiki · GitHub
I’ve toyed with the idea of completely replacing the current launcher with Emulationstation, or at least having the option to change between them, kind of like “bean” in the utilities.
I’m posting it here, only because it’s reflective of the directory structure of this custom OS.
- Start by following the script, as per the above thread to install the launcher/frontend:
sudo apt-get update
sudo apt-get install -y libsdl2-dev libboost-system-dev libboost-filesystem-dev libboost-date-time-dev libboost-locale-dev libfreeimage-dev libfreetype6-dev libeigen3-dev libcurl4-openssl-dev libasound2-dev libgl1-mesa-dev build-essential cmake fonts-droid-fallback vlc libvlc5 libvlc-dev rapidjson-dev
git clone --recursive https://github.com/RetroPie/EmulationStation.git
cd EmulationStation
cmake .
make -j4
sudo make install
cp -R ~/EmulationStation/resources/ ~/.emulationstation/resources/
rm -Rf ~/EmulationStation/- Make a directory to put a shortcut.
mkdir /home/cpi/apps/Menu/60_Utils/12_EmulationStation/- Put in the running script and icon.
wget -O /home/cpi/apps/Menu/60_Utils/12_EmulationStation/EmulationStation.png https://www.dropbox.com/s/0p0pyfhv77raliy/EmulationStation.png?dl=1
wget -O /home/cpi/apps/Menu/60_Utils/12_EmulationStation/EmulationStation.sh https://www.dropbox.com/s/e95n4asq9a4yhl0/EmulationStation.sh?dl=1
chmod +x /home/cpi/apps/Menu/60_Utils/12_EmulationStation/EmulationStation.sh- Make a themes directory.
mkdir /home/cpi/.emulationstation/themes/- Get a theme.
cd /home/cpi/.emulationstation/themes/
wget -O /home/cpi/.emulationstation/themes/simple_latest.zip https://emulationstation.org/downloads/themes/simple_latest.zip
unzip -o simple_latest.zip
rm simple_latest.zip- Copy in all the configs.
wget -O /home/cpi/.emulationstation/es_input.cfg https://www.dropbox.com/s/lz18dzx7ks2vbai/es_input.cfg?dl=1
wget -O /home/cpi/.emulationstation/es_settings.cfg https://www.dropbox.com/s/3i2t416ilkjcz75/es_settings.cfg?dl=1
wget -O /home/cpi/.emulationstation/es_systems.cfg https://www.dropbox.com/s/0l4tlvkoi3b0s5c/es_systems.cfg?dl=1-
Reload the launcher, or restart the Gameshell. There should be a new entry in Utilities. Run it to test out Emulationstation. To enter the EmulationStation menu, push start.
-
It is currently set up to primarily use Retroarch emulators. This is to reflect a possible candidate for a slimline OS, say using @Joao_Manoel 's minimal image. If you would prefer to include EVERY emulator on the gameshell, run this:
wget -O /home/cpi/.emulationstation/es_systems.cfg https://www.dropbox.com/s/khxoigwgq265n5z/es_systems.cfg.all.bak?dl=1It will display A LOT of doubled up systems, and generally be quite a mess. Eventually, it would be good to use this: Launch emulator script - #2 by Dowdheur
To revert it to retroarch only, run this again:
wget -O /home/cpi/.emulationstation/es_systems.cfg https://www.dropbox.com/s/0l4tlvkoi3b0s5c/es_systems.cfg?dl=1Oh my, I forgot to reply to your post!
The kernels are for the most part using the defconfs of the specific author’s work. I’ve mentioned who made which one in the OP.
The only thing added was the tcon patch mentioned above, and manually adding the wifi module after the kernel was compiled.
Here’s the main kernels I’m using. I’m not cross compiling, but using the gameshell itself to compile.
Re: ZRAM, I uses to run into some problems using -j4 when building or making binaries. I believe that was possibly due to a lack of a swap file. I’m guessing that’s what you’re thinking, re enabling ZRAM. I actually included a few scripts for enabling, setting and deactivating the swap file space. I used that for times when I needed it. You should be able to find it in utilities/tools.
Of course there’s also the controversy of running a swap file on SD flash memory, and potentially having the benefits being less than the degradation of life. Realistically unless I’m compiling, I’ve rarely found RAM to be the bottleneck of the system.
Otherwise, it should be a simple case of running [make menuconfig] and enabling zram as you see fit; and any other changes to the config. The only other thing I’ve altered was the including of a custom splash screen. I just substitutes the stock one with my own. Since we didn’t have the source code, I just imported images from media coverage, formatted the file to the required standard and put it in the arch/drivers/video/logo directory. Here’s some more info.
https://developer.toradex.com/knowledge-base/splash-screen-linux
Hopefully this is somewhat helpful. Again, sorry for overlooking your post! Life got busy!!
On the topic of flickering, no one’s reported back re: the update I posted two posts up.
I’m just going to tag a few people who have mentioned flickering, and hopefully this can fix everyone’s problems. If you could post your results, that would be great. I can’t tell if it changes anything, since I don’t get flickers.
@ajbrensike @Lambdanaut @CommanderKitler @ghostronaut @Lix @Shwifty @DJC4
Was it possibly not clear how to do it? You need to SSH into your Gameshell, then basically copy paste everything in the code box into your session.
@javelinface I have replaced my battery and will inform you if that gets rid of my flickering for good after a few days of use. I will then tell you my results. In the event of the battery replacement not fixing the flickering I will back up my files and try the above solution and report that too.
Theoretically, it should be safe enough to do without backing up. But of course, Murphy’s law dictates that if something can go wrong, it will go wrong!
Perhaps test it out on a spare SD Card, testing the process; then when you’re confident, and see if it works, apply it to your main SD card.
Thanks for getting back to test the above. I’m fairly confident that the kernel change will do the trick, and you won’t need to mess around with changing the battery. Although, it’s probably a good idea to do it anyway, since the battery is a consumable item that degrades over time.
Okay, I found that the battery replacement did indeed not fix the flickering (although it does provide slight stabilization). I tried the fix above and and It fixed the flickering. I would like if you could an explanation of the root problem and how you fixed it @javelinface.
For future viewers:
If you do the linked fix without internet the links won’t download and upon the restart and execution command the Gameshell will freeze and you will need to re-flash.
Oh my goodness I completely forgot to mention that!! Ahh I just assumed that it would be known, via the wget command. But forget that there may be an off chance that people are just copy pasting blindly!
Glad to know that the update fixed it.
As for the process re; the kernel compiling process, the kernel is based on @Joao_Manoel ’s kernel.
See here: GitHub - wolfallein/clockworkpi-debian: A minimal Debian OS for clockworkpi device based on Allwinner R16 SOC
I simply added sed -i 's/tcon->dclk_min_div = tcon->quirks->dclk_min_div/tcon->dclk_min_div = 6/' ./drivers/gpu/drm/sun4i/sun4i_tcon.c before executing a make command.
Of course I also replaced the boot image with the DEOT version, but this is obviously not something you would want unless you’re using the DEOT image.
The commands I provided merely downloaded a compiled set of kernels and boot images, set the permissions, and provides a script for add to the rest of the pile to switch the kernel/boot img at will. It does so by mounting the boot partition, and copying the downloaded kernel/images to the appropriate directory, and overwriting the existing files with renames copies of the patches ones. This is how all of the kernel changing scripts work. You can open the script file to see for yourself. It’s far from elegant, and much cleaner solutions exist. I just did something super rough to get quick changed out to people as soon as possible.
Anyway, keep testing it out, and report back any problem (if any) you encounter that weren’t present in the original one. If there aren’t any, we may well have just solved the flickering problem once and for all! I’d still rather have a larger test sample before deeming it a success. Thanks again!
i been away a while, anything new in your image Jav?
I’m not sure what you last used, but you can check if you scroll up.
The latest thing I did was a test kernel to address the flickering issue. That wasn’t a new image, but a hot fix.
i think im on the current one, just wondered