Given that there are memory issues on boot, before Tiler should become an issue I don't think this is an issue yet.
I'm not sure if DMM is already in use at uboot time. Thought it was more for Linux to use, but a quick google suggests that it could be set up in uboot.
When I've experienced crashes inside Linux, I've generally been doing nothing. I'll be looking something up or compiling on a different machine and when I return the device is unresponsive.
I've never had the devboard fail to boot, but yes, I've had my devboard randomly crash.
It got better when I was blowing air over the heatsink but I always worried that my power supply was only just good enough.
Was hoping that the battery in the Pyra would would provide ample power for the changing situations.
I've never had the devboard fail to boot, but yes, I've had my devboard randomly crash.
It got better when I was blowing air over the heatsink but I always worried that my power supply was only just good enough.
Was hoping that the battery in the Pyra would would provide ample power for the changing situations.
Yeah, my devboard always boots too. I haven't checked my power supply, but it could be that. I figure that overheat should show at least some warning in the logs before shutdown
Yeah, my devboard always boots too. I haven't checked my power supply, but it could be that. I figure that overheat should show at least some warning in the logs before shutdown
The Devboard is supposed to run on either 5V or 12Volts, but I've always had to use a 12V supply to be stable on mine and I've powered it on my Bench power supplies that can provide 10A if it had to.
The Devboard is supposed to run on either 5V or 12Volts, but I've always had to use a 12V supply to be stable on mine and I've powered it on my Bench power supplies that can provide 10A if it had to.
But it didn't get me far enough. To the best of my knowledge, I was filling out all of the fields correctly. It was nice that the Pyra would sometimes boot better, but it would always lock up.
There was always a bit of an unknown about the memory. The stupid thing was, @hns had given the exact version of the memory being used in production Pyras.
But I had to ask EvilDragon for a picture of the CPU board to be sure (I was feeling too lazy to pull the unit apart).
The challenging thing is, the RAM is 800mhz being used in a 533mhz slot. The documentation sometimes talks about clock speeds and sometimes about picoseconds. I had pointed this out earlier but I didn't know how relevant it was going to be.
Most of our settings seem like they come from 533mhz section of the documentation. But the devices clearly need so many clock cycles to do certain operations.
I am still going to struggle to understand what settings to take from which section. I started feeling confident when I started, but then I ran into a configuration that needed so many clock cycles, but needed to be completed in so many picoseconds (otherwise it would be considered timed out?)
So, I've got a uboot that boots with this ram. It is becoming clear that the ram settings need to be pulled from the DTB since I believe we have a few units that will have old ram (2gb units?).
I have uploaded it to the Pyra discord for @EvilDragon to test. I think it has a huge performance penalty attached.
But if it finally boots more of the dead boards, I'll have something exciting to work from.
I thought the RAM chips would be directly soldered to the PCB. Is the RAM socketed ?
Or do you mean the SOC requires 533MHz RAM and the RAM chips are 800MHz ? That would sound doable (maybe tricky?).
It's directly soldered onto the CPU board, but I don't think he meant it in the sense of slotting or socketing, but used slot as a term for essentially saying in the same spot or place.
I thought the RAM chips would be directly soldered to the PCB. Is the RAM socketed ?
Or do you mean the SOC requires 533MHz RAM and the RAM chips are 800MHz ? That would sound doable (maybe tricky?).
They are soldered. I just think of it slotted in. Maybe I should have said 800mhz devices connected to a 533mhz clock?
Tricky is an under statement when we don't know what we are doing
Yeah. I put a little more information in the wiki. It's not a lot but it can fill in some blanks.
But it didn't get me far enough. To the best of my knowledge, I was filling out all of the fields correctly. It was nice that the Pyra would sometimes boot better, but it would always lock up.
There was always a bit of an unknown about the memory. The stupid thing was, @hns had given the exact version of the memory being used in production Pyras.
But I had to ask EvilDragon for a picture of the CPU board to be sure (I was feeling too lazy to pull the unit apart).
The challenging thing is, the RAM is 800mhz being used in a 533mhz slot. The documentation sometimes talks about clock speeds and sometimes about picoseconds. I had pointed this out earlier but I didn't know how relevant it was going to be.
Most of our settings seem like they come from 533mhz section of the documentation. But the devices clearly need so many clock cycles to do certain operations.
I am still going to struggle to understand what settings to take from which section. I started feeling confident when I started, but then I ran into a configuration that needed so many clock cycles, but needed to be completed in so many picoseconds (otherwise it would be considered timed out?)
So, I've got a uboot that boots with this ram. It is becoming clear that the ram settings need to be pulled from the DTB since I believe we have a few units that will have old ram (2gb units?).
I have uploaded it to the Pyra discord for @EvilDragon to test. I think it has a huge performance penalty attached.
But if it finally boots more of the dead boards, I'll have something exciting to work from.
They are soldered. I just think of it slotted in. Maybe I should have said 800mhz devices connected to a 533mhz clock?
Tricky is an under statement when we don't know what we are doing
Yeah. I put a little more information in the wiki. It's not a lot but it can fill in some blanks.
Uh, nope, not quite.
With 533MHz, the RAM should be setup with timings for DDR3-1066
So if the RAM has DDR3-800 timings, it would be wrong, and would cause issues.
K4B8G1646D-MYK0 is DDR3L-1600 (11-11-11), so would be most performant on an 800mhz clock.
Fortunately: "7. Any DDR3-1600 speed bin also supports functional operation at lower frequencies as shown in the table which are not subject to Production Tests but verified by Design/Characterization."
Yes, a lot of the settings are pulled from the 1066 table. But it is still a 1600 device. Although I've been able to claw back some performance by one of the settings that has seemed to make the unit more stable, which doesn't make sense (to me) if it really does need longer delay.
But the fact that the documentation says all of the 8Gb chips have a 2KB page size and the unit keeps crashing when I change it from 1 to 2 makes me doubt the accuracy of the documentation.
-edit-
Unless I am completely out of line. I am just coming at this as a programmer that thought he understood reading documentation.
Getting down to electrical characteristics has given me some doubt in my abilities >.<
-edit2-
Just had a conversation with EvilDragon on IRC and he pointed out that 2KB page size requires some different timings. Somehow I had overlooked that part of one of the table. I'll do some testing later and report back.
AFAIK, RAMs are produced and binned like that:
They start testing the DDR3 chips with the highest speed. If it runs stable, it's binned and sold as being usable for that speed.
If the DDR3 fails, they use the next lower clock and test it again. And so on.
So technically, they're all the same chip, just are being binned differently. But lower clock speeds than the tested ones all should run fine.
Except that lower clocks are commonly also used with lower latency settings, which can actually result in overall more aggressive timings that can still cause issues. Actually calculating the absolute time period from both the latency cycles and the frequency makes it more obvious.
Additionally, the frequency we're talking about here is only used for the interface, internally the actual memory is clocked with a completely different clock. DRAM timings are complex AF for a reason.
<EvilDragon> @pimaster Just tried your MLO and U-Boot. Out of 20 boards we put aside because of the memory readback error during initialization, all of them booted
Well. Looks like I've got to clean up a lot of code. Work out why USB isn't working and make it available.
This was far more of a journey than I was expecting.
Well. Looks like I've got to clean up a lot of code. Work out why USB isn't working and make it available.
This was far more of a journey than I was expecting.
ERgh. I've finally got my changes up on git: https://dev.pyra-handheld.com/pimaster/pyra-uboot/-/tree/pimaster-dll
Ended up basing it on https://dev.pyra-handheld.com/kernel/pyra-uboot instead of https://dev.pyra-handheld.com/daveshah/pyra-uboot
There just seemed more niceties for pyra start up (like not turning on when plugged in, keep your finger on the power button until the side lights go green). I did have to pluck some memory changes from Dave S.
I was all excited to announce it on IRC when I discovered that Pyra had frozen with screen tearing issues. First time it has done it in ages. Going to just pretend it was an anomaly (it's been sitting idle for about an hour now without issue). Or maybe I have to pluck more Dave S changes.
The biggest thing I had to add was disabling EMIF power saving for this to work with DLL on. It would constantly freeze at desktop if it was left as is. I'll need to look into that some more.
Hopefully it doesn't punish the battery too much (more)
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.