Maintained list of all remaining issues. Call to help.


Askarus

Forum Addict!
Joined
Sep 28, 2011
Messages
4,995
Location
Germany
At the time of writing this, I am working hard on the hardware side to finally get the Pyra production up and running again. However, there is also a lot of work that needs to be done on the software side.

First, there are several issues that never got fixed since the beginning, Second, Debian 10 is at the end of its support period and we need to transition to Debian 12 (Bookworm) as soon as possible. The later comes with its own kind of issues.

This topic will be a collection of all the open issues that I am aware off. I plan to keep the first post updated whenever a fix gets uploaded or I become aware of a new issue.
Having all issues collected here is a better method than communicating them on the Discord or IRC channels.


[FIXED] RAM timings [Crucial]

(Yes, I just copy-pasted this section from my other news thread. I am happy to discuss this issue here to a deeper extent. Maybe @EvilDragon can join the discussion)

What we need the most is some help to fix the boot issues. What we need is a way so that EvilDragon or I (= the noobs) can easily experiment with RAM timings. We have high hopes that many of the dead PCBs can be revived if we experiment with the timings and tweak them to make them work with more CPU-boards.
The issue is, that EvilDragon lacks the time to get into it, so he would need someone to provide an easy solution that allows him to tweak the parameters and test them.
I myself have some moments of ambition to get into the whole OS stuff, however there is a reason why I quit as a programmer. If someone would be willing to contact me, I'd gladly help or collaborate. However the both of us need someone to take us by the hand a bit.

There is a lot more work that needs to be done. This post however shall be about the good news and is already long enough.
Maybe some day I will be stupid enough to publicly promise and other news post regarding open issues and I must commit to it (like I did with this one here).


EDIT solution:
We can close the uboot issue.
We did not know that our Debian 10 test and flash SD card used an older less compatible uboot.

I tested ALL dead CPU bords we have and in the end 74 of them could be survived with the new uboot and in total only 16 did not boot.
That could be uboot or anything else.
Remember, those are not 16 out of 90 but 16 out of all CPU boards produced so far.
This is brilliant news.

[FIXED] exFat support [Debian 12]

Currently Debian 12 does not support exFat SD cards. That is because since Debian 11, exFat is now supported by the kernel and not being handled by exfat-fuse any more. This requires a kernel parameter to be set accordingly, which has not been done for the current Pyra kernel.
The above can be checked easily via the following command:

Code:
$ grep -i exfat /boot/config-$(uname -r)
# CONFIG_STAGING_EXFAT_FS is not set

As you can see, the Pyra kernel supports the needed parameters and all we need to do is to enable it.

So if I know this, why don’t I do it myself. First, it would not help to fix the OS because I am not the one to take care of those things. Second, I have not built the Pyra kernel yet and I have no idea how long it takes to test it.
I consider this to be the easiest fix. We just need someone to test it and push it upstream.

EDIT solution:
aTc set the required kernel parameter and exFat id working on a test OS he uploaed.


[FIXED] Broken _ and : [Debian 12]

Debian 12 has an issue of non functional _ and : keys. This issue is related to how keycodes are being handled on Linux. I deeply investigated the issue already and made an other thread about it already.
For a deeper sumary see my explanation and proposed fix here: https://pyra-handheld.com/boards/th...n-debian-12-bookworm-download-provided.99975/

A short summary would be the following:
The way we handle FN keys is that we assign a keycode to each of them. Linux however only has keycodes for a standard QWERTY keyboard and not for keys that are on modifiers like for example _ and : . Those do not exist on QWERTY but are SHIFT keys.
What we do to work around this is to assign unused keycodes, like F20 for example, to those FN keys and later use xkb to map the to the desired ASCII key. This approach works well enough, as long as there are enough free keycodes.
What happened with Debian 12 is that apparently more keycodes are being used now. On our Debian 10 install, inet has some keycodes commented out that we could use. This however is not the case any longer with Debian 12. So the codes we use for _ and : fall victim to this.

The main issue is, that our Pyra xkb file will always be overwritten by inet. This rule, which specifies that inet always loads last, is defined in a system package and the file itself tells us not to edit it.
After login, we can manually set the Pyra keycodes, If we do that, they will take precedence over inet and _ and : will be functional again.

What can we do about it?
  1. Look for other keycodes not in use – That is possible but I did not find one and got tired by trying them out manually. Maybe I should give that an other try
  2. Modify the inet symbols and comment out the lines that were commented out before – That was and still is the approach I use. It is the one proposed on the other post I made. For anyone who wants an automated installer for that fix, consult that thread, I uploaded an installer there. The issue is however that aTc does not like that approach because he says that the inet keycode files are not maintained by us but system files and we should not modify those.
  3. Do something to load the Pyra symbols after we login – We can do this via an autostart command in the desktop environment. That however is not an universal fix. I experimented with .bashrc or systemd and did not get anything to work that gets to load out key codes properly. What we need to do load the keycodes is to run the following command:
    Code:
    setxkbmap -symbols pyra
So if anyone is an expert on xkb, please comment. Feel free to experiment with any way to load the Pyra symbols using the command I posted above. Chances are high that I overlooked something and that we could go that route.


EDIT solution:
Both, aTc and Wally included my xkb fix into their OS and it works nicely.

[FIXED] Broken MATE theme and icons [Debian 12]

The MATE theme on Debian 12 is broken and has some missing icons. Especially the dark theme seems to be more broken than the light theme.

According to @elvissteinjr, that is the case because Debian 12 removed
Code:
 albatross-gtk-theme
and installing that theme fixed it.

Further, he mentiones a missing icon for the networkmanager. I also encountered that issue but I am not sure if it is theme related or not.


EDIT solution:
There was some issue with icon scaling.
When we set the panel size to 32 pixels instead of 42, all the icons show up properly.
This has been added to aTc's test OS.

At some point we need to rework the MATE desktop to make it look more pretty.
However, this solves the breaking issue for the moment.

[FIXED] Loading Pyra keycodes causes minor breaks

I make a separate topic for that despite being closely linked to the above issue. That is because I already updated the keycodes file. All that’s left is to include it into the OS.

If we manually execute
Code:
setxkbmap -symbols pyra
, some minor things break. That is because the Pyra symbols we currently use are missing two or three entries.

I already fixed the file and use it since then. The fixed file is included in the automatic installer I made in regards to the _ and : fix. This is a non breaking change that does not modify any system files. It can be added to the OS any time.


EDIT solution:
My fixed pyra symbols file was added to both aTc's as well as Wally's OS


[FIXED] Random freezes [Debian 12]

At the time of writing this issue has already been fixed. I will add it to the list nevertheless because not everyone might be aware of this.

For quite a while we had an issue that made the Pyra freeze at random. I also encountered that issue several times. However a fix for that issue has long been made (sorry, I don’t know by whom. Please let me know and I’ll add credits here) and some month ago finally made its way into the official kernel thanks to aTc.

I used my Pyra since then and I did not encounter a single freeze. So I consider this issue to be fixed.
If you still encounter this issue, run the following 2 commands to update your kernel:

Code:
sudo apt update
sudo apt full-upgrade


Audio Driver, AESS

I am not 100% sure about all the ways this issue manifests. What I know is that sound begins to crackle if the volume is set to near maximum.

This issue is related to the AESS driver. It is something I have no experience with and can not contribute at all. Luckily, HNS and Risca are working on it and made some progress. I do not know what the current state is in that regards. However there is a dedicated thread for that topic and I guess it is time to revive that one a bit.


Volume wheel and headphone jack issues

For me, the whole audio part is not very stable.
  • Plugging in a headphone does not change the sound output
  • My volume wheel permanently stopped working all of a sudden (this is not hardware related)
Is this related to the AESS topic? Can we improve this?

@elw3 once made a nice modification to the volume wheel, which adds more functionality to it. We should investigate if it is still functional and provide it as a patch for our upcoming testing OS.: https://pyra-handheld.com/boards/threads/improve-volume-wheel-daemon-bounty.99430/post-1692618


DBP not working on exFat

The topic basically says it all. Apparently at some point the DBP system does not work on exFat drives any more. According to others, it once did but now does not.
This is an issue if you (like me) have a 1tb micro SD card filled with ROMs and music. I can not simply add an emulator via DBP to it.

I have not looked into this and to my knowledge, no one else does currently. So if you want to contribute, this is your chance.


HDMI out not working

I do not have much knowledge about this. It seems like HDMI out does not work currently. If I remember correctly, it somehow is not compatible with the current implementation for display rotation we use.
Maybe someone can comment on this topic.


[IN TESTING] OMAP MHz scaling and power draw

The Pyra is a lot less efficient than the Pandora was. We should aim to improve on that by tweaking the voltage and the CPU frequencies available.

Here is an old patch that unlocks the device tree with additional frequencies and tweaked voltages. More people should test that approach and we should add it to our test release.


EDIT in testing:
I did an in depth investigation on that subject and reduced the voltages for each frequency by as much as possible.
Further I added more MHz steps.
This seems not to decrease power draw significantly, if at all.
Further it seems stable to overclock to 1.8GHz if we adapt the Pyra temperature script to gradually reduce max frequency.

I further tried to make a fake standby by reducing all the background services by as much as possible.
this apparently has also no significant impact and probably does more harm than good.
We should investigate this further.

LTE reception

LTE works but the reception is poor, worse than that. I do get the LTE modem to work and at the right spot, some weak signal will be picked up.

I have investigated this issue as good as I can. Tests with 2 different external antenna show little but not much of an improvement.

Does anyone have experience with that topic? Does anyone know how to test if we even use the built in antenna at all?

HNS assumes that the reception is poor because the LTE module is quite old already and that the frequencies available now are not supported by the Pyra.
I made some tests and the frequencies that are the strongest I my area were already in use once the Pyra was designed. I did that test via my rooted mobile phone. There is an App that allows me to see what frequencies are in use and available. All of those are supported by our module AFAIK. Further, the reception with my phone is quite good and even my old Blackberry Priv from 2015 has no issues with LTE reception.


[FIXED] Booting LeTux

Both, EvilDragon and I could not get the latest version of LeTux to run. This is important because HNS claims that he got very different results during his tests than us. Those tests however were conducted on LeTux OS.
Helping us with instructions on how to get LeTux OS running on the Pyra would be a huge help to us. This would clarify if the LTE issue is related to our OS and some settings we miss, or if it is a hardware related issue.

Here is the installer: https://projects.goldelico.com/p/gta04-makesd/


EDIT solution:
johnicboom did an awesome job here. He got LeTux to boot and uploaded a flashable and working image.
For some reason, only he can properly make a flashable LeTux, even if I follow the same procedure as he describes.

He also made some great progress on the LTE issue and was able to connect to the Internet via LTE and LeTux.
So this issue can be closed.


Charging

1. Slow charging if not booted
We have that awkward situation that the Pyra only loads with about 3 watt if it gets plugged in. Once we boot, the battery charges with about 9 watt. This persists even if we shut down the system afterwards. So to charge the Pyra with maximum speed, one needs to plug it in, boot and shutdown. I know that this is related to our charger chip somehow. Is there a way to fix improve that behavior? It feels super awkward. If someone does not know that, charging the Pyra will take forever. Also it makes it less practical to use a second Pyra motherboard as a charger dock for a replacement battery.

2. Almost no charging beyond 85%
Once we hit 85%, the charging rate drops to an absolute minimum and pretty much never reaches beyond 90%.
This is probably some old implementation to conserve battery health by not having it charged to 100% all the time. However I thing that 85% is a way too low threadshold for the throttle. We are not using a fast charge mechanism anyways.
Not having access to 15% of my battery reduces its capacity for at least an hour of light use.


Severe slow charging issue for some devices

Here is a post explaining in detail an issue that severely affects charging speed for some users: https://pyra-handheld.com/boards/th...ining-issues-call-to-help.100033/post-1719430

The post is quite detailed and lengthy and definitely worth a read. I added the post as a spoiler here, however I recommend you to follow the link above. The original post contains an image that is not present in the qoute in the spoiler tags.

If you want to comment on the issue, I suggest to reply to the original post linked above and not to this one, so that FelixNemis will get notified as well.

I personally have not encountered it by myself and never have heard of it before.

For me the bigger issue is how it always lowers the charging rate to below idle levels after a couple minutes when the Pyra is powered on and plugged in. (Doesn't seem to affect everybody)
I honestly really don't know much of what I'm doing with anything this low level in linux or hardware related stuff but I looked into charging behavior because my Pyra kept lowering the charging speed while using it when plugged in and that was the main thing that kept me from using it more.

I posted on ED's discord #pyra-dev channel but I didn't realize nobody actually uses it apparently? and aTc can't see it from irc, anyway here's what I found.

In pyra-thermal.sh we're reading the temperature of the battery monitor chip itself (bq27421) not the temp sensor from the battery. The bq27421 can report it's own temperature or you can tell it what temperature the battery is, it doesn't connect to the battery's temp sensor at all. The bq24297 charger chip does connect to the battery's temperature sensor but it only uses it to shut off when it's outside of a configurable safe range. It doesn't report the temp from the battery (the driver for it reports an estimate though).

At the bottom of pyra-mainboard-common.dtsi there's a device configuration for "battery-monitor" that uses a driver called "generic-adc-battery" which looks at palmas-gpadc channels 6, 11, and 1 for voltage, current, and temperature respectively. There's definitely something happening on channels 6 and 1, just watching the raw values at /sys/bus/iio/devices/iio:deviceN/in_temp1_raw and in_voltage6_raw, though in_voltage11_raw is suspiciously low whether I'm charging or not. (I've only seen 0, 1, and 2).
The generic_adc_battery module isn't loaded though, if I sudo modprobe generic_adc_battery though it logs iio_charge:0 in the system log then proceeds to immediately shut down the system.
[this is the driver for the ADC chip TWL6040]

It looks like the only source of actual battery temps is the palmas_gpadc channel 1 but idk if that's actually properly hooked up or how to get a celcius temp from the raw data (or get some driver to do it)

also IDK what the actual channel mappings in the palmas_gpadc driver correspond to though there's a Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt doc file that says

Which seems like the config in pyra-mainboard-common.dtsi is at least on the right track

Based on the schematics, the battery temp line does go through the cpu board connector and connects to the TWL6037 (palmas chip I think?) [yes it is] so I see no reason not to believe that the data from the palmas-gpadc driver is actual temperature data

I couldn't really figure out at the time how to properly get a good reading from palmas-gpadc, but I did modify my local pyra-thermal.sh to basically never throttle charging based on temperature so that I can actually use my Pyra more. I would be interested in making/testing a proper fix but I don't know when I'll have time to go looking for answers on how to get good data out of that driver myself. If anyone can point me in the right direction though I might be able to cobble it together quicker.

Note I found the data sheets for bq27421 and bq24297, apparently the sheet for the TWL6037 is behind a NDA or just not publicly available to download (from this TI forum answer). So if someone has that it would be helpful.

I also managed to dig up some more updates to the palmas-gpadc driver from the android source where we originally pulled it that I was talking with Risca about, it's probably worth updating it but it didn't seem to help me get good temp data.
the most up to date one I found was here VS the commit that letux got it from which is this one


Standby

There is no functional standby mode. Do we have any more information on this issue?


Restart

There is no functional restart. Do we have any more information on this issue?


[IN PROGRESS] Keyboard and display brightness

The keyboard as well as the display brightness have generic brightness values set in the device tree starting from 0 and reaching 100 in steps of 10.
In an older OS I tweaked those values to exponential scaling for the display to better match human perception.
Also, the display could go way darker than it currently can.
I would love to see those changes back in the OS.

Further, the keyboard is perfectly readable in the dark with a much lower brightness than what the current minimum is. We should expose more values here as well.

In general, I want to strongly raise my voice to expose every single step between 0 and 100 and handle the steps via a script in the user space. This is how it was handled on the Pandora and it worked wonderfully. This would have huge benefit in the long run, as further customization could be done easily.

EDIT in progress:
I tweaked the device tree so that the screen and keyboard have better values.
The screen seems good now. I could get it a bit darker than it was before.

The remaining issue is the keybord. It is still too bright in my opinion but I can not get it darker without causing significant flickering.


SD card encryption

According to @Nilsnsn , SD card encryption does not work. His assumption is, that the following Kernel parameter is missing:
Code:
CONFIG_CRYPTO_USER_API_SKCIPHER
Here is his initial forum thread: https://pyra-handheld.com/boards/threads/recompiling-kernel-for-cryptsetup-support.99817/

I have not tested this by myself and can neither deny nor confirm this issue.
 
Last edited:
I'm not a programmer or a linux expert, but I do have a Pyra and love for this community. I'm happy to test anything out that might help move any bit of this forward.

Maybe I can find some time to dig into one of these issues like the HDMI-out issue and see what I can learn and how far I can get.
 
I'm not a programmer or a linux expert, but I do have a Pyra and love for this community. I'm happy to test anything out that might help move any bit of this forward.

Maybe I can find some time to dig into one of these issues like the HDMI-out issue and see what I can learn and how far I can get.

That's a tough one. Good luck :)

If you want to test LeTux, here is an installer. Maybe you can figure out something. https://projects.goldelico.com/p/gta04-makesd/

I added the link to the installer to the main post.
 
Charging

We have that awkward situation that the Pyra only loads with about 3 watt if it gets plugged in. Once we boot, the battery charges with about 9 watt. This persists even if we shut down the system afterwards. So to charge the Pyra with maximum speed, one needs to plug it in, boot and shutdown. I know that this is related to our charger chip somehow. Is there a way to fix improve that behavior? It feels super awkward. If someone does not know that, charging the Pyra will take forever. Also it makes it less practical to use a second Pyra motherboard as a charger dock for a replacement battery.
For me the bigger issue is how it always lowers the charging rate to below idle levels after a couple minutes when the Pyra is powered on and plugged in. (Doesn't seem to affect everybody)
I honestly really don't know much of what I'm doing with anything this low level in linux or hardware related stuff but I looked into charging behavior because my Pyra kept lowering the charging speed while using it when plugged in and that was the main thing that kept me from using it more.

I posted on ED's discord #pyra-dev channel but I didn't realize nobody actually uses it apparently? and aTc can't see it from irc, anyway here's what I found.

In pyra-thermal.sh we're reading the temperature of the battery monitor chip itself (bq27421) not the temp sensor from the battery. The bq27421 can report it's own temperature or you can tell it what temperature the battery is, it doesn't connect to the battery's temp sensor at all. The bq24297 charger chip does connect to the battery's temperature sensor but it only uses it to shut off when it's outside of a configurable safe range. It doesn't report the temp from the battery (the driver for it reports an estimate though).

At the bottom of pyra-mainboard-common.dtsi there's a device configuration for "battery-monitor" that uses a driver called "generic-adc-battery" which looks at palmas-gpadc channels 6, 11, and 1 for voltage, current, and temperature respectively. There's definitely something happening on channels 6 and 1, just watching the raw values at /sys/bus/iio/devices/iio:deviceN/in_temp1_raw and in_voltage6_raw, though in_voltage11_raw is suspiciously low whether I'm charging or not. (I've only seen 0, 1, and 2).
The generic_adc_battery module isn't loaded though, if I sudo modprobe generic_adc_battery though it logs iio_charge:0 in the system log then proceeds to immediately shut down the system.
[this is the driver for the ADC chip TWL6040]

It looks like the only source of actual battery temps is the palmas_gpadc channel 1 but idk if that's actually properly hooked up or how to get a celcius temp from the raw data (or get some driver to do it)

also IDK what the actual channel mappings in the palmas_gpadc driver correspond to though there's a Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt doc file that says
Channels list:
0 battery type
1 battery temp NTC (optional current source)
2 GP
3 temp (with ext. diode, optional current source)
4 GP
5 GP
6 VBAT_SENSE
7 VCC_SENSE
8 Backup Battery voltage
9 external charger (VCHG)
10 VBUS
11 DC-DC current probe (how does this work?)
12 internal die temp
13 internal die temp
14 USB ID pin voltage
15 test network
Which seems like the config in pyra-mainboard-common.dtsi is at least on the right track

Based on the schematics, the battery temp line does go through the cpu board connector and connects to the TWL6037 (palmas chip I think?) [yes it is] so I see no reason not to believe that the data from the palmas-gpadc driver is actual temperature data
schem_battemp.png


I couldn't really figure out at the time how to properly get a good reading from palmas-gpadc, but I did modify my local pyra-thermal.sh to basically never throttle charging based on temperature so that I can actually use my Pyra more. I would be interested in making/testing a proper fix but I don't know when I'll have time to go looking for answers on how to get good data out of that driver myself. If anyone can point me in the right direction though I might be able to cobble it together quicker.

Note I found the data sheets for bq27421 and bq24297, apparently the sheet for the TWL6037 is behind a NDA or just not publicly available to download (from this TI forum answer). So if someone has that it would be helpful.

I also managed to dig up some more updates to the palmas-gpadc driver from the android source where we originally pulled it that I was talking with Risca about, it's probably worth updating it but it didn't seem to help me get good temp data.
the most up to date one I found was here VS the commit that letux got it from which is this one
 
OMAP MHz scaling

According to EvilDragon, currently we only have 3 frequency levels set for the OMAP, 500, 1000 and 1500 MHz. Some while ago, someone testes more frequency levels, 250, 500, 750, 1000, 1250, 1500 MHz. According to EvilDragon, tests had shown that such a small change will result in a much better efficiency and longer battery life.

It would be great if we could clarify the current state on this. Has this made its way to the official OS already? If not, why not?
I'm on bookworm now, fully updated as far as I can tell. cpufreq-info prints the 250, 500, 750, 1000, 1250, 1500 MHz frequency steps as available for me and I can also set the range with cpu-freq-set to any of these. If I recall correctly this also worked on buster before.
Well, at least on my unit.
 
I'm on bookworm now, fully updated as far as I can tell. cpufreq-info prints the 250, 500, 750, 1000, 1250, 1500 MHz frequency steps as available for me and I can also set the range with cpu-freq-set to any of these. If I recall correctly this also worked on buster before.
Well, at least on my unit.

Okay, confirmed. I guess neither ED nor I were aware of this. Great, I will mark this as fixed :)

Out of total ignorance, how do I manually set a frequency? How do I set a maximum frequency?
Can I limit my SoC to let's say 1GHz but still allow the steps below?
 
Last edited:
I posted on ED's discord #pyra-dev channel but I didn't realize nobody actually uses it apparently? and aTc can't see it from irc, anyway here's what I found.

Do not use the pyra-dev channel. I have no idea why that one still exists. The only relevant one is the #pyra channel, since that one hsa the IRC brige applied to it.
 
Update: I updated the list accordingly to all the incoming reports here and on Discord.
 
Don’t use the #pyra channel: I spam there all day long.. ^^

cool that Pyra Software Development is now starting to continue again ..
 
Okay, confirmed. I guess neither ED nor I were aware of this. Great, I will mark this as fixed :)

Out of total ignorance, how do I manually set a frequency? How do I set a maximum frequency?
Can I limit my SoC to let's say 1GHz but still allow the steps below?
Code:
cpufreq-set -r -d 250Mhz -u 1Ghz
"-r" sets it for both cores, but you can also use "-c 0" and "-c 1" to set them individually. (guess it's always both on OMAP5, so no need for that arg) You can check with cpufreq-info.
However, I spoke a bit too soon saying setting them works fine. From memory it worked nicely on buster, but it only briefly sticks on bookworm as if something is constantly resetting it on its own. It noticeably slows down when setting to 250 MHz for example, so it's definitely applying the limits, even if briefly. Governor changes stick though, so powersave for always sticking to the default low end of 250 MHz works in that sense.
I did try blindly killing some processes from tty in hope to stumble upon the one that does it, but this is where I need to stop pretending I know what I'm doing... no idea how you'd go about finding what is doing it.

However, I haven't done the clean reflash yet I mentioned over on Discord, so I wouldn't take anything I say as authoritative of the current OS state.
 
Last edited:
Code:
cpufreq-set -r -d 250Mhz -u 1Ghz
"-r" sets it for both cores, but you can also use "-c 0" and "-c 1" to set them individually. You can check with cpufreq-info.
However, I spoke a bit too soon saying setting them works fine. From memory it worked nicely on buster, but it only briefly sticks on bookworm as if something is constantly resetting it on its own. It noticeably slows down when setting to 250 MHz for example, so it's definitely applying the limits, even if briefly. Governor changes stick though, so powersave for always sticking to the default low end of 250 MHz works in that sense.
I did try blindly killing some processes from tty in hope to stumble upon the one that does it, but this is where I need to stop pretending I know what I'm doing... no idea how you'd go about finding what is doing it.

However, I haven't done the clean reflash yet I mentioned over on Discord, so I wouldn't take anything I say as authoritative of the current OS state.

Okay, good to know. Thanks.

Yeah, do the clean reflash first. I had issues upgrading from 10 -> 11 -> 12.
 
Code:
cpufreq-set -r -d 250Mhz -u 1Ghz
"-r" sets it for both cores, but you can also use "-c 0" and "-c 1" to set them individually. You can check with cpufreq-info.
However, I spoke a bit too soon saying setting them works fine. From memory it worked nicely on buster, but it only briefly sticks on bookworm as if something is constantly resetting it on its own. It noticeably slows down when setting to 250 MHz for example, so it's definitely applying the limits, even if briefly. Governor changes stick though, so powersave for always sticking to the default low end of 250 MHz works in that sense.
I did try blindly killing some processes from tty in hope to stumble upon the one that does it, but this is where I need to stop pretending I know what I'm doing... no idea how you'd go about finding what is doing it.

However, I haven't done the clean reflash yet I mentioned over on Discord, so I wouldn't take anything I say as authoritative of the current OS state.
You're likely to know this better than I do, but the governor in the kernel should be changing the frequency, it's kind of it's job and only purpose in life.
It watches the system load and decides the frequency at every moment. Some governors are stubborn and some adapt to workloads.
If you set the governor to cpufreq_userspace then it will leave the frequency alone, and either you can set it manually or some process in userspace can do it for you (and only then can you kill it).
Maybe check something like
https://docs.redhat.com/en/document...pufreq_governors#intel_p_state_governor_types
or find some better docs... these are a little Intel specific, so a distraction.
Here they list some processes that can change freq if cpufreq_userspace is selected. Maybe disable them if you have some and that's what you want.
 
That's a tough one. Good luck :)

If you want to test LeTux, here is an installer. Maybe you can figure out something. https://projects.goldelico.com/p/gta04-makesd/

I added the link to the installer to the main post.
Hmmm, I can boot to tty1 login, and log in as root (no password), but I don't have the function keys available... One step at a time. Is that how it's failing for you and ED?

I created a thread about LeTux to keep all of the info in one place, and so I don't spam your thread with my ignorant exploration:
 
You're likely to know this better than I do, but the governor in the kernel should be changing the frequency, it's kind of it's job and only purpose in life.
As far as I understand it at least, we're trying to set the min and max values the governor is using as a base. Writing to the files /sys/devices/cpu/cpu0/cpufreq should have a similar effect to using the tool. Kernel docs don't seem to disagree, unless I'm misinterpreting them.
It does work briefly after all, and used to work fine.
 
Update.
Added the following to the charging section

2. Almost no charging beyond 85%
Once we hit 85%, the charging rate drops to an absolute minimum and pretty much never reaches beyond 90%.
This is probably some old implementation to conserve battery health by not having it charged to 100% all the time. However I thing that 85% is a way too low threadshold for the throttle. We are not using a fast charge mechanism anyways.
Not having access to 15% of my battery reduces its capacity for at least an hour of light use.
 
However I thing that 85% is a way too low threadshold for the throttle.
85% is what's commonly used by Android. On my device the last Android update even decreased it to 80%
We are not using a fast charge mechanism anyways.
It has absolutely nothing to do with fast charging. Charging the last 15-20% of a Li-Ion battery always degrade it significantly, no matter how slow or fast you charge it. There's a reason why the last 10% always take forever to charge - it is not healthy for the battery.

Devices that permanently limit the max charge because they absolutely rely on minimizing wear and tear of the battery due to having a much longer planned life time than just 2 years like electric cars simply define the 80% charge as 100% to not confuse the user.
 
Last edited:
85% is what's commonly used by Android. On my device the last Android update even decreased it to 80%

It has absolutely nothing to do with fast charging. Charging the last 15-20% of a Li-Ion battery always degrade it significantly, no matter how slow or fast you charge it. There's a reason why the last 10% always take forever to charge - it is not healthy for the battery.

Devices that permanently limit the max charge because they absolutely rely on minimizing wear and tear of the battery due to having a much longer planned life time than just 2 years like electric cars simply define the 80% charge as 100% to not confuse the user.

As far as I know, we do both. Even 100% is not 100% charged. We should investigate that. From what I remember, our battery is not loaded fully if charged to 100%.

100% charge is not as harmful as some thing as long as the current is not kept forever.
The batteries degrade because if charged fully, small crystals form and physically damage the bettery. However this takes some time and if you discharge every several days to a bit below 50%, then it's not a big deal.

I have never seen an Android device limiting the charge to 85%. They always show me 100%. If that 100% is artificial, fine. I would prefer that.

The manufacturer of the Pyra betteries is the same as the one who made the Pandora batteries. The batteries were already designed in a way to not be as energy dense as possible like most laptop batteries are.
So even fully charged the battery is in a ore healthy state than those laptop batteries that will die within 2 years because they have a higher maximum current than what is healty for them.
 
I have never seen an Android device limiting the charge to 85%. They always show me 100%.
It's a fairly young configuration option that needs to be enabled first, my device only got it with an update and apparently it's not available for every hardware - I guess the charge controller needs to support this feature. My father's phone does not have this option despite having an up-to-date Android 14 as well.

Maybe there is a bit of a misconfiguration, e.g. a mismatch between the used and expected type of Lithium battery. Even among Li-Ion batteries there are several different types with a small difference in voltage. If this was just a charge limit it shouldn't get past 85% at all instead of slowly going towards 90%.
 
Back
Top