misc/emulation: fix image path

Signed-off-by: Leah Rowe <info@minifree.org>

site.cfg

@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: CC0-1.0
 TITLE="Libreboot"
 DOMAIN="https://libreboot.org/"
 BLOGDIR="news/" # leave as empty string if you want the blog to be the homepage

site/contrib.md

@@ -196,33 +196,13 @@ systems.
 Joshua Gay
 ----------
 
-Joshua is former FSF staff.
+Joshua was in a position during 2014-2016 to help promote Libreboot in the
+media, in his capacity working for the employer he worked for at the time;
+I credit him specifically. Joshua was one of Libreboot's earliest supporters.
 
-Joshua helped with the early founding of the Libreboot project, in his capacity
-(at that time) as the FSF's licensing and compliance manager. It was his job to
-review products sent into to the FSF for review; the FSF has a certification
-program called *Respects Your Freedom* (RYF) where the FSF will promote your
-company's products if it comes with all Free Software.
-
-I, Leah Rowe, was initially just selling ThinkPad X60 laptops with regular
-coreboot on them, and this included CPU microcode updates. At the time, I didn't
-think much of that. Joshua contacted me, in his capacity at the FSF, and asked
-if I would be interested in the FSF's RYF program; I was very surprised that the
-FSF would take me seriously, and I said yes. This is what started the early
-work on Libreboot. Joshua showed me all the problems my products had, and from
-that, the solution was clear:
-
-Joshua used his media connections at the FSF to heavily promote my work, and
-on December 13th, 2013, the Libreboot project was born (but not called that).
-Joshua made sure that everyone knew what I was doing!
-
-A few months later, the name *Libreboot* was coined, and the domain name
-*libreboot.org* was registered. At that point, the Libreboot project (in early
-2014) was officially born. Once again, Joshua provided every bit of help he
-could, heavily promoting the project and he even wrote this article on the FSF
-website, announcing it:
-
-<https://web.archive.org/web/20171222063358/https://www.fsf.org/blogs/licensing/replace-your-proprietary-bios-with-libreboot>
+He made sure everyone knew what I was doing, and he taught me a *lot* about
+licensing; many of Libreboot's practises today are still based on his lessons,
+such as the pitfalls of GPL compliance and how to really audit everything.
 
 Klemens Nanni
 -------------
@@ -233,55 +213,17 @@ libreboot, and several tweaks to the build system.
 Lisa Marie Maginnis
 -------------------
 
-Lisa is a former sysadmin at the Free Software Foundation. In the early days of
-the project, she provided Leah with a lot of technical advice. She initially
-created Libreboot IRC channel, when Leah did not know how to
-use IRC, and also handed +F founder status to Leah for the channel. As an FSF
-sysadmin, it was Lisa's job to maintain a lot of the infrastructure used by
-Libreboot; at the time, mailing lists on the Savannah website were used by
-the Libreboot project. When Paul Kocialkowski was a member of the project in
-2016, she helped him get help from the FSF; he was the leader of the Replicant
-project at the time, which had funding from the FSF, and the FSF authorized him
-to use some of that funding for his work on Libreboot, thanks to Lisa's
-encouragement while she worked at the FSF.
+Lisa was one of Libreboot's early contributors to Libreboot. She personally
+helped me set up a lot of the early infrastructure, including things like IRC,
+mailing list and so on. She provided a lot of technical guidance, while working
+in a sysadmin job for a certain free software organisation; she was both a
+mentor and a friend.
 
-Lisa also stepped in when Leah Rowe missed her LibrePlanet 2016 talk. Leah was
-scheduled to do a talk about Libreboot, but didn't show up in time. Lisa, along
-with Patrick McDermott (former Libreboot developer, who was present at that
-conference) did the talk in Leah's place. The talk was never recorded, but the
-Free Software Foundation has these photos of that talk on their LibrePlanet
-website (the woman with the blue hair is Lisa, and the long-haired dude with the
-moustache is Patrick):
-
-<http://web.archive.org/web/20170319043913/https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>
-
-<http://web.archive.org/web/20170319043915/https://media.libreplanet.org/u/libreplanet/m/session-02-c-wide-png-libreplanet-2016-sessions/>
-
-Fun fact: Patrick is also the lead developer of ProteanOS, an FSF-endorsed
-embedded OS project: <http://proteanos.com/> (uses BusyBox and Linux-libre)
-
-Leah Rowe ran *2* LibrePlanet workshops; one in 2015 and another in 2016, while
-visiting Boston, MA, USA on both occasions to attend these conferences. These
-workshops were for Libreboot installations. People came to both workshops, to
-have Libreboot installed onto their computers. As FSF sysadmin, at that time,
-Lisa provided all of the infrastructure and equipment used at those workshops.
-Without her help, those workshops would have not been possible.
-
-When the ASUS KGPE-D16 mainboard (high-end server board) was ported to Libreboot,
-Leah, working with Timothy Pearson (the one who ported it), shared patches back
-and forth with Lisa around mid 2016, mostly raminit patches, to get the board
-running at the FSF offices. This work ultimately lead to a most wonderful
-achievement:
-
-The FSF and GNU websites now run on
-Librebooted ASUS KGPE-D16 based servers, on a fully free GNU+Linux distro. This
-means that the FSF now has full software freedom for their hosting infrastructure.
-
-The FSF also provides access to this infrastructure for many other projects
-(besides GNU projects).
-
-Lisa was a strong supporter of Libreboot in the very early days of the project,
-and her contributions were invaluable. I, Leah Rowe, owe her a debt of gratitude.
+She got me in touch with a lot of people, and at one point was instrumental in
+helping Paul Kocialkowski secure funding to work on the Veyron Speedy boards
+in Libreboot, e.g. ASUS Chromebook C201PA - at the time, this was using
+Google's own Depthcharge payload, which you can find in 2016 Libreboot
+releases.
 
 Lorenzo Aloe
 ------------
@@ -316,10 +258,6 @@ relating to the [Intel Management Engine](../faq.md#intelme), in addition
 to making several improvements to the build system in libreboot. **Former
 libreboot project maintainer.**
 
-In 2016, Leah Rowe ran a Libreboot installation workshop at the FSF's
-LibrePlanet conference. Working alongside Leah, Patrick helped run the workshop
-and assisted with installing Libreboot onto people's machines.
-
 Paul Kocialkowski
 -----------------
 

site/contrib.uk.md

@@ -1,467 +0,0 @@
----
-title: Учасники проекту
-x-toc-enable: true
-...
-
-У цьому списку не обов'язково вказується, хто зараз працює над проектом,
-але в ньому вказано людей, які зробили значний внесок у проект.
-
-Якщо ми забули вас тут згадати, повідомте нам, і ми вас додамо. (або якщо
-ви не хочете, щоб вас згадували, повідомте нас, і ми видалимо ваш
-запис)
-
-Інформацію про те, хто працює над libreboot і як працює проект, можна
-знайти на цій сторінці: [who.md](who.md)
-
-Ви можете дізнатися історію проекту libreboot, просто прочитавши цю сторінку.
-Тут докладно розповідається про всі основні внески в проект і
-загалом про те, як створювався проект (і хто допоміг його створити).
-
-Лія Роу
----------
-
-**Засновник проекту Libreboot, а зараз провідний розробник** Лія
-працює над усіма аспектами libreboot, такими як:
-
-* Загальне керівництво. Лія обробляє всі зовнішні внески до libreboot,
-  переглядає пул реквести, має справу із звітами про помилки, делегує завдання, коли це необхідно
-  або бажано. Лія контролює серверну інфраструктуру libreboot.org, розміщену
-  в її лабораторії.
-* Лія має останнє слово щодо всіх рішень, беручи внесок через обговорення з
-  представниками громадськості, переважно на IRC. Лія контролює випуски libreboot
-  і загалом підтримує проект. Без Лії не було би Libreboot!
-* Система збірки (lbmk, скорочення від libreboot Make). Це автоматизована
-  система збирання, яка лежить в серці libreboot; він завантажує, патчить, налаштовує
-  та компілює відповідні компоненти, такі як coreboot, GRUB, і генерує образи ROM
-  libreboot, які ви можете знайти в архівах випусків.
-* Апстрім робота над coreboot, коли необхідно (та іншими проектами, які libreboot
-  використовує). Це також означає роботу з людьми поза межами проекту libreboot,
-  щоб об'єднати виправлення (між іншим) в апстрім проектах,
-  які libreboot використовує
-* Надання підтримки користувачів на IRC
-
-Калеб Ла Гранж
----------------
-
-**Вторинний розробник, номер два для Лії.** Калеб - розробник libreboot на повний робочий день
-з вузьким фокусом. Калеб зосереджується на кількох напрямках розвитку:
-
-* Система побудови. Калеб відповідає за вдосконалення та виправлення системи побудови libreboot Make.
-Зокрема, управління бінарними блобами, автоматизація та відтворюваність. 
-* Апаратна модифікація. Калеб має пристрасть до переробки апаратного забезпечення; паяння,
-розпаювання, та тестування libreboot на отриманому обладнанні.
-* Перенесення плати. Все, що підтримується в Coreboot, можна перенести на libreboot, Калеб
-перевірить і перенесе будь-яку плату, до якої зможе потрапити. Крім того, будь-хто може
-зв'язатись з Калебом, щоб створити образи libreboot для тестування на своїй платі.
-* Документація. Калеб активно веде документацію щодо зазначених вище сфер
-інтересу. Додатково, Калеб відповідає за посібники з розбирання з власними
-малюнками та діаграмами для кількох плат.
-* Підтримка користувачів. Калеб активний в irc і готовий допомогти будь-якому користувачеві, який зацікавлений в
-використанні libreboot або потребує допомоги.
-* Цілі проекту. Калеб співпрацює з Лією над визначенням цілей проекту.
-Лія має останнє слово в кожному рішенні.
-
-Зовнішні проекти
-================
-
-Проект Coreboot
-----------------
-
-Без coreboot проект libreboot був би просто неможливий.
-
-Людей і компаній, які працюють над coreboot, багато, і вони роблять
-проект libreboot таким, яким він є. Проект libreboot активно використовує coreboot
-для ініціалізації обладнання.
-
-GRUB
---------
-
-GRUB - це завантажувач, який використовується libreboot. Само собою зрозуміло, що
-розробники GRUB стимулюють libreboot своєю роботою.
-
-SeaBIOS
--------
-
-Прошивка libreboot надає SeaBIOS як опцію корисного навантаження. SeaBIOS забезпечує
-застарілу реалізацію BIOS x86.
-
-U-Boot
-------
-
-Libreboot використовує U-Boot як корисне навантаження coreboot на ноутбуках
-ARM Chromebook з підтримкою coreboot.
-
-Внески в алфавітному порядку
-============================
-
-Алісса Розенцвейг
------------------
-
-Переключила веб-сайт на використання розмітки замість рукописного HTML та користувацького
-PHP. **Колишній супроводжувач проекту libreboot (системний адміністратор libreboot.org).**
-
-Алісса написала оригінальний генератор статичних сайтів (скрипти `sh`, що перетворюють
-markdown в html, через pandoc) для libreboot.org. Цей генератор статичних сайтів
-був значно змінений і відгалужений Лією Роу у формальний проект:
-
-<https://untitled.vimuser.org/> (untitled - це робота Лії, а не Алісси, але вона базується на
-оригінальній роботі Аліси над генератором статичних сайтів, який раніше використовував Libreboot;
-веб-сайт Libreboot тепер створено за допомогою Untitled)
-
-Альпер Небі Ясак
-----------------
-
-Надав інтеграцію системи збірки та документацію для використання
-U-Boot в якості корисного навантаження, та початкові порти Libreboot деяких ARM Chromebook
-виходячи з того.
-
-Альпер також займається розробкою на U-Boot, напр. продовжив майже завершений
-порт плати `gru-kevin` і об'єднав його з апстрімом.
-
-Артур Хейманс
---------------
-
-Об'єднав патч із coreboot у libreboot, дозволяючи режимам живлення C3 та C4
-правильно працювати на ноутбуках GM45. Це була давня проблема до внеску
-Артура. Артур також виправив розмір відеопам'яті на i945 на системах
-GM45, що дозволило максимально розподілити VRAM для вбудованих графічних процесорів
-у цих системах, ще одна давня проблема в libreboot.
-
-Артур також працював над системою збірки Libreboot, коли він був учасником
-проекту. Він досі працює над coreboot, і Libreboot отримує велику
-користь від його роботи. Його внесок у проект coreboot і Libreboot
-неоціненний.
-
-Володимир Сербіненко
--------------------
-
-Перенес багато thinkpad, які підтримуються в libreboot, на coreboot, а
-також зробив багато виправлень у coreboot, які принесли користь проекту libreboot.
-
-Володимир написав багато вихідного коду ініціалізації відео, який використовується різними
-платформами Intel у Libreboot, під час прошивки (зараз переписаний
-іншими в Ada, для libgfxinit в coreboot, але спочатку він був написаний на
-C і включений безпосередньо в coreboot; libgfxinit є субмодуль третьої сторони).
-
-Демієн Замміт
--------------
-
-Підтримує порт coreboot Gigabyte GA-G41M-ES2L, інтегрований у
-libreboot. Також працює над іншим апаратним забезпеченням на користь
-проекту libreboot.
-
-Демієн не працював безпосередньо над самим Libreboot, але він багато працював з
-Лією Роу, інтегруючи патчі та нові порти плати в Libreboot на основі
-попередньої роботи Демієна над coreboot.
-
-Денис Каріклі
--------------
-
-На основі роботи, виконаної Пітером Стюджем, Володимиром Сербіненко та іншими
-в проекті coreboot, вдалось налагодити нативну ініціалізацію графіки для роботи
-на ThinkPad X60, що дозволяє підтримувати її в libreboot. Денис дав
-багато порад і допоміг створити проект libreboot.
-
-Денис був наставником Лії Роу в ранні дні, коли вона заснувала проект
-Libreboot. Багато прийнятих рішень, особливо щодо системи збірки
-Libreboot (lbmk), були натхненні розмовами з Денисом.
-
-Денис навчив Лію про регістри, які використовуються графічним процесором Intel для керування підсвічуванням.
-В ранні дні, ноутбуки ThinkPad X60 та T60 в Libreboot не мали працюючого
-контроля підсвічуванням, тому яскравість завжди була 100%. За допомогою Дениса,
-Лія змогла налаштувати керування підсвічуванням шляхом зворотньої розробки
-правильних значень для запису в ці регістри. На основі цього в coreboot
-було написано просте виправлення; однак виправлення перезаписувало безпосередньо регістр
-і не працювало з елементами керування яскравістю на основі ACPI. Інші в coreboot
-пізніше вдосконалили його, змусивши елементи керування підсвічуванням на основі ACPI працювати належним чином, на основі цієї
-попередньої роботи.
-
-Джерун Квінт
-------------
-
-Додав кілька виправлень до документації libreboot, пов'язаної зі
-встановленням Arch з повним дисковим шифруванням у системах libreboot.
-
-Джошуа Гей
-----------
-
-Джошуа колишній співробітник FSF.
-
-Джошуа допоміг із раннім заснуванням проекту Libreboot, будучи
-(на той час) менеджером з ліцензування та відповідності FSF. Його роботою було
-переглядати продукти, надіслані до FSF для перевірки; FSF має програму
-сертифікації, під назвою *Поважає Вашу Свободу* (Respects Your Freedom), за якою FSF рекламуватиме
-продукти вашої компанії, якщо вони постачаються з усім вільним програмним
-забезпеченням.
-
-Я, Лія Роу, спочатку просто продавала ноутбуки ThinkPad X60 із звичайним
-coreboot, і це включало оновлення мікрокоду ЦП. У той час
-я не дуже про це думала. Джошуа зв'язався зі мною, в своїх повноваженнях FSF, і спитав,
-чи зацікавить мене програма RYF FSF; Я була дуже здивована, що FSF
-сприйме мене серйозно, і я сказала так. Саме з цього почалася рання робота
-над Libreboot. Джошуа показав мені всі проблеми з моїми продуктами, і з
-цього, рішення було очевидним:
-
-Необхідно, щоб існував проект із повністю вільною версією coreboot без будь-яких
-бінарних блобів. У той час (і це актуально й сьогодні) coreboot не був
-повністю вільним програмним забезпеченням і за замовчуванням постачався з двійковими блобами. Зокрема,
-оновлення мікрокоду ЦП включено за замовчуванням на всіх машинах x86. Працюючи
-з Джошуа, я створила повністю вільну версію coreboot.
-Спочатку він не називався Libreboot, і робота була призначена виключно для моєї
-компанії (на той час вона називалася Gluglug), яку просувала FSF.
-
-Джошуа використовував свої медійні зв'язки в FSF, щоб активно рекламувати мою роботу, і
-13 грудня 2013 року народився проект Libreboot (але не названий так).
-Джошуа переконався, щоб всі знали, що я роблю!
-
-Через кілька місяців було створено назву *Libreboot* і зареєстровано доменне ім'я
-*libreboot.org*. У цей момент офіційно народився проект Libreboot (на початку
-2014 року). Знову Джошуа надав всю можливу допомогу,
-активно просуваючи проект, і навіть написав цю статтю на веб-сайті FSF
-оголосивши про це:
-
-<https://web.archive.org/web/20171222063358/https://www.fsf.org/blogs/licensing/replace-your-proprietary-bios-with-libreboot>
-
-Ендрю Роббінс
---------------
-
-Працював над великими частинами старої системи збірки Libreboot і пов'язаною документацією.
-Ендрю приєднався до проекту Libreboot як штатний розробник у червні 2017,
-до моменту свого відходу в березні 2021 року.
-
-Я, Лія Роу, дуже вдячна Ендрю Роббінсу за його численні внески
-протягом багатьох років.
-
-Клеменс Нанні
--------------
-
-Внесено багато виправлень і покращень у конфігурацію GRUB, яка використовується в
-libreboot, а також кілька змін у системі збірки.
-
-Ліза Марі Магінніс
--------------------
-
-Ліза - колишній системний адміністратор Free Software Foundation. На перших днях
-проекту вона давала Лії багато технічних порад. Спочатку вона створила
-IRC-канал Libreboot, коли Лія не знала, як користуватися
-IRC, а також передала +F статус засновника для каналу. Як системний
-адміністратор FSF, роботою Лізи було підтримувати велику частину інфраструктури,
-яку використовує Libreboot; на той час списки розсилки на веб-сайті Savannah
-використовувалися проектом Libreboot. Коли Пол Коціалковскі був
-учасником проекту в 2016 році, вона допомогла йому отримати допомогу від FSF; на той час він був
-керівником проекту Replicant, який фінансував FSF, і FSF дозволив
-йому використати частину цього фінансування для його роботи над Libreboot, завдяки Лізи
-підтримці, коли вона працювала у FSF.
-
-Ліза також втрутилася, коли Лія Роу пропустила виступ на LibrePlanet 2016. Лія мала
-виступити з доповіддю про Libreboot, але не з'явилася вчасно. Ліза разом
-із Патріком Макдермоттом (колишнім розробником Libreboot, який був присутній
-на тій конференції) виступили замість Лії. Розмова ніколи не була записана, але
-Фонд вільного програмного забезпечення має ці фотографії цієї розмови на веб-сайті LibrePlanet
-(жінка з блакитним волоссям - Ліза, а довговолосий хлопець із вусами -
-Патрік):
-
-<http://web.archive.org/web/20170319043913/https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>
-
-<http://web.archive.org/web/20170319043915/https://media.libreplanet.org/u/libreplanet/m/session-02-c-wide-png-libreplanet-2016-sessions/>
-
-Цікавий факт: Патрік також є провідним розробником ProteanOS, проекту вбудованої
-ОС, схваленого FSF: <http://proteanos.com/> (використовує BusyBox і Linux-libre)
-
-Лія Роу провела *2* семінари LibrePlanet; один у 2015 році та інший у 2016 році,
-відвідуючи Бостон, Массачусетс, США в обох випадках для участі в цих конференціях. Ці
-семінари стосувалися встановлення Libreboot. Люди приходили на обидва семінари, щоб
-встановити Libreboot на свої комп'ютери. Як системний адміністратор FSF, на той час,
-Ліза забезпечила всю інфраструктуру та обладнання, яке використовувалося на цих семінарах.
-Без її допомоги ці майстер-класи були б неможливими.
-
-Коли материнська плата ASUS KGPE-D16 (серверна плата високого класу) була перенесена на Libreboot,
-Лія, працюючи з Тімоті Пірсоном (той, хто її переніс),
-приблизно в середині 2016 року поділилася з Лізою виправленнями, в основному виправленнями raminit, щоб отримати плату, яка працює в офісах FSF. Ця робота
-зрештою призвела до чудового досягнення:
-
-Веб-сайти FSF і GNU тепер працюють на, з встановленим Libreboot,
-заснованих на ASUS KGPE-D16 серверах, на повністю вільному GNU+Linux дистрибутиві. Це
-означає, що FSF тепер має повну свободу програмного забезпечення для своєї
-інфраструктури хостингу.
-
-FSF також надає доступ до цієї інфраструктури для багатьох інших проектів
-(крім проектів GNU).
-
-Ліза була сильною прихильницею Libreboot на перших днях проекту,
-і її внесок був неоціненним. Я, Лія Роу, у боргу перед нею.
-
-Lorenzo Aloe
-------------
-
-Provided hardware testing for the [Dell OptiPlex 9020](docs/hardware/dell9020.md),
-also provided testing for proxmox with GPU passthrough on Dell Precision T1650,
-confirming near-native performance; with this, you can boot operating systems
-virtually natively, performance-wise, on a Libreboot system in cases where
-that OS is not natively supported.
-
-All round good guy, an honest and loyal fan.
-
-Маркус Мьоллер
---------------
-
-Зробив логотип libreboot.
-
-Nicholas Chin
--------------
-
-[Ported Dell Latitude E6400 to Libreboot](news/e6400.md).
-
-Патрік "П. Дж." Макдермотт
----------------------------
-
-Патрік також провів багато досліджень і написав розділ поширених запитань libreboot,
-пов'язаний із [Intel Management Engine](../faq.md#intelme), а також зробив кілька покращень у
-системі збірки libreboot. **Колишній супроводжувач проекту
-libreboot.**
-
-У 2016 році Лія Роу провела семінар зі встановлення Libreboot на конференції FSF
-LibrePlanet. Працюючи разом з Лією, Патрік допомагав вести семінар
-та допомагав установлювати Libreboot на комп'ютери людей.
-
-Пітер Стюдж
------------
-
-Допоміг написати [розділ поширених запитань про DMA](../faq.md#hddssd-firmware), та надав
-загальні поради на перших днях проекту. У той час Пітер був розробником coreboot
-і головним розробником проекту *libusb* (який flashrom
-активно використовує).
-NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
-now, as of 27 January 2024.
-
-Пітер також написав утиліту *bucts*, яка використовується для встановлення біта Top Swap
-(TS) для керування резервним копіюванням (BUC) на ноутбуках i945, таких як ThinkPad X60/T60, яка є корисною для
-обхідного шляху для прошивки Libreboot без використання зовнішнього обладнання; на цій машині,
-з Lenovo BIOS, можна перепрошити все, крім головного завантажувального
-блоку, але платформи Intel мають 2 завантажувальні блоки, і ви вказуєте, який із них
-використовувати, встановленням біта TS. Потім ви завантажуєтеся лише з одним прошитим завантажувальним блоком
-(завантажувальним блоком проекту coreboot на цій машині), а потім скидаєте
-bucts перед повторною прошивкою ROM, щоб прошити основний завантажувальний блок. Libreboot
-розміщує копію його роботи, оскільки його веб-сайт, на якому розміщено bucts,
-більше не відповідає.
-
-Пол Коціалковський
------------------
-
-Переніс ноутбуки Chromebook на основі ARM (Rockchip RK3288 SoC) до
-libreboot. Також один із головних розробників [Replicant](http://www.replicant.us/).
-
-Пол Менцель
------------
-
-Дослідив та виправив помилку в coreboot на ThinkPad X60/T60, яку виявляло
-ядро Linux 3.12 і новіших версій, через яку прискорення 3D не
-працювало, а відео загалом ставало нестабільним. Проблема полягала в тому, що
-coreboot під час ініціалізації відеочіпсета Intel, відображав *GTT Stolen Memory* в
-не тому місці, оскільки код базувався на коді ядра, а в ядрі Linux
-була така сама помилка. Коли Linux це виправив, він виявив ту саму помилку в coreboot.
-
-Пол працював над цим із Libreboot,
-періодично надсилаючи патчі для тестування, доки помилку не було виправлено
-в coreboot, а потім допоміг ій інтегрувати виправлення в libreboot.
-
-Riku Viitanen
--------------
-
-Added support for HP Elite 8200 SFF desktop PC to Libreboot. You can read
-about this in the hardware page:
-
-[HP Elite 8200 SFF](docs/hardware/hp8200sff.md)
-
-Стів Шентон
--------------
-
-Стів виконав першу роботу зі зворотньої розробки Intel Flash Descriptor, який використовується
-на машинах ICH9M, таких як ThinkPad X200. Він створив структуру C, що визначає (використовуючи
-бітові поля в C) цю область дескриптора. За допомогою деяких хитрих трюків він зміг
-виявити існування біта в дескрипторі для *вимкнення* Intel ME
-(management engine) на цих платформах.
-
-Його початкове підтвердження концепції визначило лише дескриптор, і зробило би це:
-
-* Читання дескриптора за замовчуванням і регіонів GbE з ROM Lenovo X200 (прошивка
-  за замовчуванням, не coreboot)
-* Вимкнення ME, встановивши 2 біти в дескрипторі
-* Вимкнення регіона ME
-* Переміщення дескриптора+GbE (загалом 12КБ) поруч
-* Виділення решти флеш-пам'яті для регіону BIOS
-* На основі цього створено 12КБ регіон дескриптор+область GBE для вставки
-  в образ ROM coreboot.
-
-У перші дні, до того, як Libreboot підтримував платформи GM45+ICH9M, такі як
-ThinkPad X200/T400, ви могли використовувати ці машини, але щоб уникнути
-Intel ME, вам доводилося виконувати прошивку без області дескриптора. У ті часи це працювало нормально,
-тому що ME обробляв лише TPM та AMT на цих машинах, і система
-працювала нормально, але Intel Flash Descriptor також обробляє область Intel GbE NVM
-у флеш-пам'яті, яка використовується для інтерфейсу Intel Gigabit Ethernet.
-
-Отже, ви або мали Intel ME, або не підтримували ethernet. Стів зрозумів, як
-вимкнути Intel ME за допомогою 2 бітів перемикання в дескрипторі, а також як видалити область
-Intel ME з флеш-пам'яті.
-
-Ґрунтуючись на його дослідженні, я, Лія Роу, працюючи разом зі Стівом, також виконала зворотню розробку
-області Intel GbE NVM (енергонезалежна пам'ять) у
-завантажувальній флеш-пам'яті. Цей регіон визначає параметри конфігурації для вбудованої мережевої карти Intel
-GbE, якщо присутня.
-
-На основі цього я змогла взяти початкове підтвердження концепції та написати
-утиліту `ich9gen`, яка генерує Intel Flash Descriptor та регіон GbE NVM,
-з нуля, без визначення регіону Intel ME. Саме цей інструмент,
-інструмент `ich9gen`, використовує Libreboot для надання образів ROM для GM45+ICH9M
-платформ (таких як ThinkPad X200/T400/T500/W500), із повнофункціональним
-дескриптором та функціональним Gigabit Ethernet, але *без* необхідності мікропрограми Intel
-Management Engine (ME), що робить ці машини *вільними* (ME
-повністю вимкнено, коли ви використовуєте образ дескриптора+gbe, створене `ich9gen`).
-
-З *моїм* інструментом `ich9gen` (інструмент Стіва називався `ich9deblob`), вам більше
-не потрібен був дамп оригінальної мікропрограми Lenovo BIOS! Я не могла би написати цей інструмент
-без первинного підтвердження концепції Стіва. Я працювала з ним
-протягом багатьох місяців. Вся GM45+ICH9M підтримка (X200, T400 і так далі) в
-Libreboot стала можливою завдяки його роботі у 2014 році.
-
-Тімоті Пірсон
----------------
-
-Перенес плату ASUS KGPE-D16 до coreboot для компанії Raptor
-Engineering, генеральним директором якої є Тімоті.
-Тімоті підтримує цей код у coreboot, допомогаючи проекту,
-з його інтеграцією з libreboot. Контактні
-дані цієї людини є на сайті raptor.
-
-**Підтримку D16 було припинено 19 листопада 2022 року. Ви все ще можете використовувати
-старіші версії Libreboot, і старіші випуски.**
-
-Swift Geek
-----------
-
-Додав патч для ich9gen для створення дескрипторів розміром 16MiB.
-
-Після цього Swift Geek повільно почав долучатися, поки не став розробником на повний
-робочий день. Внески Swift Geek насправді ніколи не були у формі *коду*,
-але те, що йому не вистачало в коді, він компенсував чудовою підтримкою як для користувачів,
-так і для інших розробників, допомагаючи іншим дізнатися більше про технології на
-низькому рівні.
-
-Коли Swift Geek був учасником проекту, його роль здебільшого полягала в
-наданні підтримки користувачам (на каналі IRC) і проведенні досліджень. Swift Geek знає
-багато про апаратне забезпечення. Swift Geek також зробив деяку апстрім розробку GRUB.
-
-Swift Geek неодноразово надавав технічні поради Лії Роу
-та допоміг їй покращити її навички паяння, а також навчив її
-деяким навичкам ремонту, до того моменту, коли вона тепер може виправляти більшість несправностей
-на материнських платах ThinkPad (під час перегляду схем та бордв'ю).
-
-Swiftgeek залишив проект у березні 2021 року. Я, Лія Роу, бажаю його всього найкращого в його
-починаннях і дуже вдячна за його численні внески протягом багатьох
-років.
-
-vitali64
---------
-
-Додав підтримку cstate 3 на macbook21, що забезпечує тривалий термін служби батареї
-та нижчу температуру процесора під час простою. vitali64 на irc

site/docs/build/index.md

@@ -25,37 +25,20 @@ libreboot from the available source code.
 The following document describes how `lbmk` works, and how you can make changes
 to it: [libreboot maintenance manual](../maintain/)
 
-Release status
-==============
-
-Information about status will be reported during builds; if a board is
-marked as stable, the build proceeds without further input. If the board is
-marked anything other, a warning appears asking if you wish to proceed; to
-disable these warnings, do this before building (not recommended):
-
-	export LBMK_STATUS=n
-
-In Libreboot, we specify: `stable`, `unstable`, `broken` or `untested`.
-The "unstable" marking means that the board boots mostly/entirely reliably
-annd should be safe to use, but may have a few issues, but nothing which would,
-for example, cause safety issues e.g. thermal, data reliability etc.
-
-The `broken` setting means that a given board will likely brick if flashed.
-The `untested` setting means untested.
-
-Release status is always set with regards to the current lbmk revision, on
-the theory that the current revision is being used to generate a full release.
-
 Multi-threaded builds
 =====================
 
 Libreboot's build system defaults to a single build thread, but you can change
 it by doing e.g.
 
-	export LBMK_THREADS=4
+	export XBMK_THREADS=4
 
 This would make lbmk run on 4 threads.
 
+More specifically: when compiling source trees via `script/trees`, `-jTHREADS`
+is passed, where THREADS is the number of threads. This is also set when running
+xz commands for compression, using the `-t` option.
+
 Environmental variables
 =======================
 

site/docs/hardware/dell9020.md

@@ -48,7 +48,7 @@ P*: Partially works with blobs
 
 | ***Features***                                    |    |
 |---------------------------------------------------|----|
-| **Internal flashing with original boot firmware** | ?  |
+| **Internal flashing with original boot firmware** | W+ |
 | **Display (if Intel GPU)**                        | W+ |
 | **Display (discrete CPU, SeaBIOS payload only)**  | W* |
 | **Audio**                                         | W+ |
@@ -66,7 +66,7 @@ Introduction
 **Unavailable in Libreboot 20240126 or earlier. You must [compile from
 source](../build/), or use a version newer than Libreboot 20240126**
 
-Official information about the laptop can be found here:
+Official information about this machine can be found here:
 <https://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/optiplex-9020-micro-technical-spec-sheet.pdf>
 
 Buy Libreboot preinstalled
@@ -143,18 +143,12 @@ NOTE2: Libreboot uses a *static option table* on all boards that have nvram,
 which is why you must use the `-C` option on your ROM, to change the static
 table that is baked into it.
 
-On current lbmk master, graphics cards *do* work. The option to hide PEG
-devices from MRC was disabled. Now when you insert a graphics card, the
-onboard Intel GPU is disabled and the graphics card is used instead.
-
 Here is an example of the type of errors we got when testing graphics cards
 with IOMMU enabled:
 
 <https://av.vimuser.org/error.jpg>
 
-We believe the native MRC replacement may work better on graphics card with
-IOMMU turned on. This will be enabled in a future Libreboot release, if not
-already supported.
+Make sure to configure your image accordingly.
 
 7020 compatibility
 ------------------
@@ -168,11 +162,11 @@ separate targets for MT and SFF.
 Build ROM image from source
 ---------------------------
 
-For the MT variant (7020 MT and 9020 SFF):
+For the MT variant (7020 MT and 9020 MT):
 
 	./build roms dell9020mt_12mb
 
-For the SFF variant (7020 MT and 7020 SFF):
+For the SFF variant (7020 SFF and 9020 SFF):
 
 	./build roms dell9020sff_12mb
 
@@ -206,6 +200,21 @@ Flash a ROM image (software)
 If you're already running Libreboot, and you don't have flash protection
 turned on, [internal flashing](../install/) is possible.
 
+Internal flashing can also be done with the original Dell BIOS, if the
+SERVICE_MODE jumper near the PCIe slots is installed. Before flashing,
+
+	rmmod spi-intel-platform
+
+needs to be run to prevent errors. Once Libreboot is installed, the
+SERVICE_MODE jumper can be removed.
+
+**Note: The Dell BIOS can write EFI variables to flash when shutting
+down, which could corrupt the newly flashed Libreboot ROM and render
+the system unusable. To prevent this, after flashing internally from
+the original Dell BIOS, remove power from the computer instead of
+shutting it down normally. It's recommended to use a live USB instead
+of the internal drive to prevent potential filesystem corruption.**
+
 Flash a ROM image (hardware)
 -----------------
 

site/docs/hardware/ga-g41m-es2l.md

@@ -17,7 +17,7 @@ GA-G41M-ES2L
                                         Pentium Extreme/D/4 Extreme/4/Celeron |
 | **Graphics**               | Integrated                                     |
 | **Display**                | None.                                          |
-| **Memory**                 | Up to 16GB                                     |
+| **Memory**                 | Up to 8GB (2x4GB DDR2-800)                     |
 | **Architecture**           | x86_64                                         |
 | **Original boot firmware** | AWARD BIOS                                     |
 | **Intel ME/AMD PSP**       | Present. Can be disabled                       |

site/docs/install/e6400.md

@@ -104,6 +104,19 @@ variants with Intel graphics.
 For Intel GPU variants, Libreboot 20230423 and up have full support. Simply
 flash a release ROM, if you wish.
 
+Intel GPU errata
+----------------
+
+Systems with a 1440 x 900 display panel instead of the more common 1280 x 800
+panel will have garbled graphics before the OS boots (i.e. in SeaBIOS or GRUB)
+in Libreboot 20240504 and earlier. This is fixed in releases after 20240504.
+
+This was caused by libgfxinit calculating PLL divider values for the pixel clock
+assuming a 96 MHz reference frequency, whereas the E6400 uses a 100 MHz
+reference frequency. The error is not large enough to affect the lower
+resolution panels, but is enough to affect the 1440 x 900 panels which use a
+higher pixel clock.
+
 Nvidia GPU: Video BIOS Option ROM required
 ==========================================
 
@@ -158,24 +171,6 @@ codeberg](https://codeberg.org/libreboot/lbmk/issues/14#issuecomment-907758).
 How to flash internally (no diassembly)
 =======================================
 
-Warning for BSD users
----------------------
-
-**NOTE (15 October 2023): The util is now called `dell-flash-unlock`, but it
-was previously called `e6400-flash-unlock`. Links have been updated.**
-
-BSD *boots* and works properly on these machines, but take note:
-
-Nicholas's [dell-flash-unlock](https://browse.libreboot.org/lbmk.git/plain/util/dell-flash-unlock/dell_flash_unlock.c)
-utility has been ported to OpenBSD, but *other* BSDs are assumed unsupported for
-now.
-
-NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
-now, as of 27 January 2024, which is a fork of flashrom.
-
-NOTE: BSD is mentioned above, but the only BSD tested for `dell-flash-unlock`
-is OpenBSD, as of 15 October 2023.
-
 Flashing from Linux
 -------------------
 

site/docs/install/index.md

@@ -3,6 +3,55 @@ title: Installation instructions
 x-toc-enable: true
 ...
 
+**SAFETY WARNING!**
+====================================================================
+
+**IMPORTANT ADVICE: [PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING/UPDATING
+LIBREBOOT](../../news/safety.md).**
+
+**GRUB payload warning**
+====================
+
+Firstly, it should be stated: in almost all cases, GRUB works just fine, on
+all of the machines that we test, but as of 26 May 2024 we got the error
+report:
+
+See: <https://codeberg.org/libreboot/lbmk/issues/216>
+
+Although we've only seen this thus far (as per user reports) on Intel
+SandyBridge based Dell Latitude laptops, we advise:
+
+**DO NOT use a ROM image where GRUB is the first payload. If you want to
+use the GRUB payload, please use a ROM image with `seabios_` at the start
+of the file name. Avoid images with `grub_` at the start of the file name.**
+
+ROM images with `grubonly` in them should also be avoided; if you want GRUB
+to be the first thing you see (without interruption), use a ROM image
+with `seabios_` at the start of the file name, and `grubfirst` at the end;
+these place a bootorder file in CBFS, so that SeaBIOS loads GRUB first, but
+you can still press ESC to bring up the SeaBIOS boot select menu.
+
+*This warning applies to Libreboot 20240504 and other recent releases.*
+
+**We have since fully mitigated this bug**; SeaBIOS is now the primary payload on
+all boards, with GRUB still available in the boot select menu, and we have
+identified that it was caused by the xHCI driver which has since been removed
+for the affected machines(machines which don't have xHCI anyway, but they
+touch code that does run on the given machines). The xHCI support works fine
+on some newer machines and will be re-added there by making GRUB multi-tree,
+so that different boards can use different versions of GRUB. This will be done,
+and present in the next Libreboot release after 20240504, in addition to fixing
+the actual bug itself. **For now, there are no problems!**
+
+Libreboot releases after 20240504 will *only* (on x86) contain ROM images where
+SeaBIOS is the first payload, without disabling the SeaBIOS menu (no `grubonly`). You'll still be able to use GRUB, either by pressing ESC for the boot
+select menu, and/or using an image with `grubfirst` in the file name so that
+SeaBIOS loads it first (while still permitting boot select via ESC keypress).
+
+GRUB's code is vast, and complicated, so this policy change is permanent,
+until GRUB can be well-audited (likely forked, with dead/legacy code removed).
+SeaBIOS code is much smaller and more robust. Remember always: code equals bugs.
+
 Need help?
 ==========
 
@@ -68,12 +117,6 @@ Otherwise, if you get such errors, it may just be that you're not root. You
 must run flashprog as root, at least to use the internal flasher (using external
 USB flashing dongles doesn't normally require root).
 
-SAFETY WARNING!
-====================================================================
-
-**IMPORTANT ADVICE: [PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING/UPDATING
-LIBREBOOT](../../news/safety.md).**
-
 PRECAUTIONS
 ===========
 
@@ -199,48 +242,16 @@ an option in the boot menu.
 ROM images that have `seabios_withgrub` in the file name start with SeaBIOS
 first, but also have GRUB available in the boot menu when you press ESC.
 
-### seabios\_grubfirst (DEFUNCT)
-
-**DEFUNCT**
-
-This build option is obsolete, and should not be used. It was deleted
-in lbmk revision `e1bbdadc9584291cf062660d67128e9f17ab788e`.
-
-It was believed, in earlier theory, that VGA ROM initialisation could
-be used in SeaBIOS and then SeaBIOS boots into a GRUB payload (built
-for coreboot), where the initialisation would continue to be used, but
-it didn't work that way.
-
-It's best to use PC GRUB (normal BIOS GRUB), but compile it into a floppy
-image to insert inside CBFS, to then be executed by SeaBIOS. This is referred
-to as SeaGRUB by the Libreboot project, and it would be quite useful
-for desktop users, but it's largely irrelevant on laptops where
-coreboot's own `libgfxinit` is usually available (or the option ROM is
-easy to extract from vendor firmware and insert).
-
-Where direct bare metal GRUB is desired, but you use a desktop system with
-an add-on graphics card, you must extract the VGA ROM for your card and
-insert it into the coreboot ROM, for coreboot itself to execute. This will
-require custom configuration on your part, and it is thus beyond the scope
-of the Libreboot project, in context of lbmk (automated build system).
-
-Some older Libreboot releases included ROM images built using this option,
-and those specific ROM images (`seabios_grubfirst` ones) should not be
-used; you should only use `seabios_grubfirst` or `seabios`, in most
-scenarios, if SeaBIOS is required.
-
-For most desktop users, if running an external graphics card, it's easier
-to simply boot in text mode with a SeaBIOS payload and use only that. This
-will Just Work with almost all graphics cards, allowing you to use an
-operating system with a full display and (drivers permitting) full 2D/3D
-acceleration.
+ROM images with this and `grubonly` in the image start SeaBIOS, but only load
+GRUB from SeaBIOS and the SeaBIOS menu is disabled. Use these images if you
+only want GRUB; they are provided on systems that only have VGA ROM-based
+initialisation, usually discrete graphics cards on desktop machines.
 
 Which systems are supported?
 ============================
 
 [Refer to the hardware compatibility page](../hardware/)
 
-Sandy/Ivybridge/Haswell MAC address (e.g. X230, X220, T440p, W541, hp8200sff)
 Intel GbE MAC address (IFD-based systems)
 =====================================================================
 

site/docs/install/ivy_has_common.md

@@ -66,8 +66,7 @@ Libreboot build system:
   target name.
 * SMSC SCH5545 fan control firmware (for Dell T1650): `vendor/t1650/sch5545ec.bin`
 * SMSC KBC1126 embedded controller firmware, on HP EliteBooks: `ec/`
-* Intel MRC firmware, used for ram/peripheral init on Haswell machines such as
-  thinkpad t440p/w541: `mrc/`
+* Intel MRC firmware, provides raminit on HP EliteBook 820 G2
 
 The above list refers to the *non-redistributable files*, and these are not
 directly included in releases. These are auto-downloaded during the build.
@@ -82,10 +81,6 @@ generated when running this command:
 
 	./build roms list
 
-For example, `t440pmrc_12mb` corresponds to ThinkPad T440p with MRC firmware.
-Whereas `t440plibremrc_12mb` corresponds to T440p with libre MRC firmware.
-Another example: `x230_12mb` corresponds to Thinkpad X230.
-
 In order to inject the necessary files into a rom image, run the script from the root of lbmk and point to the rom image.
 
 If you only wish to flash a release rom then the process of injecting the necessary files is quite simple.

site/docs/install/ivy_has_common.uk.md

@@ -70,8 +70,7 @@ Libreboot build system:
   target name.
 * SMSC SCH5545 fan control firmware (for Dell T1650): `vendor/t1650/sch5545ec.bin`
 * SMSC KBC1126 embedded controller firmware, on HP EliteBooks: `ec/`
-* Intel MRC firmware, used for ram/peripheral init on Haswell machines such as
-  thinkpad t440p/w541: `mrc/`
+* Intel MRC firmware, provides raminit on HP EliteBook 820 G2
 
 The above list refers to the *non-redistributable files*, and these are not
 directly included in releases. These are auto-downloaded during the build.
@@ -86,10 +85,6 @@ generated when running this command:
 
 	./build roms list
 
-For example, `t440pmrc_12mb` corresponds to ThinkPad T440p with MRC firmware.
-Whereas `t440plibremrc_12mb` corresponds to T440p with libre MRC firmware.
-Another example: `x230_12mb` corresponds to Thinkpad X230.
-
 In order to inject the necessary files into a rom image, run the script from the root of lbmk and point to the rom image.
 
 If you only wish to flash a release rom then the process of injecting the necessary files is quite simple.

site/docs/linux/grub_hardening.md

@@ -221,6 +221,51 @@ of user-friendliness.
 
 That just about covers it, where password setup is concerned!
 
+SeaBIOS first?
+==============
+
+In releases after Libreboot 20240504, SeaBIOS is the primary payload on
+all images, but GRUB is available in the boot menu. Select a ROM image
+with `grubfirst` at the end, and do this to the ROM image:
+
+	cbfstool libreboot.rom add-int -i 0 -n etc/show-boot-menu
+
+This disables the SeaBIOS menu, so that it only loads GRUB. The `grubfirst`
+image had this done to it by lbmk (Libreboot build system) during build:
+
+	cbfstool libreboot.rom add -f config/grub/bootorder -n bootorder -t raw
+
+This `bootorder` file has the following contents:
+
+```
+/rom@img/grub2
+```
+
+You can add it yourself if your image doesn't have it. With this, SeaBIOS
+only loads GRUB first.
+
+NOTE: Before disabling the boot menu, make sure GRUB works. Access it using
+the `bootorder` file and/or press ESC in the SeaBIOS menu. Then disable the
+SeaBIOS menu.
+
+Alternative: GRUB as primary
+----------------------------
+
+The *SeaBIOS first* policy is now law, in Libreboot releases. The only
+exception is the x86 QEMU target. You can do this if building from source:
+
+	./build roms -p grub targetname
+
+Where `targetname` is e.g. `x200_8mb` (use the correct one for your board).
+
+Again: make sure GRUB works. Also: don't do this if you're using a non-Intel
+graphics card because only the Intel graphics have native video initialisation
+in Libreboot, and we rely on SeaBIOS to execute the VGA ROM for others.
+
+(it is assumed that you know to add the VGA ROM in CBFS if needed, if using
+a dGPU, or that you're using a graphics card on a desktop so SeaBIOS will use
+that automatically)
+
 GPG keys
 ========
 

site/docs/linux/index.md

@@ -46,6 +46,11 @@ Then still as root, do these commands:
 	export PATH="$PATH:/sbin"
 	update-grub
 
+NOTE: `update-grub` is very much Debian-centric. Not all distros will have it.
+On Arch-based distros for instance, you might do:
+
+	grub-mkconfig -o /boot/grub/grub.cfg
+
 Now your distro's GRUB menu should work, when your distro's GRUB bootloader is
 executed from Libreboot's SeaBIOS payload.
 

site/docs/maintain/index.md

@@ -88,39 +88,27 @@ project that Libreboot imports, such as coreboot.
 Environmental variables
 =======================
 
-LBMK\_THREADS
+XBMK\_THREADS
 -------------
 
 For example:
 
-	export LBMK_THREADS=2
+	export XBMK_THREADS=2
 
 This would build on two threads, when running lbmk. It defaults to 1.
 
 Previous revisions of lbmk used `nproc` by default, but this was set to 1
 instead, because nproc is not available on every operating system.
 
-LBMK\_STATUS
-------------
-
-By default, the user is asked to confirm when building for a given mainboard,
-if that mainboard is not marked *stable* in `target.cfg`. To disable such
-dialogs, do this:
-
-	export LBMK_STATUS=n
-
-LBMK\_RELEASE
+XBMK\_RELEASE
 -------------
 
-If set to `y`, it signals to `script/build/roms` that a release is being built,
+If set to `y`, it signals to `script/roms` that a release is being built,
 and it will honour `release="n"` in target.cfg files. You could also set this
 yourself, when doing regular builds, if you wanted to test how `./build roms`
 behaves running it in release mode. Do this if you want to:
 
-	export LBMK_RELEASE=y
-
-This has a similar effect compared to `LBMK_STATUS="y"` but you probably don't
-need to use this option yourself.
+	export XBMK_RELEASE=y
 
 Projects/files downloaded/generated by lbmk
 ===========================================
@@ -139,8 +127,8 @@ This directory is created when running any of the following commands, with the
 right arguments:
 
 	./build roms ARGUMENTS_HERE
-	./build serprog stm32
-	./build serprog rp2040
+	./build roms serprog stm32
+	./build roms serprog rp2040
 
 Simply speaking, `bin/` shall contain finished ROM images or firmware, that
 can then be installed (flashed) to the target device.
@@ -188,15 +176,7 @@ releases (only the images under `bin/` are provided).
 mrc/
 ---------------
 
-Please also
-visit: <https://doc.coreboot.org/northbridge/intel/haswell/mrc.bin.html> - the
-handling of this, in Libreboot, is based largely on the information there.
-
-This contains the Intel MRC firmware, auto-downloaded during build
-by `script/vendor/download`.
-
-In some cases, libre MRC firmware is also available, and provided
-by Libreboot as an alternative choice.
+Intel System Agent downloaded at build time for HP EliteBook 820 G2.
 
 pciroms/
 ---------------
@@ -208,7 +188,7 @@ currently only initialises Intel GPUs natively, on Libreboot systems.
 release/
 ---------------
 
-The script at `script/update/release` create tarballs in here, which
+The script at `build` create tarballs in here, which
 constitute regular Libreboot releases. It is meticulously maintained, as per
 current lbmk behaviour, and executed so as to provide Libreboot release
 archives.
@@ -218,6 +198,26 @@ containing non-redistributable vendor code are *scrubbed* such that these files
 in regular releases, be [re-added manually](../install/ivy_has_common.md) by
 the user.
 
+You can create release archives by doing:
+
+	./update release
+
+By default, this creates a release under `release/`, but you can change the
+directory, for example:
+
+	./update release -d path
+
+You can also specify that only a *source archive* be created, like so:
+
+	./update release -m src
+
+Or with a custom directory:
+
+	./update release -d path -m src
+
+The build system expects there to be a *git tag*, so make sure there is one.
+This is used to create the version number for a given release.
+
 src/
 ----
 
@@ -290,23 +290,6 @@ GRUB image under `elf/grub/`.
 NOTE: This is *only* provided for x86 machines, in Libreboot. For ARM, we ship
 U-Boot instead.
 
-src/me\_cleaner/
----------------
-
-Please also visit: <https://github.com/corna/me_cleaner/>
-
-This is used by Libreboot, to *neuter* Intel ME images. The intel ME images
-are auto-downloaded from the vendor during each build process, cached on
-disk and processed by `me_cleaner`. It removes almost all code from Intel ME,
-leaving only the basic bringup code (analogous to running coreboot without a
-payload). More information available at these pages:
-
-* <https://github.com/corna/me_cleaner/>
-* Libreboot [freedom status page](../../freedom-status.md)
-
-The *vendor file* scripts are what handle this, specifically the download script
-located at `script/vendor/download`.
-
 src/memtest86plus/
 ---------------
 
@@ -347,7 +330,7 @@ src/uefitool/
 Please also visit: <https://github.com/LongSoft/UEFITool>
 
 This is compiled, so as to provide `UEFIExtract`. Currently used by the
-vendor download script at `script/vendor/download`, to download SCH5545 EC
+vendor download logic within `include/vendor.sh`, to download SCH5545 EC
 firmware (used for fan control on Dell Precision T1650).
 
 src/pico-serprog
@@ -411,9 +394,6 @@ desirable, `lbmk.git` provides a few utilities as part of itself, namely:
 util/dell-flash-unlock/
 ---------------
 
-**NOTE (15 October 2023): The util is now called `dell-flash-unlock`, but it
-was previously called `e6400-flash-unlock`. Links have been updated.**
-
 This program, written by Nicholas Chin, unlocks the boot flash on Dell Latitude
 E6400; it permits internal flashing, from factory firmware to Libreboot, so that
 the user need not disassemble and flash externally.
@@ -498,6 +478,25 @@ config/
 This directory contains configuration files, used by the Libreboot build
 system. These next sections will cover specific configuration files.
 
+config/PROJECT\*/nuke.list
+--------------------------
+
+The script `include/git.sh` handles deletion of certain files, for downloaded
+projects, based on a `nuke.list` file that can (for single-tree projects) be
+included at `config/PROJECT/nuke.list` or (multi-tree project)
+at `config/PROJECT/TREE/nuke.list` (entries are relative links from the root
+directory of the given source tree e.g. `src/coreboot/default/`).
+
+So, if `src/coreboot/default/` contained foo/bar.txt, you could add to
+the `nuke.list` file as follows:
+
+```
+foo/bar.txt
+```
+
+Ditto `src/flashprog/`, if you wanted to delete a file from in there, as one
+other example. Deletions occur when the source tree is created.
+
 config/vendor/
 ---------------
 
@@ -526,7 +525,7 @@ When a given coreboot tree is compiled, for a given target, this file defines
 which files to copy from the coreboot directory, which are then copied to
 a location under `elf/coreboot`.
 
-The presence of this file affects behaviour in `script/update/release`;
+The presence of this file affects behaviour in `./update release` commands;
 specifically, PROJECT is then downloaded to `src/PROJECT/PROJECT`, and files
 under `config/PROJECT/TARGET/target.cfg` define which tree to use, which then
 looks under `config/PROJECT/TREE/target.cfg` to get the git revision; then
@@ -579,7 +578,6 @@ as:
 * `grub_scan_disk="ata"`
 * `uboot_config=default` (specify which U-Boot tree to use)
 * `release="n"` (example entry)
-* `status=stable` (example entry)
 * `xtree="default"` (example entry)
 * `tree_depend="default"` (example entry)
 
@@ -633,19 +631,11 @@ on a ThinkPad X60 with the optical drive may cause GRUB to hang, so on that
 machine it is advisable to set this option to `ahci` (becuse the default HDD
 slot is AHCI).
 
-The `release` variable can be set to n, which makes the `script/update/release`
-script skip that target, when creating release images. For example, a given
+The `release` variable can be set to n, which makes the `./update release`
+call skip that target, when creating release images. For example, a given
 board may not be stable and you don't want images for it to be included in the
 release.
 
-The `status` variable can be set to whatever you want, but anything other
-than `stable` will make `script/build/roms` ask for y/n confirmation if
-not building images using `script/update/release`.
-
-Recommended strings for `status` could be: `stable`, `unstable`, `broken`
-or `untested`. Alternatively, you might state `wip`. You can set whatever
-string you want here.
-
 The `xtree` option specifies that a given tree with use a specific coreboot
 tree for compiling crossgcc. This can be used to skip building gcc if OK on
 a given board; two trees may use the same crossgcc as each other.
@@ -653,13 +643,6 @@ a given board; two trees may use the same crossgcc as each other.
 The `tree_depend` option means that a given tree needs another tree, defined
 by this variable, to also be present.
 
-### config/coreboot/BOARDNAME/warn.txt
-
-Additionally: the `warn.txt` file can be included alongside target.cfg, to
-provide warning of any potential issues or quirks. For example, raminit may
-only be reliable with certain modules. This is printed on the user's terminal
-when building that target.
-
 ### config/coreboot/BOARDNAME/config/
 
 Files in this directory are *coreboot* configuration files. 
@@ -1071,44 +1054,37 @@ Scripts in root directory of lbmk
 build
 ---------------
 
-This is the main script in lbmk, Libreboot's build system. It is what executes
-all other parts of the Libreboot build system. The rules are as follows:
+This is the main script. Symlinks `vendor` and `update` also point to it.
 
-* Argument zero, representing the name of the symlink, will be used to
-  execute `script/LINKNAME/COMMAND` - for example: `./build roms all`
-  would execute `script/build/roms all` in `sh`.
-* In the above example, `LINKNAME` could also be `vendor`. In examples below,
-  symlinks are described pointing to `build` (the actual script). The script
-  works by checking argument zero, so it would look in a different directory
-  under `script/` matching `LINKNAME` - in this case, `script/vendor/`
-* `TMPDIR` is exclicitly set, providing a constant location where temporary
-  files and directories can be made. `TMPDIR` is exported by the parent to
-  all children; for example, `./build roms all` would export it
-  to `script/build/roms`, and then anything called by *that* will also
-  inherit it - the main parent process running `lbmk` will then clean up this
-  `TMPDIR` directory upon any exit.
-* All exits from lbmk are handled by this script. *All* exits, zero or non-zero,
-  are engineered such that *this* script, in the parent process (the very first
-  instance) is what ultimately exits back to the user's shell prompt.
-* This script is programmed to *exit* with non-zero status, when run as root,
-  unless the `./build dependencies *` commands are used,
-  referencing files under `config/dependencies/`
-* Under fault conditions, each child process shall output to stderr, and the
-  main parent process running `lbmk` will output the final error message.
+Take any given file under `script/` and you can do:
 
-tl;dr break this script and you *break Libreboot*.
+	./build file # (THIS IS NOT A VALID COMMAND)
 
-update
----------------
+For example:
 
-Symbolic link, pointing to the `build` script. This is executed by the user, or
-by lbmk, referencing scripts under `script/update/`.
+	./build roms
+	./update trees
 
-vendor
----------------
+Special commands available (not provided by files under `script/`):
 
-Symbolic link, pointing to the `build` script. This is executed by the user, or
-by lbmk, referincing scripts under `script/vendor/`
+	./update release
+	./vendor download
+	./vendor inject
+
+The `vendor` commands are handled by the `build` script, calling functions
+inside `include/vendor.sh`, and the `./update release` logic is handled
+directly by the `build` script.
+
+More information about `./vendor` commands can be found
+here: [inserting vendor files](../install/ivy_has_internal.md)
+
+Information about `./update release` is written elsewhere on this page.
+
+You can also know what build system revision you have by running:
+
+	./build version
+
+This script is the beating heart of Libreboot. Break it and you break Libreboot.
 
 include/
 ===============
@@ -1117,27 +1093,6 @@ This directory contains *helper scripts*, to be included
 by main scripts using the `.` command (called the `source`
 command in `bash`, but we rely upon posix `sh` only).
 
-include/err.sh
----------------
-
-Generic error handling, used by all lbmk scripts.
-
-This also contains functions to verify the current libreboot version, and check
-whether Git is properly initialised on the host system. It also contains
-the `setvars` function, which provides a shorthand way of initialising many
-variables (combined with use of `eval`), which lbmk uses heavily.
-
-This function also contains `x_` and `xx_` which lbmk uses to execute commands
-and ensure that they cause an exit (with non-zero status) from lbmk, if they
-return an error state; the `xx_` function calls `fail()` which a script must
-provide, to perform some action before calling `err` which in turn prints an
-error message provided as argument. It is used similarly to the C
-function `err()` in BSD libc. The `x_` function simply calls `err`.
-
-This entire file is heavily inspired by `err.h` in BSD libc code. This file is
-heavily used by lbmk (it's used by every script), to provide clean error
-handling in `sh`.
-
 include/git.sh
 --------------
 
@@ -1164,37 +1119,31 @@ it is provided as an include to bypass license incompatibility. It has been
 heavily modified to use the same style of logic and general control flow used
 in the script at `script/vendor/download`, and it is used from there.
 
-include/option.sh
+include/lib.sh
 ---------------
 
-Functions used by scripts under `script/vendor/`, for checking defconfig
-files. These files are checked because the scripts need to know whether a given
-file is used; if it is, a path is then specified in defconfig, telling the vendor
-script either where it is, or where it should be downloaded to.
-
 Several other parts of lbmk also use this file. It is added to as little as
 possible, and contains miscallaneous functions that don't belong anywhere else.
 
 The functions here are mostly those that deal with configuration files; scanning
 them to set variables and so on.
 
+This file also contains generic error handling, used by all lbmk scripts.
+
+This also contains functions to verify the current libreboot version, and check
+whether Git is properly initialised on the host system. It also contains
+the `setvars` function, which provides a shorthand way of initialising many
+variables (combined with use of `eval`), which lbmk uses heavily.
+
+This function also contains `x_()` which lbmk uses to execute commands
+and ensure that they cause an exit (with non-zero status) from lbmk, if they
+return an error state.
+
 script/
 =======
 
-*All* scripts under `script/` are executed only by the main `lbmk` script,
-conforming to the standard `buildpath/option` e.g. `build/roms` - so,
-running `./build roms` would run `script/build/roms`.
-
-script/build/
----------------
-
-These are highly specialised build scripts, written for specific tasks, almost
-entirely in the context of building firmware images themselves, but some utils
-are also handled.
-
-The scripts that create release archives are also located under this directory.
-
-### script/build/roms
+script/roms
+-----------
 
 This builds coreboot ROM images.
 
@@ -1236,28 +1185,6 @@ It creates ROM images with GRUB, SeaBIOS, U-Boot, optionally with Memtest86+
 also included, in various separate configurations in many different ROM images
 for user installation.
 
-The `romtype` entry in `target.cfg` tells this script what to do with the ROM,
-after it has been built. Currently, it operates based on these possible values
-for `romtype`:
-
-* `d8d16sas` will cause *fake* (empty) files named `pci1000,0072.rom`
-  and `pci1000,3050.rom` to be inserted in CBFS. This prevents SeaBIOS from
-  loading or executing the option ROM stored on PIKE2008 modules, present on
-  certain configurations with the ASUS KCMA-D8 or KGPE-D16 mainboards. Those
-  option ROMs cause the system to hang, so they should never be executed (this
-  means however that booting Linux kernels from SAS devices is impossible on
-  those boards, unless a Linux payload is used; Linux can use those SAS drives,
-  without relying on the PIKE2008 option ROMs). When SeaBIOS runs, it will
-  default to loading the corresponding option ROM from CBFS, if it exists, for
-  a given PCI device, overriding whatever option ROM is present on the device
-  itself, but if the option ROM is invalid/empty, SeaBIOS will not attempt to
-  load another one, until the empty/invalid one (in CBFS) is deleted.
-* `i945 laptop`: in this configuration, the upper 64KB section of the ROM is
-  copied into the 64KB section below that. This results in there being two
-  bootblocks in the ROM, and you can decide which one is used by setting `bucts`
-* If no declaration is made, or a declaration is made contrary to the above,
-  no special modifications will be made.
-
 If no payload is defined in `target.cfg`, the `build/roms` script will exit
 with error status.
 
@@ -1286,60 +1213,25 @@ When the ROM is finished compiling, it will appear under a directory in `bin/`
 This script is the beating heart of Libreboot. Break it, and you break
 Libreboot!
 
-### script/build/serprog
+Serprog images:
 
 Build firmware images for serprog-based SPI programmers, where they use an
 STM32 MCU. It also builds for RP2040-based programmers like Raspberry Pi Pico.
 
-Example command: `./build serprog stm32`
+Example command: `./build roms serprog stm32`
 
-Example command: `./build serprog rp2040`
+Example command: `./build roms serprog rp2040`
 
 The `list` argument is available:
 
-	./build serprog stm32 list
+	./build roms serprog stm32 list
+	./build roms serprog rp2040 list
 
 Without arguments, all targets would be compiled, but you can specify a short
 list of targets instead, based on the output of `list`.
 
-script/update/
---------------
-
-This handles most actual building of source trees, called into by scripts
-under `script/build/fw` - it also contains logic for downloading source trees
-or vendor files.
-
-### script/update/release
-
-This script builds the release archives, which are then provided in a new
-Libreboot release. Most users do not need to look at this file at all, but it
-is provided under free license for curious souls.
-
-Command: `./update release`
-
-NOTE: if the `-d` option is used, you can specify a directory other
-than `release`. For example:
-
-	./update release -d /media/stuff/libreboot_release_test
-
-If `-d` is not passed, they will go under `release/` in your lbmk repository.
-The script is engineered to re-initialise git if ran from a release archive.
-Libreboot releases after 20230625 include `.gitignore` in the src archive.
-
-This builds release archives, containing ROM images for coreboot and/or serprog
-programmers. It works simply: lbmk clones *itself*, and builds itself in its
-clone, then cleans itself up and creates tarballs. If you run this script, you
-should expect it to take at least 4 hours; slower on really old systems. On
-really fast systems, it might take 2-3 hours.
-
-NOTE: This script *scrubs* certain vendor firmware from release ROMs, such as
-Intel ME or MRC firmware. The release ROMs shall then exclude these files
-within them, requiring manual insertion by the user post-release. See:
-
-[Insert vendor files
-on Sandybridge/Ivybridge/Haswell](../install/ivy_has_common.md)
-
-### script/update/trees
+script/trees
+------------
 
 *This* is the other beating heart of Libreboot. Used heavily by Libreboot, this
 script is what handles defconfig files for SeaBIOS, U-Boot *and* coreboot; it
@@ -1459,37 +1351,3 @@ All of this used to about 20 different scripts, all with much-duplicated logic.
 Now it is unified, efficiently, under a single script.
 
 Remember: code equals bugs, so less code equals fewer bugs.
-
-script/vendor/
---------------
-
-### script/vendor/download
-
-This downloads vendor code when needed, on a given coreboot target. It does
-this by scanning the defconfig files of that board, to know where the files
-are (or where they should be) within lbmk. Based on this, it then knows which
-files to download.
-
-These files are then inserted at build time by the coreboot build system (as
-defined by defconfigs), or post-release by running the `inject` script.
-
-It looks inside `config/vendor/` at the files in there, concatenating them and
-then scanning that to find info about the given board; for example, info like
-where to download a Lenovo BIOS updater to extract `me.bin` from, to run through
-the `me_cleaner` program.
-
-More information is available [here](../install/ivy_has_common.md).
-
-This script is executed automatically, when you compile ROM images, if the given
-mainboard requires vendor code to be inserted. In this way, you do not need to
-manually extract such files from your original vendor image.
-
-### script/vendor/inject
-
-This is not used during the build process, but it can be run by the user on
-release ROMs (which do not contain non-redistributable code handled by these
-vendor scripts, even if they are required). This script inserts those files
-into the coreboot ROM image; if you're building from source, using lbmk, you
-do not need to run the inject script at all.
-
-More information is available [here](../install/ivy_has_common.md).

site/docs/misc/emulation.md

@@ -23,16 +23,16 @@ In order to test the resulting roms, you must have qemu installed on the host ma
 Test the roms by pointing qemu to the rom in bios mode.
 For example:
 
-`qemu-system-x86_64 -bios bin/qemu_x86_12mb/grub_qemu_x86_12mb_libgfxinit_corebootfb_usqwerty_noblobs.rom`
+`qemu-system-x86_64 -bios bin/qemu_x86_12mb/grub_qemu_x86_12mb_libgfxinit_corebootfb_usqwerty.rom`
 
-`qemu-system-x86_64 -bios bin/qemu_x86_12mb/uboot_payload_qemu_x86_12mb_libgfxinit_corebootfb_noblobs.rom -serial stdio`
+`qemu-system-x86_64 -bios bin/qemu_x86_12mb/uboot_payload_qemu_x86_12mb_libgfxinit_corebootfb.rom -serial stdio`
 
 There is basic support for an arm64 virtual machine as well, although the payloads are not as developed as the x86 one:
 
 	./build roms qemu_arm64_12mb
 
 ```
-qemu-system-aarch64 -bios bin/qemu_arm64_12mb/uboot_payload_qemu_arm64_12mb_libgfxinit_corebootfb_noblobs.rom \
+qemu-system-aarch64 -bios bin/qemu_arm64_12mb/uboot_payload_qemu_arm64_12mb_libgfxinit_corebootfb.rom \
 	-M virt,secure=on,virtualization=on,acpi=on -cpu cortex-a53 -m 768M -serial stdio -vga none -display none
 ```
 

site/download.md

@@ -31,7 +31,7 @@ LIBREBOOT](news/safety.md).**
 GPG signing key
 ---------------
 
-**The latest release is Libreboot 20240225, under the `testing` directory.**
+**The latest release is Libreboot 20240504, under the `stable` directory.**
 
 ### NEW KEY
 
@@ -83,7 +83,7 @@ there is a Git repository that you can download from. Go here:
 HTTPS mirrors {#https}
 -------------
 
-**The latest release is Libreboot 20240225, under the `testing` directory.**
+**The latest release is Libreboot 20240504, under the `stable` directory.**
 
 These mirrors are recommended, since they use TLS (https://) encryption.
 
@@ -174,7 +174,7 @@ crontab. This page tells you how to use crontab:
 HTTP mirrors {#http}
 ------------
 
-**The latest release is Libreboot 20240225, under the `testing` directory.**
+**The latest release is Libreboot 20240504, under the `stable` directory.**
 
 WARNING: these mirrors are non-HTTPS which means that they are
 unencrypted. Your traffic could be subject to interference by
@@ -188,7 +188,7 @@ if using HTTPS.
 FTP mirrors {#ftp}
 -----------
 
-**The latest release is Libreboot 20240225, under the `testing` directory.**
+**The latest release is Libreboot 20240504, under the `stable` directory.**
 
 WARNING: FTP is also unencrypted, like HTTP. The same risks are present.
 

site/download.uk.md

@@ -31,7 +31,7 @@ LIBREBOOT](news/safety.md).**
 Код підпису GPG
 ---------------
 
-**Останнім випуском є Libreboot 20240225, в директорії `testing`.**
+**Останнім випуском є Libreboot 20240504, в директорії `stable`.**
 
 ### НОВИЙ КЛЮЧ
 
@@ -50,7 +50,7 @@ will expire on 26 December 2028.
 Повний відбиток ключа: `98CC DDF8 E560 47F4 75C0  44BD D0C6 2464 FA8B 4856`
 
 This key is for Libreboot releases *after* the 20160907 release, and up
-to the Libreboot 20240225 release. This key *expired* during December 2023,
+to the Libreboot 20240504 release. This key *expired* during December 2023,
 so you should use the *newer* key (see above) for the releases after
 Libreboot 20240126.
 
@@ -83,7 +83,7 @@ Libreboot 20240126.
 Дзеркала HTTPS {#https}
 -------------
 
-**Останнім випуском є Libreboot 20240225, в директорії `testing`.**
+**Останнім випуском є Libreboot 20240504, в директорії `stable`.**
 
 Дані дзеркала є рекомендованими, оскільки використовують TLS (https://) шифрування.
 
@@ -174,7 +174,7 @@ crontab. Ця сторінка розповідає вам, як викорис
 Дзеркала HTTP {#http}
 ------------
 
-**Останнім випуском є Libreboot 20240225, під директорією `testing`.**
+**Останнім випуском є Libreboot 20240504, під директорією `stable`.**
 
 УВАГА: ці дзеркала є не-HTTPS, що означає, що вони
 незашифровані. Ваш трафік може бути об'єктом втручання
@@ -188,7 +188,7 @@ crontab. Ця сторінка розповідає вам, як викорис
 Дзеркала FTP {#ftp}
 -----------
 
-**Останнім випуском є Libreboot 20240225, під директорією `testing`.**
+**Останнім випуском є Libreboot 20240504, під директорією `stable`.**
 
 УВАГА: FTP є також незашифрованим, подібно HTTP. Ті ж самі ризики присутні.
 

site/footer.de.include

@@ -9,8 +9,6 @@
 * [Vorlage](/template-license.md)
 * [Logo](/logo-license.md)
 * [Autoren](/contrib.md)
-* -
-* [Canoeboot??](https://canoeboot.org/)
 
 -------------------------------------------------------------------------------
 

site/footer.include

@@ -9,8 +9,6 @@
 * [Template](/template-license.md)
 * [Logo](/logo-license.md)
 * [Authors](/contrib.md)
-* -
-* [Canoeboot??](https://canoeboot.org/)
 
 -------------------------------------------------------------------------------
 

site/footer.it.include

@@ -9,8 +9,6 @@
 * [Modelli di licenze](/template-license.md)
 * [Logo](/logo-license.md)
 * [Autori](/contrib.md)
-* -
-* [Canoeboot??](https://canoeboot.org/)
 
 -------------------------------------------------------------------------------
 

site/footer.uk.include

@@ -8,9 +8,7 @@
 * [Ліцензія](/license.md)
 * [Шаблон](/template-license.uk.md)
 * [Логотип](/logo-license.uk.md)
-* [Автори](/contrib.uk.md)
-* -
-* [Canoeboot??](https://canoeboot.org/)
+* [Автори](/contrib.md)
 
 -------------------------------------------------------------------------------
 

site/footer.zh-cn.include

@@ -9,8 +9,6 @@
 * [模板](/template-license.md)
 * [图标](/logo-license.md)
 * [作者](/contrib.md)
-* -
-* [Canoeboot??](https://canoeboot.org/)
 
 -------------------------------------------------------------------------------
 

site/freedom-status.md

@@ -214,7 +214,7 @@ Mostly free software, except for the requirement on `daisy` and `peach` mainboar
 to include BL1 bootloader files from the vendor. These are:
 
 * HP Chromebook 11 G1 (daisy-spring) **(board removed from Libreboot, due to
-	issues (will be re-added at a later date)**
+	issues (will be re-added at a later date))**
 * Samsung Chromebook XE303 (daisy-snow) **(ditto)**
 * Samsung Chromebook 2 13” (peach-pi) **(ditto)**
 * Samsung Chromebook 2 11” (peach-pit) **(ditto)**

site/index.de.md

@@ -21,9 +21,9 @@ for [Libreboot preinstallation](https://minifree.org/product/installation-servic
 The founder and lead developer of Libreboot, Leah Rowe, also owns and operates
 Minifree; sales provide funding for Libreboot.
 
-**NEUESTE VERSION: Die neueste Version von Libreboot ist 20240225, veröffentlicht
-am 25. February 2024.
-Siehe auch: [Libreboot 20240225 release announcement](news/libreboot20240225.md).**
+**NEUESTE VERSION: Die neueste Version von Libreboot ist 20240504, veröffentlicht
+am 4. May 2024.
+Siehe auch: [Libreboot 20240504 release announcement](news/libreboot20240504.md).**
 
 Warum solltest Du *Libreboot* verwenden?
 ----------------------------

site/index.fr.md

@@ -19,8 +19,8 @@ for [Libreboot preinstallation](https://minifree.org/product/installation-servic
 The founder and lead developer of Libreboot, Leah Rowe, also owns and operates
 Minifree; sales provide funding for Libreboot.
 
-**NOUVELLE VERSION: La dernière version est [Libreboot 20240225](news/libreboot20240225.md), sortie
-le 25 February 2024.**
+**NOUVELLE VERSION: La dernière version est [Libreboot 20240504](news/libreboot20240504.md), sortie
+le 4 May 2024.**
 
 Pourquoi devriez-vous utiliser *Libreboot*?
 -----------------------------------

site/index.it.md

@@ -20,8 +20,8 @@ for [Libreboot preinstallation](https://minifree.org/product/installation-servic
 The founder and lead developer of Libreboot, Leah Rowe, also owns and operates
 Minifree; sales provide funding for Libreboot.
 
-**ULTIMO RILASCIO: L'ultimo rilascio e' Libreboot 20240225, rilasciato il 25 February 2024.
-Vedi: [Libreboot 20240225 annuncio di rilascio](news/libreboot20240225.md).**
+**ULTIMO RILASCIO: L'ultimo rilascio e' Libreboot 20240504, rilasciato il 4 May 2024.
+Vedi: [Libreboot 20240504 annuncio di rilascio](news/libreboot20240504.md).**
 
 Per quale ragione utilizzare *Libreboot*?
 -----------------------------------------

site/index.md

@@ -23,9 +23,9 @@ for [Libreboot preinstallation](https://minifree.org/product/installation-servic
 The founder and lead developer of Libreboot, Leah Rowe, also owns and operates
 Minifree; sales provide funding for Libreboot.
 
-**NEW RELEASE: The latest release is Libreboot 20240225, released on
-25 February 2024.
-See: [Libreboot 20240225 release announcement](news/libreboot20240225.md).**
+**NEW RELEASE: The latest release is Libreboot 20240504, released on
+4 May 2024.
+See: [Libreboot 20240504 release announcement](news/libreboot20240504.md).**
 
 *We* believe the freedom to [study, share, modify and use
 software](https://writefreesoftware.org/), without any

site/index.uk.md

@@ -21,8 +21,8 @@ for [Libreboot preinstallation](https://minifree.org/product/installation-servic
 The founder and lead developer of Libreboot, Leah Rowe, also owns and operates
 Minifree; sales provide funding for Libreboot.
 
-**НОВИЙ ВИПУСК: Останній випуск Libreboot 20240225, випущено 25 лютий 2024.
-Дивіться: [Оголошення про випуск Libreboot 20240225](news/libreboot20240225.md).**
+**НОВИЙ ВИПУСК: Останній випуск Libreboot 20240504, випущено 25 травень 2024.
+Дивіться: [Оголошення про випуск Libreboot 20240504](news/libreboot20240504.md).**
 
 Чому вам варто використовувати *Libreboot*?
 ----------------------------

site/index.zh-cn.md

@@ -12,7 +12,7 @@ x-toc-enable: true
 Libreboot 的创始人和主要开发者，Leah Rowe，也是 Minifree 的所有者和经营者；
 销售电脑为 Libreboot 提供资金。
 
-**新版发布: 最新版本 Libreboot 20240225 已在 2024 年 02 月 25 日发布。详见: [Libreboot 20240225 发布公告](news/libreboot20240225.md).**
+**新版发布: 最新版本 Libreboot 20240504 已在 2024 年 05 月 04 日发布。详见: [Libreboot 20240504 发布公告](news/libreboot20240504.md).**
 
 为什么要使用 *Libreboot*?
 ----------------------------

site/news/MANIFEST

@@ -1,3 +1,4 @@
+canoegnu.md
 libreboot20240504.md
 libreboot20240225.md
 ports202402.md
@@ -6,7 +7,6 @@ libreboot20240126.md
 x201.md
 hp820g2.md
 audit4.md
-10.md
 libreboot20231106.md
 libreboot20231101.md
 libreboot20231021.md

site/news/audit3.md

@@ -156,7 +156,7 @@ are also repeated below but in more detail:
 * Don't use the `-B` option in make commands.
 * Where no-microcode ROM images are provided, ensure that the ROM hashes still
   match when running the vendor inject script. This is only useful on the
-  Dell Latitude E6400, which is otherwise FSDG-compatible but (in Libreboot)
+  Dell Latitude E6400, which is otherwise blob-free but (in Libreboot)
   comes with or without microcode updates, and with or without the Nvidia VGA
   ROM (handled by vendor inject/download scripts) for dGPU variants. Verification
   previously failed, under certain conditions, when inserting that VGA ROM.
@@ -198,8 +198,8 @@ are also repeated below but in more detail:
   spaces in them.
 * Don't support removal of microcode (during release time) on untested targets.
   Set `microcode_required="y"` on most boards, but leave it set to `"n"` on
-  platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything FSDG
-  compatible, in other words.
+  platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything that
+  can run without blobs, in other words.
 * Improved Dell Latitude E6400 support; the same image now provides iGPU and
   dGPU support, since it's SeaBIOS-only anyway, so a VGA ROM is inserted into
   the same ROM that also enables libgfxinit, enabling the Intel or Nvidia GPU

site/news/audit4.md

@@ -123,16 +123,6 @@ And now, specific changes:
   the script on certain targets. Patch courtesy of Leah Rowe.
 * `script/vendor/inject`: Fixed a bad error check, when running `cd` to switch
   to the ROM images directory, when creating archives. Patch courtesy Leah Rowe.
-* Don't delete microcode updates on GM45 ROMs in releases. Microcode updates
-  are always included in builds, but the release build scripts were copying
-  certain ROM images to cerate versions (alongside the default ones) with
-  microcode disabled. This is no longer required, due to the existence of
-  the [Canoeboot project](https://canoeboot.org/). You can also still delete them
-  very easily, using cbfstool, if they are included in a given set of images,
-  so this change reduces the uncompressed size of the ROM images in releases.
-  This also means that the file names of all ROM images now match the file names
-  in canoeboot images, when dealing with a mainboard supported by both projects.
-  Patch courtesy of Leah Rowe.
 * `script/update/release`: Don't test `script/vendor/inject` at the end. This
   is regularly tested anyway, during development, so it's a waste of time to
   have it done by the release build script. This reduces the amount of time

site/news/canoegnu.md

@@ -0,0 +1,152 @@
+% Should Canoeboot become GNU Canoeboot?
+% Leah Rowe
+% 12 May 2024
+
+Introduction/context
+====================
+
+As many readers know, Libreboot abandoned the GNU FSDG policy in November 2022,
+instead opting for a [different policy](policy.md) allowing blobs only under
+the most limited circumstances, to allow newer machines to be supported from
+coreboot. Fewer/zero blobs is still preferred, and this is provided whenever
+possible; for example, Libreboot recently [removed a
+blob](https://browse.libreboot.org/lbmk.git/commit/?id=cc33974150d275140fced9cfa4b8e901b0552074) previously used for raminit
+on Haswell machines, from now on allowing only the libre raminit that recently
+became stable. This *binary blob reduction policy* of Libreboot will remain.
+
+However, a minority of people disliked this move, and are yearning for a
+project much like the old one. Libreboot used to be entirely blob-free; coreboot
+is otherwise free software, but requires blobs on some mainboards, so Libreboot
+previously could not support all mainboards from Coreboot.
+
+The benefit of both Canoeboot and Libreboot is that they provide a completely
+automated build process and installation procedure, with well-tested builds
+released on a regular basis that the user can simply install, with minimal
+fuss. You can think of it as a *coreboot distro*. Coreboot provides snapshot
+source code archives every few months, but that's it. Libreboot/Canoeboot gives
+you the ROM images pre-compiled, with source code, and with payloads
+already pre-configured. In other words: Canoeboot and Libreboot make coreboot
+extremely easy to use.
+
+Canoeboot: the blob-free fork
+=============================
+
+I've been maintaining my own fork of Libreboot since October 2023, called
+Canoeboot. While it may have fewer supported mainboards than Libreboot as a
+result, it complies fully with the GNU Free System Distribution Guidelines,
+in providing an entirely de-blobbed coreboot distro, like Libreboot used to
+be. See:
+
+<https://canoeboot.org/>
+
+Email sent to GNU Eval
+====================
+
+With the recent Canoeboot 20240510 release, I've decided: Canoeboot should
+become a GNU project.
+
+Therefore, I sent GNU Eval an email requesting that they review it, laying the
+case for GNU membership. This will apply to *Canoeboot*, not Libreboot, since
+Canoeboot is the only one of the two that fully complies with their policies.
+
+That email is published here (replies will not be published):
+
+<https://canoeboot.org/news/gnu.html>
+
+In it, I make a strong case in support of membership.
+
+Share your opinion!
+===================
+
+I encourage members
+of the public to also voice their opinions about this topic. Therefore, I have
+publicised this link in several places:
+
+Thread on FSF LibrePlanet mailing list:
+<https://lists.gnu.org/archive/html/libreplanet-discuss/2024-05/msg00001.html>
+
+Thread on my Mastodon account:
+<https://mas.to/@libreleah/112428793049670713>
+
+Thread on Trisquel forums (FSF endorsed GNU+Linux distro, and de-facto stomping
+ground for many debates within the FSF community):
+
+<https://trisquel.info/en/forum/should-gnu-boot-become-gnu-canoeboot>
+
+And reddit: <https://www.reddit.com/r/linux/comments/1cqe924/should_canoeboot_become_gnu_canoeboot/>
+
+Discussion welcome!
+
+Final thoughts
+==============
+
+I'm taking a very much hands-off approach with this; I've sent the initial
+email and asked the public what they think, so it's up to them to say what
+they think.
+
+Whether Canoeboot is accepted or not, it will continue operating along its
+current course, providing a viable coreboot distro for diehard purists who
+adhere to the FSF and GNU project.
+
+I've always believed absolutely in the Four Freedoms, as defined by the GNU
+Free Software Definition; Libreboot merely takes a different approach these
+days in implementing it, while Canoeboot takes an approach that is precisely
+in line with that of the FSF. In so doing, I provide users with a choice of
+which vision they prefer, and I try as best I can to faithfully serve both
+communities.
+
+That's all for now. I'm probably expecting that nothing will come of this, but
+the intent is there. I'd be very happy though if they say yes!
+
+Follow-up
+=========
+
+In addition to the [original message](https://canoeboot.org/news/gnu.html#email-sent-to-gnu-eval), I also sent this message to GNU Eval:
+
+some people have actually asked me if i should contribute to GNU Boot, instead of trying to replace it with GNU Canoeboot. They have asked this outside of this email discussion, but some here may be wondering that.
+
+I'd like now to address it. Here goes:
+
+I actually submitted extensive patches to gnuboot in January 2024:
+
+<https://lists.gnu.org/archive/html/gnuboot-patches/2024-01/index.html>
+
+<https://web.archive.org/web/20240511074211/https://lists.gnu.org/archive/html/gnuboot-patches/2024-01/index.html>
+
+The patches were never reviewed, let alone merged, but they:
+
+* Replace "Libreboot" with "GNU Boot" in several places on the documentation (**THIS IS THE ONLY PATCH THEY MERGED**)
+* Fix major build issues, allowing GNU Boot to build on modern distros (GNU Boot only builds on Trisquel 10, my patches make it build on 12. also Gentoo-libre and Arch/Parabola)
+* Add Dell Latitude E6400 support
+* Fix hang in GRUB caused when there is a stuck key, by disabling the "Unknown key" spew message
+* ESP and btrfs subvol support in grub.cfg
+* Fixes building KGPE-D16 on newer distros, by skipping GNAT which isn't needed
+* Add gru bob support (rk3399 chromebooks, with free EC and *no* microcode) - ditto gru kevin
+* Keyboard fix for GRUB: force it to use scancode set 2 translated, instead of untranslated set 2 to work around buggy ECs such as Dell Latitude E6400
+* Avoid spewing the Unknown prefix message in GRUB
+* Adds the dell-flash-unlock tool from Nicholas Chin, allowing internal flashing from factory BIOS to GNU Boot, on the E6400
+* cache cbfstool/ifdtool builds to speed up build time
+* better caching of coreboot rom images during build, to speed up build time
+* Prevent future GRUB build errors by disabling -Werror
+* Support for *building* U-Boot as a coreboot payload, on gru bob/kevin chromebooks (GNU Boot only archives it, doesn't build it)
+
+A second patch set that I sent does the above, and also:
+
+* Updates GRUB, coreboot and SeaBIOS to newer revisions from late 2023 (GNU Boot uses late 2021 revisions)
+* Adds Argon2 KDF support, for booting from LUKS2-encrypted /boot (GNU Boot can't boot from encrypted LUKS2 /boot without this patch)
+* Reduced the number of modules in GRUB to only those needed, saving 100KB of space in flash
+* Update memtest86+ to v6.x instead of 5.x
+
+I sent all of these patches to GNU Boot while bored, and it only took me 1 day to implement all of them, re-using what I had done in Canoeboot months beforehand
+
+My patches fixed all of the fundamental issues with GNU Boot, without rewriting the build system; they use an older version of the Libreboot build system, prior to my re-write of the latter half of 2023 (my re-write makes the build system much smaller and more efficient.
+
+All of the above improvements *and much more* is in Canoeboot. In terms of development, Canoeboot is about 2 years ahead of Canoeboot; Canoeboot has since far surpassed the improvements sent to GNU Boot in January, so even if they did merge them now, they'd still be behind.
+
+I may be missing a thing or two, above, but one thing I'm not missing is my strong and stable commitment to the free software movement, even when I'm dealing with hostile project maintainers who won't even consider my patches.
+
+This is why I will no longer assist the GNU Boot project. Because I tried to help them; and this wasn't my first attempt to help, either.
+
+Whether GNU accepts Canoeboot or not, Canoeboot will continue to press full speed ahead. I say now it's 2 years ahead of GNU Boot;
+
+Next year it'll be 3 years ahead.

site/news/libreboot20231021.md

@@ -303,7 +303,7 @@ logs, combined:
 * Don't use the `-B` option in make commands.
 * Where no-microcode ROM images are provided, ensure that the ROM hashes still
   match when running the vendor inject script. This is only useful on the
-  Dell Latitude E6400, which is otherwise FSDG-compatible but (in Libreboot)
+  Dell Latitude E6400, which is otherwise blob-free but (in Libreboot)
   comes with or without microcode updates, and with or without the Nvidia VGA
   ROM (handled by vendor inject/download scripts) for dGPU variants. Verification
   previously failed, under certain conditions, when inserting that VGA ROM.
@@ -345,8 +345,8 @@ logs, combined:
   spaces in them.
 * Don't support removal of microcode (during release time) on untested targets.
   Set `microcode_required="y"` on most boards, but leave it set to `"n"` on
-  platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything FSDG
-  compatible, in other words.
+  platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything that
+  can be blob-free, in other words.
 * Improved Dell Latitude E6400 support; the same image now provides iGPU and
   dGPU support, since it's SeaBIOS-only anyway, so a VGA ROM is inserted into
   the same ROM that also enables libgfxinit, enabling the Intel or Nvidia GPU
@@ -1223,10 +1223,3 @@ On ASUS KFSN4-DRE, KCMA-D8 and KGPE-D16 boards, do this to remove microcode:
 
 We recommend *keeping* microcode updates, for reasons written in the [Binary
 Blob Reduction Policy](policy.md).
-
-There is also the recent launch of the [Canoeboot project](https://canoeboot.org/),
-an official sister project of Libreboot, maintained by Leah Rowe who also leads
-the Libreboot project; Canoeboot release images do not ever contain microcode
-updates in them. This is precisely why it will not be fixed in lbmk to fix
-the naming issue. The behaviour is simply disabled instead, becasue there's no
-point adding further complexity to the build system.

site/news/libreboot20231101.md

@@ -247,9 +247,3 @@ x4x (e.g. GA-G41M-ES2L) remains untested.
 Pineview (D945GCLF) is untested for S3.
 
 The AMD boards should work fine with suspend.
-
-------------------
-
-A corresponding [Canoeboot 20231101
-release](https://canoeboot.org/news/canoeboot20231101.html) is also available.
-

site/news/libreboot20231106.md

@@ -240,11 +240,6 @@ archives; E6430 ROM images will instead be provided in the next release. For
 now, you can build Libreboot from `lbmk.git`. See:
 [Building Libreboot from source](../docs/build/)
 
-------------------
-
-A corresponding [Canoeboot 20231107
-release](https://canoeboot.org/news/canoeboot20231107.html) is available.
-
 Errata
 ======
 

site/news/libreboot20240126.md

@@ -107,12 +107,6 @@ changes first):
   updated - notably, the E6430/E6530 and 8300CMT ports have been modified to
   define SPD location in devicetree, rather than `early_init.c` (thanks to
   Nicholas Chin for the warning).
-* U-Boot: support setting `xarch` too, to define which coreboot tree to use
-  for crossgcc. Although lbmk uses coreboot/default for u-boot, a special tree
-  of canoeboot had gru bob/kevin in `coreboot/cros` again, and it was seen that
-  u-boot was being compiled from crossgcc for coreboot/default, not coreboot/cros,
-  while the latter was used for actual coreboot firmware. In such a scenario,
-  lbmk can now correctly re-use the same crossgcc build, thus saving time.
 * Re-use crossgcc builds across coreboot trees, when possible, to speed up the
   overall build time when building across multiple trees. This is done
   using the `xtree` and `tree_depend` variables in `target.cfg` files, for
@@ -201,16 +195,6 @@ changes first):
   the script on certain targets. Patch courtesy of Leah Rowe.
 * `script/vendor/inject`: Fixed a bad error check, when running `cd` to switch
   to the ROM images directory, when creating archives. Patch courtesy Leah Rowe.
-* Don't delete microcode updates on GM45 ROMs in releases. Microcode updates
-  are always included in builds, but the release build scripts were copying
-  certain ROM images to cerate versions (alongside the default ones) with
-  microcode disabled. This is no longer required, due to the existence of
-  the [Canoeboot project](https://canoeboot.org/). You can also still delete them
-  very easily, using cbfstool, if they are included in a given set of images,
-  so this change reduces the uncompressed size of the ROM images in releases.
-  This also means that the file names of all ROM images now match the file names
-  in canoeboot images, when dealing with a mainboard supported by both projects.
-  Patch courtesy of Leah Rowe.
 * `script/update/release`: Don't test `script/vendor/inject` at the end. This
   is regularly tested anyway, during development, so it's a waste of time to
   have it done by the release build script. This reduces the amount of time

site/news/libreboot20240504.md

@@ -25,33 +25,13 @@ is [software freedom](https://writefreesoftware.org/learn). With use of GRUB
 in the flash, you can make use of many advanced features such as the ability
 to [boot from an encrypted /boot partition](../docs/linux/)
 and [verify kernel GPG signature at boot time](../docs/linux/grub_hardening.md).
-Libreboot's GRUB payload is *heavily* patched; for example, today's release
-uses GRUB based on version 2.12, but Libreboot adds argon2 KDF support (for
-LUKS2) and xHCI support - you can use USB 3.0 devices natively, in GRUB,
-including distro install media via USB3. This means that with the right
-coreboot config, you could use Libreboot's GRUB even on modern machines that lack
-PS/2 keyboard controllers or EHCI support; many modern machines only have USB3.
-
-Another example of the type of benefit you could get from Libreboot: you can
-boot from NVMe SSDs in the SeaBIOS payload, if your board can take them (e.g.
-desktop board with an NVMe adapter in the PCI-E slot). If your vendor's BIOS/UEFI
-firmware only supports SATA, then this is a nice bonus for you. With Libreboot,
-you get continued firmware updates over time, adding new features on both older
-and newer hardware. Libreboot still provides updates for machines that are
-nearly 20 years old, while also supporting newer machines. More hardware support
-is being added all the time!
-
-These and other examples are just the start. Libreboot provides a *superior* boot
-experience compared to proprietary BIOS/UEFI, giving you the same power and level of
-control that running a Linux or BSD operating system does. It's *your* computer
-to boot however you wish. Libreboot lets you get more out of the hardware. All
-your favourite Linux distros and BSDs are compatible, even Qubes(on most machines).
 
 If you're fed up of the control that proprietary UEFI vendors have over you,
 then Libreboot is *for you*. Although many would agree that it is a major step
-forward for most users, it's actually a conservative idea socially. It used to
+forward for most users, it's actually a very old idea. Old is often better. It used to
 be that computers were much more open for learning, and tinkering. Libreboot
 implements this old idea in spirit and in practise, helping you wrest back control.
+
 Unlike the hardware vendors, Libreboot does not see *you* as a *security threat*;
 we regard the ability to use, study, modify and redistribute software freely to
 be a human right that everyone *must* have, and the same is true of hardware.
@@ -144,17 +124,6 @@ This release supports the following hardware:
 -   [ASUS Chromebook Flip C101 (gru-bob)](../docs/install/chromebooks.md)
 -   [Samsung Chromebook Plus (v1) (gru-kevin)](../docs/install/chromebooks.md)
 
-Canoeboot 20240504 also released!
-=========================
-
-I've done simultaneous Canoeboot and Libreboot releases, today. I strongly
-recommend that everyone uses Libreboot, which adheres to Libreboot's
-own [Binary Blob Reduction Policy](policy.md) and therefore supports more
-boards. Canoeboot is a parallel effort, that I also maintain, but Canoeboot
-adheres to GNU FSDG as policy and therefore supports far fewer mainboards. See:
-
-[Canoeboot 20240504 release](https://canoeboot.org/news/canoeboot20240504.html)
-
 New mainboard added
 ====================
 
@@ -172,7 +141,7 @@ is still broken and therefore disabled, but pressing the power button works.
 Work done since Libreboot 20230625
 ============================
 
-Today's release, Libreboot 20240504, is a stable. The *previous* stable release
+Today's release, Libreboot 20240504, is a stable release. The *previous* stable release
 was Libreboot 20230625, but there have been a number of *testing* releases
 between that and today's release.
 

site/news/policy.de.md

@@ -176,365 +176,3 @@ exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
 * <https://libresilicon.com/>
 
 (Sam literally makes CPUs in his garage)
-
-Problems with RYF criteria
-==========================
-
-Libreboot previously complied with FSF RYF criteria, but it now adheres to a
-much more pragmatic policy aimed at providing more freedom to more people, in a
-more pragmatic way. You can read those guidelines by following this URL:
-
-* FSF Respects Your Freedom (RYF) guidelines:
-<https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
-
-Put simply, the RYF guidelines pertain to commercial products, with the
-stipulation that they must not contain proprietary software, or known privacy
-issues like backdoors.
-
-The total exclusion of all proprietary software is currently not feasible. For
-example, proprietary SDR firmware in WiFi chipsets, firmware in AHCI devices
-like HDDs or SSDs, and the like. The FSF RYF guidelines state the following
-exception, to mitigate this fact:
-
-* "However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."
-
-*This should be
-rejected on ideological grounds*. The rest of libreboot's policy and overall
-ideology expressed, in this article, will be based largely on that rejection.
-The definition of *product software* is completely arbitrary; software is
-software, and software should always be *libre*. Instead of making such
-exceptions, more hardware should be encouraged, with help given to provide as
-much freedom as possible, while providing education to users about any pitfalls
-they may encounter, and encourage freedom at all levels. When an organisation
-like the FSF makes such bold exceptions as above, it sends the wrong message,
-by telling people essentially to sweep these other problems under the rug, just
-because they involve software that happens to run on a "secondary processor".
-If the software is possible to update by the user, then it should be libre,
-regardless of whether the manufacturer *intended* for it to be upgraded or not.
-Where it really *isn't* possible to update such software, proprietary or not,
-advice should be given to that effect. Education is important, and the FSF's
-criteria actively discourages such education; it creates a false hope that
-everything is great and wonderful, just because the software on one arbitrary
-level is all perfect.
-
-This view of the FSF's, as expressed in the quoted paragraph, assumes that
-there is primarily *one* main processor controlling your system. On many
-modern computers, this is *no longer true*.
-
-Libre *software* does not exist in a vacuum, but we had less freedom in the
-past, especially when it came to hardware, so *software* was our primary focus.
-
-The ability to study, adapt, share and use/re-use software freely is important,
-but there is a lot of nuance when it comes to *boot firmware*, nuance which is
-largely non-existent outside of firmware development, or kernel development.
-Most typical application/system software is high level and portable, but boot
-firmware has to be written for each specific machine, and due to the way
-hardware works, there are many trade-offs made, including by the FSF when
-defining what standards should apply *in practise*.
-
-The fact that almost nobody talks about the EC firmware is *because* of the
-Respects Your Freedom certification. In reality, the EC firmware is crucial
-to user freedom, and ought to be free, but it is completely disregarded by
-the FSF as *part of the hardware*. This is wrong, and the FSF should actively
-encourage people to free it, on every laptop!
-
-Other firmware currently outside the reach of the libreboot project are covered
-in the libreboot FAQ page. For example, HDD/SSD firmware is covered in the FAQ.
-Again, completely disregarded and shrugged off by the FSF.
-
-The libreboot project will not hide or overlook these issues, because they are
-indeed critical, but again, currently outside the scope of what the Libreboot
-build system does. At the moment, the Libreboot build system concerns itself
-just with coreboot (and payloads), but this ought to change in the future.
-
-Examples of FSF *sweeping blobs under the rug*
-----------------------------------------------
-
-Over the years, there have been numerous cases where the FSF actively fails to
-provide incentive for levels of software freedom, such as:
-
-* TALOS II "OpenPOWER" workstation from Raptor Engineering USA. It contains a
-  broadcom NIC inside it which requires firmware, and that firmware was non-free.
-  The FSF were willing to ignore it, and certify the TALOS II product under RYF,
-  but Timothy Pearson of Raptor Engineering had it freed anyway, without being
-  told to. Hugo Landau reverse engineered the specification and Evan Lojewski
-  wrote libre firmware. See:
-  See: <https://www.devever.net/~hl/ortega> and <https://github.com/meklort/bcm5719-fw>
-* FSF once endorsed the ThinkPad X200, as sold by [Minifree Ltd](https://minifree.org),
-  which contains the Intel ME; the bootrom is still there, as is the ME
-  coprocessor, but the ME is put into a disabled state via the Intel Flash
-  Descriptor, and the ME firmware in flash is removed. However, the ME is an
-  entire coprocessor which, with libre firmware, could be used for a great many
-  things. In the Libreboot and coreboot projects, there has always been interest
-  in this but the FSF disregards it entirely. The X200 product they certified
-  came with Libreboot pre-installed.
-* Libreboot has a utility written by I, Leah Rowe, that generates ICH9M flash
-  descriptors and GbE NVM images from scratch. This is necessary to configure
-  the machine, but these are binary blobs otherwise; the FSF would have been
-  quite content to certify the hardware anyway since these were non-software
-  blobs in a format fully documented by Intel (they are just binary configuration
-  files), but I went ahead and wrote ich9gen anyway. With ich9gen, you can
-  more easily modify the descriptor/gbe regions for your firmware image. See:
-  <https://libreboot.org/docs/install/ich9utils.html> - libreboot also has this
-* FSF once endorsed the ThinkPad T400 with Libreboot, as sold by Minifree. This
-  machine comes in two versions: with ATI+Intel GPU, or only Intel GPU. If ATI
-  GPU, it's possible to configure the machine so that either GPU is used. If the
-  ATI GPU is to be used, a binary blob is needed for initialization, though the
-  driver for it is entirely libre. *The FSF* ignored this fact and endorsed the
-  hardware, so long as Libreboot does not enable the ATI GPU or tell people how
-  to enable it. The *Intel* GPU on that machine has libre initialization code by
-  the coreboot project, and a fully libre driver in both Linux and BSD kernels.
-  In the configuration provided by Libreboot, the ATI GPU is completely disabled
-  and powered down.
-* All Libreboot-compatible ThinkPads contain proprietary Embedded Controller
-  firmware, which is user-flashable (*and intended for update by the
-  manufacturer*). The FSF chose to ignore the EC firmware, under
-  their *secondary processor* exemption. See:
-  <http://libreboot.org/faq.html#ec-embedded-controller-firmware>
-
-In all of the above cases, the FSF could have been stricter, and bolder, by
-insisting that these *additional* problems for freedom were solved. They did
-not. There are many other examples of this, but the purpose of this article is
-not to list all of them (otherwise, a book could be written on the subject).
-
-Problems with FSDG
-------------------
-
-<img tabindex=1 src="https://av.libreboot.org/firmware.png" /><span class="f"><img src="https://av.libreboot.org/firmware.png" /></span>
-
-The FSF maintains another set of criteria, dubbed Free System Distribution
-Guidelines (GNU FSDG)]
-
-The FSDG criteria is separate from RYF, but has similar problems. FSDG is
-what the FSF-endorsed GNU+Linux distros comply with. Basically, it bans
-all proprietary software, including device firmware. This may seem noble, but
-it's extremely problematic in the context of firmware. Food for thought:
-
-* Excluding vendor blobs in the linux kernel is *bad*. Proprietary firmware
-  is *also bad*. Including them is a wiser choice, if strong education is also
-  provided about *why they are bad* (less freedom). If you expose them to
-  the user, and tell them about it, there is greater incentive (by simple
-  reminder of their existence) to reverse engineer and replace them.
-* Firmware *in your OS kernel* is *good*. The FSF simultaneously gives the OK
-  for hardware *with those same binary blobs* if the firmware is embedded
-  into a ROM/flash chip on the device, or embedded in some processor. If the
-  firmware is on separate ROM/flash, it could still be replaced by the user via
-  reverse engineering, but then you would probably have to do some soldering
-  (replace the chip on the card/device). *If the firmware is loaded by the
-  OS kernel, then the firmware is exposed to the user and it can be more
-  easily replaced. FSF criteria in this regard encourages hardware designers
-  to hide the firmware instead, making actual (software) freedom less likely!*
-
-Besides this, FSDG seems OK. Any libre operating system should ideally not
-have proprietary *drivers* or *applications*.
-
-Hardware manufacturers like to shove everything into firmware because their
-product is often poorly designed, so they later want to provide workarounds in
-firmware to fix issues. In many cases, a device will already have firmware on it
-but require an update supplied to it by your OS kernel.
-
-The most common example of proprietary firmware in Linux is for wifi devices.
-This is an interesting use-case scenario, with source code, because it could be
-used for owner-controlled *software defined radio*.
-
-The *Debian* way is ideal. The Debian GNU+Linux distribution is entirely libre
-by default, and they include extra firmware if needed, which they have in a
-separate repository containing it. If you only want firmware, it is
-trivial to get installer images with it included, or add that to your installed
-system. They tell you how to do it, which means that they are helping people
-to get *some* freedom *rather than none*. This is an inherently pragmatic
-way to do things, and it's now how Libreboot does it.
-
-More context regarding Debian is available in this blog post:
-<https://blog.einval.com/2022/04/19#firmware-what-do-we-do> - in it, the
-author, a prominent Debian developer, makes excellent points about device
-firmware similar to the (Libreboot) article that you're reading now. It's
-worth a read! As of October 2022, Debian has voted to include device firmware
-by *default*, in following Debian releases. It used to be that Debian excluded
-such firmware, but allowed you to add it.
-
-OpenBSD is very much the same, but they're clever about it: during the initial
-boot, after installation, it tells you exactly what firmware is needed and
-updates that for you. It's handled in a very transparent way, by
-their `fw_update` program which you can read about here:
-
-<https://man.openbsd.org/fw_update>
-
-*Banning* linux-firmware specifically is a threat to freedom in the long term,
-because new users of GNU+Linux might be discouraged from using the OS if their
-hardware doesn't work. You might say: just buy new hardware! This is often not
-possible for users, and the user might not have the skill to reverse engineer
-it either.
-
-More detailed insight about microcode
-=====================================
-
-[Releases after 20230423 will provide separate ROM images with microcode
-excluded, alongside the default ones that include microcode.](microcode.md)
-
-To be clear: it is preferable that microcode be libre. The microcode on Intel
-and AMD systems *are* proprietary. Facts and feelings rarely coincide; the
-purpose of this section is to spread *facts*.
-
-The libreboot build system now enables microcode updates *by default.*
-
-Not including CPU microcode updates is an absolute disaster for system
-stability and security.
-
-Making matters worse, that very same text quoted from the FSF RYF criteria in
-fact specifically mentions microcode. Quoted again for posterity:
-
-*"However, there is one exception for secondary embedded processors. The
-exception applies to software delivered inside auxiliary and low-level
-processors and FPGAs, within which software installation is not intended after
-the user obtains the product. This can include, for instance, microcode inside
-a processor, firmware built into an I/O device, or the gate pattern of an FPGA.
-The software in such secondary processors does not count as product software."*
-
-Here, it is discussing the microcode that is burned into *mask ROM* on the CPU
-itself. It is simultaneously not giving the OK for microcode *updates* supplied
-by either coreboot or the Linux kernel; according to the FSF, these are an
-attack on your freedom, but the older, buggier microcode burned into ROM is OK.
-
-The CPU already has microcode burned into mask ROM. The microcode configures
-logic gates in the CPU, to implement an instruction set, via special *decoders*
-which are fixed-function; it is not possible, for example, to implement a RISCV
-ISA on an otherwise x86 processor. It is only possible for the microcode to
-implement x86, or *broken* x86, and the default microcode is almost always
-*broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
-these processors.
-
-The FSF believes
-that these x86 microcode updates (on Intel/AMD) allow you to completely create
-a new CPU that is fundamentally different than x86. This is not true. It is also
-not true that *all* instructions in x86 ISA are implemented with microcode. In
-some cases, hardcoded circuitry is used! The microcode updates are more like
-tiny one liner patches here and there in a git repository, by way of analogy.
-To once again get in the head-space of the FSF: these updates cannot do the CPU
-equivalent of re-factoring an entire codebase. They are *hot fixes*, nothing
-more!
-
-Not including these updates will result in an unstable/undefined state. Intel
-themselves define which bugs affect which CPUs, and they define workarounds, or
-provide fixes in microcode. Based on this, software such as the Linux kernel
-can work around those bugs/quirks. Also, upstream versions of the Linux kernel
-can update the microcode at boot time (however, it is recommend still to do it
-from coreboot, for more stable memory controller initialization or “raminit”).
-Similar can be said about AMD CPUs.
-
-Here are some examples of where lack of microcode updates affected *Libreboot*,
-forcing Libreboot to work around changes made upstream in coreboot, changes
-that were *good* and made coreboot behave in a more standards-compliant manner
-as per Intel specifications. Libreboot had to *break* coreboot to retain
-certain other functionalities, on some GM45/ICH9M thinkpads:
-
-<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>
-
-<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc7e8736be0c9b51>
-
-These patches revert *bug fixes* in coreboot, fixes that happen to break other
-functionality but only when microcode updates are excluded. The most
-technically correct solution is to *not* apply the above patches, and instead
-supply microcode updates!
-
-Pick your poison. Not adding the updates is *irresponsible*, and ultimately
-futile, because you still end up with proprietary microcode, but you just get
-an older, buggier version instead!
-
-This shift in project policy does not affect your freedom at all, because you
-still otherwise have older, buggier microcode anyway. However, it does improve
-system reliability by including the updates!
-
-Such pragmatic policy is *superior* to the *dogma* that Libreboot users once
-had to endure. Simply put, the Libreboot project aims to give users as much
-freedom as is possible for their hardware; this was always the case, but this
-mentality is now applied to [a lot] more hardware.
-
-Other considerations
-====================
-
-Also not covered strictly by Libreboot: OSHW and Right To Repair. Freedom at
-the silicon level would however be amazing, and efforts already exist; for
-example, look at the RISCV ISA (in practise, actual fabrication is still
-proprietary and not under your control, but RISCV is a completely libre CPU
-design that companies can use, instead of having to use proprietary ARM/x86 and
-so on). Similarly, Right To Repair (ability to repair your own device, which
-implies free access to schematics and diagrams) is critical, for the same
-reason that Libre Software (Right To Hack) is critical!
-
-OSHW and Right To Repair are not covered at all by RYF (FSF's Respects Your
-Freedom criteria), the criteria which Libreboot previously complied with.
-RYF also makes several concessions that are ultimately damaging, such as
-the *software as circuitry* policy which is, frankly, nonsensical. ROM is still
-software. There was a time when the FSF didn't consider BIOS software a freedom
-issue, just because it was burned onto a mask ROM instead of *flashed*; those
-FSF policies ignore the fact that, with adequate soldering skills, it is trivial
-to replace stand-alone mask ROM ICs with compatible flash memory.
-
-Conclusion
-==========
-
-RYF isn't *wrong* per se, just flawed. It is correct in some ways and if
-complied with, the result *does* give many freedoms to the user, but RYF
-completely disregards many things that are now possible, including freedoms at
-the hardware level (the RYF criteria only covers *software*). Those guidelines
-are written with assumptions that were still true in the 1990s, but the world
-has since evolved. The libreboot project rejects those policies in their
-entirety, and instead takes a pragmatic approach.
-
-The conclusion that should be drawn from all of this is as follows:
-
-*Following* FSF criteria does not damage anything, but that criteria is very
-conservative. Its exemptions should be *disregarded* and entirely ignored.
-RYF is no longer fit for purpose, and should be rewritten to create
-a *more strict* set of guidelines, without all the loopholes or exemptions.
-As has always been the case, Libreboot tries to always go above and beyond, but
-the Libreboot project does not see RYF as a *gold standard*. There are levels
-of freedom possible now that the RYF guidelines do not cover at all, and in
-some cases even actively discourage/dis-incentivize because it makes compromises
-based on assumptions that are no longer true. 
-
-Sad truth: RYF actively encourages *less* freedom, by not being bold enough.
-It sets a victory flag and says *mission accomplished*, despite the fact
-that the work is *far* from complete!
-
-If followed *with exemptions unchallenged*, RYF may in some cases encourage
-companies to *sweep under the rug* any freedom issues that exist, where it
-concerns proprietary firmware not running on the host CPU (such as the
-Embedded Controller firmware).
-
-I propose that new guidelines be written, to replace RYF. These new guidelines
-will do away with all exemptions/loopholes, and demand that *all* software be
-libre on the machine, or as much as possible. Instead of only promoting products
-that meet some arbitrary standard, simply catalog all systems on a grand
-*database* of sorts (like h-node.org, but better), which will define exactly
-what *hardware* **and** software issues exist on each device. Include Right to
-Repair and OSHW (including things like RISCV) in the most "ideal"
-standard machine; the gold standard is libre *silicon*, like what Sam Zeloof
-and others are working on nowadays.
-
-This new set of criteria should not attempt to hide or ignore *anything*. It
-should encourage people to push the envelope and innovate, so that we can have
-much *more* freedom than is currently possible. Necessity is the mother of all
-invention, and freedom is an important goal in every aspect of life, not just
-computing.
-
-Don't call it "Respects Your Freedom" or something similar. Instead, call it
-something like: the freedom catalog. And actually focus on hardware, not just
-software!
-
-Other resources
-===============
-
-Ariadne Conill's RYF blog post
-------------------------------
-
-Ariadne Conill, security team chair of *Alpine Linux*, posted a very robust
-article about RYF, with similar points made when compared to *this* article.
-However, Ariadne goes into detail on several other examples of problems with
-the FSF RYF criteria; for example, it talks about the *Novena* product by
-Bunnie.
-
-It's worth a read! Link:
-
-<https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/>

site/news/policy.md

@@ -2,22 +2,6 @@
 % Leah Rowe
 % 4 January 2022 (updated 15 November 2022)
 
-The *[Canoeboot project](https://canoeboot.org/)* is an official sister project
-of Libreboot, that implements the GNU Free System Distribution Guidelines
-or *GNU FSDG* as policy, instead of the policy below. Canoeboot is maintained by
-Leah Rowe, the same person who founded the Libreboot project, and who maintains
-Libreboot releases to this day. Criticism of GNU FSDG is provided, in the
-article below.
-
-Canoeboot provides a clear example as to the merits of the policy seen below, by
-showing what Libreboot would be if it *didn't* adopt that policy; it is vastly
-inferior to Libreboot, due to weaker hardware support and less freedom of choice
-for users. Canoeboot is engineered to a high standard, basing off of each
-Libreboot release, but you should still use *Libreboot*. Canoeboot is only
-a *proof of concept*.
-
-And now, without further ado,
-
 Introduction
 ============
 
@@ -184,375 +168,3 @@ exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
 * <https://libresilicon.com/>
 
 (Sam literally makes CPUs in his garage)
-
-Problems with RYF criteria
-==========================
-
-Libreboot previously complied with FSF RYF criteria, but it now adheres to a
-much more pragmatic policy aimed at providing more freedom to more people, in a
-more pragmatic way. You can read those guidelines by following this URL:
-
-* FSF Respects Your Freedom (RYF) guidelines:
-<https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
-
-Put simply, the RYF guidelines pertain to commercial products, with the
-stipulation that they must not contain proprietary software, or known privacy
-issues like backdoors.
-
-The total exclusion of all proprietary software is currently not feasible. For
-example, proprietary SDR firmware in WiFi chipsets, firmware in AHCI devices
-like HDDs or SSDs, and the like. The FSF RYF guidelines state the following
-exception, to mitigate this fact:
-
-* "However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."
-
-*This should be
-rejected on ideological grounds*. The rest of libreboot's policy and overall
-ideology expressed, in this article, will be based largely on that rejection.
-The definition of *product software* is completely arbitrary; software is
-software, and software should always be *libre*. Instead of making such
-exceptions, more hardware should be encouraged, with help given to provide as
-much freedom as possible, while providing education to users about any pitfalls
-they may encounter, and encourage freedom at all levels. When an organisation
-like the FSF makes such bold exceptions as above, it sends the wrong message,
-by telling people essentially to sweep these other problems under the rug, just
-because they involve software that happens to run on a "secondary processor".
-If the software is possible to update by the user, then it should be libre,
-regardless of whether the manufacturer *intended* for it to be upgraded or not.
-Where it really *isn't* possible to update such software, proprietary or not,
-advice should be given to that effect. Education is important, and the FSF's
-criteria actively discourages such education; it creates a false hope that
-everything is great and wonderful, just because the software on one arbitrary
-level is all perfect.
-
-This view of the FSF's, as expressed in the quoted paragraph, assumes that
-there is primarily *one* main processor controlling your system. On many
-modern computers, this is *no longer true*.
-
-Libre *software* does not exist in a vacuum, but we had less freedom in the
-past, especially when it came to hardware, so *software* was our primary focus.
-
-The ability to study, adapt, share and use/re-use software freely is important,
-but there is a lot of nuance when it comes to *boot firmware*, nuance which is
-largely non-existent outside of firmware development, or kernel development.
-Most typical application/system software is high level and portable, but boot
-firmware has to be written for each specific machine, and due to the way
-hardware works, there are many trade-offs made, including by the FSF when
-defining what standards should apply *in practise*.
-
-The fact that almost nobody talks about the EC firmware is *because* of the
-Respects Your Freedom certification. In reality, the EC firmware is crucial
-to user freedom, and ought to be free, but it is completely disregarded by
-the FSF as *part of the hardware*. This is wrong, and the FSF should actively
-encourage people to free it, on every laptop!
-
-Other firmware currently outside the reach of the libreboot project are covered
-in the libreboot FAQ page. For example, HDD/SSD firmware is covered in the FAQ.
-Again, completely disregarded and shrugged off by the FSF.
-
-The libreboot project will not hide or overlook these issues, because they are
-indeed critical, but again, currently outside the scope of what the Libreboot
-build system does. At the moment, the Libreboot build system concerns itself
-just with coreboot (and payloads), but this ought to change in the future.
-
-Examples of FSF *sweeping blobs under the rug*
-----------------------------------------------
-
-Over the years, there have been numerous cases where the FSF actively fails to
-provide incentive for levels of software freedom, such as:
-
-* TALOS II "OpenPOWER" workstation from Raptor Engineering USA. It contains a
-  broadcom NIC inside it which requires firmware, and that firmware was non-free.
-  The FSF were willing to ignore it, and certify the TALOS II product under RYF,
-  but Timothy Pearson of Raptor Engineering had it freed anyway, without being
-  told to. Hugo Landau reverse engineered the specification and Evan Lojewski
-  wrote libre firmware. See:
-  See: <https://www.devever.net/~hl/ortega> and <https://github.com/meklort/bcm5719-fw>
-* FSF once endorsed the ThinkPad X200, as sold by [Minifree Ltd](https://minifree.org),
-  which contains the Intel ME; the bootrom is still there, as is the ME
-  coprocessor, but the ME is put into a disabled state via the Intel Flash
-  Descriptor, and the ME firmware in flash is removed. However, the ME is an
-  entire coprocessor which, with libre firmware, could be used for a great many
-  things. In the Libreboot and coreboot projects, there has always been interest
-  in this but the FSF disregards it entirely. The X200 product they certified
-  came with Libreboot pre-installed.
-* Libreboot has a utility written by I, Leah Rowe, that generates ICH9M flash
-  descriptors and GbE NVM images from scratch. This is necessary to configure
-  the machine, but these are binary blobs otherwise; the FSF would have been
-  quite content to certify the hardware anyway since these were non-software
-  blobs in a format fully documented by Intel (they are just binary configuration
-  files), but I went ahead and wrote ich9gen anyway. With ich9gen, you can
-  more easily modify the descriptor/gbe regions for your firmware image. See:
-  <https://libreboot.org/docs/install/ich9utils.html> - libreboot also has this
-* FSF once endorsed the ThinkPad T400 with Libreboot, as sold by Minifree. This
-  machine comes in two versions: with ATI+Intel GPU, or only Intel GPU. If ATI
-  GPU, it's possible to configure the machine so that either GPU is used. If the
-  ATI GPU is to be used, a binary blob is needed for initialization, though the
-  driver for it is entirely libre. *The FSF* ignored this fact and endorsed the
-  hardware, so long as Libreboot does not enable the ATI GPU or tell people how
-  to enable it. The *Intel* GPU on that machine has libre initialization code by
-  the coreboot project, and a fully libre driver in both Linux and BSD kernels.
-  In the configuration provided by Libreboot, the ATI GPU is completely disabled
-  and powered down.
-* All Libreboot-compatible ThinkPads contain proprietary Embedded Controller
-  firmware, which is user-flashable (*and intended for update by the
-  manufacturer*). The FSF chose to ignore the EC firmware, under
-  their *secondary processor* exemption. See:
-  <http://libreboot.org/faq.html#ec-embedded-controller-firmware>
-
-In all of the above cases, the FSF could have been stricter, and bolder, by
-insisting that these *additional* problems for freedom were solved. They did
-not. There are many other examples of this, but the purpose of this article is
-not to list all of them (otherwise, a book could be written on the subject).
-
-Problems with FSDG
-------------------
-
-<img tabindex=1 src="https://av.libreboot.org/firmware.png" /><span class="f"><img src="https://av.libreboot.org/firmware.png" /></span>
-
-The FSF maintains another set of criteria, dubbed Free System Distribution
-Guidelines (GNU FSDG)]. They recommend a special version of the Linux kernel,
-dubbed *linux-libre*, which removes all vendor code from upstream. These
-vendor files are required for certain hardware to work correctly.
-
-The FSDG criteria is separate from RYF, but has similar problems. FSDG is
-what the FSF-endorsed GNU+Linux distros comply with. Basically, it bans
-all proprietary software, including device firmware. This may seem noble, but
-it's extremely problematic in the context of firmware. 
-
-*Banning* linux-firmware specifically is a threat to freedom in the long term,
-because new users of GNU+Linux might be discouraged from using the OS if their
-hardware doesn't work. You might say: just buy new hardware! This is often not
-possible for users, and the user might not have the skill to reverse engineer
-it either. **Banning such firmware constitutes
-*[censorship](https://en.wikipedia.org/wiki/Book_burning)*, in the name of
-freedom, but all it does is reduce freedom of choice; somebody else has already
-made that decision for you, *against* you.** You should not use linux-libre at
-all. Some wisdom:
-
-* Excluding vendor blobs in the linux kernel is *bad*. Proprietary firmware
-  is *also bad*. Including them is a wiser choice, if strong education is also
-  provided about *why they are bad* (less freedom). If you expose them to
-  the user, and tell them about it, there is greater incentive (by simple
-  reminder of their existence) to reverse engineer and replace them.
-* Firmware *in your OS kernel* is *good*. The FSF simultaneously gives the OK
-  for hardware *with those same binary blobs* if the firmware is embedded
-  into a ROM/flash chip on the device, or embedded in some processor. If the
-  firmware is on separate ROM/flash, it could still be replaced by the user via
-  reverse engineering, but then you would probably have to do some soldering
-  (replace the chip on the card/device). *If the firmware is loaded by the
-  OS kernel, then the firmware is exposed to the user and it can be more
-  easily replaced. FSF criteria in this regard encourages hardware designers
-  to hide the firmware instead, making actual (software) freedom less likely!*
-
-Besides this, FSDG seems OK. Any libre operating system should ideally not
-have proprietary *drivers* or *applications*. Libreboot *previously* adhered
-to FSDG, but now takes a more pragmatic approach when it comes to things like
-CPU microcode or *EC firmware*.
-
-Hardware manufacturers like to shove everything into firmware because their
-product is often poorly designed, so they later want to provide workarounds in
-firmware to fix issues. In many cases, a device will already have firmware on it
-but require an update supplied to it by your OS kernel.
-
-The most common example of proprietary firmware in Linux is for wifi devices.
-This is an interesting use-case scenario, with source code, because it could be
-used for owner-controlled *software defined radio*.
-
-The *Debian* way is ideal. The Debian GNU+Linux distribution is entirely libre
-by default, and they include extra firmware if needed, which they have in a
-separate repository containing it. If you only want firmware, it is
-trivial to get installer images with it included, or add that to your installed
-system. They tell you how to do it, which means that they are helping people
-to get *some* freedom *rather than none*. This is an inherently pragmatic
-way to do things, and it's now how Libreboot does it.
-
-More context regarding Debian is available in this blog post:
-<https://blog.einval.com/2022/04/19#firmware-what-do-we-do> - in it, the
-author, a prominent Debian developer, makes excellent points about device
-firmware similar to the (Libreboot) article that you're reading now. It's
-worth a read! As of October 2022, Debian has voted to include device firmware
-by *default*, in following Debian releases. It used to be that Debian excluded
-such firmware, but allowed you to add it.
-
-OpenBSD is very much the same, but they're clever about it: during the initial
-boot, after installation, it tells you exactly what firmware is needed and
-updates that for you. It's handled in a very transparent way, by
-their `fw_update` program which you can read about here:
-
-<https://man.openbsd.org/fw_update>
-
-OpenBSD is great.
-
-More detailed insight about microcode
-=====================================
-
-[Releases after 20230423 will provide separate ROM images with microcode
-excluded, alongside the default ones that include microcode.](microcode.md)
-
-To be clear: it is preferable that microcode be libre. The microcode on Intel
-and AMD systems *are* proprietary. Facts and feelings rarely coincide; the
-purpose of this section is to spread *facts*.
-
-The libreboot build system now enables microcode updates *by default.*
-
-Not including CPU microcode updates is an absolute disaster for system
-stability and security.
-
-Making matters worse, that very same text quoted from the FSF RYF criteria in
-fact specifically mentions microcode. Quoted again for posterity:
-
-*"However, there is one exception for secondary embedded processors. The
-exception applies to software delivered inside auxiliary and low-level
-processors and FPGAs, within which software installation is not intended after
-the user obtains the product. This can include, for instance, microcode inside
-a processor, firmware built into an I/O device, or the gate pattern of an FPGA.
-The software in such secondary processors does not count as product software."*
-
-Here, it is discussing the microcode that is burned into *mask ROM* on the CPU
-itself. It is simultaneously not giving the OK for microcode *updates* supplied
-by either coreboot or the Linux kernel; according to the FSF, these are an
-attack on your freedom, but the older, buggier microcode burned into ROM is OK.
-
-The CPU already has microcode burned into mask ROM. The microcode configures
-logic gates in the CPU, to implement an instruction set, via special *decoders*
-which are fixed-function; it is not possible, for example, to implement a RISCV
-ISA on an otherwise x86 processor. It is only possible for the microcode to
-implement x86, or *broken* x86, and the default microcode is almost always
-*broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
-these processors.
-
-The FSF believes
-that these x86 microcode updates (on Intel/AMD) allow you to completely create
-a new CPU that is fundamentally different than x86. This is not true. It is also
-not true that *all* instructions in x86 ISA are implemented with microcode. In
-some cases, hardcoded circuitry is used! The microcode updates are more like
-tiny one liner patches here and there in a git repository, by way of analogy.
-To once again get in the head-space of the FSF: these updates cannot do the CPU
-equivalent of re-factoring an entire codebase. They are *hot fixes*, nothing
-more!
-
-Not including these updates will result in an unstable/undefined state. Intel
-themselves define which bugs affect which CPUs, and they define workarounds, or
-provide fixes in microcode. Based on this, software such as the Linux kernel
-can work around those bugs/quirks. Also, upstream versions of the Linux kernel
-can update the microcode at boot time (however, it is recommend still to do it
-from coreboot, for more stable memory controller initialization or “raminit”).
-Similar can be said about AMD CPUs.
-
-Here are some examples of where lack of microcode updates affected *Libreboot*,
-forcing Libreboot to work around changes made upstream in coreboot, changes
-that were *good* and made coreboot behave in a more standards-compliant manner
-as per Intel specifications. Libreboot had to *break* coreboot to retain
-certain other functionalities, on some GM45/ICH9M thinkpads:
-
-<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>
-
-<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc7e8736be0c9b51>
-
-These patches revert *bug fixes* in coreboot, fixes that happen to break other
-functionality but only when microcode updates are excluded. The most
-technically correct solution is to *not* apply the above patches, and instead
-supply microcode updates!
-
-Pick your poison. Not adding the updates is *irresponsible*, and ultimately
-futile, because you still end up with proprietary microcode, but you just get
-an older, buggier version instead!
-
-This shift in project policy does not affect your freedom at all, because you
-still otherwise have older, buggier microcode anyway. However, it does improve
-system reliability by including the updates!
-
-Such pragmatic policy is *superior* to the *dogma* that Libreboot users once
-had to endure. Simply put, the Libreboot project aims to give users as much
-freedom as is possible for their hardware; this was always the case, but this
-mentality is now applied to [a lot] more hardware.
-
-Other considerations
-====================
-
-Also not covered strictly by Libreboot: OSHW and Right To Repair. Freedom at
-the silicon level would however be amazing, and efforts already exist; for
-example, look at the RISCV ISA (in practise, actual fabrication is still
-proprietary and not under your control, but RISCV is a completely libre CPU
-design that companies can use, instead of having to use proprietary ARM/x86 and
-so on). Similarly, Right To Repair (ability to repair your own device, which
-implies free access to schematics and diagrams) is critical, for the same
-reason that Libre Software (Right To Hack) is critical!
-
-OSHW and Right To Repair are not covered at all by RYF (FSF's Respects Your
-Freedom criteria), the criteria which Libreboot previously complied with.
-RYF also makes several concessions that are ultimately damaging, such as
-the *software as circuitry* policy which is, frankly, nonsensical. ROM is still
-software. There was a time when the FSF didn't consider BIOS software a freedom
-issue, just because it was burned onto a mask ROM instead of *flashed*; those
-FSF policies ignore the fact that, with adequate soldering skills, it is trivial
-to replace stand-alone mask ROM ICs with compatible flash memory.
-
-Conclusion
-==========
-
-RYF isn't *wrong* per se, just flawed. It is correct in some ways and if
-complied with, the result *does* give many freedoms to the user, but RYF
-completely disregards many things that are now possible, including freedoms at
-the hardware level (the RYF criteria only covers *software*). Those guidelines
-are written with assumptions that were still true in the 1990s, but the world
-has since evolved. The libreboot project rejects those policies in their
-entirety, and instead takes a pragmatic approach.
-
-The conclusion that should be drawn from all of this is as follows:
-
-*Following* FSF criteria does not damage anything, but that criteria is very
-conservative. Its exemptions should be *disregarded* and entirely ignored.
-RYF is no longer fit for purpose, and should be rewritten to create
-a *more strict* set of guidelines, without all the loopholes or exemptions.
-As has always been the case, Libreboot tries to always go above and beyond, but
-the Libreboot project does not see RYF as a *gold standard*. There are levels
-of freedom possible now that the RYF guidelines do not cover at all, and in
-some cases even actively discourage/dis-incentivize because it makes compromises
-based on assumptions that are no longer true. 
-
-Sad truth: RYF actively encourages *less* freedom, by not being bold enough.
-It sets a victory flag and says *mission accomplished*, despite the fact
-that the work is *far* from complete!
-
-If followed *with exemptions unchallenged*, RYF may in some cases encourage
-companies to *sweep under the rug* any freedom issues that exist, where it
-concerns proprietary firmware not running on the host CPU (such as the
-Embedded Controller firmware).
-
-I propose that new guidelines be written, to replace RYF. These new guidelines
-will do away with all exemptions/loopholes, and demand that *all* software be
-libre on the machine, or as much as possible. Instead of only promoting products
-that meet some arbitrary standard, simply catalog all systems on a grand
-*database* of sorts (like h-node.org, but better), which will define exactly
-what *hardware* **and** software issues exist on each device. Include Right to
-Repair and OSHW (including things like RISCV) in the most "ideal"
-standard machine; the gold standard is libre *silicon*, like what Sam Zeloof
-and others are working on nowadays.
-
-This new set of criteria should not attempt to hide or ignore *anything*. It
-should encourage people to push the envelope and innovate, so that we can have
-much *more* freedom than is currently possible. Necessity is the mother of all
-invention, and freedom is an important goal in every aspect of life, not just
-computing.
-
-Don't call it "Respects Your Freedom" or something similar. Instead, call it
-something like: the freedom catalog. And actually focus on hardware, not just
-software!
-
-Other resources
-===============
-
-Ariadne Conill's RYF blog post
-------------------------------
-
-Ariadne Conill, security team chair of *Alpine Linux*, posted a very robust
-article about RYF, with similar points made when compared to *this* article.
-However, Ariadne goes into detail on several other examples of problems with
-the FSF RYF criteria; for example, it talks about the *Novena* product by
-Bunnie.
-
-It's worth a read! Link:
-
-<https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/>

site/news/policy.uk.md

@@ -170,363 +170,3 @@ Libreboot вирішує цю ситуацію *суворо* та *принци
 * <https://libresilicon.com/>
 
 (Сем буквально виробляє процесори в своєму гаражі)
-
-Проблеми з критеріями RYF
-==========================
-
-Раніше Libreboot відповідав критеріям FSF RYF, але тепер він дотримується
-набагато більш прагматичної політики, спрямованої на надання більшої свободи більшій кількості людей у
-більш прагматичний спосіб. Ви можете прочитати ці вказівки, перейшовши за цією URL-адресою:
-
-* Рекомендації FSF Поважає Вашу Свободу (RYF):
-<https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
-
-Простіше кажучи, інструкції RYF стосуються комерційних продуктів із застереженням,
-що вони не повинні містити пропрієтарне програмне забезпечення чи відомі проблеми конфіденційності,
-як-от лазівки.
-
-Повне виключення всього пропрієтарного забезпечення наразі неможливе. Наприклад,
-пропрієтарне мікропрограмне забезпечення SDR у чіпсетах WiFi, мікропрограмне забезпечення пристроїв AHCI, таких як
-жорсткі диски або твердотілі накопичувачі тощо. В інструкціях FSF RYF зазначено наступний виняток, щоб пом'якшити цей факт:
-
-* "Однак є один виняток для вторинних вбудованих процесорів. Виняток стосується програмного забезпечення, що постачаєтья в бічних допоміжних і низькорівневих процесорах та FPGA, у яких встановлення програмного забезпечення не передбачається після того, як користувач отримає продукт. Це може включати, наприклад, мікрокод всередині процесора, мікропрограму, вбудовану в пристрій вводу-виводу, або структуру вентилів FPGA. Програмне забезпечення в таких вторинних процесорах не вважається програмним забезпеченням продукту."
-
-*та має бути відхилено
-з ідеологічних міркувань*. Решта політики libreboot і загальна
-ідеологія, виражена в цій статті, базуватиметься в основному на цьому неприйнятті.
-Визначення *програмного забезпечення продукту* абсолютно довільне; програмне забезпечення
-є програмне забезпечення, а програмне забезпечення завжди має бути *вільним*. Замість того, щоб робити такі
-винятки, слід заохочувати більше апаратного забезпечення, допомогаючи надавати якомога
-більше свободи, одночасно надаючи користувачам інформацію про будь-які підводні
-камені, з якими вони можуть зіткнутися, і заохочувати свободу на всіх рівнях. Коли така організація,
-як FSF, робить такі сміливі винятки, як вище, вона надсилає неправильне повідомлення,
-кажучи людям, по суті, заховати ці інші проблеми лише тому, що вони стосуються програмного забезпечення,
-яке працює на "вторинному процесорі".
-Якщо користувач може оновити програмне забезпечення, воно має бути вільним,
-незалежно від того, *передбачав* виробник оновлення чи ні.
-Там де справді *не* можливо оновити таке програмне забезпечення, пропрієтарне чи ні,
-слід надати поради щодо цього. Освіта важлива, і критерії FSF
-активно перешкоджають такій освіті; це створює помилкову надію, що
-все добре і чудово, лише тому, що програмне забезпечення на одному довільному
-рівні ідеальне.
-
-Цей погляд FSF, виражений у цитованому абзаці, припускає,
-що системою керує переважно *один* головний процесор. На багатьох
-сучасних комп'ютерах це *більше не відповідає дійсності*.
-
-Вільне *програмне забезпечення* не існує у вакуумі, але ми мали менше свободи в
-минулому, особливо коли справа стосувалася апаратного забезпечення, тому *ПЗ* було нашим основним фокусом.
-
-Здатність вільно вивчати, адаптувати, обмінюватися та використовувати/повторно використовувати ПЗ є важливою,
-але є багато нюансів, коли справа доходить до *завантажувального мікропрограмного забезпечення*, нюансів, які
-здебільшого не існують поза розробкою мікропрограмного забезпечення чи поза розробкою ядра.
-Більшість типового прикладного/системного програмного забезпечення є високорівневим і портативним, але
-завантажувальна мікропрограма має бути написана для кожної конкретної машини, і через те, як
-апаратне забезпечення працює, існує багато компромісів, зокрема FSF, коли
-визначає які стандарти слід застосовувати *на практиці*.
-
-Той факт, що майже ніхто не говорить про прошивку EC, *пов'язаний* із
-сертифікацією Поважає Вашу Свободу (Respects Your Freedom). Насправді мікропрограмне забезпечення EC має вирішальне
-значення для свободи користувачів і повинно бути вільним, але FSF повністю ігнорує його як
-*частину апаратного забезпечення*. Це неправильно, і FSF має активно
-заохочувати людей визволяти його на кожному ноутбуці!
-
-Інше мікропрограмне забезпечення, яке наразі не доступне для проекту libreboot, описано на
-сторінці поширених питань libreboot. Наприклад, прошивка жорстких дисків/твердотілих накопичувачів описана в розділі поширених запитань.
-Знову ж таки, повністю проігноровано та знизано плечима FSF.
-
-Проект libreboot не буде приховувати або пропускати ці проблеми, тому що вони
-справді є критичними, але, знову ж таки, наразі виходять за межі того, що робить система збірки Libreboot
-На даний момент, система збірки Libreboot займається лише
-coreboot (і корисними навантаженнями), але в майбутньому це має змінитися.
-
-Приклади *замітання блобів під килим* FSF
-----------------------------------------------
-
-Протягом багатьох років було багато випадків, коли FSF активно не 
-заохочував рівень свободи програмного забезпечення, наприклад:
-
-* Робоча станція TALOS II "OpenPOWER" від Raptor Engineering USA. Вона містить
-  мережеву плату Broadcom в собі, яка потребує прошивки, і ця прошивка була невільною.
-  FSF були готові проігнорувати це та сертифікувати продукт TALOS II відповідно до RYF,
-  але Тімоті Пірсон із Raptor Engineering все одно звільнив її, хоча йому навіть
-  про це не було сказано. Гуго Ландау розробив специфікацію, а Еван Лоєвскі
-  написав вільну прошивку. Дивіться:
-  <https://www.devever.net/~hl/ortega> та <https://github.com/meklort/bcm5719-fw>
-* FSF свого часу схвалив ThinkPad X200, який продавав [Minifree Ltd](https://minifree.org),
-  який містить Intel ME; bootrom все ще там, як і співпроцесор ME,
-  але ME переведено в вимкнений стан через Intel Flash
-  Descriptor, а мікропрограму ME у флеш-пам'яті видалено. Однак ME - це цілий
-  співпроцесор, який з вільною прошивкою можна було би використовувати для багатьох
-  речей. У проектах Libreboot та coreboot завжди був інтерес до цього,
-  але FSF повністю ігнорує це. Продукт X200, який вони сертифікували,
-  постачався з попередньо встановленим Libreboot.
-* У Libreboot є утиліта, написана мною, Лією Роу, яка створює флеш-дескриптори ICH9M і образи
-  GbE NVM з нуля. Це необхідно для налаштування
-  машини, але інакше це двійкові блоб-файли; FSF був би цілком
-  задоволений сертифікацією апаратного забезпечення в будь-якому випадку, оскільки це були непрограмні
-  блоби у форматі, повністю задокументованому Intel (це лише двійкові конфігураційні
-  файли), але я все одно пішла вперед і написала ich9gen. За допомогою ich9gen ви можете
-  легше змінювати регіони дескриптора/gbe для вашого образу мікропрограмного забезпечення. Дивіться:
-  <https://libreboot.org/docs/install/ich9utils.html> - libreboot також має це
-* FSF свого часу схвалив ThinkPad T400 з Libreboot, який продавав Minifree. Ця
-  машина доступна в двох версіях: з графічним процесором ATI+Intel або лише Intel. Якщо ATI
-  GPU, можна налаштувати машину так, щоб використовувався будь-який GPU. Якщо буде використовуватися
-  графічний процесор ATI, для ініціалізації потрібен блоб мікропрограми, хоча драйвер для нього
-  повністю вільний. *FSF* проігнорувала цей факт і схвалила апаратне забезпечення,
-  доки Libreboot не вмикає графічний процесор ATI і не повідомляє людям, як його
-  увімкнути. Графічний процесор *Intel* на цій машині має вільний код ініціалізації
-  від проекту coreboot і повністю вільний драйвер в обох ядрах Linux та BSD.
-  У конфігурації, наданій Libreboot, ATI GPU повністю вимкнено
-  та виключено.
-* Усі ноутбуки ThinkPad, сумісні з Libreboot, містять невільне мікропрограмне забезпечення вбудованого контролера,
-  яке можна прошивати користувачем (*і призначене для оновлення
-  виробником*). FSF вирішила ігнорувати прошивку EC, відповідно до
-  свого винятку *вторинного процесора*. Дивіться:
-  <http://libreboot.org/faq.uk.html#прошивка-ec-вбудований-контролер>
-
-У всіх вищезазначених випадках FSF міг бути суворішим і сміливішим, наполягаючи
-на тому, що ці *додаткові* проблеми свободи були вирішені. Вони цього не
-зробили. Є багато інших прикладів цього, але мета цієї статті
-не перелічити їх усі (інакше на цю тему можна були б написати книгу).
-
-Проблеми з FSDG
-------------------
-
-<img tabindex=1 src="https://av.libreboot.org/firmware.uk.png" /><span class="f"><img src="https://av.libreboot.org/firmware.uk.png" /></span>
-
-FSF підтримує ще один набір критеріїв, які називаються Правилами вільного
-розповсюдження системи (GNU FSDG)]
-
-Критерії FSDG відрізняються від RYF, але мають подібні проблеми. FSDG - це
-те, чому відповідають схвалені FSF дистрибутиви GNU+Linux. По суті, він забороняє
-все пропрієтарне програмне забезпечення, включаючи мікропрограму пристрою. Це може здатися благородним, але
-вкрай проблематично в контексті прошивки. Їжа для роздумів:
-
-* Виключення мікропрограмним блобів із ядра linux - це *погано*. Пропрієтарна прошивка
-  є *також поганою*. Включення їх є мудрішим вибором, якщо також забезпечується сильна освіта
-  про те, *чому вони погані* (менше свободи). Якщо ви відкриєте їх для
-  користувача та повідомите йому про це, з'явиться більше стимулів (через просте
-  нагадування про їх існування) провести зворотне проектування та замінити їх.
-* Прошивка *в ядрі вашої ОС* *хороша*. FSF одночасно дає дозвіл на
-  апаратне забезпечення *з тими самими блобами прошивки*, якщо прошивка вбудована в
-  ROM/флеш-пам'ять на пристрої або вбудована в якийсь процесор. Якщо
-  вбудоване програмне забезпечення знаходиться на окремому ROM/флеш-пам'яті, його все одно можна замінити
-  користувачем за допомогою зворотного проектування, але тоді вам, ймовірно, доведеться провести деяку пайку
-  (замінити чіп на картці/пристрої). *Якщо мікропрограма завантажується ядром
-  ОС, тоді вона відкрита для користувача, і її можна легше замінити.
-  Критерії FSF у цьому відношенні заохочують розробників апаратного забезпечення
-  приховувати вбудоване програмне забезпечення, що робить фактичну (програмну) свободу менш імовірною!*
-
-Окрім цього, FSDG здається нормальним. Будь-яка вільна операційна система має в ідеалі не містити
-пропрієтарних *драйверів* або *застосунків*.
-
-Виробники обладнання полюбляють заштовхувать все в мікропрограмне забезпечення, оскільки їх
-продукт часто має поганий дизайн, тому вони пізніше хочуть надати вирішення в
-прошивці для налагодження проблемних питань. В багатьох випадках, пристрій вже матиме прошивку в собі,
-але вимагає оновлення, надане йому вашим ядром ОС.
-
-Найбільш поширений приклад пропрієтарної прошивки в Linux для пристроїв wifi.
-Це цікавий сценарій використання, з джерельним кодом, тому що його може бути
-використано для контрольованого власником *software defined radio*.
-
-Шлях *Debian* є ідеальним. Дистрибутив Debian GNU+Linux повністю вільний
-за замовчуванням, і вони включають додаткову прошивку за необхідності, яку вони мають в
-окремому репозиторії, що містить її. Якщо ви хочете тільки прошивку, тривіально
-взяти образи встановлювача з нею доданою, або додати її до вашої встановленої
-системи. Вони розповідають вам, як зробити це, що означає, що вони допомогають людям
-отримати *деяку* свободу, *замість ніякої*. Це невід'ємно прагматичний
-спосіб робити справи, і це те, як це робить Libreboot.
-
-Більше контексту, стосовно Debian, доступно в публікації цього блога:
-<https://blog.einval.com/2022/04/19#firmware-what-do-we-do> - в ньому, автор,
-відомий розробник Debian, робить чудовий акцент про прошивку
-пристроїв, подібну до статті (Libreboot), яку ви зараз читаєте. Її
-варто прочитати! Станом на жовтень 2022 року, Debian проголосував за включення прошивки пристроїв
-за *замовчуванням*, в наступних випусках Debian. Раніше Debian виключав таке
-мікропрограмне забезпечення, але дозволяв вам його додавати.
-
-OpenBSD майже така сама, але вони розумні в цьому: під час початкового
-завантаження, після інсталяції, він повідомляє вам, яке мікропрограмне забезпечення потрібно,
-і оновляє його для вас. Це дуже прозоро обробляється їхньою
-програмою `fw_update`, про яку ви можете прочитати тут:
-
-<https://man.openbsd.org/fw_update>
-
-*Заборона* прошивки linux конкретно є загрозою свободі в довгостроковій перспективі,
-тому що нові користувачі GNU+Linux можуть бути відбиті від використання ОС, якщо їх
-апаратне забезпечення не працює. Ви можете сказати: просто купіть нове обладнання! Це часто неможливо
-для користувачів, і користувач також може не мати навичок для
-зворотного проектування.
-
-Більш детальна інформація про мікрокод
-=====================================
-
-[Releases after 20230423 will provide separate ROM images with microcode
-excluded, alongside the default ones that include microcode.](microcode.md)
-
-Щоб було зрозуміло: бажано, щоб мікрокод був вільним. Мікрокод систем Intel
-та AMD *є* пропрієтарним. Факти і почуття рідко збігаються; метою цього
-розділу є поширення *фактів*.
-
-Система збірки libreboot тепер дозволяє оновлення мікрокоду *за замовчуванням.*
-
-Відсутність оновлень мікрокоду ЦП є абсолютною катастрофою для стабільності
-та безпеки системи.
-
-Що ще гірше, той самий текст, цитований із критеріїв FSF RYF,
-насправді конкретно згадує мікрокод. Знову процитую для нащадків:
-
-*"Однак є один виняток для вторинних вбудованих процесорів. Виняток
-стосується програмного забезпечення, що постачається всередині допоміжних і низкорівневих
-процесорів та FPGA, у яких інсталяція програмного забезпечення не передбачається після того,
-як користувач отримає продукт. Це може включати, наприклад, мікрокод всередині
-процесора, мікропрограму, вбудовану в пристрій вводу-виводу, або структуру вентилів FPGA.
-Програмне забезпечення в таких вторинних процесорах не вважається програмним забезпеченням продукту."*
-
-Тут обговорюється мікрокод, який записується в *mask ROM* на самому
-ЦП. Одночасно він не дає ОК для *оновлень* мікрокоду, які надаються
-coreboot або ядром Linux; згідно з FSF, це напад на
-вашу свободу, але старіший мікрокод із більшими помилками, записаний на ROM, є нормальним.
-
-ЦП вже має мікрокод, записаний в mask ROM. Мікрокод налаштовує
-логічні вентилі в ЦП, для реалізації набору інструкцій через спеціальні *декодери*,
-які мають фіксовану функцію; неможливо, наприклад, реалізувати набір інструкцій RISCV
-на процесорі x86. Для мікрокода можливо тільки
-реалізувати x86, або *зламаний* x86, і мікрокод за замовчуваням майже завжди є
-*зламаним x86* на ЦП Intel/AMD; це неминуче через складність цих
-процесорів.
-
-FSF вважає,
-що ці оновлення мікрокоду x86 (для Intel/AMD) дозволяють повністю створити новий
-ЦП, який принципово відрізняється від x86. Це не правда. Також неправда,
-що *всі* інструкції в наборі інструкцій x86 реалізовано за допомогою мікрокоду. У
-деяких випадках використовується жорстко закодована схема! Оновлення мікрокоду більше нагадують
-крихітні одиничні патчі тут і там у сховищі git, за аналогією.
-Щоб знову потрапити у головний простір FSF: ці оновлення не можуть зробити ЦП
-еквівалентом рефакторингу всієї кодової бази. Це *гарячі виправлення*, нічого
-більше!
-
-Невиключення цих оновлень призведе до нестабільного/невизначеного стану. Intel
-сама визначає, які помилки впливають на які ЦП, і вони визначають обхідні шляхи або надають
-виправлення в мікрокоді. Виходячи з цього, таке програмне забезпечення, як ядро Linux
-може обійти ці помилки/примхи. Крім того, апстрім версії ядра Linux
-можуть оновити мікрокод під час завантаження (однак все одно рекомендується робити це
-з coreboot для більш стабільної ініціалізації контролера пам'яті або “raminit”).
-Подібне можна сказати і про ЦП AMD.
-
-Ось кілька прикладів того, як відсутність оновлень мікрокоду вплинула на *Libreboot*,
-змусивши Libreboot обійти зміни, внесені в апстрім coreboot, зміни,
-які були *хорошими* і зробили coreboot більш сумісним зі стандартами відповідно до
-специфікацій Intel. Libreboot довелося *поламати* coreboot, щоб зберегти деякі
-інші функції на деяких Thinkpad GM45/ICH9M:
-
-<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>
-
-<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc7e8736be0c9b51>
-
-Ці патчі повертають *виправлення помилок* у coreboot, виправлення, які порушують
-інші функції, але лише якщо оновлення мікрокоду виключено. Найбільш
-правильним з технічної точки зору рішенням є *не* застосування наведених вище патчів, а натомість
-оновлення мікрокоду!
-
-Виберіть свою отруту. Недодавання оновлень є *безвідповідальним* і, зрештою,
-марним, оскільки ви все одно отримуєте пропрієтарний мікрокод, ви просто отримуєте
-старішу, з більшими помилками, версію натомість!
-
-Ця зміна в політиці проекту зовсім не впливає на вашу свободу,
-тому що в іншому випадку ви все одно маєте старіший мікрокод із більшими помилками. Однак він покращує
-надійність системи, включаючи оновлення!
-
-Така прагматична політика *перевершує* *догму*, яку колись
-доводилося терпіти користувачам Libreboot. Простіше кажучи, проект Libreboot має на меті надати користувачам
-якомога більше свободи для їх апаратного забезпечення; так було завжди,
-але цей менталітет тепер застосовується до [набагато] більшої кількості обладнання.
-
-Інші міркування
-====================
-
-Також Libreboot не покриває суворо: OSHW і Право на ремонт (Right To Repair). Однак свобода
-на рівні кремнію була б дивовижною, і зусилля вже є; наприклад, подивіться на RISCV ISA (на
-практиці фактичне виготовлення все ще є пропрієтарним і не під вашим контролем, але RISCV є повністю вільним
-дизайном ЦП, який компанії можуть використовувати замість того, щоб використовувати пропрієтарний ARM/x86 і
-так далі). Подібним чином, Право на ремонт (можливість відремонтувати свій власний пристрій, що
-передбачає вільний доступ до схем і діаграм) є критично важливим з тієї ж причини, що
-критично важливо вільне програмне забезпечення (Право на хакерство)!
-
-OSHW і Право на ремонт взагалі не охоплюються RYF (критерії FSF Поважає Вашу
-Свободу), критеріями, яких Libreboot дотримувався раніше..
-RYF також робить кілька поступок, які зрештою завдають шкоди, наприклад,
-політика *програмне забезпечення як схема*, яка, чесно кажучи, є безглуздою. ROM все ще
-програмне забезпечення. Був час, коли FSF не вважав програмне забезпечення BIOS проблемою
-свободи, лише тому, що воно записане на mask ROM, а не *прошито*; ця
-політика FSF ігнорує той факт, що, маючи відповідні навички паяння, легко замінити
-автономні мікросхеми mask ROM на сумісну флеш-пам'ять.
-
-Висновки
-==========
-
-RYF сам по собі не є *неправильним*, просто має недоліки. Певним чином це правильно, і
-якщо його дотримуватися, результат *надає* багато свобод користувачеві, але RYF
-повністю ігнорує багато речей, які зараз можливі, включаючи свободи на
-апаратному рівні (критерії RYF охоплюють лише *програмне забезпечення*). Ці вказівки
-написані з припущеннями, які все ще були вірними в 1990-х роках, але відтоді
-світ змінився. Проект libreboot повністю відкидає цю політику та натомість
-використовує прагматичний підхід.
-
-Висновок, який слід зробити з усього цього, такий:
-
-*Дотримання* критеріїв FSF нічого не шкодить, але ці критерії є дуже
-консервативними. Його винятки слід *ігнорувати* та повністю ігнорувати. RYF
-більше не відповідає меті, і його слід переписати, щоб створити *більш суворий*
-набір інструкцій без усіх лазівок чи винятків.
-Як завжди було, Libreboot намагається завжди виходити за межі, але
-проект Libreboot не розглядає RYF як *золотий стандарт*. Зараз є
-можливі рівні свободи, які вказівки RYF взагалі не охоплюють, а
-в деяких випадках навіть активно не заохочують/перешкоджають, оскільки це робить компроміси
-на основі припущень, які більше не відповідають дійсності. 
-
-Сумна правда: RYF активно заохочує *менше* свободи, не будучи достатньо сміливим.
-Він встановлює прапор перемоги та говорить *місію виконано*, незважаючи на те, що
-робота *далека* від завершення!
-
-Якщо дотримуватись *з незаперечними винятками*, RYF може в деяких випадках заохочувати
-компанії *приховувати* будь-які проблеми зі свободою, які існуюють,
-коли це стосується пропрієтарного мікропрограмного забезпечення, яке не працює на центральному процесорі хоста (наприклад, мікропрограмне забезпечення
-вбудованого контролера).
-
-Я пропоную написати нові рекомендації, щоб замінити RYF. Ці нові правила
-ліквідують усі винятки/лазівки та вимагають, щоб *все* програмне забезпечення
-було вільним на машині або якомога більше. Замість того, щоб лише рекламувати продукти,
-які відповідають певним стандартам, просто каталогізуйте всі системи у великій
-*базі даних* свого роду (наприклад, h-node.org, але краще), яка точно визначатиме, які
-*апаратні* **і** програмні проблеми існують на кожному пристрої. Включіть Право
-на ремонт і OSHW (включно з такими речами, як RISCV) до найбільш "ідеальної"
-стандартної машини; золотим стандартом є вільний *кремній*, як те, над чим
-Сем Зелоф та інші працюють зараз.
-
-Цей новий набір критеріїв не повинен намагатися приховати або проігнорувати *щось*. Це
-має заохочувати людей розширювати рамки та впроваджувати інновації, щоб ми могли мати
-набагато *більше* свободи, ніж зараз можливо. Необхідність є матір'ю всіх
-винаходів, а свобода є важливою метою в кожному аспекті життя, не лише в
-обчисленні.
-
-Не називайте це "Поважає вашу свободу" чи щось подібне. Натомість назвіть це
-приблизно так: каталог свободи. І насправді зосередьтеся на апаратному забезпеченні, а не
-лише на програмному забезпеченні!
-
-Інші ресурси
-===============
-
-Повідомлення в блозі RYF Аріадни Конілл
-------------------------------
-
-Аріадна Конілл, голова групи безпеки *Alpine Linux*, опублікувала дуже серйозну
-статтю про RYF, у якій висловлено схожі моменти в порівнянні з *цією* статтею.
-Однак Аріадна докладно розглядає кілька інших прикладів проблем із
-критеріями FSF RYF; наприклад, йдеться про продукт *Novena* від
-Bunnie.
-
-Варто прочитати! Посилання:
-
-<https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/>

site/news/safety.md

@@ -12,7 +12,8 @@ Introduction
 implemented, and this page is still relevant for Libreboot 20231021. It applies
 to any system that requires vendor code to be inserted inside ROM images.**
 
-(it also applies to Libreboot 20231101, 20231106, 20240126 and 20240225)
+(it also applies to Libreboot 20231101, 20231106, 20240126, 20240225
+and 20240504)
 
 **UPDATE (16 August 2023): This also applies to the recently added Dell
 Precision T1650 mainboard.**
@@ -23,7 +24,7 @@ users have been bricking their machines, on the following mainboards:
 
 * Sandybridge platforms (e.g. ThinkPad X220, T420)
 * Ivybridge platforms (e.g. ThinkPad X230, T430)
-* Haswell platforms (e.g. ThinkPad T440p, W541)
+* Haswell platforms (e.g. ThinkPad T440p, W541, OptiPlex 9020)
 
 Why?
 ----
@@ -32,8 +33,7 @@ On these platforms, the following binary vendor files are required:
 
 * Intel ME firmware: all Sandy/Ivy/Haswell boards. Libreboot's build system
   runs `me_cleaner` to neuter the Intel ME, so that it's disabled after BringUp.
-* Intel MRC firmware: Haswell platforms (W541, T440p) - a libre MRC replacement
-  is available, but experimental, and the vendor version is still recommended.
+* Intel MRC firmware: broadwell (HP EliteBook 820 G2)
 * KBC1126 EC firmware: HP laptops (all sandy/ivy/haswell)
 
 When you [build Libreboot from source](../docs/build/), Libreboot's automated

site/news/update202308.md

@@ -57,14 +57,6 @@ This *only* affects the `default` coreboot tree used in Libreboot; the `haswell`
 tree (libre MRC on T440p/W541), `cros` (gru chromebooks) and `fam15h` trees used
 on KGPE-D16/KCMA-D8/KFSN4-DRE have not yet been updated.
 
-I'm planning to merge Angel's libre MRC patches into `default` at some point,
-re-basing them on the newer coreboot release, but this is done yet; unless, of
-course, these patches upstream (on coreboot gerrit) are improved and/or merged
-soon. I already covered fam15h AMD boards in a [previous post](fam15h.md) - I
-plan to eventually use Dasharo (based on newer coreboot) instead of `4.11_branch`
-on these boards. The `cros` boards need work - lots more testing, and many of
-them must be re-added again based on said testing.
-
 Testing needed!
 ===============
 

site/tasks/index.md

@@ -191,7 +191,7 @@ These typically use MEC5045 or compatible EC. Some may use MEC5035.
 
 SuperIO: at least M6500 is known to use ECE5028. I have a bunch of these
 Dells at my lab, they are high priority for porting because they would be
-easily flashable, and blob-free configs (Canoeboot could also support them).
+easily flashable.
 
 Broadwell Dell
 --------------
@@ -350,9 +350,6 @@ This is part of a patch series, from 9 September 2023 onward, re-adding
 AMD Family 16 platform to coreboot, most notably enabling use of the new
 allocator and other things in coreboot.
 
-The linked patch is for mainboard: HP T620 - of note, it may also be suitable
-for Canoeboot. Worth looking into.
-
 AMD AGESA-based platforms were removed from coreboot, because they weren't
 being maintained anymore, so they were dropped. Some of those boards are
 still quite decent today. Various efforts here and there have revived some
@@ -2212,3 +2209,23 @@ page 89
 also
 
 <https://winraid.level1techs.com/t/bios-mod-to-enable-pcie-bifurcation/31547>
+
+ec hacking on lenovo x230
+=========================
+
+<https://zmatt.net/unlocking-my-lenovo-laptop-part-2/>
+
+DELL 7th gen
+============
+
+
+3050 micro is being worked on.
+
+3050 sff and mt are TODO
+
+5050 models also.
+
+Dell 3020
+=========
+
+another haswell. different to 9020, but could be added.

site/who.uk.md

@@ -7,7 +7,7 @@ x-toc-enable: true
 проект, як приймаються рішення, і взагалі як проект функціонує.
 
 Ви можете знайти інформацію про великий внесок, зроблений у libreboot, на цій
-сторінці, яка перелічує таких людей: [Список учасників](contrib.uk.md)
+сторінці, яка перелічує таких людей: [Список учасників](contrib.md)
 
 Лія Роу (засновниця, провідний розробник)
 ===================================
@@ -17,7 +17,7 @@ x-toc-enable: true
 і керує серверами libreboot.org зі своєї лабораторії у Великобританії.
 
 Ви можете дізнатися більше про участь Лії в libreboot, прочитавши її запис на
-[сторінці зі списком усіх учасників, минулих і теперішніх](contrib.uk.md)
+[сторінці зі списком усіх учасників, минулих і теперішніх](contrib.md)
 
 Калеб Ла Гранж
 ===============
@@ -27,7 +27,7 @@ x-toc-enable: true
 та документацією.
 
 Ви можете дізнатись більше про участь Калеба в libreboot, прочитавши його
-запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.uk.md)
+запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.md)
 
 Альпер Небі Ясак
 ================
@@ -37,7 +37,7 @@ x-toc-enable: true
 апстрім роботу над самим U-Boot. `alpernebbi` на Libera IRC.
 
 Ви можете дізнатись більше про участь Альпера в Libreboot, читаючи його
-запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.uk.md)
+запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.md)
 
 Потрібні розробники!
 ==================