Maintained list of all remaining issues. Call to help.

[TeDaDeS]

If anyone doesn't have a Pyra and it would help if I test some stuff for them on mine, I can always try.

 

[Askarus]

It probably makes sense to check who has ordered a Pyra and is capable and willing to help.
If I had to decide, I'd send out those Pyras as soon as possible.
We should not let this stupid order number system get in our way.
It's not like this would affect 50 units, probably 5 at max.

So if only 1 or 2 issues will get fixed way sooner than they would have been, that would benefit everyone.
Those people should be from the community and it should be made public who gets a fast lane developer ticket.
That would at least impose some psychological barrier to cheaters.
Also I am not talking about free Pyras or new orders here, just people who are already in the queue and have a high potential of being beneficial to everyone.

 

[TrashyMG]

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.

Far as I know this commands with the OMAP5432 it sets both cores implicitly with the default commands

 

[elvissteinjr]

Far as I know this commands with the OMAP5432 it sets both cores implicitly with the default commands

This might actually be true. Looks to be for the brief moment I can just at least.
Was a bit too glued to the man page I was reading there I guess, oops.

 

[pyrat]

Send me my pyra and I'll get standby working.

Standby is working. Your pyra and mine are on standby. Have been forever.
I they ever get delivered they'll be on and off, but meanwhile, they're on standby, just as we stand by waiting for them.
It's all about managing expectations...

 

[netcat]

One thing that would speed up development would be an easy way for us all to run pyra os in a vm. It would be extremely cool if you then game on your desktop via pyra but any kicking of the tires would be good. Currently I'm helpless, I can just follow these threads, but never poke around anything myself. I want to be parachuted into the rainforest but instead I'm taken to the zoo for the afternoon.

But I def think we should honor agreements on pyra delivery and not allow devs to jump the queue. FIFO.

 

[Askarus]

But I def think we should honor agreements on pyra delivery and not allow devs to jump the queue.

Why? This whole order number thing slows down everything. We should produce them in batches.
Like 50 EU black and then send out to the next 50 EU black orders.
Going customer by customer is way to inefficient.

Also what benefit does anyone have if devs get stalled out? None IMO.
With that many years of delay and issues we faced, all delivery agreements are obsolete anyways.
The focus should be to deliver and develop as quickly and efficiently as possible.

 

[ElPoco]

One thing that would speed up development would be an easy way for us all to run pyra os in a vm.

In the VM you won't have the hardware-related issues which seem to be the main problems the Pyra has.

Another option would be to have remotely accessible Pyras

 

[netcat]

Why? This whole order number thing slows down everything. We should produce them in batches.
Like 50 EU black and then send out to the next 50 EU black orders.
Going customer by customer is way to inefficient.

Also what benefit does anyone have if devs get stalled out? None IMO.
With that many years of delay and issues we faced, all delivery agreements are obsolete anyways.
The focus should be to deliver and develop as quickly and efficiently as possible.

Not honoring agreements is dishonest.

Post automatically merged: Aug 13, 2024

In the VM you won't have the hardware-related issues which seem to be the main problems the Pyra has.

Another option would be to have remotely accessible Pyras

I don't think it's that hard to do - if you've done it before.
But it seems near consensus that it's not worth the effort.

 

[pyrat]

Not honoring agreements is dishonest

You're right. My doubt is whether not honoring some agreements would help honor other agreements earlier.
But in the end I'd say the agreement was more to provide the hardware than to have all the software ironed out,
so skipping the queue to improve the software would benefit those who already have pyras and somewhat inconvenience those who still don't have.
Those who, according to agreements, already enjoy a Pyra would enjoy it more, they would enjoy a better functioning Pyra.
Those who are waiting for a Pyra would be left waiting longer for a better functioning Pyra (just those affected by the queue skip).

But I think the trouble is not so much so. The trouble is that you never can tell who can contribute more.
There are so many ways to contribute. And contributions are not a business, and are not a binding compromise,
so even if you managed to select those preorderers with the right know-how, they could still be busy, or
unable to allocate the time, or just have bad luck when looking for solutions, or be run over by a bus...
It's never a sure thing.

I don't think it's that hard to do - if you've done it before.
But it seems near consensus that it's not worth the effort.

Not sure how hard, but my gut feeling is a VM is not worth the effort.
Edit: I meant a VM imitating a Pyra as test environment. A VM or container on debian package or something with a development environment might be useful.
Some form of remote accessible Pyra is borderline worth the effort.

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).

I tried to ask in the other thread where are your hands or how to take you by the hand.
I'm not sure if trying to help here I'll be able to help or I'll just waste other people's time.

I don't know enough about the hardware. Not sure if getting some parameters wrong in the DRAM timings could damage the hardware permanently somehow.
If you're desesperate enough, because the hardware you might damage is going to the dust bin anyway, then I guess it should be OK.
If there's some suspicion that the hardware might be permanently damaged by the test, the problem is that then you may not want to test twice on the same board
(because the second test might be the right solution, but not working because the first test damaged the hardware).
And that may be wasteful of boards.
Edit: But worse than waste, you are not sure all your defective boards are equally defective,
or need the same RAM timings, so not trying everything on the same board is a problem too.
Edit2: A compromise could be: make a list beforehand of the test you want to do. Do them all on one board, then on the next board do a different permutation of the same tests.
There's of course a combinatory explosion to take into account, but it's better than nothing, I guess.
The change of order does not need to be random if you have some intuition of which tests are more risky to damage hardware. You could start by the safest.

As far as I understand, the current situation is that to change DRAM timings one needs to:
0 install the build tooling and git. That might be easier on a similar system, like a Pyra, than on a computer where you need to cross compile.
1 download the U-boot source code for the Pyra. Configure it for building the Pyra boot loader and not for some other machine.
2 edit(*) the source code for MLO (=U-boot SPL = U-Boot 1st stage), Commit or document your changes somehow.
3 recompile the MLO. That may be slower on a Pyra or similar system than in a more powerful computer where you cross compile.
4 install it to a Pyra
5 boot to test. Document your tests.
6 since it didn't work, go back to 2.

(*) The first time you try step 2 you don't edit anything, just build a pristine MLO to test that it works on a workign board, so that you know
you're compiling things right.

How many of those steps do you already know how to do and how many could someone help you do ?
Can you use a Debian system to do it?
Which architecture is your debian system on ?


The alternative would be to change MLO so that it loads the setting from some place, and then write a program that is able to write the settings in that place.
The program that writes the settings in that place could be made more or less user friendly relatively easy.
But changing MLO to load the settings from somewhere is difficult, because MLO does not have all the computer ready to work when loading things.
Remember that at that time, it can't even use RAM, because it's not yet initialized, So let alone OS functionality or most libraries. MLO binary code should also be space constrained somehow. You can't write all the code you want because it won't fit in SRAM, cache as RAM or whatever it is. In U-Boot some TPL or SPL stages are able to load the next stage (so then they should be just as able to load RAM settings) and some are not able and have to request it from bootrom or some external system.
So it's not ordinary C programming, although something should be doable.


A third alternative would be some way to edit an MLO binary to just change some constant where the RAM settings are, without needing to recompile.
Could be so easy as: Put some UUID in a constant in the code. Put the RAM settings constant next, put some UUID right after it. Persuade the compiler not to suppress those useless UUIDs that nothing is using.
Use a binary editor to change the constant between the 2 UUIDs. Install the edited binary MLO and test.
But I find that dirty.

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.

I don't know, just linking to the (hopefully) relevant thread.

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/

Johnic boom is working on that in another thread
If I understood he's installing available binaries. Is that all your problem or what you need is to
be able to build those binaries from source ?

 

[TeDaDeS]

You're right. My doubt is whether not honoring some agreements would help honor other agreements earlier.
But in the end I'd say the agreement was more to provide the hardware than to have all the software ironed out,
so skipping the queue to improve the software would benefit those who already have pyras and somewhat inconvenience those who still don't have.
Those who, according to agreements, already enjoy a Pyra would enjoy it more, they would enjoy a better functioning Pyra.
Those who are waiting for a Pyra would be left waiting longer for a better functioning Pyra (just those affected by the queue skip).

I think it's probably more hassle then it's worth.
You could claim a single Pyra, label it as developer, and if there is a developer that for sure can fix some issue send the Pyra for a certain duration. Ship it to the next developer for the next fix.
Setting-up a remote Pyra could work but sounds like a lot of effort to do and do correctly. You would need secure remote access, probably some camera and microphone, a way to remotely control power (reset, power on/off, etc) and some way to write data.
You could add an SD-card with wifi read/write capabilities, which would work as long as the SD-card is powered-on (something like the Toshiba FlashAir might work).
But it sounds like a setup like this is prone to failure and would require a person to be near it at least once a day to reset everything to a working state. Next to the possible privacy and security risks of having a remote setup and a camera pointing at it.

 

[netcat]

effort = work / know-how

so...... i have no clue how much effort creating a pyra virtual device would be.

but yeah, the big issues are related to hardware. so nevermind.

 

[Wally]

I've taken the liberty to get the current OS building via CI/CD https://github.com/pyraos for the goodies.

I'll add Letux as a job on this site so that everyone can try it out if we need to. Could add some packages to it as we go?

 

[pyrat]

I've taken the liberty to get the current OS building via CI/CD https://github.com/pyraos for the goodies.

That's the libertinism I like !
Thank you.

I'll add Letux as a job on this site so that everyone can try it out if we need to. Could add some packages to it as we go?

The keyboard stuff maybe ?
I tend to prefer test systems relatively minimal. But I don't have a Pyra to test, so don't mind me.

 

[elvissteinjr]

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.

I figured out how to make the network tray icon not be blank on Bookworm at least, but I'm not sure why this is. It's as simple as setting the panel height to 32 so the 32x32 PNG icon gets used.
What I don't get is why it stays blank when it doesn't match one of the PNG icons. The SVG variant is present in the filesystem at least and they render in the file browser and stuff.
It's not only the network icon that disappears at different panel height though, but the others are visible at the default one.

librsvg2-common (supposedly responsible for SVG icons) is installed and the rsvg-convert tool does convert the icons fine, so I don't believe that lib is broken.
I'm kind of fine with the panel at that height, even if it's on the smaller side, so it's... ok? Have not checked other desktop environments so it might be a Mate thing, iunno.

 

[Askarus]

I figured out how to make the network tray icon not be blank on Bookworm at least, but I'm not sure why this is. It's as simple as setting the panel height to 32 so the 32x32 PNG icon gets used.

Thanks. I knew that I did something to fix the icons. That was it.

 

[Wally]

Small update on the PyraOS Repo:

I've modified the make image script to isolate things that don't work between cross builds such as security repos being present in stable but not testing and sid. There's still a little bit to do and would like to keep the script building outside of CI/CD, which can be done by OS=bookworm ./makeimg.sh blah blah pyra-meta-mate

Starting to compile 3 separate builds:
stable - Current stable distribution (Bookworm)
testing - Current testing distribution (Trixie)
sid - the scary one. (The angry kid)

Each of these will build automatically when some issues are resolved:

Testing currently has a few issues relating to GCC14 and dependencies in the Pyra Repo which should be addressed soon, I suspect that these will go away with sid.

When all 3 are building i'll get the CI/CD actions to post a release on Github, maybe have it do these weekly as it takes 18 minutes to build at the moment!

The idea behind this is when trixie moves to stable and forky moves to testing we can swap out bookworm for trixie as we know it's stable and it'll post a release automatically and we can continue the process of change for Debian.

 

[Bosbeetle]

Great stuff wally (just pretending here that I know what it all means, but it smells of progress)

(I can guess what it means though, I think it means I should at some point in the future get an linux machine again, since my previous one kind of died i.e. I cant charge the battery anymore / or get power to it due to a defective power socket)

 

[edgex004]

On the topic of LTE connection quality, I would recommend attempting to lock the modem to the frequency you believe is strongest in your area. Do you know if you have a script/interface for this already?

If not, I can dig through old posts about sending AT commands to the modem and attempt to write something that lets you select a band to lock to.

 

[Askarus]

On the topic of LTE connection quality, I would recommend attempting to lock the modem to the frequency you believe is strongest in your area. Do you know if you have a script/interface for this already?

If not, I can dig through old posts about sending AT commands to the modem and attempt to write something that lets you select a band to lock to.

I am not aware of any command like that. So you are welcomed to dig through some posts and send me an AT command