#372 hardware freedom criteria/guidelines on libreboot.org

Open
opened 6 months ago by vimuser · 2 comments

context: https://www.eff.org/issues/right-to-repair

I've been discussing with swiftgeek, and I believe we should start to work on and publish a set of guidelines on the libreboot website, for hardware freedom guidelines, and, as much as possible, try to tell people what to do to go about improving our rights when it comes to hardware

e.g. access to boardviews, schematics, designs etc, access to lower level parts of hardware (not just interfaces) etc

The motivation behind this is to set minimum standards for exactly what information ought to be available for hardware, to enable understanding of how the hardware works and how to use/repair/modify it.

This is relevant to Libreboot, since firmware is much closer to hardware than higher level e.g. OS kernel. There are many systems supported in Libreboot, even, where hardware info is mostly unavailable.

E.g. chromebooks (rockchip/arm) have very little manuals available for the hardware.

We are not merely interested in free software, but also hardware. I use the term "free hardware", though the community often refers to it as OSHW (open source hardware)

The EFF is doing a lot in this regard, especially on "right to repair". We should promote their work heavily. In the US, there are laws that prohibit right to repair, and our freedoms are currently under attack. For many electronics nowadays, documentation is completely unavailable to the public, so we are increasingly living in a world of black boxes with little ability to have actual freedom over the devices that we own.

context: https://www.eff.org/issues/right-to-repair I've been discussing with swiftgeek, and I believe we should start to work on and publish a set of guidelines on the libreboot website, for hardware freedom guidelines, and, as much as possible, try to tell people what to do to go about improving our rights when it comes to hardware e.g. access to boardviews, schematics, designs etc, access to lower level parts of hardware (not just interfaces) etc The motivation behind this is to set minimum standards for exactly what information ought to be available for hardware, to enable understanding of how the hardware works and how to use/repair/modify it. This is relevant to Libreboot, since firmware is much closer to hardware than higher level e.g. OS kernel. There are many systems supported in Libreboot, even, where hardware info is mostly unavailable. E.g. chromebooks (rockchip/arm) have very little manuals available for the hardware. We are not merely interested in free software, but also hardware. I use the term "free hardware", though the community often refers to it as OSHW (open source hardware) The EFF is doing a lot in this regard, especially on "right to repair". We should promote their work heavily. In the US, there are laws that prohibit right to repair, and our freedoms are currently under attack. For many electronics nowadays, documentation is completely unavailable to the public, so we are increasingly living in a world of black boxes with little ability to have actual freedom over the devices that we own.
Swift Geek commented 6 months ago
Collaborator
  • Don't use "Free Hardware" because it implies that it's 100% free - and today even LowRISC can't be taped out 100% free (it still needs proprietary library from the fab of standard cells etc). Always try to define what exactly is free/available
  • For repair/sane coreboot support and porting - absolute minimum is boardview with full netlist and/or schematic
  • Boardview/schematic can be always reversed with enough attempts and enough of dead boards. see http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#PCB_layers
  • Datasheets are nearly never full, documentation is scattered behind many formats and requirements to obtain. It's usually easier to get base datasheet than documentation on custom JTAG commands (and modes like via straps), IBIS (for simulation), and any other debug functionality

Some examples:

  • any brainfart caused accident involving KGPE-D16 can end up with dead mobo - while fixes are usually as simple as replacing some tantalum/electrolytic capacitor it's few orders of magnitude harder to do without boardview/schematic.
  • e10a-usb - none of its functionality (JTAG commands) is documented for H8S/2116 which is used for supported thinkpads. This could pose some threat to security model depending on implementation
  • 5th party battery replacements for thinkpads have firmware so bad that they are bricking themselves in regular use, and have broken gauge on day one. If all documentation was available for them, fixing them would most likely require only connecting to I2C/smbus master (like any ARM SBC or even just VGA(D-SUB) port)
* Don't use "Free Hardware" because it implies that it's 100% free - and today even LowRISC can't be taped out 100% free (it still needs proprietary library from the fab of standard cells etc). Always try to define what exactly is free/available * For repair/sane coreboot support and porting - absolute minimum is boardview with full netlist and/or schematic * Boardview/schematic can be always reversed with enough attempts and enough of dead boards. see http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#PCB_layers * Datasheets are nearly never full, documentation is scattered behind many formats and requirements to obtain. It's usually easier to get base datasheet than documentation on custom JTAG commands (and modes like via straps), IBIS (for simulation), and any other debug functionality Some examples: * any brainfart caused accident involving KGPE-D16 can end up with dead mobo - while fixes are usually as simple as replacing some tantalum/electrolytic capacitor it's few orders of magnitude harder to do without boardview/schematic. * e10a-usb - none of its functionality (JTAG commands) is documented for H8S/2116 which is used for supported thinkpads. This could pose some threat to security model depending on implementation * 5th party battery replacements for thinkpads have firmware so bad that they are bricking themselves in regular use, and have broken gauge on day one. If all documentation was available for them, fixing them would most likely require only connecting to I2C/smbus master (like any ARM SBC or even just VGA(D-SUB) port)

I found this article by Richard Stallman: https://www.gnu.org/philosophy/free-hardware-designs.html

I found this article by Richard Stallman: https://www.gnu.org/philosophy/free-hardware-designs.html
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.