Coreboot and Skylake, Part 2: A Beautiful Game
puri.sm
puri.sm
Even early SDRAM controllers had similar tunable settings for clock delays and such, because different DIMMs may vary slightly --- upon POST, the BIOS would set all the settings to nominal values, then nudge each one in one direction while reading/writing pathological data until errors occurred; then nudge them in the other direction until errors occurred, and finally settle on the average of the two extremes. I suspect a similar process needs to be done here, and if you reverse-engineered the BIOS further you would find the algorithm to do it.
More interesting information on DTLE "discrete time linear equalization" here: http://cc.ee.ntu.edu.tw/~rbwu/rapid_content/course/highspeed...
Big kudos to the Purism folks for trying to figure these things out. And big fuckings to Intel for keeping this stuff NDA'd --- it only makes it harder for those trying to buy and use your products (I hope someone leaks it all eventually...)
Define "early". F00F-era Pentium, 486, 8086...?
> upon POST, the BIOS would set all the settings to nominal values, then nudge each one in one direction while reading/writing pathological data until errors occurred; then nudge them in the other direction until errors occurred, and finally settle on the average of the two extremes.
Is this the seemingly-pointless "memory test" all computers do?
I always thought that just zeroed RAM. TIL it's doing similar things to modem line training. Wow.
Now I remember - I have an old 400MHz Celeron-based system I used years ago with an AMI BIOS that would occasionally recommend a different "RAS-to-CAS delay" on startup. I'd go and change it and reboot, and then a little while (days/weeks) later it would recommend a slightly different setting. It would always alternate between the two delays. I was pretty sure the memory in the system was on the way out and be sad whenever I saw the message, haha.
I might not be sure what your parent is talking but it is called "DDR memory training and calibration". I used to struggle with this when I was bringing up LPDDR2 on an i.MX6 embedded board.
You can find more about it here -> https://github.com/librecore-org/librecore/wiki/Understandin...
I can completely understand it being a struggle now. At some point was I thinking of getting into tinkering with DDR3/4 on FPGAs (to play with some video capture ideas), but I'm beginning to not look forward to it... heheh
However BIOSes catered to overclocking crowd has this functionality.
Ref1: http://www.overclock.net/t/1490835/the-gigabyte-z97x-overclo...
Ref2: http://www.tomshardware.co.uk/ram-overclocking-guide,review-...
Also remember that the training also depends on the environmental temperature.
> I can completely understand it being a struggle now. At some point was I thinking of getting into tinkering with DDR3/4 on FPGAs
Understanding of the different values for the registers which the tool recommends and validating the value is a real pain although some of the vendors such as Micron's datasheets explains things nicely.
Xilinx MIG has a really dense guide and you really need to understand your timing etc. It is really not for the faint hearted.
When the DDR/LPDDR training happens it is supposed to be left overnight for multiple iterations. Temperature also matters for proper values and hence one of the reasons the multiple iteration testing done overnight.
In my case I had some really incompetent board designers who were just blaming. Finally since there might have been layout issues I was forced to lower the clock speeds (halve the clocks) for the DDR interfacing.
I think that the classic case was that the computer wrote and read to/from every memory address to check that the memory reported present was actually there. I'm not positive, but I think that most machines these days do a cut-down version of that to save time.
I also think that auto-adjusting the timing is probably a separate process.
As far as I know, that's roughly the era when this was introduced --- late Pentium/early Pentium II, mid to late-90s.
The "memory test" happens after the tuning (which in my experience only touches limited portions of the whole address space) but if you watch carefully and have multiple, slightly differing (or even failing) memory modules, you may see it repeat once or twice as it encounters an error and retries the tuning.
Regarding the testing only touching limited portions of the address space, that reminds me of my early 90s vintage 486 (which I still have! :D). It would make the PC speaker tick as it counted out RAM. The first few ticks would be a little slow, then the rest would run quicker. It took me a few years to realize that it was slowly counting out the first 640K, then racing to the rest of the installed 8MB.
I remember very well (this was the first computers I owned that I've been able to keep around... somewhere, lol) that there were exactly four "slow" ticks and then the rest were faster. I definitely have to find all the bits for that machine sometime - I just tried to reproduce the ticking sound with `beep` but failed, and Googling to figure out what frequency and duration the ticks might have had was perhaps predictably useless.
Now, it's widely known within the Xbox "scene" that the quality of the RAM fluctuates a lot between different machines. The speculation was that Microsoft bought the cheapest bottom-of-the-barrel RAM it could find in bulk, which meant they couldn't hardcode the memory timings.
Instead, on boot, it clocks the RAM at the highest speed and does a quick write-and-read test. If it fails, it clocks it down a step and repeats the test until it finds a stable frequency.
This explains why sometimes the same game would run perfectly on one Xbox while stuttering on the other one, even when swapping DVD drives.
[0]:https://en.wikipedia.org/wiki/Xbox_technical_specifications
An alternate explanation is that most this code is written by electrical engineers that while smart, don't quite have enough experience managing larger code projects yet and are still prone to some of the newbie software developer mistakes, and probably without good mentoring on that front because those that have already weathered this storm and learned enough to sail through smoothly have either jumped ship for greener pastures or been promoted enough to be out of the trenches but not enough to have sway to fix the problem.
If there is something they can't fix, it goes back to the core guys who are already busy working on the new project and can only dedicate so much time to addressing this issue.
As Andrew "bunnie" Huang once said, "You are not storing data, you are storing probabilistic approximation of your data."[1]
That being said, analog effects have been noticeable at the software level for a while; here's another example: https://www.linusakesson.net/scene/safevsp/
(I'm tired and needed to re-google it, so for anyone else: Full = 1.1/12Mbps, High = 2.0/480Mbps.)
At least, they are trying to keep the promise of coreboot part(It's coreboot not libreboot or librecore so it must contains binary blob firmware... still better than nothing)
For Intel Bay Trail parts (which Intel publicly says you have to use FSP for), I was once told by a BIOS/firmware vendor that they didn't use Intel's FSP because it was too slow and their customers wanted very fast boot times. No idea if they were pulling my leg or not, but Intel's FSP on Bay Trail wasn't exactly super speedy.
But they are using Intel processors. What about Intel ME? There is some workaround or they just let it be?
I think the summary is: it's hard but they're working on it, and they think they can disable it.
Perhaps they could work together on this.
i am not sure how anyone with a clear conscience could ship a device which works by accident
I wish the team finds a proper solution
LOL, welcome to enterprise level "Ship now, the service contract gives us at least a few weeks to work out the kinks" hardware, where understanding how the whole system actually works is a luxury most the engineers don't even have.
Kudos to them for giving it a good shot and continuing to look. A lot of times, unless you have money or clout to throw at some of the component originators, you're out of luck if you want real answers. The few engineers that have them are probably so busy that to devote them to figuring out what's really going on isn't worthwhile for the companies without some higher level intervention..