Maintained list of all remaining issues. Call to help.

[Wally]

Yeah, something where ED and I and others can put in patches they made.
We have some great stuff hidden in some threads here that aTc does not want in his OS but ED and I think are well worth it and shuold go in some public test build

I think we should have a separate apt repo where these fixes are added and people can download them that way. Which means it's easily undone.

Of course it's easy to do a test image with all the bells and whistles too.

 

[Wally]

Okay finally got it working.. Using a MacBook Air running Debian at the moment to pull packages from, it seems to build testing and sid okay (I butchered the folders a bit and will need some reorganising so stable does not work (ironic)

https://github.com/PyraOS/OS_Build/actions/runs/10488734960 When this run is completed testing (Trixie) and sid images can be downloaded. (All are broken at the moment though)

Next Steps:
* Document the hell out of the build process because the documentation online is pretty poor. (Specifically around certificates)
* Tidy up the repo and fix the modified debs properly (with versioning and changelogs) so all three OS's build.
* Setup docker containers for all three builds
* Add the community testing patches to a github repo and build a github.io page with a repo to pull from.
* Move rest of the debs from ED's repo to the github.io page, at this point ED can stop hosting it.

Of course i'd love help from the community if able to speed some things up a bit. I am no expert on apt repos but now at least I understand how the certificates work..

 

[Wally]

It looks like testing and sid don't work at the moment, might need some other things updated to get them to work properly (MLO and Uboot perhaps)

 

[Wally]

discord is a bunch of heathens. i didn't say it there but they are wrong. we already discussed appropriateness and #pyra is for pyra community talk, including knives. actually they were polluting the community channel with dev talk. but i do want a blade as a peripheral in my pyra. my inspiration is this laptop gun:

View attachment 39330

The knife discussions are .. well interesting. Most of us would agree that Mat has been talking about his knive collection for a good while now and yeah we need something else to talk about (Which is why the PyraOS stuff is happening in the main channel..)

 

[matzesu]

But i was not the one who did post an Knive whit a quite "difficult Background" ..

At least this whole stuff brought me back to Pyra as Pocket EDC

If there is an Image, i know how to Flash Stuff ..

 

[Null]

and yeah we need something else to talk about

Keyboard layouts it is.

 

[edgex004]

I even made a gui for this and we testet stuff on irc with little luck.
Basically all sensible AT commands have been tried already.
To my unterstanding this is not a frequency problem but an antenna thing, you may search for someting like gain or input switch in the docs, might have missed it, might be my docs where incomplete.
But the thing is the self test command returns that it appears to work just fine, i even can connect to every network, that is , if i am next to the cell tower only tho.

Do you recall if there were commands to check the current band that has been connected to? I’ve never used this module, but used 2 others that both offered a method to query the currently connected band as well as restrict the module to a specific band. This was helpful when i was working in very remote areas with poor connectivity (perhaps similar in effect to an antenna issue?).

One module would keep connecting to a band that had poor support from the carrier (i think it was like a legacy band that they were moving away from), because that legacy band had the best signal. Restricting to a band that had slightly weaker signal but had better support from the carrier led to a touchier connection, but much faster speeds. The signal strength difference was minor (maybe SINR of 8dB for legacy and 7dB for the faster band)

The other module I worked with had a somewhat similar issue where band selection was helpful, but I don’t remember the behavior in as much detail.

You’ve likely done more than I’ll be able to do already, but I’ll take a look at the docs just in case. I should be able to try out some external antennas that I have leftover from my other project too.

EDIT: from the AT command set I found, the <rba> parameter allows you to restrict to specific band(s). A script can be written to cycle through the various options, measure signal strength, and run a speed test (assuming the connected band is even usable). However, the bands you are allowed to select changes based on the carrier you are currently configured for. So ideally the script would first query whatever bands are available for your currently selected carrier and then loop through them. Internally, the modem does this loop for you and selects a band, but it would be good to have insight into what manual selection results in.

EDIT2: Another interesting tidbit, this comment suggests PLS8 supports a special antenna with hardware for measuring signal strength. Might be interesting to check if the external antennas that have been tested support this. The link in the comment is broken, so I need to find details on this in the docs.

 

[pyrat]

Well, this is all I got for now.
I'll attach a Dockerfile (edit: please remove the .txt extension, it didn't allow me to upload with the real name) if I can, which seems to be able to cross-compile an MLO, but I can't test the resulting MLO.
The problem I've had is that gcc 12 didn't want to compile the old U-Boot, and I have to change KBUILD_CFLAGS to add -msoft-float to have it compile.
I don't think it's very likely to do harm, but it seems less than optimal.
It's probably better to try this patch, but I haven't. I don't know if we want it, or want to compile as close to possible to the known good source.
Edit: or maybe before starting to cherry pick patches from later on U-Boot history, we may prefer to rebase somehow to a newer U-Boot, but that should be done by someone who can test it.
Edit: version2: just corrected some comments and moved some exported variables in a script, nothing of much consequence.
Edit: version3. Corrected more comments. Left the typo bookworn/bookworm, because I'm too lazy to rebuild the images and retest and after all, the Pyra is something you can "wear" like a book (ok, carry), isn't it ?

 

[pyrat]

Oops ! I just realized the MLO in https://github.com/PyraOS/OS_Build/tree/main/makeimg_data/uboot-versions are around 64 KB, and the ones gcc-12 generated with -msoft-loat -march=armv7-a are 117KB. I'm afraid this won't work.
With earlier gcc U-boot was compiled without -msoft-float and with -march=armv5, but newer gcc does not accept -march=armv5 anymore.

But with the patch I mentioned in my previous post (or the part that applies, I disregarded changes to comments), it generates a 65 KB (65788 bytes) MLO. Would it be small enough ? The biggest I've seen in the PyraOS repo is 64.2 KB.
Mmm... may be a question of KiB vs KB ?
I see this MLO in uboot-2g is 65780 bytes ? Does it work ? would 8 bytes more matter ?

 

[pimaster]

I see this MLO in uboot-2g is 65780 bytes ? Does it work ? would 8 bytes more matter ?

28.3.2.2 RAM Memory Map
Downloaded image
This space is used by the public ROM code to store a downloaded booting image. It can be up to
120KiB.

28.3.7.6.4 Read Sector Procedure
"For this reason, the size of a booting image must not exceed 128 KiB."

pyra-install-uboot.sh · master · aTc / pyra-install · GitLab

PyraOS install script

dev.pyra-handheld.com

dd if="$UBOOT/MLO" of=${DISK} count=1 seek=1 bs=128k
dd if="$UBOOT/u-boot.img" of=${DISK} count=2 seek=1 bs=384k

Few extra bytes shouldn't hurt. But I haven't tested. Hope the documentation referencing is helpful.

 

[Askarus]

I am back from the Gamescom and updated the first post.

There are 2 patches I'd love to get more attention and at least to be added in our testing OS.

1. Volume wheel tweaks by @elw3: https://pyra-handheld.com/boards/threads/improve-volume-wheel-daemon-bounty.99430/post-1692618
2. Tweaked voltage and CPU scaling, as well as unlocked frequencies by @Asaggynoodle https://pyra-handheld.com/boards/th...-now-with-water-resistance.99686/post-1706483

Further, I added a new issue:

Spoiler

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.

My next steps will be to
1. Finalize my keycode fix and my pyrainput update, so that Wally can include it into our testing OS
2. Make a boot SD for LeTux and check LTE
3. Dig up the brightness values for the display and keyboard of my old device tree, so we can get that in our testing OS
4. I'll be back and active again here and on the Discord and will make sure that nothing gets lost and we keep the train rolling
(5. Suffer hard and continue building Pyras)

 

[asimov-solensan]

Also, the display could go way darker than it currently can.

Really? Actually I almost use Pyra only to watch series while in bed. It may be a minor thing but I always found Pandora screen more convenient because of this. I'm happy to hear this can be solved via software.

 

[Askarus]

Really? Actually I almost use Pyra only to watch series while in bed. It may be a minor thing but I always found Pandora screen more convenient because of this. I'm happy to hear this can be solved via software.

It can go WAY darker.

 

[Askarus]

Here is a quick update:

1. I made some changes to the device tree so that lower display brightness levels are now available. The new value range is like this
   

   brightness-levels = <0 1 2 3 5 7 10 15 20 27 35 45 60 77 100>;

   Before, the lowest value we could get was "5", now we can enjoy our dark screen at night
2. Same for the keyboard backlight. the new values are
   

   brightness-levels = <0 1 20 100>;

   There is no need for fine grained brightness controls. "1" is bright enough for pretty much any situation and anything above will consume a lot of power and generates heat.
3. That all means that I can build the device tree manually and Wally aims to figure out how to build it automated in his GitHub. If you do not like the values, tweaking them is super easy and when I feel like it, I'll make a post here with the instructions.
4. I still plan to expose all brightness values between 0 and 100 to the OS and handle the steps via a script in the userspace. Now that I got the device tree dev environment set up, a big part is done already. AFAIR, our pyrainput daemon is already set up in a way to trigger a script when the brightkey or any combination is pressed. So it more depebds on my mood than on figuring out complicated stuff.
5. If you follow the LeTux thread, you already know that we can boot into LeTux finally but still are having display issues. Since we want to test the LTE module, we do not rely on a desktop but can fal back to basic AT commands. Personally I would have preferred a GUI similar to our OS but that might be quite a huge effort to achieve in LeTux. Huge thanks to johnicboom for his help.
6. At the moment I am giving the Zen Browser a shot. I still have multiple Pyras here and as a result it does not hurt my productivity if I boot one up and see if the Zen browser compiles. It is a popular FireFoc fork that claims to be more performance friendly. All the build is set up ad a couple of npm commands. I do not have high hopes for it to work, but who knows. Maybe we are lucky
7. I downloaded the device tree file with the tweaked OMAP frequencies. Once I am done posting this, I will boot up a test SD card and see if those files actuallt do any good. Unfortunately it seems like the author left us and only provided a compiled dtb file. So I do not know of how much value that will be to us.

 

[pyrat]

You can get a dts from a dtb. It will always be worse than the original source, but it might help a little sometimes. Sorry if everybody knew it.

 

[Askarus]

You can get a dts from a dtb. It will always be worse than the original source, but it might help a little sometimes. Sorry if everybody knew it.

Thanks a lot
I'm fine with a worse file as long as I can somehow read the values from it and transfer them over to our proper dtsi file.

At least for me, my Pyra freezes if I use 1.9 GHz for too long. We probably need to tweak the values a little more.
I have sent a PM to the author, maybe he is still around. If not, I'll see if I can reverse engineer the values.

The Zen browser, too game me issues.
I'll wait if someone responds in Discord, if not, I'll open a thread here and ask on the official GitHub.
It would be cool if we had a FireFox based browser alternative that claims to be more privacy and performance focused.

 

[pimaster]

Yay, I was finally able to update the wiki - https://pyra-handheld.com/wiki/index.php?title=U-Boot

 

[Askarus]

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.

 

[Askarus]

I updated the first post.
Many of the issues are fixed now
A description regarding the fix was added.

 

[netcat]

if the hdmi issue turns out to be hardware related will there be a pyra recall?