Live data from Hacker News

Coreboot and Skylake, Part 2: A Beautiful Game

puri.sm

11–20 of 44 posts

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

#11
post #10

Can someone explain this "Purism" thing? I understand that they are trying to build laptops with secure components. But they are using Intel processors. What about Intel ME? There is some workaround or they just let it be?

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.

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

#12
About the open phone: Knowing that KaKaRoTo is involved, I start top believe that this will not be vaporware. If I had enough money I would surely put some in this project. Every time somebody talked about open phone I just think "another failure", now I know it has some possibility to really happen. As you can see by his text, he is ready to solve this puzzle. Anyway, good job Youness, keep going strong.

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

#13
post #8

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

Every time I've had to deal with troubleshooting weird firmware or hardware (and good luck sometimes knowing which it is), I've been continually amazed at the giant mess that's being pushed as commercial or "enterprise" equipment. It appears every product enters a special phase of a few weeks to a few months right before shipping where time constraints force whoever is responsible for the code to wildly shovel crap fixes into place until the hardware "works".

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.

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

#14
post #5

That was a very disappointing article. The issue was not solved, and the workaround has no reason to work other than it does, meaning that it could also stop working anytime. i am not sure how anyone with a clear conscience could ship a device which works by accident

> i am not sure how anyone with a clear conscience could ship a device which works by accident

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

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

#16
post #13
post #8

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

Every time I've had to deal with troubleshooting weird firmware or hardware (and good luck sometimes knowing which it is), I've been continually amazed at the giant mess that's being pushed as commercial or "enterprise" equipment. It appears every product enters a special phase of a few weeks to a few months right before shipping where time constraints force whoever is responsible for the code to wildly shovel crap f…

It is definitely not lack of experience. Some of the best coders I've known have been hardcore low level EE guys. The issue is organizational priorities and available bandwidth. As soon as the product ships the core people are moved to the next project. Maintenance is done by a few guys whose job it is not to break anything.

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.

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

#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 gets received at the other end, it's as "clear" as possible.

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

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

#18
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.pdf

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

#19
post #11
post #10

Can someone explain this "Purism" thing? I understand that they are trying to build laptops with secure components. But they are using Intel processors. What about Intel ME? There is some workaround or they just let it be?

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.

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

#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)

Post reply on HN