libreboot / lbwww (public) (License: Unspecified) (since 2023-04-11) (hash sha1)
libreboot website (markdown files). https://libreboot.org/
Clone URLs: https://rocketgit.com/user/libreboot/lbwww ssh://rocketgit@ssh.rocketgit.com/user/libreboot/lbwww git://git.rocketgit.com/user/libreboot/lbwww
25.04 master
List of commits:
Subject Hash Author Date (UTC)
fix oversight ceaaeb98d924d89fd91bda78300423348f48bf79 Leah Rowe 2025-01-13 14:50:27
expand other.md but shorten the intro e5d30675db4119269259b3c4539278639da28522 Leah Rowe 2025-01-13 13:37:18
simplify the skulls section in other.md 4702e167673363af0e63c0de51fbd220d7f45a55 Leah Rowe 2025-01-12 12:36:05
payloads, not "programs" 97b0fa3c600b3a2dc0446029c38a7d538078ab7c Leah Rowe 2025-01-12 04:20:27
link to coreboot build docs on other.md c278f8b5bf1fb020d9bec53c93c620aa1c9469c2 Leah Rowe 2025-01-12 02:05:08
more links ec57689078a54afe1c0ba5a73f3cdb3f4ce46759 Leah Rowe 2025-01-12 01:29:32
reparieren der deutschen homepage 572ea3bdc15b8a33016888333e731307f0edab57 Leah Rowe 2025-01-12 00:43:39
homepage: emphasize the coreboot distro aspect f78ee7861af3a6b930cf640d7dfce1942dad4a2b Leah Rowe 2025-01-12 00:34:05
add ownerboot to the other.md page 5afacd5138015b5115bf9d3d3d805f9eb26d3999 Leah Rowe 2025-01-11 23:22:13
tidy up the other.md page b5e0d96be580678ad6710e4c3259abd128ebb7bc Leah Rowe 2025-01-11 23:03:54
actual alphabetical order e94f06a744c0e98943e31d5b141c5cfbf9901ef5 Leah Rowe 2025-01-11 05:39:12
clarification 71e4a89c862158f0f78815c4972b7d948cfbf35e Leah Rowe 2025-01-11 05:01:08
add missing entry 0b7a136d733bb91f397ea230fc8903483e47ce12 Leah Rowe 2025-01-11 04:59:40
add page linking to other coreboot distros 3809609b3e2798108b89898e33fee11a50dbd205 Leah Rowe 2025-01-11 04:41:25
update images on translated home pages ba3ca8c23da22687772d8e4cd53a747dcba00977 Leah Rowe 2025-01-11 02:11:07
make "coreboot distro" a link to docs/maintain/ 8c678d515d76ad689de62af4a08ffcf9b5394181 Leah Rowe 2025-01-11 00:20:04
typo ee4aca89fc6d85f4729a7d3e687a193758799c16 Leah Rowe 2025-01-10 16:30:55
don't link 4bd184da81f24a2932d03f3181812e7ad5cdeb85 Leah Rowe 2025-01-10 16:29:21
acknowledgement aa98970a8891e3a3300a6fca1df3314f8e7dbdb3 Leah Rowe 2025-01-10 16:27:51
fix links again again d25c4185f053ffa924e4f14a55c7a09083d86a4c Leah Rowe 2025-01-10 16:01:01
Commit ceaaeb98d924d89fd91bda78300423348f48bf79 - fix oversight
i'm re-adding the most important information libreboot.org
currently lacks

Signed-off-by: Leah Rowe <leah@libreboot.org>
Author: Leah Rowe
Author date (UTC): 2025-01-13 14:50
Committer name: Leah Rowe
Committer date (UTC): 2025-01-13 14:50
Parent(s): e5d30675db4119269259b3c4539278639da28522
Signer:
Signing key:
Signing status: N
Tree: 312b7aa102e3c48e1dea94e5b934ff5dc739ffdd
File Lines added Lines deleted
site/news/policy.de.md 56 2
site/news/policy.md 53 2
site/news/policy.uk.md 53 2
File site/news/policy.de.md changed (mode: 100644) (index ca3be12..87d6ac6)
... ... exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
177 177
178 178 (Sam literally makes CPUs in his garage) (Sam literally makes CPUs in his garage)
179 179
180 Why?
181 ====
180 More detailed insight about microcode
181 =====================================
182
183 To be clear: it is preferable that microcode be free.
184 Not including CPU microcode updates is an absolute disaster for system
185 stability and security, so Libreboot *includes microcode updates by default, in
186 all modern release images, where possible to do so*.
187
188 The CPU already has microcode burned into mask ROM. The microcode configures
189 logic gates in the CPU, to implement an instruction set, via special *decoders*
190 which are fixed-function; it is not possible, for example, to implement a RISCV
191 ISA on an otherwise x86 processor. It is only possible for the microcode to
192 implement x86, or *broken* x86, and the default microcode is almost always
193 *broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
194 these processors.
195
196 These processors provide a way to supply microcode *updates*. These updates
197 are volatile, and consequently must be applied during every boot cycle. The
198 updates fix stability/reliability/security bugs, and their *absence*
199 is *technically incorrect*, so you are strongly advised to install them.
200 Examples of where these updates fix bugs: on ASUS KCMA-D8/KGPE-D16
201 and ThinkPad X200/T400/T500/W500/X200T/X200/R500/X301, the updates make
202 hardware-based virtualization (via `kvm`) completely stable, where it would
203 otherwise lead to a kernel panic. They allow those same thinkpads to be run with
204 high CPU usage and I/O (RAM usage), without crashing (otherwise, it's very
205 likely to encounter a kernel panic caused by a *Machine Check Exception*).
206
207 Not including these updates will result in an unstable/undefined state. Intel
208 themselves define which bugs affect which CPUs, and they define workarounds, or
209 provide fixes in microcode. Based on this, software such as the Linux kernel
210 can work around those bugs/quirks. Also, upstream versions of the Linux kernel
211 can update the microcode at boot time (however, it is recommend still to do it
212 from coreboot, for more stable memory controller initialization or “raminit”).
213 Similar can be said about AMD CPUs.
214
215 Once upon a time, Libreboot *excluded* microcode updates by default, but this
216 lead to broken behaviour. Here are some examples:
217
218 <https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdfec051cae41448e>
219
220 <https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc7e8736be0c9b51>
221
222 These patches revert *bug fixes* in coreboot, fixes that happen to break other
223 functionality but only when microcode updates are excluded. The most
224 technically correct solution is to *not* apply the above patches, and instead
225 supply microcode updates!
226
227 You *need* microcode updates, or you will have a broken CPU; broken, because
228 it literally behaves differently than it's supposed to, so software will have
229 unpredictable bugs that could even cause data corruption - or worse.
230
231 Why was this page written?
232 ==========================
233
234 Many of the topics discussed here are actually hotly contested, by different
235 sections of the free software movement. Libreboot has taken a firm stance.
182 236
183 237 Firstly, observe the following graphic: Firstly, observe the following graphic:
184 238
File site/news/policy.md changed (mode: 100644) (index dbb2661..59f9afb)
... ... exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
242 242
243 243 (Sam literally makes CPUs in his garage) (Sam literally makes CPUs in his garage)
244 244
245 Why?
246 ====
245 More detailed insight about microcode
246 =====================================
247
248 To be clear: it is preferable that microcode be free.
249 Not including CPU microcode updates is an absolute disaster for system
250 stability and security, so Libreboot *includes microcode updates by default, in
251 all modern release images, where possible to do so*.
252
253 The CPU already has microcode burned into mask ROM. The microcode configures
254 logic gates in the CPU, to implement an instruction set, via special *decoders*
255 which are fixed-function; it is not possible, for example, to implement a RISCV
256 ISA on an otherwise x86 processor. It is only possible for the microcode to
257 implement x86, or *broken* x86, and the default microcode is almost always
258 *broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
259 these processors.
260
261 These processors provide a way to supply microcode *updates*. These updates
262 are volatile, and consequently must be applied during every boot cycle. The
263 updates fix stability/reliability/security bugs, and their *absence*
264 is *technically incorrect*, so you are strongly advised to install them.
265 Examples of where these updates fix bugs: on ASUS KCMA-D8/KGPE-D16
266 and ThinkPad X200/T400/T500/W500/X200T/X200/R500/X301, the updates make
267 hardware-based virtualization (via `kvm`) completely stable, where it would
268 otherwise lead to a kernel panic. They allow those same thinkpads to be run with
269 high CPU usage and I/O (RAM usage), without crashing (otherwise, it's very
270 likely to encounter a kernel panic caused by a *Machine Check Exception*).
271
272 Not including these updates will result in an unstable/undefined state. Intel
273 themselves define which bugs affect which CPUs, and they define workarounds, or
274 provide fixes in microcode. Based on this, software such as the Linux kernel
275 can work around those bugs/quirks. Also, upstream versions of the Linux kernel
276 can update the microcode at boot time (however, it is recommend still to do it
277 from coreboot, for more stable memory controller initialization or “raminit”).
278 Similar can be said about AMD CPUs.
279
280 Once upon a time, Libreboot *excluded* microcode updates by default, but this
281 lead to broken behaviour. Here are some examples:
282
283 <https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdfec051cae41448e>
284
285 <https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc7e8736be0c9b51>
286
287 These patches revert *bug fixes* in coreboot, fixes that happen to break other
288 functionality but only when microcode updates are excluded. The most
289 technically correct solution is to *not* apply the above patches, and instead
290 supply microcode updates!
291
292 You *need* microcode updates, or you will have a broken CPU; broken, because
293 it literally behaves differently than it's supposed to, so software will have
294 unpredictable bugs that could even cause data corruption - or worse.
295
296 Why was this page written?
297 ==========================
247 298
248 299 Firstly, observe the following graphic: Firstly, observe the following graphic:
249 300
File site/news/policy.uk.md changed (mode: 100644) (index 5ab0b37..8832709)
... ... Libreboot вирішує цю ситуацію *суворо* та *принци
171 171
172 172 (Сем буквально виробляє процесори в своєму гаражі) (Сем буквально виробляє процесори в своєму гаражі)
173 173
174 Why?
175 ====
174 More detailed insight about microcode
175 =====================================
176
177 To be clear: it is preferable that microcode be free.
178 Not including CPU microcode updates is an absolute disaster for system
179 stability and security, so Libreboot *includes microcode updates by default, in
180 all modern release images, where possible to do so*.
181
182 The CPU already has microcode burned into mask ROM. The microcode configures
183 logic gates in the CPU, to implement an instruction set, via special *decoders*
184 which are fixed-function; it is not possible, for example, to implement a RISCV
185 ISA on an otherwise x86 processor. It is only possible for the microcode to
186 implement x86, or *broken* x86, and the default microcode is almost always
187 *broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
188 these processors.
189
190 These processors provide a way to supply microcode *updates*. These updates
191 are volatile, and consequently must be applied during every boot cycle. The
192 updates fix stability/reliability/security bugs, and their *absence*
193 is *technically incorrect*, so you are strongly advised to install them.
194 Examples of where these updates fix bugs: on ASUS KCMA-D8/KGPE-D16
195 and ThinkPad X200/T400/T500/W500/X200T/X200/R500/X301, the updates make
196 hardware-based virtualization (via `kvm`) completely stable, where it would
197 otherwise lead to a kernel panic. They allow those same thinkpads to be run with
198 high CPU usage and I/O (RAM usage), without crashing (otherwise, it's very
199 likely to encounter a kernel panic caused by a *Machine Check Exception*).
200
201 Not including these updates will result in an unstable/undefined state. Intel
202 themselves define which bugs affect which CPUs, and they define workarounds, or
203 provide fixes in microcode. Based on this, software such as the Linux kernel
204 can work around those bugs/quirks. Also, upstream versions of the Linux kernel
205 can update the microcode at boot time (however, it is recommend still to do it
206 from coreboot, for more stable memory controller initialization or “raminit”).
207 Similar can be said about AMD CPUs.
208
209 Once upon a time, Libreboot *excluded* microcode updates by default, but this
210 lead to broken behaviour. Here are some examples:
211
212 <https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdfec051cae41448e>
213
214 <https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc7e8736be0c9b51>
215
216 These patches revert *bug fixes* in coreboot, fixes that happen to break other
217 functionality but only when microcode updates are excluded. The most
218 technically correct solution is to *not* apply the above patches, and instead
219 supply microcode updates!
220
221 You *need* microcode updates, or you will have a broken CPU; broken, because
222 it literally behaves differently than it's supposed to, so software will have
223 unpredictable bugs that could even cause data corruption - or worse.
224
225 Why was this page written?
226 ==========================
176 227
177 228 Firstly, observe the following graphic: Firstly, observe the following graphic:
178 229
Hints:
Before first commit, do not forget to setup your git environment:
git config --global user.name "your_name_here"
git config --global user.email "your@email_here"

Clone this repository using HTTP(S):
git clone https://rocketgit.com/user/libreboot/lbwww

Clone this repository using ssh (do not forget to upload a key first):
git clone ssh://rocketgit@ssh.rocketgit.com/user/libreboot/lbwww

Clone this repository using git:
git clone git://git.rocketgit.com/user/libreboot/lbwww

You are allowed to anonymously push to this repository.
This means that your pushed commits will automatically be transformed into a merge request:
... clone the repository ...
... make some changes and some commits ...
git push origin main