asimov-solensan
Very Active Member
- Joined
- Jan 8, 2010
- Messages
- 741
Thanks for the news.
The Rise of Pyra - A story about the past 6 months
- Thread starter Askarus
- Start date
squaresosig
Member
- Joined
- Jul 15, 2012
- Messages
- 53
Great work! I might yet end up getting a pyra!
It's very exciting to see that progress is still happening. I'm wondering how well the software side of things is going now o:
It's very exciting to see that progress is still happening. I'm wondering how well the software side of things is going now o:
Not at all.
That is the most frustrating part of it.
No one cared about Debian 12 and tries to fix the remaining bugs.
I had some fixes for Bookworm supplied but it's harder to contribute to this project than to submit a PR in big tech
It seems like a non-optimal fix is worse than a broken system.
So I just don't care any longer.
There is both a public TRM (Technical Reference Manual) and a more complete one under NDA.
Luckily, the public one has surprisingly detailed documentation about the DDR controller (EMIF).
IIRC the NDA one only has additional documentation about the video encoder/decoder or something like that, nothing vital.
But unfortunately, TI has decided to make public documentation about their discontinued products needlessly difficult to find.
It's still on their website, but it is hidden unless you are logged in with your TI account. You should then be able to access the documents. (URL for the relevant product on TI's website should go here but it seems I can't have a URL in my first post)
Thanks a lot for the explanation. Hopefully you get to be allowed to post links soon.
Click on the ↓ orange arrow below to go to the original post containing the URL to the OMAP5432 documents, remember to log in on TI's website first, otherwise you'll be redirected.
elw3
ƐʍlƎ
- Joined
- Aug 10, 2010
- Messages
- 1,859
Remainder that your channel is actually linked in 4chans handheld spreadcheat making you the most known pyra reviewer
@pyrat I forgot to answer on the OMAP NDA topic.
The problem is not som NDA issue.
The real problem is that the OMAP we use was abandoned by TI and has some hardware bugs.
The 4GB RAM issue is one of them, as well as the RAM timing issue.
The OMAP is supposed to set the RAM timings automatically but that does not work properly.
The problem is not som NDA issue.
The real problem is that the OMAP we use was abandoned by TI and has some hardware bugs.
The 4GB RAM issue is one of them, as well as the RAM timing issue.
The OMAP is supposed to set the RAM timings automatically but that does not work properly.
The only reason I’m the most known Pyra Reviewer is that I think some time I’m the only one „there can only be one!! „
im still believe under the other Pyra Owners, there where lots who where much better for this part.. I’m Unprofessional, use an almost 7 year old IPhone as Camera, don’t follow any script, steal some times famous YouTube Slogans „let me show you its features“..
I think I’m introverted ..
im still believe under the other Pyra Owners, there where lots who where much better for this part.. I’m Unprofessional, use an almost 7 year old IPhone as Camera, don’t follow any script, steal some times famous YouTube Slogans „let me show you its features“..
I think I’m introverted ..
But then what is the current workflow and what needs ED to be improved ?
Does ED just change some hex value in a source file, compile and flash a card to test ?
Or can he get the compiled binary it loaded from serial or net ?
Should MLO be changed to read the timings from some file, sector or from serial or net so that it doesn't have to compile each time ?
Or there are already some values, say half a dozen, that work in different boards and it just needs to load diffferent MLOs, run a memtest automatically, and set the one that works?
Or is the problem just some editor to produce the hex value given the different fields and possible values ?
Or something else ?
He would like to do so but needs someone who sets up a build chain for him, so that he can easily test values.
Right now we just have one setting that works with a majority of PCBs. If one fails it is sorted out.
So the issue is that we can not even tweak the values because we get no help with at least the setup that.
We need something that quickly and easily lets us change values, compile/build, test.
If anyone could give us a hand here or some instructions at least, that might help.
I've built U-Boot some times, but I don't have OMAP hardware to test if I'm doing it right.
And I'm kind of weird, so what works for me might not work for others. For example, I don't have x86 computers to cross compile from.
What would be useful? Some docker file for a build environment so that the repository at the link @pimaster sent compiles and produces an MLO binary ? Some ISO image to do it on a Pyra itself ?
A shell script ? a minimal list of debian dependencies to try ?
Or is all that already covered and it's the U-boot code base that needs to be ported to more modern tooling, and rebased to modern U-Boot ?
(I'm not offering help, I'm very amateur at these things, I'm trying to help collect requirements, which is a first step in any case)
And I'm kind of weird, so what works for me might not work for others. For example, I don't have x86 computers to cross compile from.
What would be useful? Some docker file for a build environment so that the repository at the link @pimaster sent compiles and produces an MLO binary ? Some ISO image to do it on a Pyra itself ?
A shell script ? a minimal list of debian dependencies to try ?
Or is all that already covered and it's the U-boot code base that needs to be ported to more modern tooling, and rebased to modern U-Boot ?
(I'm not offering help, I'm very amateur at these things, I'm trying to help collect requirements, which is a first step in any case)
But if there are different Ram Timings needed, how to take care that an customers Pyra would work after he make an apt update / upgrade? Or an Reflash`?
Or are the Ram Timings somewhere on the Nand where an Reflash cant delete them?
Or are the Ram Timings somewhere on the Nand where an Reflash cant delete them?
Good questions. But maybe we cross that bridge when we get to it. I don't know. But I suspect that they are on a fixed sector on an SD card or EMMC, or in some EEPROM or something.
In principle, from what I understand the RAM timings are now fixed in a constant in MLO.
I'm not sure if the upgrades one can get with an apt upgrade can change some package that installs a new MLO. Normally I'd say no, but it's not impossible or even necessarily unwanted. Might be.
But if the boards work well with some timings then something should be able to be done to fix things. Either fusing some code in the SOC that tells MLO which timings to use, tell MLO to load timings from somewhere,
change the MLO install process so it choses the right MLO or changes some value inside it... I don't know how, but that's something to keep in mind more than showstopper, I'd say.
When the CPU Update Board was still a Topic (which might not come true due to funds), i was also wondering how to deal whit different CPU Boards as it would need different OSes, and also different DPB Files maybe? As an Omap5 Pyra would not work whit the Stuff for an Hypotetical Ryzon7 Pyra ..
jedi23
Very Active Member
- Joined
- Aug 11, 2020
- Messages
- 230
Can anyone answer this? Debian 10 stays rock solid stable, so apt upgrades won't touch the timings for sure.
And what exactly makes Debian 11 and 12 unstable? I guess these images use the same well-proven ram settings that are shipped with the majority of Pyras...
It is not an issue that makes Debian 11 or 12 unstable.
aTc has pushed an update with a fix that makes Debian 12 stable, too.
That however is totally unrelated.
If the RAM timings are off, the PCB won't work, not matter what OS we use. It just won't boot.
In worst case, it will boot but crash once the SoC gets warmer after some time during the flashing process.
We still flash Debian 10 stable and that is affected by the RAM timing issue like Debian 12 would be.
