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:
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?
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
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
, 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:
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.
@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.
pyra-handheld.com
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.
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:
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.
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 setAs 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?
- 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
- 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.
- 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
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-themeFurther, 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 pyraI 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-upgradeAudio 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)
@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.
20*C Cooler, and now with water resistance!
Wow, just wow :) Thanks a lot for your awesome work. I will probably contact you via PM as I'd like to find out if there's a feasible way to include the better heating method into the next units we assemble. Having additional speed steps and other optimizations to lower the battery usage of the...
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.
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_SKCIPHERI have not tested this by myself and can neither deny nor confirm this issue.
Last edited:
