Discussion in 'Pyra News' started by EvilDragon, Dec 25, 2017.
Just for you, that Polish region's Pyra successor will get called the Spud.
Well this must be some kind of a record; for a news thread to go this off-topic this quickly. Probably something to do with most people having time off work and many of us are probably still drunk somehow, even if you haven't had a drop since finishing off the champers on boxing day lunchtime.
Sorry for an ignant post but where are we at with the replacement for the .pnd system? (dbp) Is it finalized?
I've made both .pnd and .deb packages and i really like the pnds. On the other hand, any work we do to make .deb packages could get used for debian-arm. Excepting stuff that is optimized to pyra hardware of coruse.
Seriously you like making PNDs ? I HATE pxml to death. We have tools to make it bearable, sure. Yet the file format sucks b....
The dbp system is working nicely. dependencies are working like a breath. The file format is .desktop which is very close to .ini files, hence very simple to make and maintain. If you liked PNDs you'll love dbp for sure.
I doubt we'll make lot's of debs here. The debian community is doing awesome in the arm world. There's very few left to package in that format.
If where talking weird translations then Prosit is weird in Swedish, it's what we say after someone sneezes lol
In Germany it's what we say, when we try to shatter glasses, and get drunk, if we don't succeed.
Oi! watch it mate...lol
The dbp format hasn't been officially released yet, unless I've not been looking, but a change now would probably call for all of those packages to need to be republished. I'd take the fact that it's in use means it's pretty much de-facto finalised.
Well, the thing is : it has been released so long ago that many forgot about it.
A possible PND-system replacement
and since that's part of the default pyra OS, I'ld indeed say that it's official
similar in swedish region skåne (south part) here we call potato för Pära
Does anyone else feel that the 1.35V rail doesn't seem well regulated at the point of load (looks like it drops down to ~1.25V not too far from where it is generated)? I haven't been following this project too closely, so I am admittedly not very familiar with the design--what else is powered by the 1.35V? What is generating the 1.35V (a buck in the TWL6030 or some other PMIC?)? Is there no remote sense option with whatever regulator is generating the 1.35V? I'm curious what those voltages would look like when you factor in variations (within spec) of the buck itself (assuming this PCB simulation assumed an ideal rail).
(I realize this project is very far along and there isn't time for major redesigns--something just caught my eye and I am here for discussion, not to suggest a redeisgn)
The PALMAS (which is the power chip for the OMAP) constantly talks to the OMAP and regulates the power.
And no worries, the voltage IS allowed to drop at some areas. For the simulation, official OMAP5 IBIS files have been used. IBIS files (see information here: http://www.ti.com/lit/an/snla046/snla046.pdf) are files that are being used to make accurate simulations for the specific processor used.
So we could in fact see in the simulation, that all needed power supplies and connections are now within the accepted range in the datasheet of the processor - so everything is good here
Thanks for the reply! I guess my question stems from the variability of the 1.35V itself and what generates it. It must be an LDO or SMPS with finite spec windows. If this PALMAS chip is responsible for ensuring proper voltage regulation, is there a particular reason it presumably failed to regulate the voltage with the old PCB layout with the large IR drops (this is where the remote sensing question came from as I am curious where exactly is the voltage regulated to 1.35V?)? Is there a part # for this PALMAS chip?
It's the TWL6040: http://www.ti.com/product/twl6040
The PALMAS didn't have any issues powering the OMAP5 on any CPU board version.
We were out of the suggested specs, but it was working.
The problem with the 4GB RAM was the power supply for the RAM.
Also, if traces are too thin, then you simply can't squeeze enough power through them, regardless how much you crank up the power source
Are you sure it's not the TWL6030 or some other product? The TWL6040 appears to be for audio.
But back to the 4GB RAM--isn't the issue that your 1.35V rail dropped out of spec by the time it reached your RAM, but was still regulated to 1.35V at the source? Even if you try to minimize IR drops, fundamentally isn't there still a discrepancy between where this rail is regulated and what voltage is at the RAM? You mentioned the PALMAS chip is responsible for regulation--does it monitor the 1.35V at the source or does it monitor the voltage at the RAM?
I'm curious about the margining--it seems the lower spec limit for the RAM is 1.215V based on the graphic, and we're getting down to 1.245V in simulation with the improved layout? So, that's 2.4% (30mV) of margin--is that enough margin for component/manufacturing variability and any possible discrepancies between simulation & real-world? Does the 2.4% budget in transient response (is this a DC simulation? I'm curious as to how low those 1.245V nodes go in a transient response)? Are any of these traces accessible (perhaps with minor hacking if need be?) with a multimeter for correlation to simulation (I know the memory is a FBGA package, so probing the individual nodes is unrealistic, but I was wondering if there were some other point on the 1.35V rail that could be probed for correlation)?
Lastly (sorry for all the questions!), what determined the 1.35V +/- 10% spec in the graphic? My impression is that the Pyra uses DDR3L, which I thought has a lower spec of 1.283V?
Happy New Pyra Year !!!
Yes! The year of the Pyra has arrived! Probably.
Happy 0x7E2! May the Pyra be with us!
google "bag transparent bike map" I have one. It is open on one side though, for a paper map. But for a few drops (not a downpour) it works.
Wait... I thought it was
$PyraYear= new PyraYear();
That seems inefficient.
$PyraYear= new PyraYear();
Separate names with a comma.