A bit of a sidetrack, but has anybody bought their laptops? How are they? Particularly the trackpad.
Coreboot and Skylake, Part 2: A Beautiful Game
21–30 of 44 posts
Re: Coreboot and Skylake, Part 2: A Beautiful Game
#22Wow, KaKaRoTo is still in the hardware scene, damn.
Re: Coreboot and Skylake, Part 2: A Beautiful Game
#23Re: Coreboot and Skylake, Part 2: A Beautiful Game
#24I 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…
One one of our boards, we had intermittent USB failures (sometimes after 5 minutes, sometimes after 13 days of continuous operation) that were ultimately caused by slightly misaligned/misspaced USB D+/D- traces. We ended up having to force usage of USB full speed mode for USB high speed devices via a debug register (not unlike the article's case). Makes me feel slightly better that even people much more competent than I end up having to use such workarounds.
Re: Coreboot and Skylake, Part 2: A Beautiful Game
#25Earlier quoted context omitted.
Is this the controller bug where you have to drop the joystick polling rate while writing to the memory card or all goes to hell?
Yes this one; the one that even the hardware designer refused to acknowledge until reality check hit.
Re: Coreboot and Skylake, Part 2: A Beautiful Game
#26I really like where this is going. I'm seriously considering their phone. Only doubt I have is not knowing what battery life would be like.
Re: Coreboot and Skylake, Part 2: A Beautiful Game
#27I'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 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.
Re: Coreboot and Skylake, Part 2: A Beautiful Game
#28Earlier quoted context omitted.
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…
One one of our boards, we had intermittent USB failures (sometimes after 5 minutes, sometimes after 13 days of continuous operation) that were ultimately caused by slightly misaligned/misspaced USB D+/D- traces. We ended up having to force usage of USB full speed mode for USB high speed devices via a debug register (not unlike the article's case). Makes me feel slightly better that even people much more competent tha…
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.)
Re: Coreboot and Skylake, Part 2: A Beautiful Game
#29Earlier quoted context omitted.
One one of our boards, we had intermittent USB failures (sometimes after 5 minutes, sometimes after 13 days of continuous operation) that were ultimately caused by slightly misaligned/misspaced USB D+/D- traces. We ended up having to force usage of USB full speed mode for USB high speed devices via a debug register (not unlike the article's case). Makes me feel slightly better that even people much more competent tha…
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.
Re: Coreboot and Skylake, Part 2: A Beautiful Game
#30I 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?