Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coreboot and Skylake, Part 2: A Beautiful Game

puri.sm

Post reply on HN
Print view View original

31–40 of 44 posts

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

#31

Post by exikyut »

userbinator wrote: post #18
lanius wrote: post #8

I am continually amazed that computers manage to work at all.

Modern computers operate so close to the margins that analog effects are very much visible. 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/ [1] http://bunniefoo.com/bunnie/sdcard-30c3-pub…

I just finished reading through the VSP saga. That was very interesting.

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

#32

Post by exikyut »

simcop2387 wrote: post #29
exikyut wrote: post #28

Earlier quoted context omitted.

Could you describe the misalignment? That's interesting - Arduinos etc have made USB 2 pretty ubiquitous, so this could be useful knowledge. (I'm tired and needed to re-google it, so for anyone else: Full = 1.1/12Mbps, High = 2.0/480Mbps.)

If I were to guess, given the tolerances in timing for USB 2.0, one line was slightly longer than the other on the board. That'd mean that the transition on D- would happen at a different time than the one on D+ causing corrupted data.

Ah, yikes. Duly noted.

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

#33

Post by bradfa »

floatboth wrote: post #30
ezoe wrote: post #20

I was skeptical about those Purism products which shipped with proprietary BIOS and they claims they are working on coreboot and disable Intel ME in the future. 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)

Of course they use binary blobs — no one reverse engineered and reimplemented Intel's FSP… I wonder if there are any attempts though?

You don't need to use Intel's FSP if Intel will tell you how to do what the FSP does. FSP doesn't do anything magical, it just happens to setup a whole lot of early boot things for you like SDRAM configuration, microcode loading (and FSP knows what instructions its not allowed to use before microcode gets loaded), and starting the ME.

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.

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

#34

Post by mindentropy »

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

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

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

#36

Post by exikyut »

mindentropy wrote: post #34
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.…

> 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

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

#37

Post by khedoros1 »

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

> Is this the seemingly-pointless "memory test" all computers do?

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.

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

#38

Post by userbinator »

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

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

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

#39

Post by squarefoot »

userbinator wrote: post #19
mikeash wrote: post #11

Earlier quoted context omitted.

Interesting question. They have a page about it here: https://puri.sm/learn/intel-me/ I think the summary is: it's hard but they're working on it, and they think they can disable it.

Very recently, another team claims to have managed to disable one version of ME completely: https://news.ycombinator.com/item?id=15116719 Perhaps they could work together on this.

It would be nice having a centralized list of the hardware that uses "liberated" CPUs, just in case one pops in front of us at discounted prices, flea markets etc.

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

#40

Post by elcritch »

wodenokoto wrote: post #21

A bit of a sidetrack, but has anybody bought their laptops? How are they? Particularly the trackpad.

Second this! Anyone tried the trackpad? I have hopes it's not completely as terrible as most PC's. Between that, and this (cool) work on open boot processes, it might make my next laptop after my macbook pro ages some more.
Post reply on HN