Coreboot and Skylake, Part 2: A Beautiful Game • Hacker News Board

Re: Coreboot and Skylake, Part 2: A Beautiful Game

#41

Post by exikyut » Thu, Aug 31, 2017, 11:12 AM UTC

userbinator wrote: post #38

exikyut wrote: post #27

Earlier quoted context omitted.

> Even early SDRAM controllers had similar tunable settings for clock delays and such, 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.…

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. 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 careful…

Interesting.

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.

Re: Coreboot and Skylake, Part 2: A Beautiful Game

#42

Post by mindentropy » Thu, Aug 31, 2017, 1:08 PM UTC

exikyut wrote: post #36

mindentropy wrote: post #34

Earlier quoted context omitted.

> Is this the seemingly-pointless "memory test" all computers do? 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...

Wow. Really, really impressive. How far back did BIOSes do this - has it always been done?(!) 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

I don't have advanced BIOS and most of the BIOS uses a safe set of values is my assumption.

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.

Re: Coreboot and Skylake, Part 2: A Beautiful Game

#43

Post by mindentropy » Thu, Aug 31, 2017, 5:59 PM UTC

exikyut wrote: post #36

mindentropy wrote: post #34

Earlier quoted context omitted.

> Is this the seemingly-pointless "memory test" all computers do? 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...

Wow. Really, really impressive. How far back did BIOSes do this - has it always been done?(!) 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

In case of the i.MX6 SoC I do the training and calibration and the recommended register values obtained is provided to U-boot. So now when U-boot starts up it starts on the SoC inbuilt SRAM which is very less (a few kilobytes). Once the first stage U-boot is booted it sets up the memory controller registers and the boots using this RAM.

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.

Re: Coreboot and Skylake, Part 2: A Beautiful Game

#44

Post by breakingcups » Fri, Sep 01, 2017, 11:33 AM UTC

exikyut wrote: post #27

userbinator wrote: post #17

I'm not surprised that going back to 3Gbps works; modern high frequency signaling is so close to the boundaries of what works that even things like the length of the SATA cable and how it's oriented, and what temperature components are at, can mean the difference between a working link and one that fails when the right sequence of bits gets sent. DTLE is a way of tuning the transmitter output so that when the signal…

> Even early SDRAM controllers had similar tunable settings for clock delays and such, 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.…

The original Xbox from Microsoft was basically a slightly modified x86 computer (complete with actually-usb-ports-with-a-proprietary-plug controller ports)[0], where the 64mb of DDR SDRAM was soldered directly onto the motherboard.

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