Creation of i18n folder containing translations of the libreboot project. Added french one, not finished.

1 files changed, 1145 insertions, 0 deletions

diff --git a/i18n/fr_FR/www/faq.md b/i18n/fr_FR/www/faq.md
new file mode 100644
index 00000000..5c5fc4a3
--- /dev/null
+++ b/i18n/fr_FR/www/faq.md
@@ -0,0 +1,1145 @@
+---
+title: Foire aux questions
+x-toc-enable: true
+...
+
+
+Questions importantes
+================
+
+Est-ce que le projet Libreboot est encore actif ?
+-------------------------------------------
+
+Oui ! Le [répertoire git](https://notabug.org/libreboot/libreboot) montre tout le travail que nous sommes en train de faire en ce moment.
+Libreboot est plutôt actif.
+
+
+Alors, quand est-ce que la prochaine version de Libreboot va sortir ?
+-------------------------------------------------------
+
+Réponse courte: ça sort quand ça sort. Si vous voulez aider et soumettre des patchs, référez-vous à [la page Git](git.md).
+
+Nous n'annonçons pas de temps estimé de sortie.
+
+Réponse longue:
+
+Nous avons réécris l'entiereté du système de build de Libreboot de rien, depuis la dernière version. Ça a pris plus longtemps que nous avons prévu, mais le système de build arrive à maturité. Nous sommes en train de le polir.
+
+Une fois que le système de build est stable, notre prochaine priorité est de s'assurer que toutes les cibles de build supportées maintenant se buildent proprement dans Libreboot.
+
+Après celà, la priorité est de s'assurer que toutes les cartes mères dans Libreboot utilise la révision la plus à jour de Coreboot, avec tous les correctifs et améliorations. 
+Tester ces cartes mères sera juste une affaire d'un examen collégial, étendu à la communauté entière via les versions alpha/bêta/RC.
+
+Généralement, toutes les problèmes bloquant la production d'une version doit être adressé avant qu'une nouvelle sorte.
+Voyez : 
+<https://notabug.org/libreboot/libreboot/issues>
+
+Les plus importantes tâches sont maintenant les suivantes:
+
+- Étudier le système de build de Libreboot (écrit en Bash), et y apporter des corrections.
+- Travailler sur de nouvelles améliorations et aider avec les builds une fois que toutes les ROMs sont construites pour toutes les cartes mères, quand le système de build est stable.
+- En particulier, il y a quelques nouvelles cartes mères dans coreboot que nous pouvons ajouter à Libreboot, comme documenté dans le traqueur de bogues de Libreboot.
+Celles-ci devront être ajoutées, et complétement testées. Les instructions pour mettre en place les outils de flashing matériels peuvent être trouvés dans [les guides d'installation de Libreboot](docs/install/)
+- Bogues ! Reportez les bogues ! <https://notabug.org/libreboot/libreboot/issues> 
+- Quelques nouvelles adaptions de cartes mères serait bienvenue ;).
+- Si vous avez les compétences, cela serait très apprécié. Adaptez les à coreboot d'abord, où faites en sorte que les cibles existantes de coreboot marchent sans blobs binaires.
+
+Plus généralement:
+
+- Parlez à vos amis à propos de Libreboot ! Libreboot veut libérer autant de personnes que possible.
+- Si vous avez des moyens d'ameliorer la documentation, vous pouvez faire ça aussi.
+Référez-vous à la [page Git](git.md) pour des instructions sur la soumission des patchs dans la documentation.
+- Encouragez les entreprises, où n'importe quelles personnes avec les compétences/ressources, de s'impliquer dans le développement de Libreboot.
+
+
+Quelle version de Libreboot ai-je ?
+----------------------------------------------------------------
+
+Regardez la version [dans la documentation](../docs/#version)
+
+
+Flashrom complains about DEVMEM access
+--------------------------------------
+
+If running `flashrom -p internal` for software based flashing, and
+you get an error related to /dev/mem access, you should reboot with
+`iomem=relaxed` kernel parameter before running flashrom, or use a kernel
+that has `CONFIG_STRICT_DEVMEM` and `CONFIG_IO_STRICT_DEVMEM` not enabled.
+
+Example flashrom output with both `CONFIG_STRICT_DEVMEM` and `CONFIG_IO_STRICT_DEVMEM` enabled:
+```
+flashrom v0.9.9-r1955 on Linux 4.11.9-1-ARCH (x86_64)
+flashrom is free software, get the source code at https://flashrom.org
+
+Calibrating delay loop... OK.
+Error accessing high tables, 0x100000 bytes at 0x000000007fb5d000
+/dev/mem mmap failed: Operation not permitted
+Failed getting access to coreboot high tables.
+Error accessing DMI Table, 0x1000 bytes at 0x000000007fb27000
+/dev/mem mmap failed: Operation not permitted
+```
+
+The backlight is darker on the left side of the screen when lowering the brightness on my X200/T400/T500/R400 
+---------------------------------------------------------------------------------------------------------------
+
+We don't know how to detect the correct PWM value to use in
+coreboot-libre, so we just use the default one in coreboot which has
+this issue on some CCFL panels, but not LED panels.
+
+You can work around this in your distribution, by following the notes at
+[docs: backlight control](../docs/misc/#finetune-backlight-control-on-intel-gpus).
+
+The ethernet doesn't work on my X200/T400/X60/T60 when I plug in it 
+-------------------------------------------------------------------
+
+This was observed on some systems using network-manager. This happens
+both on the original BIOS and in libreboot. It's a quirk in the
+hardware. On debian systems, a workaround is to restart the networking
+service when you connect the ethernet cable:
+
+    $ sudo service network-manager restart
+
+On Parabola, you can try:
+
+    $ sudo systemctl restart network-manager
+
+(the service name might be different for you, depending on your
+configuration)
+
+My KCMA-D8 or KGPE-D16 doesn't boot with the PIKE2008 module installed 
+-----------------------------------------------------------------------
+
+Libreboot 20160818, 20160902 and 20160907 all have a bug: in SeaBIOS,
+PCI options ROMs are loaded when available, by default. This is not
+technically a problem, because an option ROM can be free or non-free. In
+practise, though, they are usually non-free.
+
+Loading the option ROM from the PIKE2008 module on either ASUS KCMA-D8
+or KGPE-D16 causes the system to hang at boot. It's possible to use
+this in the payload (if you use a linux kernel payload, or petitboot),
+or to boot (with SeaGRUB and/or SeaBIOS) from regular SATA and then use
+it in GNU+Linux. The Linux kernel is capable of using the PIKE2008
+module without loading the option ROM.
+
+Libreboot-unstable (or git) now disables loading PCI option ROMs, but
+previous releases with SeaGRUB (20160818-20160907) do not. You can work
+around this by running the following command:
+
+    $ ./cbfstool yourrom.rom add-int -i 0 -n etc/pci-optionrom-exec
+
+You can find *cbfstool* in the \_util archive with the libreboot release
+that you are using.
+
+What are the ata/ahci errors I see in libreboot's GRUB?
+-----------------------------------------------------------------------
+
+You can safely ignore those errors, they exist because we can't quiet down
+cryptomount command from `for` loop in libreboot's
+[grub.cfg](https://notabug.org/libreboot/libreboot/src/r20160907/resources/grub/config/menuentries/common.cfg#L66).
+It could be fixed in upstream grub by contributing patch that would add
+quiet flag to it.
+
+How to save kernel panic logs on thinkpad laptops?
+--------------------------------------------------
+
+The easiest method of doing so is by using the kernel's netconsole
+and reproducing the panic. Netconsole requires two machines, the one that is
+panicky (source) and the one that will receive crash logs (target). The
+source has to be connected with an ethernet cable and the target has to be
+reachable at the time of the panic. To set this system up, execute the
+following commands as root on the source (`source#`) and normal user on
+the target (`target$`):
+
+1.  Start a listener server on the target machine (netcat works well):
+
+    `target$ nc -u -l -p 6666`
+
+2.  Mount configfs (only once per boot, you can check if it is already mounted
+    with `mount | grep /sys/kernel/config`. This will return no output
+    if it is not).
+
+    `source# modprobe configfs`
+
+    `source# mkdir -p /sys/kernel/config`
+
+    `source# mount none -t configfs /sys/kernel/config`
+
+3.  find source's ethernet interface name, it should be of the form `enp*` or
+    `eth*`, see `ip address` or `ifconfig` output.
+
+    `source# iface="enp0s29f8u1"` change this
+
+    Fill the target machine's IPv4 address here:
+
+    `source# tgtip="192.168.1.2"` change this
+
+
+3.  Create netconsole logging target on the source machine:
+
+    `source# modprobe netconsole`
+
+    `source# cd /sys/kernel/config/netconsole`
+
+    `source# mkdir target1; cd target1`
+
+    `source# srcip=$(ip -4 addr show dev "$iface" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')`
+
+    `source# echo "$srcip" > local_ip`
+
+    `source# echo "$tgtip" > remote_ip`
+
+    `source# echo "$iface" > dev_name`
+
+    `source# arping -I "$iface" "$tgtip" -f | grep -o '..:..:..:..:..:..' > remote_mac`
+
+    `source# echo 1 > enabled`
+
+4.  Change console loglevel to debugging:
+
+    `source# dmesg -n debug`
+
+5.  Test if the logging works by e.g. inserting or removing an USB
+    device on the source. There should be a few lines appearing in the
+    terminal, in which you started netcat (nc), on the target host.
+
+6.  Try to reproduce the kernel panic.
+
+Machine check exceptions on some Montevina (Penryn CPU) laptops
+---------------------------------------------------------------
+
+Some GM45 laptops have been freezing or experiencing a kernel panic
+(blinking caps lock LED and totaly unresponsive machine, sometimes followed
+by an automatic reboot within 30 seconds).
+We do not know what the problem(s) is(are), but a CPU microcode
+update in some cases prevents this from happening again.
+See the following bug reports for more info:
+
+- [T400 Machine check: Processor context corrupt](https://notabug.org/libreboot/libreboot/issues/493)
+- [X200 Machine check: Processor context corrupt](https://notabug.org/libreboot/libreboot/issues/289)
+
+- [Unrelated, RAM incompatibility and suspend-to-ram issues on X200](https://libreboot.org/docs/hardware/x200.html#ram_s3_microcode)
+
+
+Hardware compatibility
+======================
+
+What systems are compatible with libreboot?
+-----------------------------------------------------------------------------------
+
+See the [hardware compatibility list](docs/hardware/).
+
+Will the Purism laptops be supported?
+----------------------------------------------------------------------
+
+Short answer: no.
+
+There are severe privacy, security and freedom issues with these laptops, due
+to the Intel chipsets that they use. See:
+
+- [Intel Management Engine](#intelme)
+- [More freedom issues on modern Intel hardware](#intel)
+
+Most notably, these laptops also use the Intel FSP binary blob, for the entire
+hardware initialization. Coreboot does support a particular revision of one of
+their laptops, but most are either unsupported or rely on binary blobs for most
+of the hardware initialization.
+
+In particular, the Intel Management Engine is a severe threat to privacy and
+security, not to mention freedom, since it is a remote backdoor that provides
+Intel remote access to a computer where it is present.
+
+Intel themselves even admitted it, publicly.
+
+The Libreboot project recommends avoiding all hardware sold by Purism.
+
+Why is the latest Intel hardware unsupported in libreboot? {#intel}
+-----------------------------------------------------------
+
+It is unlikely that any post-2008 Intel hardware will ever be supported in
+libreboot, due to severe security and freedom issues; so severe, that *the
+libreboot project recommends avoiding all modern Intel hardware. If you have an
+Intel based system affected by the problems described below, then you should
+get rid of it as soon as possible*. The main issues are as follows:
+
+### Intel Management Engine (ME) {#intelme}
+
+Introduced in June 2006 in Intel's 965 Express Chipset Family of
+(Graphics and) Memory Controller Hubs, or (G)MCHs, and the ICH8 I/O
+Controller Family, the Intel Management Engine (ME) is a separate
+computing environment physically located in the (G)MCH chip. In Q3 2009,
+the first generation of Intel Core i3/i5/i7 (Nehalem) CPUs and the 5
+Series Chipset family of Platform Controller Hubs, or PCHs, brought a
+more tightly integrated ME (now at version 6.0) inside the PCH chip,
+which itself replaced the ICH. Thus, the ME is ***present on all Intel
+desktop, mobile (laptop), and server systems since mid 2006***.
+
+The ME consists of an ARC processor core (replaced with other processor
+cores in later generations of the ME), code and data caches, a timer,
+and a secure internal bus to which additional devices are connected,
+including a cryptography engine, internal ROM and RAM, memory
+controllers, and a ***direct memory access (DMA) engine*** to access the
+host operating system's memory as well as to reserve a region of
+protected external memory to supplement the ME's limited internal RAM.
+The ME also has ***network access*** with its own MAC address through an
+Intel Gigabit Ethernet Controller. Its boot program, stored on the
+internal ROM, loads a firmware "manifest" from the PC's SPI flash
+chip. This manifest is ***signed with a strong cryptographic key***,
+which differs between versions of the ME firmware. If the manifest
+isn't signed by a specific Intel key, the boot ROM won't load and
+execute the firmware and the ME processor core will be halted.
+
+The ME firmware is compressed and consists of modules that are listed in
+the manifest along with secure cryptographic hashes of their contents.
+One module is the operating system kernel, which is based on a
+***proprietary real-time operating system (RTOS) kernel*** called
+"ThreadX". The developer, Express Logic, sells licenses and source
+code for ThreadX. Customers such as Intel are forbidden from disclosing
+or sublicensing the ThreadX source code. Another module is the Dynamic
+Application Loader (DAL), which consists of a ***Java virtual machine***
+and set of preinstalled Java classes for cryptography, secure storage,
+etc. The DAL module can load and execute additional ME modules from the
+PC's HDD or SSD. The ME firmware also includes a number of native
+application modules within its flash memory space, including Intel
+Active Management Technology (AMT), an implementation of a Trusted
+Platform Module (TPM), Intel Boot Guard, and audio and video DRM
+systems.
+
+The Active Management Technology (AMT) application, part of the Intel
+"vPro" brand, is a Web server and application code that enables remote
+users to power on, power off, view information about, and otherwise
+manage the PC. It can be ***used remotely even while the PC is powered
+off*** (via Wake-on-Lan). Traffic is encrypted using SSL/TLS libraries,
+but recall that all of the major SSL/TLS implementations have had highly
+publicized vulnerabilities. The AMT application itself has ***[known
+vulnerabilities](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Known_vulnerabilities_and_exploits)***,
+which have been exploited to develop rootkits and keyloggers and
+covertly gain encrypted access to the management features of a PC.
+Remember that the ME has full access to the PC's RAM. This means that
+an attacker exploiting any of these vulnerabilities may gain access to
+everything on the PC as it runs: all open files, all running
+applications, all keys pressed, and more.
+
+[Intel Boot Guard](https://mjg59.dreamwidth.org/33981.md) is an ME
+application introduced in Q2 2013 with ME firmware version 9.0 on 4th
+Generation Intel Core i3/i5/i7 (Haswell) CPUs. It allows a PC OEM to
+generate an asymmetric cryptographic keypair, install the public key in
+the CPU, and prevent the CPU from executing boot firmware that isn't
+signed with their private key. This means that ***coreboot and libreboot
+are impossible to port*** to such PCs, without the OEM's private
+signing key. Note that systems assembled from separately purchased
+mainboard and CPU parts are unaffected, since the vendor of the
+mainboard (on which the boot firmware is stored) can't possibly affect
+the public key stored on the CPU.
+
+ME firmware versions 4.0 and later (Intel 4 Series and later chipsets)
+include an ME application for ***audio and video
+[DRM](https://defectivebydesign.org/what_is_drm_digital_restrictions_management)***
+called "Protected Audio Video Path" (PAVP). The ME receives from the
+host operating system an encrypted media stream and encrypted key,
+decrypts the key, and sends the encrypted media decrypted key to the
+GPU, which then decrypts the media. PAVP is also used by another ME
+application to draw an authentication PIN pad directly onto the screen.
+In this usage, the PAVP application directly controls the graphics that
+appear on the PC's screen in a way that the host OS cannot detect. ME
+firmware version 7.0 on PCHs with 2nd Generation Intel Core i3/i5/i7
+(Sandy Bridge) CPUs replaces PAVP with a similar DRM application called
+"Intel Insider". Like the AMT application, these DRM applications,
+which in themselves are defective by design, demonstrate the omnipotent
+capabilities of the ME: this hardware and its proprietary firmware can
+access and control everything that is in RAM and even ***everything that
+is shown on the screen***.
+
+The Intel Management Engine with its proprietary firmware has complete
+access to and control over the PC: it can power on or shut down the PC,
+read all open files, examine all running applications, track all keys
+pressed and mouse movements, and even capture or display images on the
+screen. And it has a network interface that is demonstrably insecure,
+which can allow an attacker on the network to inject rootkits that
+completely compromise the PC and can report to the attacker all
+activities performed on the PC. It is a threat to freedom, security, and
+privacy that can't be ignored.
+
+Before version 6.0 (that is, on systems from 2008/2009 and earlier), the
+ME can be disabled by setting a couple of values in the SPI flash
+memory. The ME firmware can then be removed entirely from the flash
+memory space. libreboot [does this](../docs/hardware/gm45_remove_me.md) on
+the Intel 4 Series systems that it supports, such as the [Libreboot
+X200](../docs/install/x200_external.md) and [Libreboot
+T400](../docs/install/t400_external.md). ME firmware versions 6.0 and
+later, which are found on all systems with an Intel Core i3/i5/i7 CPU
+and a PCH, include "ME Ignition" firmware that performs some hardware
+initialization and power management. If the ME's boot ROM does not find
+in the SPI flash memory an ME firmware manifest with a valid Intel
+signature, the whole PC will shut down after 30 minutes.
+
+Due to the signature verification, developing free replacement firmware
+for the ME is basically impossible. The only entity capable of replacing
+the ME firmware is Intel. As previously stated, the ME firmware includes
+proprietary code licensed from third parties, so Intel couldn't release
+the source code even if they wanted to. And even if they developed
+completely new ME firmware without third-party proprietary code and
+released its source code, the ME's boot ROM would reject any modified
+firmware that isn't signed by Intel. Thus, the ME firmware is both
+hopelessly proprietary and "tivoized".
+
+**In summary, the Intel Management Engine and its applications are a
+backdoor with total access to and control over the rest of the PC. The
+ME is a threat to freedom, security, and privacy, and the libreboot
+project strongly recommends avoiding it entirely. Since recent versions
+of it can't be removed, this means avoiding all recent generations of
+Intel hardware.**
+
+More information about the Management Engine can be found on various Web
+sites, including [me.bios.io](http://me.bios.io/Main_Page),
+[unhuffme](http://io.netgarage.org/me/), [coreboot
+wiki](http://www.coreboot.org/Intel_Management_Engine), and
+[Wikipedia](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology).
+The book ***[Platform Embedded Security Technology
+Revealed](https://www.apress.com/9781430265719)*** describes in great
+detail the ME's hardware architecture and firmware application modules.
+
+If you're stuck with the ME (non-libreboot system), you might find this
+interesting:
+<http://hardenedlinux.org/firmware/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html>
+
+Also see (effort to disable the ME):
+<https://www.coreboot.org/pipermail/coreboot/2016-November/082331.html>
+- look at the whole thread
+
+### Firmware Support Package (FSP) {#fsp}
+
+On all recent Intel systems, coreboot support has revolved around
+integrating a blob (for each system) called the *FSP* (firmware support
+package), which handles all of the hardware initialization, including
+memory and CPU initialization. Reverse engineering and replacing this
+blob is almost impossible, due to how complex it is. Even for the most
+skilled developer, it would take years to replace. Intel distributes
+this blob to firmware developers, without source.
+
+Since the FSP is responsible for the early hardware initialization, that
+means it also handles SMM (System Management Mode). This is a special
+mode that operates below the operating system level. **It's possible
+that rootkits could be implemented there, which could perform a number
+of attacks on the user (the list is endless). Any Intel system that has
+the proprietary FSP blob cannot be trusted at all.** In fact, several
+SMM rootkits have been demonstrated in the wild (use a search engine to
+find them).
+
+### CPU microcode updates {#microcode}
+
+All modern x86 CPUs (from Intel and AMD) use what is called *microcode*.
+CPUs are extremely complex, and difficult to get right, so the circuitry
+is designed in a very generic way, where only basic instructions are
+handled in hardware. Most of the instruction set is implemented using
+microcode, which is low-level software running inside the CPU that can
+specify how the circuitry is to be used, for each instruction. The
+built-in microcode is part of the hardware, and read-only. Both the
+circuitry and the microcode can have bugs, which could cause reliability
+issues.
+
+Microcode *updates* are proprietary blobs, uploaded to the CPU at boot
+time, which patches the built-in microcode and disables buggy parts of
+the CPU to improve reliability. In the past, these updates were handled
+by the operating system kernel, but on all recent systems it is the boot
+firmware that must perform this task. Coreboot does distribute microcode
+updates for Intel and AMD CPUs, but libreboot cannot, because the whole
+point of libreboot is to be 100% [free
+software](https://www.gnu.org/philosophy/free-sw.html).
+
+On some older Intel CPUs, it is possible to exclude the microcode
+updates and not have any reliability issues in practise. All current
+libreboot systems work without microcode updates (otherwise, they
+wouldn't be supported in libreboot). However, all modern Intel CPUs
+require the microcode updates, otherwise the system will not boot at
+all, or it will be extremely unstable (memory corruption, for example).
+
+Intel CPU microcode updates are *signed*, which means that you could not
+even run a modified version, even if you had the source code. If you try
+to upload your own modified updates, the CPU will reject them.
+
+The microcode updates alter the way instructions behave on the CPU. That
+means they affect the way the CPU works, in a very fundamental way. That
+makes it software. The updates are proprietary, and are software, so we
+exclude them from libreboot. The microcode built into the CPU already is
+not so much of an issue, since we can't change it anyway (it's
+read-only).
+
+### Intel is uncooperative 
+
+For years, coreboot has been struggling against Intel. Intel has been
+shown to be extremely uncooperative in general. Many coreboot
+developers, and companies, have tried to get Intel to cooperate; namely,
+releasing source code for the firmware components. Even Google, which
+sells millions of *chromebooks* (coreboot preinstalled) have been unable
+to persuade them.
+
+Even when Intel does cooperate, they still don't provide source code.
+They might provide limited information (datasheets) under strict
+corporate NDA (non-disclosure agreement), but even that is not
+guaranteed. Even ODMs and IBVs can't get source code from Intel, in
+most cases (they will just integrate the blobs that Intel provides).
+
+Recent Intel graphics chipsets also [require firmware
+blobs](https://01.org/linuxgraphics/intel-linux-graphics-firmwares?langredirect=1).
+
+Intel is [only going to get
+worse](https://www.phoronix.com/scan.php?page=news_item&px=Intel-Gfx-GuC-SLPC)
+when it comes to user freedom. Libreboot has no support recent Intel
+platforms, precisely because of the problems described above. The only
+way to solve this is to get Intel to change their policies and to be
+more friendly to the [free
+software](https://www.gnu.org/philosophy/free-sw.html) community.
+Reverse engineering won't solve anything long-term, unfortunately, but
+we need to keep doing it anyway. Moving forward, Intel hardware is a
+non-option unless a radical change happens within Intel.
+
+**Basically, all Intel hardware from year 2010 and beyond will never be
+supported by libreboot. The libreboot project is actively ignoring all
+modern Intel hardware at this point, and focusing on alternative
+platforms.**
+
+Why is the latest AMD hardware unsupported in libreboot? {#amd}
+----------------------------------------------------------------------------
+
+It is extremely unlikely that any post-2013 AMD hardware will ever be
+supported in libreboot, due to severe security and freedom issues; so
+severe, that *the libreboot project recommends avoiding all modern AMD
+hardware. If you have an AMD based system affected by the problems
+described below, then you should get rid of it as soon as possible*. The
+main issues are as follows:
+
+[We call on AMD to release source code and specs for the new AMD Ryzen
+platforms! We call on the community to put pressure on AMD. Click here
+to read more](amd-libre.md)
+
+### AMD Platform Security Processor (PSP) 
+
+This is basically AMD's own version of the [Intel Management
+Engine](#intelme). It has all of the same basic security and freedom
+issues, although the implementation is wildly different.
+
+The Platform Security Processor (PSP) is built in on all Family 16h +
+systems (basically anything post-2013), and controls the main x86 core
+startup. PSP firmware is cryptographically signed with a strong key
+similar to the Intel ME. If the PSP firmware is not present, or if the
+AMD signing key is not present, the x86 cores will not be released from
+reset, rendering the system inoperable.
+
+The PSP is an ARM core with TrustZone technology, built onto the main
+CPU die. As such, it has the ability to hide its own program code,
+scratch RAM, and any data it may have taken and stored from the
+lesser-privileged x86 system RAM (kernel encryption keys, login data,
+browsing history, keystrokes, who knows!). To make matters worse, the
+PSP theoretically has access to the entire system memory space (AMD
+either will not or cannot deny this, and it would seem to be required to
+allow the DRM "features" to work as intended), which means that it has
+at minimum MMIO-based access to the network controllers and any other
+PCI/PCIe peripherals installed on the system.
+
+In theory any malicious entity with access to the AMD signing key would
+be able to install persistent malware that could not be eradicated
+without an external flasher and a known good PSP image. Furthermore,
+multiple security vulnerabilities have been demonstrated in AMD firmware
+in the past, and there is every reason to assume one or more zero day
+vulnerabilities are lurking in the PSP firmware. Given the extreme
+privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities
+would have the ability to remotely monitor and control any PSP enabled
+machine completely outside of the user's knowledge.
+
+Much like with the Intel Boot Guard (an application of the Intel
+Management Engine), AMD's PSP can also act as a tyrant by checking
+signatures on any boot firmware that you flash, making replacement boot
+firmware (e.g. libreboot, coreboot) impossible on some boards. Early
+anecdotal reports indicate that AMD's boot guard counterpart will be
+used on most OEM hardware, disabled only on so-called "enthusiast"
+CPUs.
+
+### AMD IMC firmware 
+
+Read <https://www.coreboot.org/AMD_IMC>.
+
+### AMD SMU firmware 
+
+Handles some power management for PCIe devices (without this, your
+laptop will not work properly) and several other power management
+related features.
+
+The firmware is signed, although on older AMD hardware it is a symmetric
+key, which means that with access to the key (if leaked) you could sign
+your own modified version and run it. Rudolf Marek (coreboot hacker)
+found out how to extract this key [in this video
+demonstration](https://media.ccc.de/v/31c3_-_6103_-_en_-_saal_2_-_201412272145_-_amd_x86_smu_firmware_analysis_-_rudolf_marek),
+and based on this work, Damien Zammit (another coreboot hacker)
+[partially replaced it](https://github.com/zamaudio/smutool/) with free
+firmware, but on the relevant system (ASUS F2A85-M) there were still
+other blobs present (Video BIOS, and others) preventing the hardware
+from being supported in libreboot.
+
+### AMD AGESA firmware 
+
+This is responsible for virtually all core hardware initialization on
+modern AMD systems. In 2011, AMD started cooperating with the coreboot
+project, releasing this as source code under a free license. In 2014,
+they stopped releasing source code and started releasing AGESA as binary
+blobs instead. This makes AGESA now equivalent to [Intel FSP](#fsp).
+
+### AMD CPU microcode updates 
+
+Read the Intel section 
+practically the same, though it was found with much later hardware in
+AMD that you could run without microcode updates. It's unknown whether
+the updates are needed on all AMD boards (depends on CPU).
+
+### AMD is incompetent (and uncooperative) 
+
+AMD seemed like it was on the right track in 2011 when it started
+cooperating with and releasing source code for several critical
+components to the coreboot project. It was not to be. For so-called
+economic reasons, they decided that it was not worth the time to invest
+in the coreboot project anymore.
+
+For a company to go from being so good, to so bad, in just 3 years,
+shows that something is seriously wrong with AMD. Like Intel, they do
+not deserve your money.
+
+Given the current state of Intel hardware with the Management Engine, it
+is our opinion that all performant x86 hardware newer than the AMD
+Family 15h CPUs (on AMD's side) or anything post-2009 on Intel's side
+is defective by design and cannot safely be used to store, transmit, or
+process sensitive data. Sensitive data is any data in which a data
+breach would cause significant economic harm to the entity which created
+or was responsible for storing said data, so this would include banks,
+credit card companies, or retailers (customer account records), in
+addition to the "usual" engineering and software development firms.
+This also affects whistleblowers, or anyone who needs actual privacy and
+security.
+
+What *can* I use, then? {#whatcaniuse}
+-------------------------
+
+Libreboot has support for fam15h AMD hardware (~2012 gen) and some
+older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport (2004-2006).
+We also have support for some
+ARM chipsets (rk3288). On the Intel side, we're also interested in some
+of the chipsets that use Atom CPUs (rebranded from older chipsets,
+mostly using ich7-based southbridges).
+
+Will libreboot work on a ThinkPad T400 or T500 with an ATI GPU?
+---------------------------------------------------------------------------------------------------
+
+Short answer: yes. These laptops also have an Intel GPU inside, which
+libreboot uses. The ATI GPU is ignored by libreboot.
+
+These laptops use what is called *switchable graphics*, where it will
+have both an Intel and ATI GPU. Coreboot will allow you to set (using
+nvramtool) a parameter, specifying whether you would like to use Intel
+or ATI. The ATI GPU lacks free native graphics initialization in
+coreboot, unlike the Intel GPU.
+
+Libreboot modifies coreboot, in such a way where this nvramtool setting
+is ignored. Libreboot will just assume that you want to use the Intel
+GPU. Therefore, the ATI GPU is completely disabled on these laptops.
+Intel is used instead, with the free native graphics initialization
+(VBIOS replacement) that exists in coreboot.
+
+Will desktop/server hardware be supported?
+------------------------------------------------------------------------
+
+Libreboot now supports desktop hardware:
+[(see list)](../docs/hardware/#supported_desktops_x86/intel)
+(with full native video initialization).
+
+A common issue with desktop hardware is the Video BIOS, when no onboard
+video is present, since every video card has a different Video BIOS.
+Onboard GPUs also require one, so those still have to be replaced with
+free software (non-trivial task). Libreboot has to initialize the
+graphics chipset, but most graphics cards lack a free Video BIOS for
+this purpose. Some desktop motherboards supported in coreboot do have
+onboard graphics chipsets, but these also require a proprietary Video
+BIOS, in most cases.
+
+Hi, I have &lt;insert random system here&gt;, is it supported?
+--------------------------------------------------------------------------------------------------------
+
+Most likely not. First, you must consult coreboot's own hardware
+compatibility list at <http://www.coreboot.org/Supported_Motherboards>
+and, if it is supported, check whether it can run without any
+proprietary blobs in the ROM image. If it can: wonderful! Libreboot can
+support it, and you can add support for it. If not, then you will need
+to figure out how to reverse engineer and replace (or remove) those
+blobs that do still exist, in such a way where the system is still
+usable in some defined way.
+
+For those systems where no coreboot support exists, you must first port
+it to coreboot and, if it can then run without any blobs in the ROM
+image, it can be added to libreboot. See: [Motherboard Porting
+Guide](http://www.coreboot.org/Motherboard_Porting_Guide) (this is just
+the tip of the iceberg!)
+
+Please note that board development should be done upstream (in coreboot)
+and merged downstream (into libreboot). This is the correct way to do
+it, and it is how the libreboot project is coordinated so as to avoid
+too much forking of the coreboot source code.
+
+What about ARM?
+-----------------------------------
+
+Libreboot has support for some ARM based laptops, using the *Rockchip
+RK3288* SoC. Check the libreboot [hardware compatibility
+list](../docs/hardware/#supported_list), for more information.
+
+General questions
+=================
+
+How do I install libreboot?
+-------------------------------------------------------
+
+See [installation guide](docs/install/)
+
+How do I program an SPI flash chip?
+---------------------------------------------------------------------------------
+
+SPI flash chips can be programmed with the [BeagleBone
+Black](../docs/install/bbb_setup.md) or the [Raspberry
+Pi](../docs/install/rpi_setup.md).
+
+It's possible to use a 16-pin SOIC test clip on an 8-pin SOIC chip, if you
+align the pins properly. The connection is generally more sturdy.
+
+How do I set a boot password?
+-------------------------------------------------------------------
+
+If you are using the GRUB payload, you can add a username and password
+(salted, hashed) to your GRUB configuration that resides inside the
+flash chip. The following guides (which also cover full disk encryption,
+including the /boot/ directory) show how to set a boot password in GRUB:
+[(Installing Debian or Devuan with FDE)](../docs/gnulinux/encrypted_debian.md)
+and
+[(Installing Parabola or Arch GNU+Linux-Libre, with FDE)](../docs/gnulinux/encrypted_parabola.md)
+
+How do I write-protect the flash chip?
+----------------------------------------------------------------------------
+
+By default, there is no write-protection on a libreboot system. This is
+for usability reasons, because most people do not have easy access to an
+external programmer for re-flashing their firmware, or they find it
+inconvenient to use an external programmer.
+
+On some systems, it is possible to write-protect the firmware, such that
+it is rendered read-only at the OS level (external flashing is still
+possible, using dedicated hardware). For example, on current GM45
+laptops (e.g. ThinkPad X200, T400), you can write-protect (see
+[ICH9 gen utility](../docs/hardware/gm45_remove_me.html#ich9gen)).
+
+It's possible to write-protect on all libreboot systems, but the instructions
+need to be written. The documentation is in the main git repository, so you are
+welcome to submit patches adding these instructions.
+
+How do I change the BIOS settings?
+------------------------------------------------------------------------
+
+Libreboot actually uses the [GRUB
+payload](http://www.coreboot.org/GRUB2). More information about payloads
+can be found at
+[coreboot.org/Payloads](http://www.coreboot.org/Payloads).
+
+Libreboot inherits the modular payload concept from coreboot, which
+means that pre-OS bare-metal *BIOS setup* programs are not very
+practical. Coreboot (and libreboot) does include a utility called
+*nvramtool*, which can be used to change some settings. You can find
+nvramtool under *coreboot/util/nvramtool/*, in the libreboot source
+archives.
+
+The *-a* option in nvramtool will list the available options, and *-w*
+can be used to change them. Consult the nvramtool documentation on the
+coreboot wiki for more information.
+
+In practise, you don't need to change any of those settings, in most
+cases.
+
+Libreboot locks the CMOS table, to ensure consistent functionality for
+all users. You can use:
+
+    $ nvramtool -C yourrom.rom -w somesetting=somevalue
+
+This will change the default inside that ROM image, and then you can
+re-flash it.
+
+Do I need to install a bootloader when installing a distribution?
+---------------------------------------------------------------------------------------------------
+
+Libreboot integrates the GRUB bootloader already, as a
+*[payload](http://www.coreboot.org/Payloads)*. This means that the GRUB
+bootloader is actually *flashed*, as part of the boot firmware
+(libreboot). This means that you do not have to install a boot loader on
+the HDD or SSD, when installing a new distribution. You'll be able to
+boot just fine, using the bootloader (GRUB) that is in the flash chip.
+
+This also means that even if you remove the HDD or SSD, you'll still
+have a functioning bootloader installed which could be used to boot a
+live distribution installer from a USB flash drive. See
+[How to install GNU+Linux on a libreboot system](../docs/gnulinux/grub_boot_installer.md)
+
+Do I need to re-flash when I re-install a distribution?
+-------------------------------------------------------------------------------------------
+
+Not anymore. Recent versions of libreboot (using the GRUB payload) will
+automatically switch to a GRUB configuration on the HDD or SSD, if it
+exists. You can also load a different GRUB configuration, from any kind
+of device that is supported in GRUB (such as a USB flash drive). For
+more information, see
+[Modifying the GRUB Configuration in Libreboot Systems](../docs/gnulinux/grub_cbfs.md)
+
+What does a flash chip look like?
+-----------------------------------------------------------------
+
+SOIC-8 SPI flash chip:
+
+![SOIT-8 SPI flash chip](images/soic8.jpg)
+
+SOIC-16 SPI flash chip:
+
+![SOIT-8 SPI flash chip](images/soic16.jpg)
+
+Who did the logo?
+----------------------------------------------------------------
+
+See the [license information](logo/license.md).
+
+The Libreboot logo is available as a [bitmap](logo/logo.png), a
+[vector](logo/logo.svg), or a [greyscale vector](logo/logo_grey.svg).
+
+Libreboot Inside stickers are available as a
+[PDF](logo/stickers/libreboot-inside-simple-bold-1.60cmx2.00cm-diecut-3.pdf) or
+a
+[vector](logo/stickers/libreboot-inside-simple-bold-1.60cmx2.00cm-diecut-3.svg)
+
+What other firmware exists outside of libreboot?
+==================================================
+
+The main freedom issue on any system, is the boot firmware (usually
+referred to as a BIOS or UEFI). Libreboot replaces the boot firmware
+with fully free code, but even with libreboot, there may still be other
+hardware components in the system (e.g. laptop) that run their own
+dedicated firmware, sometimes proprietary. These are on secondary
+processors, where the firmware is usually read-only, written for very
+specific tasks. While these are unrelated to libreboot, technically
+speaking, it makes sense to document some of the issues here.
+
+Note that these issues are not unique to libreboot systems. They apply
+universally, to most systems. The issues described below are the most
+common (or otherwise critical).
+
+Dealing with these problems will most likely be handled by a separate
+project.
+
+### External GPUs
+
+The Video BIOS is present on most video cards. For integrated graphics,
+the VBIOS (special kind of OptionROM) is usually embedded
+in the main boot firmware. For external graphics, the VBIOS is
+usually on the graphics card itself. This is usually proprietary; the
+only difference is that SeaBIOS can execute it (alternatively, you embed it
+in a coreboot ROM image and have coreboot executes it, if you use a
+different payload, such as GRUB).
+
+On current libreboot systems, instead of VBIOS, coreboot native GPU init is used,
+which is currently only implemented for Intel GPUs.
+Other cards with proper KMS drivers can be initialized once Linux boots,
+but copy of VBIOS may be still needed to fetch proper VRAM frequency
+and other similar parameters (without executing VBIOS code).
+
+In configurations where SeaBIOS and native GPU init are used together,
+a special shim VBIOS is added that uses coreboot linear framebuffer.
+
+
+### EC (embedded controller) firmware 
+
+Most (all?) laptops have this. The EC (embedded controller) is a small,
+separate processor that basically processes inputs/outputs that are
+specific to laptops. For example:
+
+-   When you flick the radio on/off switch, the EC will enable/disable
+    the wireless devices (wifi, bluetooth, etc) and enable/disable an
+    LED that indicates whether it's turned on or not
+-   Listen to another chip that produces temperature readings, adjusting
+    fan speeds accordingly (or turning the fan(s) on/off).
+-   Takes certain inputs from the keyboard, e.g. brightness up/down,
+    volume up/down.
+-   Detect when the lid is closed or opened, and send a signal
+    indicating this.
+-   Etc.
+
+Alexander Couzens from coreboot (lynxis on coreboot IRC) is working on a
+free EC firmware replacement for the ThinkPads that are supported in
+libreboot. See: <https://github.com/lynxis/h8s-ec> (not ready yet).
+
+Most (all?) chromebooks have free EC firmware. Libreboot is currently
+looking into supporting a few ARM-based chromebooks.
+
+EC is present on nearly all laptops. Other devices use, depending on complexity,
+either EC or variant with firmware in Mask ROM - SuperIO.
+
+### HDD/SSD firmware 
+
+HDDs and SSDs have firmware in them, intended to handle the internal
+workings of the device while exposing a simple, standard interface (such
+as AHCI/SATA) that the OS software can use, generically. This firmware
+is transparent to the user of the drive.
+
+HDDs and SSDs are quite complex, and these days contain quite complex
+hardware which is even capable of running an entire operating system (by
+this, we mean that the drive itself is capable of running its own
+embedded OS), even GNU+Linux or BusyBox/Linux.
+
+SSDs and HDDs are a special case, since they are persistent storage
+devices as well as computers.
+
+Example attack that malicious firmware could do: substitute your SSH
+keys, allowing unauthorized remote access by an unknown adversary. Or
+maybe substitute your GPG keys. SATA drives can also have DMA (through
+the controller), which means that they could read from system memory;
+the drive can have its own hidden storage, theoretically, where it could
+read your LUKS keys and store them unencrypted for future retrieval by
+an adversary.
+
+With proper IOMMU and use of USB instead of SATA, it might be possible
+to mitigate any DMA-related issues that could arise.
+
+Some proof of concepts have been demonstrated. For HDDs:
+<https://spritesmods.com/?art=hddhack&page=1> For SSDs:
+<http://www.bunniestudios.com/blog/?p=3554>
+
+Viable free replacement firmware is currently unknown to exist. For
+SSDs, the
+[OpenSSD](http://www.openssd-project.org/wiki/The_OpenSSD_Project)
+project may be interesting.
+
+Apparently, SATA drives themselves don't have DMA but can make use of
+it through the controller. This
+<http://www.lttconn.com/res/lttconn/pdres/201005/20100521170123066.pdf>
+(pages 388-414, 420-421, 427, 446-465, 492-522, 631-638) and this
+<http://www.intel.co.uk/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1_3.pdf>
+(pages 59, 67, 94, 99).
+
+The following is based on discussion with Peter Stuge (CareBear\\) in
+the coreboot IRC channel on Friday, 18 September 2015, when
+investigating whether the SATA drive itself can make use of DMA. The
+following is based on the datasheets linked above:
+
+According to those linked documents, FIS type 39h is *"DMA Activate FIS
+- Device to Host"*. It mentions *"transfer of data from the host to
+the device, and goes on to say: Upon receiving a DMA Activate, if the
+host adapter's DMA controller has been programmed and armed, the host
+adapter shall initiate the transmission of a Data FIS and shall transmit
+in this FIS the data corresponding to the host memory regions indicated
+by the DMA controller's context."* FIS is a protocol unit (Frame
+Information Structure). Based on this, it seems that a drive can tell
+the host controller that it would like for DMA to happen, but unless the
+host software has already or will in the future set up this DMA transfer
+then nothing happens. **A drive can also send DMA Setup**. If a DMA
+Setup FIS is sent first, with the Auto-Activate bit set, then it is
+already set up, and the drive can initiate DMA. The document goes on to
+say *"Upon receiving a DMA Setup, the receiver of the FIS shall
+validate the received DMA Setup request."* - in other words, the host
+is supposed to validate; but maybe there's a bug there. The document
+goes on to say *"The specific implementation of the buffer identifier
+and buffer/address validation is not specified"* - so noone will
+actually bother. *"the receiver of the FIS"* - in the case we're
+considering, that's the host controller hardware in the chipset and/or
+the kernel driver (most likely the kernel driver). All SATA devices have
+flash-upgradeable firmware, which can usually be updated by running
+software in your operating system; **malicious software running as root
+could update this firmware, or the firmware could already be
+malicious**. Your HDD or SSD is the perfect place for a malicious
+adversary to install malware, because it's a persistent storage device
+as well as a computer.
+
+Based on this, it's safe to say that use of USB instead of SATA is
+advisable if security is a concern. USB 2.0 has plenty of bandwidth for
+many HDDs (a few high-end ones can use more bandwidth than USB 2.0 is
+capable of), but for SSDs it might be problematic (unless you're using
+USB 3.0, which is not yet usable in freedom. See
+
+Use of USB is also not an absolute guarantee of safety, so do beware.
+The attack surface becomes much smaller, but a malicious drive could
+still attempt a "fuzzing" attack (e.g. sending malformed USB
+descriptors, which is how the tyrant DRM on the Playstation 3 was
+broken, so that users could run their own operating system and run
+unsigned code). (you're probably safe, unless there's a security flaw
+in the USB library/driver that your OS uses. USB is generally considered
+one of the safest protocols, precisely because USB devices have no DMA)
+
+Other links:
+
+-   <http://motherboard.vice.com/read/the-nsas-undetectable-hard-drive-hack-was-first-demonstrated-a-year-ago>
+
+It is recommended that you use full disk encryption, on HDDs connected
+via USB. There are several adapters available online, that allow you to
+connect SATA HDDs via USB. Libreboot documents how to install several
+distributions with full disk encryption. You can adapt these for use
+with USB drives:
+
+-   [Full disk encryption with Debian](../docs/gnulinux/encrypted_debian.md)
+-   [Full disk encryption with Parabola](../docs/gnulinux/encrypted_parabola.md)
+
+The current theory (unproven) is that this will at least prevent
+malicious drives from wrongly manipulating data being read from or
+written to the drive, since it can't access your LUKS key if it's only
+ever in RAM, provided that the HDD doesn't have DMA (USB devices don't
+have DMA). The worst that it could do in this case is destroy your data.
+Of course, you should make sure never to put any keyfiles in the LUKS
+header. **Take what this paragraph says with a pinch of salt. This is
+still under discussion, and none of this is proven.**
+
+### NIC (ethernet controller) 
+
+Ethernet NICs will typically run firmware inside, which is responsible
+for initializing the device internally. Theoretically, it could be
+configured to drop packets, or even modify them.
+
+With proper IOMMU, it might be possible to mitigate the DMA-related
+issues. A USB NIC can also be used, which does not have DMA.
+
+### CPU microcode 
+
+Implements an instruction set. See 
+description. Here we mean microcode built in to the CPU. We are not
+talking about the updates supplied by the boot firmware (libreboot does
+not include microcode updates, and only supports systems that will work
+without it) Microcode can be very powerful. No proof that it's
+malicious, but it could theoretically
+
+There isn't really a way to solve this, unless you use a CPU which does
+not have microcode. (ARM CPUs don't, but most ARM systems require blobs
+for the graphics hardware at present, and typically have other things
+like soldered wifi which might require blobs)
+
+CPUs often on modern systems have a processor inside it for things like
+power management. ARM for example, has lots of these.
+
+### Sound card 
+
+Sound hardware (integrated or discrete) typically has firmware on it
+(DSP) for processing input/output. Again, a USB DAC is a good
+workaround.
+
+### Webcam 
+
+Webcams have firmware integrated into them that process the image input
+into the camera; adjusting focus, white balancing and so on. Can use USB
+webcam hardware, to work around potential DMA issues; integrated webcams
+(on laptops, for instance) are discouraged by the libreboot project.
+
+### USB host controller 
+
+Doesn't really apply to current libreboot systems (none of them have
+USB 3.0 at the moment), but USB 3.0 host controllers typically rely on
+firmware to implement the XHCI specification. Some newer coreboot ports
+also require this blob, if you want to use USB 3.0.
+
+This doesn't affect libreboot at the moment, because all current
+systems that are supported only have older versions of USB available.
+USB devices also don't have DMA (but the USB host controller itself
+does).
+
+With proper IOMMU, it might be possible to mitigate the DMA-related
+issues (with the host controller).
+
+### WWAN firmware 
+
+Some laptops might have a simcard reader in them, with a card for
+handling WWAN, connecting to a 3g/4g (e.g. GSM) network. This is the
+same technology used in mobile phones, for remote network access (e.g.
+internet).
+
+NOTE: not to be confused with wifi. Wifi is a different technology, and
+entirely unrelated.
+
+The baseband processor inside the WWAN chip will have its own embedded
+operating system, most likely proprietary. Use of this technology also
+implies the same privacy issues as with mobile phones (remote tracking
+by the GSM network, by triangulating the signal).
+
+On some laptops, these cards use USB (internally), so won't have DMA,
+but it's still a massive freedom and privacy issue. If you have an
+internal WWAN chip/card, the libreboot project recommends that you
+disable and (ideally, if possible) physically remove the hardware. If
+you absolutely must use this technology, an external USB dongle is much
+better because it can be easily removed when you don't need it, thereby
+disabling any external entities from tracking your location.
+
+Use of ethernet or wifi is recommended, as opposed to mobile networks,
+as these are generally much safer.
+
+On all current libreboot laptops, it is possible to remove the WWAN card
+and sim card if it exists. The WWAN card is next to the wifi card, and
+the sim card (if installed) will be in a slot underneath the battery, or
+next to the RAM.
+
+Operating Systems
+=================
+
+Can I use GNU+Linux?
+--------------------------------------------------
+
+Absolutely! It is well-tested in libreboot, and highly recommended. See
+[installing GNU+Linux](../docs/gnulinux/grub_boot_installer.md) and
+[booting GNU+Linux](../docs/gnulinux/grub_cbfs.md).
+
+Any recent distribution should work, as long as it uses KMS (kernel mode
+setting) for the graphics.
+
+Fedora won't boot? (may also be applicable to Redhat/CentOS)
+-----------------------------------------------------------
+
+On Fedora, by default the grub.cfg tries to boot linux in 16-bit mode. You
+just have to modify Fedora's GRUB configuration.
+Refer to [the GNU+Linux page](docs/gnulinux/index.md#fedora-wont-boot).
+
+
+Can I use BSD?
+----------------------------------
+
+Absolutely! Libreboot has native support for NetBSD, OpenBSD and LibertyBSD.
+Other distros are untested.
+
+See:
+[docs/bsd/](docs/bsd/)
+
+Are other operating systems compatible?
+-------------------------------------------------------------------
+
+Unknown. Probably not.
+
+Where can I learn more about electronics
+==========================================
+
+* Basics of soldering and rework by PACE  
+    Both series of videos are mandatory regardless of your soldering skill.
+    * [Basic Soldering](https://www.youtube.com/watch?v=vIT4ra6Mo0s&list=PL926EC0F1F93C1837)
+    * [Rework and Repair](https://www.youtube.com/watch?v=HKX-GBe_lUI&list=PL958FF32927823D12)
+* [edX course on basics of electronics](https://www.edx.org/course/circuits-and-electronics-1-basic-circuit-analysis)  
+    In most countries contents of this course is covered during
+    middle and high school. It will also serve well to refresh your memory
+    if you haven't used that knowledge ever since.
+* Impedance intro
+    * [Similiarities of Wave Behavior](https://www.youtube.com/watch?v=DovunOxlY1k)
+    * [Reflections in tranmission line](https://www.youtube.com/watch?v=y8GMH7vMAsQ)
+    * Stubs:
+        * [Wikipedia article on stubs](https://en.wikipedia.org/wiki/Stub_(electronics))
+        * [Polar Instruments article on stubs](http://www.polarinstruments.com/support/si/AP8166.html)  
+        With external SPI flashing we only care about unintended PCB stubs
+* Other YouTube channels with useful content about electronics
+    * [EEVblog](https://www.youtube.com/channel/UC2DjFE7Xf11URZqWBigcVOQ)
+    * [Louis Rossmann](https://www.youtube.com/channel/UCl2mFZoRqjw_ELax4Yisf6w)
+    * [mikeselectricstuff](https://www.youtube.com/channel/UCcs0ZkP_as4PpHDhFcmCHyA)
+    * [bigclive](https://www.youtube.com/channel/UCtM5z2gkrGRuWd0JQMx76qA)
+    * [ElectroBOOM](https://www.youtube.com/channel/UCJ0-OtVpF0wOKEqT2Z1HEtA)
+    * [Jeri Ellsworth](https://www.youtube.com/user/jeriellsworth/playlists)
+* Boardview files can be open with [OpenBoardview](https://github.com/OpenBoardView/OpenBoardView),
+which is free software under MIT license.
+
+Use of youtube-dl with mpv would be recommended for youtube links
+
+Lastly the most important message to everybody gaining this wonderful new hobby - [Secret to Learning Electronics](https://www.youtube.com/watch?v=xhQ7d3BK3KQ)