SoylentNews is people
SoylentNews
Libreboot Sees First New Release In Nearly 5 Years, Supports More Old Motherboards
Libreboot as the Coreboot downstream focused on providing a fully open-source BIOS/firmware replacement without any black boxes / binary blobs is out with a new release. The prior tagged release of Libreboot was all the way back in 2016 while has now been succeeded by a new release albeit in testing form.
Libreboot 20210522 allows more Intel GM45 / X3X era hardware to work with this fully open-source alternative to proprietary BIOS/UEFI firmware. New boards supported by this Libreboot release include the Acer G43T-AM3, Lenovo ThinkPad R500, Lenovo ThinkPad X301, and Intel G43T-AM3. Yeah, it's quite hard in 2021 to get excited about Socket 775 motherboards or 45nm Penryn laptops. Libreboot is largely limited to supporting these outdated platforms due to its focus on being fully open-source and not using any Intel FSP binaries, etc.
Previously: Replace your Proprietary BIOS with Libreboot
AMD to Consider Coreboot/Libreboot Support
Libreboot Applies to Rejoin GNU
(Score: 5, Interesting) by bzipitidoo on Tuesday May 25 2021, @12:35PM (3 children)
An anecdote about old hardware.
I'm still using computers that are between 10 and 15 years old. One of them, with a 65nm CPU, Linux 2.6.33 shut down just fine. Somewhere between that version and 3.0, shutdown stopped powering off that computer reliably. The system would shut down, and then I'd have to hold the power button for 4 seconds. Perhaps 10% of the time, the kernel does power off, the rest of the time I have to do it. I don't know what changed in the kernel, but what seems most likely is that the kernel maintainers removed code that works around a bug in that system's BIOS or firmware.
Reason I suspect something like that is what I learned from an even older computer, with a Pentium IV. Neither Linux nor FreeBSD could use the DVD/CD burner reliably. Curiously, the CD would boot and reading it worked just fine, but then it would fail to read. How could it work and then stop working? With a lot of experimenting, I nailed down the problem. I thought at first it was the DVD burner, that Linux had removed support for that model. I learned that 2.6.25 is the last kernel that could reliably use that optical drive. A boot CD with 2.6.26 did sort of work still, by treating the drive as hdc, rather than sdc. 2.6.27, nope, didn't work at all. It turned out the drive wasn't the problem at all. The problem was that when I first built that computer, I had used a 40 wire PATA cable for the optical drive, while the hard drive got the 80 wire cable. (I didn't have enough 80 wire cables to go 80 wire everywhere, and thought the optical drive, being slower, was the obvious choice for the 40 wire cable.) I'd long ago forgotten all about PATA cables, forgotten that there was this improvement from 40 to 80 wire, as PATA has long since been replaced by SATA. (If you're curious, the extra wires aren't actually connected to anything. What they do is simply rest between the 40 wires, and thereby cut down the interference the 40 wires that are in use cause with each other.) Anyway, 2.6.25 will announce, in the logs, that it has detected a 40 wire cable, reduce the transfer speed accordingly, and everything just works. 2.6.27 won't say anything about having detected a 40 wire cable, try to use the connection at the full speed that the 80 wire cable can support, and it won't work. The solution I adopted was to dig up another 80 wire cable. That worked, and Linux 4.x and 5.x, and FreeBSD, were suddenly able to handle that old DVD/CD drive just fine.
So why did the kernel maintainers take that little bit of 40 wire detection code out of the kernel? They do that. They will quietly take out things that they believe no one ever uses any more. The noisiest removal was kicking out the 386 code. Sometime during Linux 3.x, support for the 386 was dropped. Now a 486 is the minimum x86 CPU.
(Score: 5, Informative) by Anonymous Coward on Tuesday May 25 2021, @04:37PM (2 children)
This is wrong. All 40 extra wires are (or rather, should be) connected to one or more of the ground pins inside the connectors. If the additional wires are not electrically connected at both ends the cables will not serve their intended purpose. Specialized connectors were made for this.
The 80-wire cable solves a specific problem with the IDE cable design without altering the pinout: all 16 data lines are clustered together in the ribbon. As speeds on these cables increase this turns out to be a big problem for the data signals in the middle of this cluster. Take for example pin 10 (data bit 11). The closest ground pin is pin 2 (with pin 19 being the next closest). In a normal 40-wire ribbon cable, all the other 15 data signals are physically located directly between this wire and the nearest ground wires with half on either side.
The issue is that as frequencies increase, the return current from this middle signal will not actually travel on the ground wires: they are too far away. The high frequency return current will essentially all travel along the adjacent signal wires. This is bad for signal integrity and it is bad for EMI. This is only solved by creating an even lower inductance path for the return current, which the 80-conductor cable accomplishes by inserting a dedicated ground wire adjacent to every single other wire in the cable.
These extra wires can only serve as a low inductance the return path if they are electrically connected at both ends (for a normal IDE cable with two device connections, that means they are electrically connected inside all three connectors).
(Score: 2) by bzipitidoo on Tuesday May 25 2021, @09:08PM (1 child)
Thank you for the correction. I had thought the extra wires were just there as a shield, not as a ground. Explains why it's 80 wire, and not 79 or 81 wire. Also explains how the connector can still be only 40 pin.
(Score: 0) by Anonymous Coward on Wednesday May 26 2021, @05:17AM
I imagine the choice of 80 wires is more a practical choice than anything else. For example, presumably there is no real point in adding an extra ground wire between pins 1 (reset) and 2 (ground). These wires are right next to each other with nothing between them so there is unlikely to be problems. And the other side of the cable already has several ground wires interspersed with various (mostly non-critical) signals, with nothing as obviously horrible as the data lines.
The practicality just comes from "hey, we can just use off the shelf 0.635mm ribbon cable and off the shelf tools to terminate into special connectors, then we only need to design/build those connectors and there's barely any change to manufacture the cable assemblies". Then the geometry of ribbon cables basically makes 80 conductors the only option -- 79 would presumably do just fine but the ribbon would be off-center and the factory probably wouldn't like it as much (I have seen ribbon cables terminated this way, however).
As an aside, there was a brief period when round IDE cables were available. I doubt any of these actually had 80 wires since the point of these cables was to have a "clean" look in your case, but I suspect they would nevertheless perform quite well (despite the ATA standards only specifying the use of ribbon cables) as the round design inherently brings everything physically closer together.