Maintained list of all remaining issues. Call to help.
- Thread starter Askarus
- Start date
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.
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.
- Joined
- Jan 18, 2010
- Messages
- 11,489
Far as I know this commands with the OMAP5432 it sets both cores implicitly with the default commands
elvissteinjr
Very Active Member
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.
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...
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.
But I def think we should honor agreements on pyra delivery and not allow devs to jump the queue. FIFO.
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
Hardcore Member
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
Not honoring agreements is dishonest.
Post automatically merged:
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.
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.
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.
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.
I don't know, just linking to the (hopefully) relevant thread.
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 ?
Last edited:
TeDaDeS
Forum Addict!
- Joined
- Jan 15, 2004
- Messages
- 3,052
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.
Amazon product ASIN B072SN7QK6
Wally
I am a banana!
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?
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?
That's the libertinism I like !
Thank you.
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
Very Active Member
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.
Thanks. I knew that I did something to fix the icons. That was it.
Wally
I am a banana!
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.
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
Terminally lost
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)
(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)
Last edited:
edgex004
Advanced Member
- Joined
- Jan 5, 2008
- Messages
- 1,222
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.
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
Similar threads
