updates

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

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,6 +25,45 @@ 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
+
+This would make lbmk run on 4 threads.
+
+Environmental variables
+=======================
+
+Please read about environmental variables in [the build
+instructions](../maintain/), before running lbmk. You should set
+your variables accordingly, though you do not technically need to; some
+of them may be useful, e.g. `LBMK_THREADS` (sets the number of build threads).
+
 Sources
 =======
 

site/docs/build/index.uk.md

@@ -35,6 +35,55 @@ libreboot з доступного джерельного коду.
 Наступний документ описує те, як працює `lbmk`, і як ви можете робити зміни
 до нього: [керівництво обслуговування libreboot](../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.
+The setting is decided on a board-by-board basis, taking its various quirks
+and idiosynrasies into account.
+
+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
+
+This would make lbmk run on 4 threads.
+
+Environmental variables
+=======================
+
+Please read about environmental variables in [the build
+instructions](../maintain/), before running lbmk. You should set
+your variables accordingly, though you do not technically need to; some
+of them may be useful, e.g. `LBMK_THREADS` (sets the number of build threads).
+
+Environmental variables
+=======================
+
+Please read about environmental variables in [the build
+instructions](../maintain/), before running lbmk. You should set
+your variables accordingly, though you do not technically need to; some
+of them may be useful, e.g. `LBMK_THREADS` (sets the number of build threads).
+
 Git
 ===
 

site/docs/hardware/dell9020.md

@@ -91,23 +91,70 @@ Kukri's patch is here:
 This patch, at this revision (patchset 31), is what Libreboot uses for this
 port.
 
-Graphics cards
+QUBES: how to get it working
+-------------------
+
+Qubes requires IOMMU to be turned on. Please now read the next section.
+Qubes *WILL* work, if you configure Libreboot as directed below, but otherwise
+it will fail by default. This is because Libreboot *disables the IOMMU by
+default*, on this board.
+
+Graphics cards and IOMMU
 --------------
 
+IOMMU is buggy for some reason (we don't know why yet), when you plug in
+a graphics card. The graphics card simply won't work. On some of them,
+you can use the console but as soon as you start xorg, it will just b0rk.
+
+Current Libreboot revisions *disable IOMMU by default*, on this board. The
+coreboot code for initialising IOMMU was modified by the Libreboot project, to
+make it a toggle. IOMMU works fine if you use only Intel graphics.
+
+The way coreboot works is this: if vt-d is present on the CPU, it enables an
+IOMMU, and only if vt-d is present. This is still the behaviour in Libreboot,
+but Libreboot adds an additional check: if `iommu` is not set in nvram, it
+defaults to on, but if it's set to disabled, then IOMMU is not initialised.
+
+On all other Haswell boards, LIbreboot enables IOMMU by default. To enable
+it on the 9020, do this on your ROM:
+
+	nvramtool -C libreboot.rom -w iommu=Enable
+
+Then flash the ROM image. You can find nvram
+under `src/coreboot/default/util/nvramtool`. Do this in lbmk if you don't
+already havse `src/coreboot/default/`:
+
+	./update trees -f coreboot default
+
+Then do this:
+
+	make -C src/coreboot/default/util/nvramtool
+
+The binary `nvramtool` will then live in that directory. More information
+available in [Libreboot build instructions](../build/). Information about
+dumping/flashing the ROM can be found
+in [Libreboot flashing instructions](../install/)
+and [Libreboot external flashing instructions](../install/spi.md).
+
+NOTE: If IOMMU is enabled, you can still use a graphics card, but you must
+pass this on the Linux cmdline paramaters: `iommu=off`
+
+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.
 
-NOTE: You must set `iommu=off` in your linux cmdline. For instance, set this
-in `/etc/default/grub` and regenerate your GRUB config. With the IOMMU turned
-off, graphics cards work fine. Otherwise, with IOMMU turned on, you might get
-this error:
+Here is an example of the type of errors we got when testing graphics cards
+with IOMMU enabled:
 
 <https://av.vimuser.org/error.jpg>
 
-NOTE2: You *can* use the onboard Intel GPU (without a graphics card inserted),
-and leave IOMMU turned on. You only need to disable the IOMMU when a graphics
-card is inserted.
+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.
 
 7020 compatibility
 ------------------
@@ -168,8 +215,7 @@ This is to prevent short circuiting and power surges while flashing.**
 For general information, please refer to [25xx NOR flash
 instructions](../install/spi.md) - that page refers to use of socketed flash.
 
-This machine is somewhat cumbersome to flash, because it has a SOIC-16 flash
-for the first 8MB part, and 4MB SOIC8. You can split up your 12MB ROM image
+There are two SOIC-8 chips. You can split up your 12MB ROM image
 like so:
 
 	dd if=libreboot.rom of=4mb.rom bs=1M skip=8

site/docs/hardware/dell_thermal.md

@@ -0,0 +1,52 @@
+---
+title: Dell Latitude thermal throttling
+x-toc-enable: true
+...
+
+On some Dell Latitude laptops, you may encounter random shutdowns on
+heavy load. We believe this is because the SMSC EC is overly conservative
+by default; it is in charge of handling thermals and fan control on this
+machine. Our theory is that coreboot needs to write certain EC commands
+to allow higher temperatures; please read:
+
+<https://codeberg.org/libreboot/lbmk/issues/202>
+
+Basically, what you need to do is:
+
+* Use high quality thermal paste (don't use the same dried up paste that the
+  laptop came with, if you bought it on ebay for example). Arctic MX-6 is good.
+* Check that the fan works reliably
+
+Also: the `intel_pstate` driver can be used to artifically cap CPU speed. See:
+
+<https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html>
+
+When you use this machine, it is recommended that you cap the CPU speed once
+you've booted into Linux. Set it to something like 50% at first. Then run a
+stress test, for example:
+
+	stress -c x
+
+Where `x` is the number of CPU cores, e.g. 2. Monitor the temperatures using
+something like `xsensors`, making sure the CPU doesn't exceed 80c temperature.
+
+You can also monitor CPU speeds in Linux like so:
+
+	watch -n .2 grep MHz /proc/cpuinfo
+
+This will let you know what speed you're at. You can use this to determine
+whether the `intel_pstate` driver is working. How to cap speed to 50 percent, as
+in the above example:
+
+	echo 50 > /sys/devices/system/cpu/cpufreq/intel_pstate/max_perf_pct
+
+Gradually increase the CPU speed (up to 100 on `max_perf_pct`), waiting a few
+minutes each time. You should ensure that your machine does not exceed 80C.
+
+Dell's thermal safety is far too protective by default, on some of these, and
+we don't yet know how to properly configure it. Running a CPU below 80c in
+temperature and never higher than that, is a good idea anyway, for the
+long term life of your CPU.
+
+Regardless, thermal shutdown is extremely reliable on this machine, but Dell
+makes it shut down *earlier*, before it can even start to CPU throttle.

site/docs/hardware/e5520.md

@@ -3,6 +3,12 @@ title: Dell Latitude E5520
 x-toc-enable: true
 ...
 
+**Thermal safety**: this machine shuts down very quickly, when the machine
+exceeds 80c CPU temperature, which is far more conservative than on most
+laptops (non-Dell ones), so you should make sure that your thermals are
+excellent. More info available [here](dell_thermal.md). This is a known bug,
+but otherwise the machine will be mostly stable.
+
 <div class="specs">
 <center>
 Dell Latitude E5520

site/docs/hardware/e5530.md

@@ -3,6 +3,12 @@ title: Dell Latitude E5530
 x-toc-enable: true
 ...
 
+**Thermal safety**: this machine shuts down very quickly, when the machine
+exceeds 80c CPU temperature, which is far more conservative than on most
+laptops (non-Dell ones), so you should make sure that your thermals are
+excellent. More info available [here](dell_thermal.md). This is a known bug,
+but otherwise the machine will be mostly stable.
+
 <div class="specs">
 <center>
 Dell Latitude E5530

site/docs/hardware/e6400.md

@@ -3,6 +3,12 @@ title: Dell Latitude E6400
 x-toc-enable: true
 ...
 
+**Thermal safety**: this machine shuts down very quickly, when the machine
+exceeds 80c CPU temperature, which is far more conservative than on most
+laptops (non-Dell ones), so you should make sure that your thermals are
+excellent. More info available [here](dell_thermal.md). This is a known bug,
+but otherwise the machine will be mostly stable.
+
 <div class="specs">
 <center>
 <img tabindex=1 alt="Dell Latitude E6400" class="p" src="https://av.libreboot.org/e6400/e6400-seabios.jpg" /><span class="f"><img src="https://av.libreboot.org/e6400/e6400-seabios.jpg" /></span> <img tabindex=1 alt="Dell Latitude E6400 XFR" class="p" style="max-width:24em" src="https://av.libreboot.org/e6400/e6400xfr-seabios.jpg" /><span class="f"><img src="https://av.libreboot.org/e6400/e6400xfr-seabios.jpg" /></span>

site/docs/hardware/e6420.md

@@ -3,6 +3,12 @@ title: Dell Latitude E6420
 x-toc-enable: true
 ...
 
+**Thermal safety**: this machine shuts down very quickly, when the machine
+exceeds 80c CPU temperature, which is far more conservative than on most
+laptops (non-Dell ones), so you should make sure that your thermals are
+excellent. More info available [here](dell_thermal.md). This is a known bug,
+but otherwise the machine will be mostly stable.
+
 <div class="specs">
 <center>
 Dell Latitude E6420

site/docs/hardware/e6430.md

@@ -3,6 +3,12 @@ title: Dell Latitude E6430
 x-toc-enable: true
 ...
 
+**Thermal safety**: this machine shuts down very quickly, when the machine
+exceeds 80c CPU temperature, which is far more conservative than on most
+laptops (non-Dell ones), so you should make sure that your thermals are
+excellent. More info available [here](dell_thermal.md). This is a known bug,
+but the machine will otherwise be mostly stable.
+
 <div class="specs">
 <center>
 Dell Latitude E6430

site/docs/hardware/e6520.md

@@ -3,6 +3,12 @@ title: Dell Latitude E6520
 x-toc-enable: true
 ...
 
+**Thermal safety**: this machine shuts down very quickly, when the machine
+exceeds 80c CPU temperature, which is far more conservative than on most
+laptops (non-Dell ones), so you should make sure that your thermals are
+excellent. More info available [here](dell_thermal.md). This is a known bug,
+but the machine will otherwise be mostly stable.
+
 <div class="specs">
 <center>
 Dell Latitude E6520

site/docs/hardware/e6530.md

@@ -3,6 +3,12 @@ title: Dell Latitude E6530
 x-toc-enable: true
 ...
 
+**Thermal safety**: this machine shuts down very quickly, when the machine
+exceeds 80c CPU temperature, which is far more conservative than on most
+laptops (non-Dell ones), so you should make sure that your thermals are
+excellent. More info available [here](dell_thermal.md). This is a known bug,
+but the machine will otherwise be mostly stable.
+
 <div class="specs">
 <center>
 Dell Latitude E6530

site/docs/hardware/hp2560p.md

@@ -35,6 +35,14 @@ OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
 </div>
 
 
+BROKEN WIFI
+===========
+
+Wifi is broken in current revisions. This is because hardware `rfkill` is set,
+and pressing the button combo to enable wifi doesn't work; we believe that the
+EC is sending rfkill. We do not yet know how to enable it, at least as of
+Libreboot 202405xx.
+
 Introduction
 ============
 

site/docs/hardware/hp820g2.md

@@ -63,15 +63,6 @@ Full hardware specifications can be found on HP's own website:
 
 <https://support.hp.com/gb-en/document/c04543492>
 
-Libreboot pre-installed
-=======================
-
-My company, Minifree Ltd, also sells this machine with Libreboot pre-installed.
-I use the profits from sales to fund my work. You can find the Libreboot 820
-here:
-
-<https://minifree.org/product/libreboot-820/>
-
 Introduction
 ============
 

site/docs/hardware/hp8560w.md

@@ -62,6 +62,8 @@ source](../build/), or use a release newer than 20240126.**
 
 This is a beastly 15" Sandy Bridge mobile workstation from HP.
 
+**Wi-Fi does not work. It shows correctly in lspci, but stays hard blocked.**
+
 GPU
 ---
 

site/docs/hardware/index.md

@@ -54,12 +54,11 @@ libreboot currently supports the following systems in this release:
 
 ### Laptops (Intel, x86)
 
--   **[HP EliteBook 820 G2](hp820g2.md) - Also [available to buy with Libreboot
-    preinstalled](https://minifree.org/product/libreboot-820/)**
 -   **[Lenovo ThinkPad T440p](../install/t440p_external.md) - Also [available
     to buy with Libreboot preinstalled](https://minifree.org/product/libreboot-t440p/)**
 -   **[Lenovo ThinkPad W541](../install/ivy_has_common.md) - Also [available to
-    buy with Libreboot preinstalled](https://minifree.org/product/libreboot-w541/)**
+    buy with Libreboot preinstalled](https://minifree.org/product/libreboot-w541/)** - NOTE: W540 also compatible (same mainboard, so flash the same ROM)
+-   Lenovo ThinkPad X230 - *Also* available on Minifree: <https://minifree.org/product/libreboot-x230/>
 -   [Apple MacBook1,1 and MacBook2,1](macbook21.md)
 -   [Dell Latitude E6400, E6400 XFR and E6400 ATG, all with Nvidia or Intel
     GPU](e6400.md)
@@ -69,9 +68,11 @@ libreboot currently supports the following systems in this release:
 -   [Dell Latitude E5530 (Intel GPU](e5530.md)
 -   [Dell Latitude E6520 (Intel GPU](e6520.md)
 -   [Dell Latitude E6530 (Intel GPU](e6530.md)
+-   Dell Latitude E5420.
 -   [HP EliteBook 2170p](hp2170p.md)
 -   [HP EliteBook 2560p](hp2560p.md)
 -   [HP EliteBook 2570p](hp2570p.md)
+-   [HP EliteBook 820 G2](hp820g2.md)
 -   [HP EliteBook 8460p](hp8460p.md)
 -   [HP EliteBook 8470p](hp8470p.md)
 -   [HP EliteBook 8560w](hp8560w.md)
@@ -90,7 +91,6 @@ libreboot currently supports the following systems in this release:
 -   [Lenovo ThinkPad X200 / X200S / X200 Tablet](x200.md)
 -   [Lenovo Thinkpad X220](../install/ivy_has_common.md)
 -   [Lenovo Thinkpad X220t](../install/ivy_has_common.md)
--   Lenovo ThinkPad X230
 -   [Lenovo Thinkpad X230](../install/x230_external.md)
 -   [Lenovo Thinkpad X230t](../install/x230_external.md)
 -   Lenovo ThinkPad X301

site/docs/hardware/index.zh-cn.md

@@ -66,12 +66,11 @@ Introduction
 
 ### 笔记本（Intel，x86）
 
--   **[HP EliteBook 820 G2](hp820g2.md) - Also [available to buy with Libreboot
-    preinstalled](https://minifree.org/product/libreboot-820/)**
 -   **[Lenovo ThinkPad T440p](../install/t440p_external.md) - Also [available
     to buy with Libreboot preinstalled](https://minifree.org/product/libreboot-t440p/)**
 -   **[Lenovo ThinkPad W541](../install/ivy_has_common.md) - Also [available to
     buy with Libreboot preinstalled](https://minifree.org/product/libreboot-w541/)**
+-   Lenovo ThinkPad X230 - *Also* available on Minifree: <https://minifree.org/product/libreboot-x230/>
 -   [Apple MacBook1,1 及 MacBook2,1](macbook21.md)
 -   [Dell Latitude E6400, E6400 XFR 及 E6400 ATG，皆支持 Nvidia 或 Intel GPU](e6400.md)
 -   Dell Latitude E6420 (Intel GPU) - no guide yet.
@@ -81,6 +80,7 @@ Introduction
 -   [HP EliteBook 2170p](hp2170p.md)
 -   [HP EliteBook 2560p](hp2560p.md)
 -   [HP EliteBook 2570p](hp2570p.md)
+-   [HP EliteBook 820 G2](hp820g2.md)
 -   [HP EliteBook 8460p](hp8460p.md)
 -   [HP EliteBook 8470p](hp8470p.md)
 -   [HP EliteBook 8560w](hp8560w.md)
@@ -98,7 +98,6 @@ Introduction
 -   [Lenovo ThinkPad X200 / X200S / X200 Tablet](x200.md)
 -   [Lenovo Thinkpad X220](../install/ivy_has_common.md)
 -   [Lenovo Thinkpad X220t](../install/ivy_has_common.md)
--   Lenovo ThinkPad X230
 -   [Lenovo Thinkpad X230](../install/x230_external.md)
 -   [Lenovo Thinkpad X230t](../install/x230_external.md)
 -   Lenovo ThinkPad X301

site/docs/install/e6400.md

@@ -158,24 +158,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

@@ -455,7 +455,7 @@ example of the push pin as a proof of concept:
 
 [You must flash it externally](spi.md)
 
-#### ThinkPad X60/X60S/X60T/T60 with Lenovo BIOS {#flashprog_lenovobios}
+#### ThinkPad X60/X60S/X60T/T60 with Lenovo BIOS {#flashrom_lenovobios}
 
 **WARNING: Libreboot 20231021 and likely older 2023 releases do not have the
 bootblock copied in release ROMs, so the bucts trick below will actually cause
@@ -470,9 +470,16 @@ And then do this:
 
 (This was fixed in Libreboot 20231101)
 
+**NOTE: the section below pertaining to 20160907 static binaries references
+flashrom. Libreboot recommends flashprog nowadays, but if you're using that
+utils archive, please note that it is from a time when Libreboot used
+flashrom. Use flashrom there as that's what included in those binaries.
+Libreboot does not currently document how to patch flashprog for sst/macronix
+on X60/T60, when going (in software) from lenovobios to libreboot.**
+
 **NOTE: This section partially relates to `utils` release archive in
 Libreboot 20160907, which contains static compiled binaries for things like
-bucts and flashprog. It will *still* work on modern distros, and thus is
+bucts and flashrom. It will *still* work on modern distros, and thus is
 still referenced here. The `flash` script in that release can be used, with
 modern Libreboot ROMs. Current Libreboot releases do not include pre-compiled
 utilities, only ROMs.**
@@ -487,7 +494,7 @@ X60 BIOS password (Lenovo): you might find info here:
 <https://bios-pw.org/>
 
 You can just get bucts from the libreboot project, same thing for the patched
-flashprog. In the Libreboot 20160907 release, there is a *utility* archive, which
+flashrom. In the Libreboot 20160907 release, there is a *utility* archive, which
 has statically compiled executables. They still work just fine on modern
 systems, and they can be used for this purpose.
 
@@ -502,12 +509,12 @@ Here are a list of targets:
   and you will run it at 115200 baud rate. agetty/fgetty in Linux can give
   you a serial console in your OS)
 
-Download and build flashprog, using the instructions
-on [the Git page](../../git.md), and download the `bucts` software using the
-notes on that very same page.
-
-You can replace Lenovo BIOS with libreboot, using flashprog running on the host
-CPU. However, there are some considerations.
+You can replace Lenovo BIOS with libreboot, using flashrom running on the host
+CPU. However, there are some considerations. NOTE: needs patching for SST
+and macronix chips, but libreboot doesn't yet do this for flashprog. You can
+use the old Libreboot 20160907 sources to get the modified flashrom instead,
+which contains this patch - and static binaries are provided, for convenience;
+they will still work, due to libs being statically linked.
 
 Firstly, make sure that the yellow CMOS battery is installed, and functioning
 correctly. You could check the voltage. The battery is a CR2032
@@ -518,7 +525,7 @@ load on it, which there will be. This coincell powers the real-time clock and
 CMOS memory).
 
 Lenovo BIOS restricts write access, but there is a weakness in it. With a
-specially patched flashprog binary, you can easily flash it but the top 64KiB
+specially patched flashrom binary, you can easily flash it but the top 64KiB
 region of the boot flash, containing your bootblock, cannot be flashed just
 yet. However, there is a register called the *Backup Control* or *BUC* register
 and in that register is a status bit called *Top Swap* or *TS*.
@@ -532,12 +539,12 @@ program referenced below.
 The libreboot ROM images already have the upper 64KiB bootblock copied to the lower
 one, so you don't have to worry about copying it yourself.
 
-If you build flashprog using the libreboot build system, there will be three
+If you use the Libreboot 20160907 utils archive, there will be three
 binaries:
 
-* `flashprog`
-* `flashprog_i945_sst`
-* `flashprog_i945_mx`
+* `flashrom`
+* `flashrom_i945_sst`
+* `flashrom_i945_mx`
 
 It's these last two binaries that you should use. Now compile bucts (just
 run `make` in the bucts source directory).
@@ -549,19 +556,19 @@ Run the bucts tool:
 Ensure that your CMOS battery is connected too. Now you must determine whether
 you have Macronix or SST. An X60/T60 thinkpad will have either an SST or a
 Macronix chip. The Macronix chip will have "MX" written on the chip. You will
-use `flashprog_i945_sst` for the SST chip, and `flashprog_i945_mx` for the
+use `flashrom_i945_sst` for the SST chip, and `flashrom_i945_mx` for the
 Macronix chip.
 
-Now run flashprog (for SST):
+Now run flashrom from the Libreboot 20160907 utils archive (for SST):
 
-	sudo ./flashprog_i945_sst -p internal -w coreboot.rom
+	sudo ./flashrom_i945_sst -p internal -w coreboot.rom
 
 Or Macronix:
 
-	sudo ./flashprog_i945_mx -p internal -w coreboot.rom
+	sudo ./flashrom_i945_mx -p internal -w coreboot.rom
 
 NOTE: you *can* just run both. One of them will succeed. It is perfectly
-harmless to run both versions of flashprog. In fact, you should do so!
+harmless to run both versions of flashrom. In fact, you should do so!
 
 You'll see a lot of errors. This is normal. You should see something like:
 
@@ -589,28 +596,36 @@ Your flash chip is in an unknown state.
 If you see this, rejoice! It means that the flash was successful. Please do not
 panic. Shut down now, and wait a few seconds, then turn back on again.
 
-**WARNING: if flashprog complains about `/dev/mem` access, please
-run `sudo ./bucts 0`. If flashprog is complaining about `/dev/mem`, it means
+**WARNING: if flashrom (from Libreboot 20160907 utils) complains
+about `/dev/mem` access, please
+run `sudo ./bucts 0`. If flashrom is complaining about `/dev/mem`, it means
 that you have `CONFIG_STRICT_DEVMEM` enabled in your kernel. Reboot with the
 following kernel parameter added in your bootloader: `iomem=relaxed` and try
 again with the above instructions. DO NOT continue until the above works, and
-you see the expected flashprog output as indicated above.**
+you see the expected flashrom output as indicated above.**
 
-If you *did* run flashprog and it failed to flash, but you set bucts to 1 and
+If you *did* run flashrom and it failed to flash, but you set bucts to 1 and
 shut down, don't worry. Just remove the yellow coin-cell battery (it's underneath
 the keyboard, connected to the mainboard), wait a minute or two, reconnect the
-coin-cell and try again from scratch. In this instance, if flashprog didn't do
+coin-cell and try again from scratch. In this instance, if flashrom didn't do
 anything, and didn't flash anything, it means you still have Lenovo BIOS but
 if bucts is set to 1, you can flush it and set it back to 0. BUC.TS is stored in
 volatile memory, powered by that CR2032 coin-cell battery.
 
 Assuming that everything went well:
 
+Switch to flashprog now! (avoid flashrom)
+---------------------------------------
+
 Flash the ROM for a second time. For this second flashing attempt, the upper
 64KiB bootblock is now read-write. Use the *unpatched* flashprog binary:
 
 	sudo ./flashprog -p internal -w libreboot.rom
 
+NOTE: At this point, we recommend use of flashprog instead of flashrom, for
+the reasons mentioned in the [Libreboot 20240225
+release](../../news/libreboot20240225.md).
+
 To reset bucts, do this:
 
 	sudo ./bucts 0

site/docs/install/spi.md

@@ -966,6 +966,9 @@ Your DIP8 IC has the same pinout as a SOIC8 IC.
 Replace WSON8 IC with SOIC8
 ---------------------------
 
+**NOTE: You can alternatively purchase WSON8 probes from a site like Aliexpress.
+They look similar to SOIC8 clips, and they work similarly.**
+
 You *can* connect a SOIC8 test clip, but you will struggle to get good
 connections and it will be extremely unreliable. DO NOT solder to the pads of
 the WSON8 directly; some people do this, but you shouldn't do it, because you

site/docs/install/spi.zh-cn.md

@@ -643,6 +643,9 @@ DIP8 IC 的引脚分配和 SOIC8 IC 一样。
 使用 SOIC8 替换 WSON8 IC
 ---------------------------
 
+**NOTE: You can alternatively purchase WSON8 probes from a site like Aliexpress.
+They look similar to SOIC8 clips, and they work similarly.**
+
 你*连是可以连* SOIC8 测试夹，但要连接效果好，需要费点功夫，而且这也十分不可靠。不要直接焊接 WSON8 的焊盘；有些人会这样做，但你不要这样做，因为你这样很容易就会损坏焊盘。
 
 WSON8 的引脚分配和 SOIC8 一样，但它是球状 QFN（四边扁平无引脚封装）。它没有合适的夹子，有时候称为 QFN8。

site/docs/install/x230_external.md

@@ -3,6 +3,9 @@ title: ThinkPad X230/X230T external flashing
 x-toc-enable: true
 ...
 
+This machine is available to purchase with Libreboot pre-installed:
+<https://minifree.org/product/libreboot-x230/>
+
 NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
 now, as of 27 January 2024, which is a fork of flashrom.
 

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

@@ -85,6 +85,43 @@ the [freedom status page](../../freedom-status.md).
 Before *configuration* info, you will first be shown a brief overview of every
 project that Libreboot imports, such as coreboot.
 
+Environmental variables
+=======================
+
+LBMK\_THREADS
+-------------
+
+For example:
+
+	export LBMK_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
+-------------
+
+If set to `y`, it signals to `script/build/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.
+
 Projects/files downloaded/generated by lbmk
 ===========================================
 
@@ -102,8 +139,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.
@@ -530,9 +567,8 @@ This file can contain several configuration lines, each being a string, such
 as:
 
 * `tree="default"` (example entry)
-* `romtype="normal"` (example entry)
 * `rev="ad983eeec76ecdb2aff4fb47baeee95ade012225"` (example entry)
-* `arch="x86_64"` (example entry)
+* `xarch="i386-elf"` (example entry)
 * `payload_grub="y"` (example entry)
 * `payload_grub_withseabios="y"` (example entry)
 * `payload_seabios="y"` (example entry)
@@ -542,26 +578,23 @@ as:
 * `payload_seabios_grubonly="y"` (example entry)
 * `grub_scan_disk="ata"`
 * `uboot_config=default` (specify which U-Boot tree to use)
-* `vendorfiles="n"`
-* `microcode_required="y"`
+* `release="n"` (example entry)
+* `status=stable` (example entry)
+* `xtree="default"` (example entry)
+* `tree_depend="default"` (example entry)
 
 The `tree` value refers to `config/coreboot/TREE`; in other words, a given
 target could specify a name other than its own as the tree; it would then
 re-use code from that tree, rather than providing its own.
 
-The `romtype` entry is used during the building of ROM images, to define
-special steps; for example, d8d16sas` would tell lbmk that a fake PIKE2008
-ROM must be inserted into CBFS (prevents hanging on SeaBIOS).
-
 The `rev` entry defines which coreboot revision to use, from the
 coreboot Git repository. *At present, lbmk only supports use of the official
 repository from the upstream coreboot project*.
 
-The `arch` entry specifies which CPU architecture is to be used: currently
-recognized entries are `x86_32`, `x86_64`, `ARMv7` and `AArch64`. *Setting it
-to a non-native arch means that necessary crossgcc-arch will be compiled and be
-available when building roms, but not necessarily built or discovered when
-individual scripts are called manually.*
+The `xarch` entry specifies which CPU architecture is to be used: currently
+recognized entries are `i386-elf`, `arm-eabi` and `aarch64-elf`. This is the
+target architecture for building GCC/toolchain from coreboot crossgcc,
+hence `xarch`.
 
 The `payload_grub` entry specifies whether or not GRUB is to be included in
 ROM images.
@@ -600,12 +633,32 @@ 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 `vendorfiles` entry doesn't affect anything in code, except that
-the `noblobs` string will be appended to ROM image file names, on releases;
-ditto `nomicrocode` but in that case, the behaviour is: if no microcode to
-begin with, only `nomicrocode` images will be named, otherwise ROM images with
-and without microcode updates will be provided in releases (CPU microcode
-updates).
+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
+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.
+
+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/
 
@@ -1064,27 +1117,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
 --------------
 
@@ -1125,6 +1157,17 @@ 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/
 =======
 
@@ -1233,29 +1276,19 @@ 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/grub
-
-This builds the `grub.elf` file and keymap configuration files, placing these
-under `elf/grub/` for use by `script/build/roms`.
-
-Command: `./build grub`
-
-This builds the `grub-mkstandalone` utility under `src/grub/`, which is used
-by `script/build/roms` to insert GRUB payloads inside coreboot ROM
-images.
-
-### 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`.

site/download.md

@@ -31,13 +31,13 @@ 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
 
 Full key fingerprint: `8BB1 F7D2 8CF7 696D BF4F  7192 5C65 4067 D383 B1FF`
 
-This key is for Libreboot releases *after* the 20240225 release. It applies to
+This key is for Libreboot releases *after* the 20240126 release. It applies to
 all Libreboot releases from the year 2024, and it will expire (unless revoked
 early) on 26 December 2028.
 
@@ -50,9 +50,9 @@ Libreboot releases are signed using GPG.
 Full key fingerprint: `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 20240126 release. This key *expired* during December 2023,
 so you should use the *newer* key (see above) for the releases after
-Libreboot 20240225.
+Libreboot 20240126.
 
 Download the key here: [lbkey.asc](lbkeyold.asc)
 
@@ -83,18 +83,18 @@ 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.
 
 You can download Libreboot from these mirrors:
 
-* <https://www.mirrorservice.org/sites/libreboot.org/release/> (University
-of Kent, UK)
-* <https://mirrors.mit.edu/libreboot/> (MIT university, USA)
 * <https://mirror.math.princeton.edu/pub/libreboot/> (Princeton
 university, USA)
 * <https://mirror.shapovalov.website/libreboot/> (shapovalov.website, Ukraine)
+* <https://www.mirrorservice.org/sites/libreboot.org/release/> (University
+of Kent, UK)
+* <https://mirrors.mit.edu/libreboot/> (MIT university, USA)
 * <https://mirror.koddos.net/libreboot/> (koddos.net, Netherlands)
 * <https://mirror-hk.koddos.net/libreboot/> (koddos.net, Hong Kong)
 * <https://mirror.cyberbits.eu/libreboot/> (cyberbits.eu, France)
@@ -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,13 +31,13 @@ LIBREBOOT](news/safety.md).**
 Код підпису GPG
 ---------------
 
-**Останнім випуском є Libreboot 20240225, в директорії `testing`.**
+**Останнім випуском є Libreboot 20240504, в директорії `stable`.**
 
 ### НОВИЙ КЛЮЧ
 
 Повний відбиток ключа: `8BB1 F7D2 8CF7 696D BF4F  7192 5C65 4067 D383 B1FF`
 
-Вищезазначений ключ для Libreboot 20240225, та наступних випусків. This key
+Вищезазначений ключ для Libreboot 20240126, та наступних випусків. This key
 is applicable to any release made on or after the date: 28 December 2023. It
 will expire on 26 December 2028.
 
@@ -50,9 +50,9 @@ 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 20240225.
+Libreboot 20240126.
 
 Завантажте ключ тут: [lbkey.asc](lbkeyold.asc)
 
@@ -83,18 +83,18 @@ Libreboot 20240225.
 Дзеркала HTTPS {#https}
 -------------
 
-**Останнім випуском є Libreboot 20240225, в директорії `testing`.**
+**Останнім випуском є Libreboot 20240504, в директорії `stable`.**
 
 Дані дзеркала є рекомендованими, оскільки використовують TLS (https://) шифрування.
 
 Ви можете завантажити Libreboot через дані дзеркала:
 
-* <https://www.mirrorservice.org/sites/libreboot.org/release/> (Кентський
-університет, Великобританія)
-* <https://mirrors.mit.edu/libreboot/> (Університет МТІ, США)
 * <https://mirror.math.princeton.edu/pub/libreboot/> (Прінстонський
 університет, США)
 * <https://mirror.shapovalov.website/libreboot/> (shapovalov.website, Україна)
+* <https://www.mirrorservice.org/sites/libreboot.org/release/> (Кентський
+університет, Великобританія)
+* <https://mirrors.mit.edu/libreboot/> (Університет МТІ, США)
 * <https://mirror.koddos.net/libreboot/> (koddos.net, Нідерланди)
 * <https://mirror-hk.koddos.net/libreboot/> (koddos.net, Гонконг)
 * <https://mirror.cyberbits.eu/libreboot/> (cyberbits.eu, Франція)
@@ -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/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

@@ -3,46 +3,45 @@ title: Libreboot 项目
 x-toc-enable: true
 ...
 
-*Libreboot* 项目基于 coreboot 提供了[自由且开源](https://writefreesoftware.org/zh-cn/)的引导固件，替代了特定基于 Intel/AMD x86 及 ARM 的主板（包括笔记本和桌面计算机）上的专有 BIOS/UEFI 固件。它首先对硬件（如内存控制器、CPU、外设）进行初始化，然后为操作系统启动 bootloader。本项目对 [Linux](docs/linux/) 和 [BSD](docs/bsd/) 支持良好。寻求帮助，可以前往 [Libera](https://libera.chat/) IRC 上的 [\#libreboot](https://web.libera.chat/#libreboot) 频道。
+*Libreboot* 项目提供基于 coreboot 的[自由且开源](https://writefreesoftware.org/zh-cn/)的引导固件，以替代基于 Intel/AMD x86 和 ARM 的特定主板（包括笔记本和台式电脑）上的专有 BIOS/UEFI 固件。它首先初始化硬件（如内存控制器、CPU、外设），然后为操作系统启动引导加载程序（bootloader）。本项目对 [Linux](docs/linux/) 和 [BSD](docs/bsd/) 支持良好。如果需要寻求帮助，可以前往 [Libera](https://libera.chat/) IRC 上的 [\#libreboot](https://web.libera.chat/#libreboot) 频道。
 
 <img tabindex=1 class="r" src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /><span class="f"><img src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /></span>
 
-You can also [buy Libreboot preinstalled](https://minifree.org/) from Minifree Ltd,
-on select hardware, aswell as send your compatible hardware
-for [Libreboot preinstallation](https://minifree.org/product/installation-service/).
-The founder and lead developer of Libreboot, Leah Rowe, also owns and operates
-Minifree; sales provide funding for Libreboot.
+你也可以从 Minifree Ltd [购买特定硬件的 Libreboot 电脑](https://minifree.org/)，
+或者将兼容硬件寄来预装 Libreboot。
+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*?
 ----------------------------
 
-Libreboot 赋予了你[自由](https://writefreesoftware.org/)，而这等自由，是你用其他引导固件得不到的。同时，它的启动速度更加快，[安全性也更加高](docs/linux/grub_hardening.md)。在各种情况下使用，它都十分强大，具有高度[可配置性](docs/maintain/)。
+Libreboot 赋予了你从其他大多数引导固件得不到的[自由](https://writefreesoftware.org/)。同时，它启动速度更快，[安全性也更好](docs/linux/grub_hardening.md)。它功能强大，可针对多种使用情况进行配置。
 
-*我们*相信，不受限制地[研究、分享、修改及使用软件](https://writefreesoftware.org/)的自由，是每个人都必须享有的基本人权的一部分。这时，*软件自由*至关重要。你的自由至关重要。教育至关重要。[修理权](https://yewtu.be/watch?v=Npd_xDuNi9k)至关重要。尽管许多人在用[自由的操作系统](https://www.openbsd.org/)，但他们用的引导固件却是专有（非自由）的。专有固件常常[包含](faq.html#intel)了[后门](faq.html#amd)，并且也可能出问题。2013 年 12 月，我们建立了 Libreboot 项目，目的是让不懂技术的用户能使用 coreboot 固件。
+*我们*相信，不受限制地[研究、分享、修改及使用软件](https://writefreesoftware.org/)的自由，是每个人都必须享有的基本人权的一部分。这时，*软件自由*至关重要。你的自由至关重要。教育至关重要。[修理权](https://yewtu.be/watch?v=Npd_xDuNi9k)至关重要。尽管许多人在用[自由的操作系统](https://www.openbsd.org/)，但他们用的引导固件却是专有（非自由）的。专有固件常常[包含](faq.html#intel)了[后门](faq.html#amd)，而且可能有很多缺陷。为了让不懂技术的用户也能使用 coreboot 固件，我们于 2013 年 12 月成立了 Libreboot 项目，
 
-Libreboot 项目使用 [coreboot](https://www.coreboot.org/) 来[初始化硬件](https://doc.coreboot.org/getting_started/architecture.html)。对大部分不懂技术的用户来说，coreboot 是出了名地难安装；它只处理了基础的初始化，然后跳转进入单独的 [payload](https://doc.coreboot.org/payloads.html) 程序（例如 [GRUB](https://www.gnu.org/software/grub/)、[Tianocore](https://www.tianocore.org/)），而后者也需要进行配置。*Libreboot 解决了这样的问题*；他是一个 *coreboot 发行版*，配有[自动构建系统](docs/build/)，能够构建完整的 *ROM 镜像*，从而让安装更加稳定。另有文档可参考。
+Libreboot 项目使用 [coreboot](https://www.coreboot.org/) 来[初始化硬件](https://doc.coreboot.org/getting_started/architecture.html)。对大部分不懂技术的用户来说，coreboot 是出了名地难安装；它只处理了基础的初始化，然后跳转进入单独的 [payload](https://doc.coreboot.org/payloads.html) 程序（例如 [GRUB](https://www.gnu.org/software/grub/)、[Tianocore](https://www.tianocore.org/)），而后者也需要进行配置。*Libreboot 解决了上述问题*；作为 *coreboot 发行版*，配有[自动构建系统](docs/build/)，能构建完整的 *ROM 映像*，从而让安装更加稳定。另有文档可参考。
 
 Libreboot 不是 coreboot 的分支
 -----------------------------------
 
 <img tabindex=1 class="l" style="max-width:25%;" src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /><span class="f"><img src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /></span>
 
-事实上，Libreboot 对每一块主板，都尽可能保持与*标准*的 coreboot 接近，但 Libreboot 构建系统也自动提供了许多不同类型的配置。
+事实上，Libreboot 对每一块主板，都尽可能保持与*原版*的 coreboot 接近，但 Libreboot 构建系统也自动提供了许多不同类型的配置。
 
-Libreboot 是一个 *coreboot 发行版*，就好比 *Alpine Linux* 是一个 *Linux 发行版*。如果你想要从零开始构建 ROM 镜像，那你需要对 coreboot、GRUB 以及其他所需软件进行专业级别的配置，才能准备好 ROM 镜像。有了 *Libreboot*，你只需要下载 Git 仓库或者源代码归档，然后运行 a script，接着就能构建整个 ROM 镜像。一套自动构建系统，名为 `lbmk`（Libreboot Make），将自动构建 ROM 镜像，而无需任何用户输入或干预。配置已经提前完成。
+Libreboot 是一个 *coreboot 发行版*，就好比 *Alpine Linux* 是一个 *Linux 发行版*。如果想要从零开始构建 ROM 映像，那就需要对 coreboot、GRUB 以及其他所需软件进行专业级别的配置，才能准备好 ROM 映像。有了 *Libreboot*，只需下载 Git 仓库或者源代码归档，然后运行 `make`，接着就能构建整个 ROM 映像。名为 `lbmk` (Libreboot Make) 的自动构建系统会自动构建这些 ROM 映像，无需任何用户输入或干预。已经提前进行了配置。
 
-如果你要构建常规的 coreboot，而不使用 Libreboot 的自动构建系统，那么需要有很多的干预以及相当的技术知识，才能写出一份能工作的配置。
+如果要构建常规的 coreboot，不使用 Libreboot 的自动构建系统，那么需要更多干预以及相当的技术知识，才能得到可用的配置。
 
-Libreboot 的常规二进制版本，提供了这些预编译的 ROM 镜像。你可以轻松安装它们，而无需特别的知识和技能，只要能遵循[写给非技术用户的简单指南](docs/install/)。
+Libreboot 的常规二进制版本提供了这些预编译的 ROM 映像。按照[写给非技术用户的简单指南](docs/install/)安装即可，无需任何特殊的知识或技能。
 
-如何帮忙
+如何帮助
 -----------
 
 <img tabindex=1 class="l" style="max-width:15%;" src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /><span class="f"><img src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /></span>
 
-要帮忙的话，*最*最好的方式，就是通过提交配置文件，来为 Libreboot *添加*新的主板。coreboot 支持的任何东西，都能并入 Libreboot，并且带有 ROM 镜像。见：
+要帮助的话，*最*最好的方式，就是通过提交配置文件，来为 Libreboot *添加*新的主板。coreboot 支持的任何主板都能收录到 Libreboot，并在发布版本中附带 ROM 映像。见：
 
 * [申请成为主板维护者/测试者](docs/maintain/testing.md)
 * [新主板移植指南](docs/maintain/porting.md)
@@ -52,19 +51,19 @@ Libreboot 的常规二进制版本，提供了这些预编译的 ROM 镜像。
 
 *用户支持*也十分重要。多瞧一瞧 IRC，如果你有能力帮别人解决问题（或者愿意跟他们一起学习），那对本项目的贡献会很大。许多人也在 reddit 版块 `r/libreboot` 寻求用户支持。
 
-你可以检查[缺陷追踪系统](https://codeberg.org/libreboot/lbmk/issues)列出的缺陷。
+可以检查[缺陷追踪系统](https://codeberg.org/libreboot/lbmk/issues)列出的缺陷。
 
-如果你发现了一个缺陷，并且有解决方案，[这里说明了发布补丁的方法](git.md)，你也可以提交报告。同时，本站完全使用 Markdown 编写，并托管在了一个[单独的仓库](https://codeberg.org/libreboot/lbwww)，你可以在那里发送补丁。
+如果发现了一个缺陷，并且有解决方案，[这里说明了发布补丁的方法](git.md)，也可以提交报告。同时，本站完全使用 Markdown 编写，并托管在了一个[单独的仓库](https://codeberg.org/libreboot/lbwww)，可以在那里发送补丁。
 
-所有开发方面的讨论以及用户支持，都是在 IRC 频道上完成的。了解更多，可以查看[联系](contact.md)页面。
+所有开发方面的讨论以及用户支持，都是在 IRC 频道上完成的。想要了解更多，可以查看[联系](contact.md)页面。
 
 libreboot.org 需要翻译
 --------------------------------------
 
 Libreboot 目前有乌克兰语和法语的网页翻译（但两个语言都还没翻译完所有页面）。
 
-如果你想帮忙翻译，你可以翻译网页、更新已有翻译并提交你的译本。请阅读下面的指南：
+如果想帮忙翻译，可以翻译网页、更新已有翻译并提交译本。请阅读下面的指南：
 
 [如何提交 libreboot.org 翻译](news/translations.md)
 
-即使已经有人在进行某个语言的翻译了，我们也总是欢迎更多人。多多益善！
+即使已经有人在进行某种语言的翻译了，我们也总是欢迎更多人。多多益善！

site/news/MANIFEST

@@ -1,3 +1,4 @@
+libreboot20240504.md
 libreboot20240225.md
 ports202402.md
 sourcehut.md
@@ -5,7 +6,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/hp820g2.md

@@ -23,15 +23,6 @@ Full hardware specifications can be found on HP's own website:
 
 <https://support.hp.com/gb-en/document/c04543492>
 
-Libreboot pre-installed
-=======================
-
-My company, Minifree Ltd, also sells this machine with Libreboot pre-installed.
-I use the profits from sales to fund my work. You can find the Libreboot 820
-here:
-
-<https://minifree.org/product/libreboot-820/>
-
 Introduction
 ============
 

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/libreboot20240225.md

@@ -57,8 +57,6 @@ This release supports the following hardware:
 
 ### Laptops (Intel, x86)
 
--   **[HP EliteBook 820 G2](../docs/hardware/hp820g2.md) - Also [available to buy with Libreboot
-    preinstalled](https://minifree.org/product/libreboot-820/)**
 -   **[Lenovo ThinkPad T440p](../docs/install/t440p_external.md) - Also [available
     to buy with Libreboot preinstalled](https://minifree.org/product/libreboot-t440p/)**
 -   **[Lenovo ThinkPad W541](../docs/install/ivy_has_common.md) - Also [available to
@@ -75,6 +73,7 @@ This release supports the following hardware:
 -   [HP EliteBook 2170p](../docs/hardware/hp2170p.md)
 -   [HP EliteBook 2560p](../docs/hardware/hp2560p.md)
 -   [HP EliteBook 2570p](../docs/hardware/hp2570p.md)
+-   [HP EliteBook 820 G2](../docs/hardware/hp820g2.md)
 -   [HP EliteBook 8460p](../docs/hardware/hp8460p.md)
 -   [HP EliteBook 8470p](../docs/hardware/hp8470p.md)
 -   [HP EliteBook 8560w](../docs/hardware/hp8560w.md)
@@ -187,6 +186,10 @@ Documentation is provided for this, in the pico-serprog README. Riku also
 fixed this issue:
 <https://codeberg.org/libreboot/lbmk/issues/182>
 
+Riku also increased the default drive strength to 12mA on all RP2024 boards,
+increasing reliabily when externally flashing certain mainboards (e.g. PCH
+having low/no resistance on connections to the data lines for the flash).
+
 Flashprog now used, instead of flashrom
 ---------------------------------------
 
@@ -209,15 +212,20 @@ the new flashprog project.
 
 Several developers have already jumped ship and went to work on flashprog.
 Nico's vision is a far more sensible one, and he has been invaluable to the
-Libreboot project over many years. As a result, Libreboot withdraws its support
-and endorsement of flashrom - it will only promote flashprog from now on.
+Libreboot project over many years. He has *personally* provided me with help
+and advise on numerous occasions. He is also the author of the Roda RK9 port in
+coreboot, upon which Vladimir Serbinenko's ThinkPad X200 port was based - work
+which *defined* Libreboot in its early days, contributions for which I remain
+eternally grateful. I *know* Nico and trust him as a project leader. As a result,
+Libreboot withdraws its support and endorsement of flashrom - it will only
+promote flashprog from now on.
 
 It's quite possible that *flashrom* has a future, but there's no reason why
 their changes cannot also be included in flashprog, if they are good changes,
 moving forward. Libreboot supports Nico's work out of principle, both on
-a social (community-led, not run by an employee of Google) and technological
+a social (community-led, anyone can participate in it) and technological
 perspective. This was done because, firstly Nico Huber is a better leader,
-and flashrom is very likely to become the dominant project in the future.
+and flashprog is very likely to become the dominant project in the future.
 
 This is the *first* Libreboot release to include flashprog sources, instead
 of flashrom. Moving forward, we will *not* be providing support for flashrom.
@@ -232,6 +240,46 @@ new features and hardware functionality - for instance, it has code for handling
 Riku Viitanen's recent changes on the RP2040 serprog images, for pulling unused
 chipselects high (useful on machines like ThinkPad W541 for external flashing).
 
+Context regarding flashprog vs flashrom
+---------------------------------------
+
+It was suggested by a reader, on 27 March 2024, that the lack of context made
+judging this situation very difficult. Therefore, the following links have
+been added, with explanation below.
+
+More context can be gleaned from the following links:
+
+* <https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/47TTR4YNQV7QGPXSL2TROI3FES56XXF7/>
+* <https://www.phoronix.com/news/Flashrom-Splits-Into-Two>
+* <https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/message/ZOYX5R2R5IO3KVFBOKUSQGSL7I7WIHAL/>
+* <https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/message/6MOOPJHTXRS5GK5JUUKL6APJQ6HIHA73/>
+* <https://mail.coreboot.org/hyperkitty/list/flashrom-stable@flashrom.org/thread/RTP3UKMMGWUEVTS5XUFRCXXL24UE4FRV/>
+
+The first link is the mailing list post, where the new flashrom leader unilaterally
+announced Nico's banishment from the project, without giving actual evidence
+to back up her accusations (accusations which are made in the very same post).
+Several other flashrom developers weighed in, some taking the side of the new
+leadership, and several others taking Nico's side. What happened to Nico was
+unfair. As already stated, Libreboot will promote flashprog, *not* flashrom,
+from now on.
+
+Not only were such accusations made, but Nico was initially given his own
+repository on the coreboot project, for his project, which he then
+named *flashrom-stable*. See:
+
+* <https://review.coreboot.org/admin/repos/flashrom-stable,general>
+
+However, as you can see (at least on this date, 27 March 2024), this repo has
+been hidden from view. Nico was banned from even having flashrom-stable on
+the same infrastructure as flashrom, which uses the coreboot infrastructure.
+This later lead to Nico establishing the Flashprog project.
+
+Libreboot stands with Nico and his Flashprog project. Anyone contributing to
+flashrom should consider working for flashprog, either in addition to or
+instead of flashrom. Libreboot will continue its boycott of Flashrom until
+its current leader, Anastasia Klimchuk, steps down from the leadership, and
+even then only after reparations/apologies are issued to the accused.
+
 Exact git log
 -------------
 
@@ -290,3 +338,9 @@ branch, relative to the previous January 2024 release:
 
 You may find archives of this release, by looking at the Libreboot download
 page. Support is available on IRC or Reddit if you need help.
+
+NOTE: As in the previous release, HP 820 G2 images are not provided, because
+the inject scripts cannot currently produce a reliable checksum when inserting
+vendor files on these boards, due to the non-reproducible way in which the
+refcode file is compressed during insertion. Therefore, you
+must [build it from source](../docs/build/).

site/news/libreboot20240504.md

@@ -0,0 +1,456 @@
+% Libreboot 20240504 released!
+% Leah Rowe
+% 4 May 2024
+
+Introduction
+============
+
+Libreboot is a free/open source BIOS/UEFI replacement on x86 and ARM, providing
+boot firmware that initialises the hardware in your computer, to then load an
+operating system (e.g. Linux/BSD). It is specifically a *coreboot distribution*,
+in the same way that Debian is a Linux distribution. It provides an automated
+build system to produce coreboot ROM images with a variety of payloads such as
+GNU GRUB or SeaBIOS, with regular well-tested releases to make coreboot as easy
+to use as possible for non-technical users. From a project management perspective,
+this works in *exactly* the same way as a Linux distro, providing the same type
+of infrastructure, but for your boot firmware instead of your operating system.
+It makes use of [coreboot](https://www.coreboot.org/) for hardware initialisation,
+and then a payload such as [SeaBIOS](https://www.seabios.org/SeaBIOS)
+or [GNU GRUB](https://www.gnu.org/software/grub/) to boot your operating
+system; on ARM(chromebooks), we provide *U-Boot* (as a coreboot payload).
+
+Libreboot provides many additional benefits such as fast boot speeds, greater
+security and greater customisation, but the *primary* benefit
+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).
+
+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 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.
+Your computer is *your property* to use as you wish. Free Software protects you,
+by ensuring that you always have control of the machine.
+
+*This* new release, Libreboot 20240504, released today 4 May 2024, is
+a new *stable* release of Libreboot. The previous stable release was
+Libreboot 20230625 released on 25 June 2023, and the previous *testing* release
+was Libreboot 20240225 released on 25 February 2024. Extreme care has been
+taken with this release, but it adds a host of new features such as USB3
+support in the GRUB payload, and a slew of mainboard fixes. *Read on* to learn
+more.
+
+The main purpose of this release has been to fix bugs. A lot more work will now
+go into Libreboot for a planned *testing* release in the summer of 2024.
+
+Hardware supported in this release
+==================================
+
+This release supports the following hardware:
+
+### Servers (AMD, x86)
+
+-   [ASUS KFSN4-DRE motherboard](../docs/hardware/kfsn4-dre.md)
+-   [ASUS KGPE-D16 motherboard](../docs/hardware/kgpe-d16.md)
+
+### Desktops (AMD, Intel, x86)
+
+-   **[Dell OptiPlex 7020/9020 MT and SFF](../docs/hardware/dell9020.md) - Also [available to buy
+    with Libreboot preinstalled](https://minifree.org/product/libreboot-9020/)** - Dell OptiPlex XE2 MT/SFF also known to work
+-   [Acer G43T-AM3](../docs/hardware/acer_g43t-am3.md)
+-   [Apple iMac 5,2](../docs/hardware/imac52.md)
+-   [ASUS KCMA-D8 motherboard](../docs/hardware/kcma-d8.md)
+-   Dell OptiPlex 7010 **MT** (known to work, using the T1650 ROM, but more
+    research is needed)
+-   [Dell Precision T1650](../docs/hardware/t1650.md)
+-   [Gigabyte GA-G41M-ES2L motherboard](../docs/hardware/ga-g41m-es2l.md)
+-   [HP Elite 8200 SFF/MT](../docs/hardware/hp8200sff.md) (HP 6200 Pro Business probably works too)
+-   [HP Elite 8300 USDT](../docs/hardware/hp8300usdt.md)
+-   [Intel D510MO and D410PT motherboards](../docs/hardware/d510mo.md)
+-   [Intel D945GCLF](../docs/hardware/d945gclf.md)
+
+### Laptops (Intel, x86)
+
+-   **[Lenovo ThinkPad T440p](../docs/install/t440p_external.md) - Also [available
+    to buy with Libreboot preinstalled](https://minifree.org/product/libreboot-t440p/)**
+-   **[Lenovo ThinkPad W541](../docs/install/ivy_has_common.md) - Also [available to
+    buy with Libreboot preinstalled](https://minifree.org/product/libreboot-w541/)**
+-   [Apple MacBook1,1 and MacBook2,1](../docs/hardware/macbook21.md)
+-   [Dell Latitude E6400, E6400 XFR and E6400 ATG, all with Nvidia or Intel
+    GPU](../docs/hardware/e6400.md)
+-   [Dell Latitude E6420 (Intel GPU](../docs/hardware/e6420.md)
+-   [Dell Latitude E6430 (Intel GPU](../docs/hardware/e6430.md)
+-   [Dell Latitude E5520 (Intel GPU](../docs/hardware/e5520.md)
+-   [Dell Latitude E5530 (Intel GPU](../docs/hardware/e5530.md)
+-   [Dell Latitude E6520 (Intel GPU](../docs/hardware/e6520.md)
+-   [Dell Latitude E6530 (Intel GPU](../docs/hardware/e6530.md)
+-   Dell Latitude E5420
+-   [HP EliteBook 2170p](../docs/hardware/hp2170p.md)
+-   [HP EliteBook 2560p](../docs/hardware/hp2560p.md)
+-   [HP EliteBook 2570p](../docs/hardware/hp2570p.md)
+-   [HP EliteBook 820 G2](../docs/hardware/hp820g2.md)
+-   [HP EliteBook 8460p](../docs/hardware/hp8460p.md)
+-   [HP EliteBook 8470p](../docs/hardware/hp8470p.md)
+-   [HP EliteBook 8560w](../docs/hardware/hp8560w.md)
+-   [HP EliteBook Folio 9470m](../docs/hardware/hp9470m.md)
+-   [Lenovo ThinkPad R400](../docs/hardware/r400.md)
+-   [Lenovo ThinkPad R500](../docs/hardware/r500.md)
+-   [Lenovo ThinkPad T400 / T400S](../docs/hardware/t400.md)
+-   [Lenovo Thinkpad T420](../docs/install/ivy_has_common.md) (no install docs yet)
+-   [Lenovo ThinkPad T420S](../docs/install/ivy_has_common.md) (no install docs yet)
+-   [Lenovo ThinkPad T430](../docs/install/ivy_has_common.md) (no install docs yet)
+-   [Lenovo ThinkPad T500](../docs/hardware/t500.md)
+-   [Lenovo ThinkPad T520 / W520](../docs/install/ivy_has_common.md) (no install guide yet)
+-   [Lenovo ThinkPad T530 / W530](../docs/install/ivy_has_common.md) (no install
+-   Lenovo ThinkPad T60 (with Intel GPU)
+-   [Lenovo ThinkPad W500](../docs/hardware/t500.md)
+-   [Lenovo ThinkPad X200 / X200S / X200 Tablet](../docs/hardware/x200.md)
+-   [Lenovo Thinkpad X220](../docs/install/ivy_has_common.md)
+-   [Lenovo Thinkpad X220t](../docs/install/ivy_has_common.md)
+-   Lenovo ThinkPad X230
+-   [Lenovo Thinkpad X230](../docs/install/x230_external.md)
+-   [Lenovo Thinkpad X230t](../docs/install/x230_external.md)
+-   Lenovo ThinkPad X301
+-   Lenovo ThinkPad X60 / X60S / X60 Tablet
+
+### Laptops (ARM, with U-Boot payload)
+
+-   [ASUS Chromebook Flip C101 (gru-bob)](../docs/install/chromebooks.md)
+-   [Samsung Chromebook Plus (v1) (gru-kevin)](../docs/install/chromebooks.md)
+
+New mainboard added
+====================
+
+This release adds support for the following mainboard:
+
+* Dell Latitude E5420, courtesy of Nicholas Chin
+
+Dell Latitude laptops: S3 resume fixed
+================================
+
+Nicholas Chin sent in a patch just before the release, fixing suspend/resume
+on sandy bridge and ivy bridge Dell laptops. According to him, resume on open
+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 release. The *previous* stable release
+was Libreboot 20230625, but there have been a number of *testing* releases
+between that and today's release.
+
+To know the full set of differences between Libreboot 20230625
+and Libreboot 20240405, first you must read the changelogs of those interim
+testing releases. They are, in order: Libreboot [20231021](libreboot20231021.md),
+[20231101](libreboot20231101.md), [20231106](libreboot20231106.md),
+[20240126](libreboot20240126.md) and [20240225](libreboot20240225.md).
+
+The following log will now acount for changes since Libreboot 20240225, from
+most recent descending to very earliest commits. The most interesting changes
+are highlighted in bold:
+
+* **Fix S3 suspend/resume on Ivybridge/Sandybridge-era Dell Latitude laptops.**
+  Patch courtesy of Nicholas Chin.
+* **Fixed WiFi on HP EliteBook 8560w via GPIO config**. Patch by Leah Rowe,
+  but using advice from Angels Pons; thank you, Angel! There is a GPIO
+  that sets `WLAN_TRN_OFF#` low or high; coreboot was setting it low, but it
+  needs to be set high otherwise hardware rfkill would be set. WiFi now
+  works perfectly, but NOTE: the WiFi enable/disable button doesn't currently
+  do anything; it sends a scancode which is picked up in dmesg due to being
+  non-standard. You can still enable or disable WiFi from your OS.
+* `sript/update/release`: Report on the terminal when a tarball is being
+  created, to avoid giving the impression that the script has crashed when
+  making very large tar archives.
+* dell-flash-unlock: Use a portable Makefile (GNU Make no longer required).
+  Patch courtesy of Nicholas Chin.
+* dell-flash-unlock README updated for the BSDs (patch courtesy Nicholas Chin)
+* **`dell_flash_unlock`: Add support for FreeBSD** (patch courtesy Nicholas Chin)
+* `dell_flash_unlock`: Set iopl level back to 0 when done (patch by Nicholas Chin)
+* `dell_flash_unlock`: Fix ec_set_fdo() signature (patch courtesy Nicholas Chin)
+* QEMU: Corrected SMBIOS information in the coreboot config. Patch courtesy
+  of *livio*. (libreboot provides coreboot images to run on QEMU)
+* GRUB ATA boot: Fixed it so that it actually scans `ata` devices in GRUB,
+  rather than `ahci`. Patch courtesy of *livio*.
+* GRUB hotkeys added: at boot, hold *shift* to disable gfxterm. Hold *CTRL* to
+  enable serial output. Hold *ALT* to enable spkmodem. Patch courtesy of *livio*.
+* General code cleanup / simplification in lbmk.
+* **Support SeaGRUB with SeaBIOS menu enabled**. This is when GRUB is the first
+  thing that SeaBIOS starts (GRUB from flash). We already supported it, but
+  we disabled the SeaBIOS menu when doing this. Now we provide options with
+  the menu retained. This is useful on desktops where you use a graphics card,
+  but you still mainly want to use the GRUB payload, because we don't initialise
+  VGA from coreboot, only from SeaBIOS (we provide a framebuffer from coreboot
+  for Intel graphics, but graphics cards are handled by SeaBIOS).
+* `update/trees`: Simplified handling of defconfig files. The new code is
+  more reliable, and will not have to be modified as much when adding
+  new options for changing configs.
+* Don't use `nproc` to decide build threads; set it to 1 instead. The user
+  can manually specify build threads when running lbmk. This is because nproc
+  is not available on all systems.
+* eDP-based X230/X220 configs have been removed. Reasoning is provided at
+  the end of this article (please scroll down).
+* IASL/acpica: Libreboot now hosts these releases on the mirrors, and uses
+  them in lbmk. This is because Intel's own links often expire, or have
+  unstable hashes. Coreboot's build system is patched to use Libreboot's
+  mirror, when downloading these tarballs.
+* Allow disabling status checks during build. Do: `export LBMK_STATUS=n`
+* `./build roms list`: Allow filtering based on status. E.g.
+  command: `./build roms list stable`
+* Allow setting *status* on coreboot targets, and warn about it during builds.
+  Set it in target.cfg; e.g. `status="stable"` or `status="untested"`. If it's
+  not marked stable, a given board will provide a y/n confirmation screen on
+  build, asking if you want to skip the build (this dialog is disabled
+  in release builds) - there is another: `release` variable in target.cfg
+  can be set to n, to always skip building that target, but only skip on
+  release builds. This is better than documenting board status on the website,
+  because it's automated in lbmk. A `warn.txt` file can be provided in
+  the board directory inside lbmk, with a message that will be printed when
+  building; you can use this to warn the user about specific issues.
+* i945 targets (ThinkPad X60/T60, Macbook2,1): switch back to the February 2023
+  coreboot revision used in Libreboot 20230625 for now, to work around an issue
+  that was reported by some users; it will be updated again in a future release.
+* Export environmental variables from `err.sh`, to ensure that they are always
+  exported and therefore universally consistent in all parts of lbmk, once
+  set (unless overridden by a given script).
+* **GRUB:** Update to newer revision just after version 2.12. The new revision
+  has a fix bug fixes for file systems, most notably XFS.
+* Dell OptiPlex 9020 SFF/MT: Add TPM support and enable the TPM by default.
+* lbmk: Better handling of `/tmp` files. Fewer/no files are left behind now,
+  after a build has completed.
+* HP EliteBook 820 G2: Retain the target, allow it to be built from source, but
+  do not include ROM images in releases. This is because the *inject* script
+  cannot yet reliably and reproducibly insert the *refcode* file without
+  the hash changing, due to the native of *xz* (compression utility).
+* **Haswell targets: MRC configs disabled. Only NRI ROMs provided now.** The
+  libre raminit (NRI) is now stable enough in testing, that it's the default,
+  and the only one provided in releases. This affects: ThinkPad W541/T440p
+  and Dell OptiPlex 9020 SFF/MT. This is done, in application of Libreboot's
+  Binary Blob Reduction Policy which states: if a blob can be avoided, it
+  should be avoided.
+* **Dell OptiPlex 9020 SFF/MT: Added configs using NRI (native RAM
+  initialisation / libre raminit).** Angel Pons fixed S3 suspend/resume also,
+  which works perfectly now, on NRI.
+* **Dell OptiPlex 9020 SFF/MT: Fan control now works perfectly.** Before, the
+  fans would only run at a very low speed even in stress conditions, leading
+  to higher temperatures. The result is you can now use faster, hotter CPUs
+  and the fans will spin up just right. Patch courtesy of Mate Kukri.
+* **ThinkPad W541/T440p NRI:** GRUB payload has been enabled on setups that use
+  NRI (native RAM initialisation / libre raminit). It was previously only
+  enabled on the MRC-based setup.
+* ThinkPad T440p/W541: Added targets that use *Broadwell* MRC code (same as
+  below regarding Dell OptiPlex 9020 SFF/MT). Again: MRC targets disabled in
+  release. NRI-based images are provided exclusively now (libre raminit).
+* Dell OptiPlex 9020 SFF/MT: Added targets that use the *Broadwell* MRC code,
+  for memory controller initialisation. Use of it works around a lot of issues
+  in the Haswell one. NOTE: Libreboot no longer provides MRC-based images, so
+  you have to build this from source in lbmk. See notes above, about S3 fix
+  on NRI (native RAM initialisation / libre raminit).
+* **GRUB: Added xHCI (USB 3.0) native driver.** Patches courtesy Patrick Rudolph,
+  rebased by Leah Rowe for GRUB 2.12 series. GRUB keyboard input can now work,
+  on boards that only have xHCI (some newer boards lack EHCI and/or PS/2)
+* **Fixed 3rd SATA slot on Dell OptiPlex 9020 SFF**, and 3rd and 4th slots
+  on 9020 MT; they previously did not work. Patch courtesy of Mate Kukri.
+* Allow specifying the number of threads to build on, via environmental
+  variable `LBMK_THREADS`. This is useful if you're on a host with limited RAM.
+* Simpler, safer error handling in the build system
+* **util/autoport:** New utility, imported from coreboot's version but with extra
+  patches merged for Haswell platforms. This can be used in future, tied heavily
+  to Libreboot's own coreboot trees, to more easily add new mainboards.
+* **util/dell-flash-unlock: NetBSD support added**, courtesy of the developer
+  who goes by the name *Linear Cannon*. Here is that person's website as of
+  today: <https://linear.network/>
+* NEW MAINBOARD: Dell Latitude E5420, courtesy of Nicholas Chin
+* **OptiPlex 9020 SFF/MT: Graphics card now work perfectly.** Disable IOMMU by
+  default, to work around an issue so that graphics cards can be used. It is a
+  toggle option that you can change; IOMMU recommended if using Intel graphics,
+  otherwise leave it turned off.
+* coreboot/haswell: Make IOMMU a runtime option (on/off toggle)
+* Enable the serial console by default, on AMD boards (kgpe-d16, kcma-d8)
+
+Exact git log (versus Libreboot 20240225)
+======================================
+
+The following is an exact log of commits in the Git repository, on the master
+branch, relative to the previous January 2024 release. There are 99 changes:
+
+```
+* ae9e7389 Libreboot 20240504 release 
+* d3aeb2c7 config/git: importer newer documentation 
+* 5bf25eac coreboot: update latitude release status 
+* 7a955a4c d510mo and d945gclf: disable for release 
+* 7e799e1f nb/haswell: lock policy regs when disabling IOMMU 
+* d9c0346a build/roms: more useful status warnings 
+* 98587029 deprecate MRC 9020MT/SFF (NRI 9020 is default now) 
+* d839bfa1 mark 9020 sff/mt stable for release 
+* a9bc6b25 mark lenovo x301 as stable for release 
+*   6e61052a Merge pull request 'coreboot/default: Add patches to fix S3 on SNB/IVB Latitudes' (#208) from nic3-14159/lbmk:latitude-fix-s3 into master 
+|\  
+| * 67ddd3f2 coreboot/default: Add patches to fix S3 on SNB/IVB Latitudes 
+|/  
+* 780e03fe remove x220edp/x230edp (keep regular x220/x230) 
+* b379186a update hp machines to status=stable for release 
+* 6e7b5c0b Enable WiFi on HP EliteBook 8560w (GPIO config) 
+*   99617796 Merge pull request 'Implemented failsafe options at boot and inside menus for enabling/disabling serial, spkmodem and gfxterm' (#203) from livio/lbmk:failsafe into master 
+|\  
+| * 3e86b3ab Implemented failsafe options at boot and inside menus for enabling/disabling serial, spkmodem and gfxterm 
+* | 2d207c54 coreboot/x301: set release=n (will re-test) 
+* | 64ae2ddd update/release: purge test/lib/strlcat.c in u-boot 
+* | 748b2072 mark x4x boards ready for release 
+* | 9caff263 err.sh: update copyright info 
+* | 7db2ae0b update/release: say when an archive is being made 
+* |   cd9685d1 Merge pull request 'dell-flash-unlock: Remove dependency on GNU Make' (#207) from nic3-14159/lbmk:dell-flash-unlock-updates into master 
+|\ \  
+| * | a5cb6376 dell-flash-unlock: Remove dependency on GNU Make 
+|/ /  
+* |   4bf3da31 Merge pull request 'Fixed QEMU x86 target's SMBIOS informations' (#205) from livio/lbmk:qemux86_fix into master 
+|\ \  
+| * | 707d7ce7 Fixed QEMU x86 target's SMBIOS informations 
+| * | d654a3e5 Fixed QEMU x86 target's SMBIOS informations 
+| |/  
+* |   a18cd7f1 Merge pull request 'Fixed boot selection menu' (#204) from livio/lbmk:livio_290424 into master 
+|\ \  
+| * | b4d27d0c Fixed boot selection menu 
+| |/  
+* |   05c3f493 Merge pull request 'dell-flash-unlock-updates' (#206) from nic3-14159/lbmk:dell-flash-unlock-updates into master 
+|\ \  
+| * | 61f66a46 dell-flash-unlock: Update README for BSD 
+| * | 5e2e7611 dell_flash_unlock: Add support for FreeBSD 
+| * | 61dbaf94 dell_flash_unlock: Set iopl level back to 0 when done 
+| * | 355dffb7 dell_flash_unlock: Fix ec_set_fdo() signature 
+| * | 6fe2482f dell-flash-unlock: Remove unnecessary includes for NetBSD 
+| * | b737a24c dell-flash-unlock: Remove memory clobber from inline assembly 
+* | | 5c3d81ff correct dell latitude status for release 
+* | | 6dfd8c70 update release status for HP machines 
+* | | 50f6943c set gru bob/kevin stable for release 
+* | | df5e3216 set dell latitudes stable for release 
+* | | 7e7c3c23 mark i945 machines as stable for release 
+* | | 310378c9 build/roms: simplified list handling 
+* | | 5003e02b build/roms: if release, allow all non-broken roms 
+* | | dbe259ef build/roms: always display warnings 
+* | | 0e2c56be build/roms: reduce indentation in skip_board() 
+* | | 91927760 build/roms: simplified status handling 
+* | | 230f68fd build/roms: simplified seagrub handling 
+|/ /  
+* | 515185a7 build/roms: support SeaGRUB *with menu enabled* 
+* | a88a8281 update/trees: simplified defconfig copying 
+* | 55204dc4 option.sh: don't use nproc (not portable) 
+* | 71f8e653 eDP configs (x230/x220): don't release 
+* | a5c7cc1a fix target.cfg files on dell latitudes 
+* | d923d314 use mirrorservice.org for iasl downloads 
+* | 714d4b3e update/release: disable status checking 
+* | e614f906 build/roms: tell the user how to ignore status 
+* | f22305fb update macbook21/x60/t60 status 
+* | 6c4f07b3 allow disabling status checks during builds 
+* | ad7e3966 update 9020 sff/mt release status 
+* | 3ace925e update more board statuses before release 
+* | e7619225 Set status=unstable on dell latitudes 
+* | 1fd9ba9a declare ivy/sandy thinkpads stable for release 
+* | 5218bfb0 declare gm45 thinkpads stable for release 
+* | b99ebe05 kcma-d8/kgpe-d16: mark as tested(unstable) 
+* |   e5cc3e55 Merge pull request 'dell-flash-unlock: add NetBSD support' (#194) from linear/lbmk:master into master 
+|\ \  
+| * | e119ffa5 dell-flash-unlock: add NetBSD support 
+* | | c0b4ba2e build/roms: update help, pertaining to status 
+* | | d88783b7 build/roms: let "list" specify status types 
+* | | b6014a65 erroneous return 
+* | | ce7fd754 build/roms: report status when building images 
+* | | a2f42353 i945: switch boards to 20230625 coreboot revision 
+* | | 64177dbb exports variables from err.sh, not build 
+* | | a5082de4 GRUB: bump to today's latest revision 
+* | | ddfe71a3 9020 sff/mt: actually enable the TPM (by default) 
+* | | 2d7debd3 9020 sff/mt: add tpm enable patch from mate kukri 
+* | | 08859bb4 lbmk: export TMPDIR from err.sh, not build 
+* | | f5f2c58a build/roms: add missing deletion of tmp file 
+* | | 02e4c0b2 hp820g2: allow building, but don't do release ROMs 
+* | | ed0678ae haswell: only provide NRI-based ROMs in releases 
+* | | f5035e32 9020 sff/mt: fix bad gpio read on hwm patch 
+* | | 523f1df9 w541 libremrc: disable tseg stage cache 
+* | | c557e9e0 haswell nri: set 8MB CBFS on thinkpads (fix S3) 
+* | | ac7ce930 add 9020sff/mt configs using haswell NRI 
+* | | 9e3b217c update coreboot/haswell (NRI) 
+* | | 6da91df6 add mate's patch for 9020 sff/mt fan controls 
+* | | 83195489 enable grub payload on libremrc w541/t440p 
+* | | e9c591a5 add t440p/w541 configs using broadwell mrc 
+* | | 4134a883 add 9020 sff/mt targets that use broadwell mrc 
+* | | f7283fa1 grub xhci support 
+* | | 5cb17795 fix sata slots on dell 9020 sff and mt 
+* | | 33277897 allow users to specify number of build threads 
+* | | 6ebab10c safer, simpler error handling in lbmk 
+| |/  
+|/|   
+* |   6b11f1b0 Merge pull request 'config: Add Dell Latitude E5420' (#191) from nic3-14159/lbmk:latitude-ports into master 
+|\ \  
+| * | 036bf2c6 config: Add Dell Latitude E5420 
+* | |   457a7037 Merge pull request 'util: Import autoport with Haswell patches' (#195) from nic3-14159/lbmk:autoport-fork into master 
+|\ \ \  
+| |_|/  
+|/| |   
+| * | 8cba2370 util: Import autoport with Haswell patches 
+|/ /  
+* |   c578fe56 Merge pull request 'Use proper autolink' (#192) from eo/lbmk:master into master 
+|\ \  
+| |/  
+|/|   
+| * 98caceb1 Use proper autolink 
+|/  
+* 665840b2 coreboot/dell9020*_12mb: Disable IOMMU by default 
+* 944cafa2 coreboot/haswell: make IOMMU a runtime option 
+* db074b78 enable serial console on fam15h boards 
+```
+
+You may find archives of this release, by looking at the Libreboot download
+page. Support is available on IRC or Reddit if you need help.
+
+Disabled boards
+===============
+
+Libreboot's build system can be configured to exclude certain boards in
+release archives, while still permitting them to be re-built.
+
+All of the following boards have been disabled in the build system:
+
+HP EliteBook 820 G2, because refcode cannot be inserted reproducibly yet. This
+is what enables the gigabit ethernet on the machine (it's a Broadwell machine
+so still needs MRC). A future release will fix this, and there are three
+viable ways: execute an uncompresed refcode instead, or use tar
+reproducibly (impossible to guarantoo on the host so tar and xz would have
+to be compiled by lbmk), or: replace the blob. None of the possible solutions
+are fully viable, so lbmk will support this board but ROM images for it will
+be excluded in releases (at least for the time being)
+
+D510MO and D945 images not included either, due to lack of testing. (820 G2
+is believed to be stable and has been tested repeatedly)
+
+*All other boards have ROM images in this release.*
+
+eDP mods (ThinkPad X230/X220)
+==========================
+
+The `x230edp_12mb` and `x220edp_8mb` targets were removed, but
+the `x230_12mb` and `x220_8mb` targets were retained. Only the original
+nitrocaster mod (for eDP) is reliable in my experience, and it's unknown what
+you get with the various knockoffs available on aliexpress. Delete the board
+from Libreboot, to reduce the maintenance burden. Use an older Libreboot
+revision if you want these boards. They will probably not be re-added to
+Libreboot, unless Nitrocaster re-opens and/or a professional/reliable
+alternative appears(the alternatives as of today are all assumed to be rubbish).
+
+The nitrocaster store seems to be out of business at this time of writing,
+and these modded boards are uncommon enough as it is, making testing extremely
+challenging; testing on multiple machines is desirable, but most people who
+do these mods don't want to then mess with their hardware afterward.
+
+The good news is that coreboot has mainlined X230 eDP support, so you will
+always have that option readily available. The other bad news with this mod
+is the knockoff gear generally has poor documentation (Nitrocaster has very
+good documentation), and people frequently have problems, either by their own
+fault or by virtue of the product; the eDP-based targets are therefore a liability
+to the Libreboot project.
+
+That is all.

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.**

site/tasks/index.md

@@ -27,27 +27,6 @@ U-Boot test/lib/strlcat.c
 Delete this file, in U-Boot trees, before the next release
 after Libreboot 20231106.
 
-S3 on ivy/sandy/haswell
-=======================
-
-Ivybridge, sandybridge and haswell thinkpads have broken S3 suspend/resume,
-at least in coreboot 4.22 - we are affected in lbmk, where we use a revision
-that is quite close to 4.22, but we mitigate it by turning off the TSEG stage
-cache.
-
-It's possible that upstream may have properly fixed it already. In our case,
-disabling TSEG stage cache makes S3 work again, on these machines - but GM45
-and i945 are still broken (see below).
-
-Of interest, this patch was merged *after* the current revision used
-in Libreboot, at least on 26 December 2023:
-
-<https://review.coreboot.org/c/coreboot/+/78850>
-
-Updating coreboot revisions is par for the course in Libreboot. This should
-be tested again, but with TSEG Stage Cache re-enabled, to verify whether S3
-is still broken on these machines (ditto GM45 and i945).
-
 Rockchip RK3588 SoCs in coreboot
 ================================
 
@@ -73,41 +52,7 @@ TF-A is quite an interesting project:
 It is essentially an analog of coreboot; coreboot even uses parts of this, on
 some boards.
 
-S3 on GM45 and i945
-===================
-
-S3 is currently broken on GM45 and i945 machines. This can be bisected in
-coreboot revisions, because it is believed to work well on Libreboot releases
-as recent as 20230625. This needs to be fixed before the next stable release.
-
-The October 2023 and November 2023 releases are affected by this. GM45 means
-machines such as ThinkPad X200 and T400. i945 machines machines such as
-ThinkPad X60 and T60.
-
-The newer generation of Intel machines are not affected, and S3 has never
-worked on Dell Latitude E6400 (a GM45 machine), because (according to Nicholas
-Chin) an idiosyncrasy in how the EC affects coming out of reset.
-
-Libreboot mailing list
-======================
-
-Use <https://sr.ht/~libreboot/> to provide a mailing list, for the Libreboot
-project. Sourcehut is a codeforge, that revolves around use of a mailing list.
-The actual mailing list itself is very good, though Libreboot would likely
-continue using [Codeberg](../news/codeberg.md) since it provides an interface
-that most contributors will be familiar with.
-
-Libreboot last had a mailing list in 2016, but running one isn't very feasible
-for a small project like this, with a smaller scope. Although Libreboot has an
-ambition to support every board from coreboot, of which there are hundreds, the
-actual design of Libreboot (as a [source-based package manager that auto-builds
-ROM images](../docs/maintain/)) is very limited in scope.
-
-At the same time, there aren't many good outsourced options for providing a
-mailing list. Sourcehut is basically our best option. Access to the `~libreboot`
-account was [acquired](../news/10.md) during April 2023.
-
-General auditing
+general auditing
 ================
 
 Libreboot's build system design is already extremely efficient. See:
@@ -169,24 +114,6 @@ Libreboot can support any board from coreboot, in principle. It would also be
 feasible to integrate other (libre) boot firmware, if desirable. The list below
 is not exhaustive, it just lists boards that are interesting to us at this time:
 
-Autoport
---------
-
-Autoport is not available for all boards, but is available under the coreboot
-repository. When you run it, the program provides you with instructions for
-how to run it and how to handle the results, what to check
-for manually for tweaking later, while providing general advice to the budding
-coreboot developer.
-
-Well, it's not available for some newer Intel platforms. There are patches
-on coreboot gerrit, that enable it for these platforms. Namely:
-
-* Haswell-lynxpoint: <https://review.coreboot.org/c/coreboot/+/30890>
-* Broadwell: <https://review.coreboot.org/c/coreboot/+/46832>
-
-These patches for the newer platforms are not yet merged in coreboot main. You
-can just cherry-pick these as desired.
-
 Boards
 ------
 
@@ -222,18 +149,6 @@ machine).
 
 Both are supported by coreboot.
 
-ASUS A88XM-E
-------------
-
-See: <https://browse.libreboot.org/lbmk.git/commit/?h=a88hm_test&id=80118a24b80b94078dec6aee9f54cfc5d286a14b>
-
-This is in a special branch, because there is currently no automation in the
-vendor scripts. it was done just to test the board. This uses an older revision
-of coreboot, because the board was dropped after coreboot 4.18. This lbmk
-patch makes use of coreboot `4.18_branch`.
-
-TODO: Finish this port in lbmk, and add it to the master branch.
-
 840 G2 (possible 820 G2)
 -------------------------
 
@@ -276,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
 --------------
@@ -435,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
@@ -700,36 +612,6 @@ boot many distros. We could provide something similar to this in Libreboot.
 This was briefly documented on the Libreboot website,
 before [argon2 kdf support](../news/argon2.md) was merged in Libreboot GRUB.
 
-Disable Libgfxinit on DGPU setups
-=================================
-
-On machines where a discrete GPU is used, and no Intel GPU is present, but there
-are other variants where an Intel GPU is present, it is possible to provide a
-ROM image where:
-
-1) Libgfxinit is enabled, for Intel graphics
-2) SeaBIOS payload starts first, and can execute VGA ROMs from graphics cards
-3) If a graphics card works, then that VGA ROM provides initialisation
-
-When a dGPU is used, this can cause problems. For example, VGA-based
-mode setting doesn't work properly on some machines, for some reason. For
-example, on the Nvidia variants of Dell Latitude E6400, no Intel graphics
-exists. For some reason, enabling libgfxinit makes `nomodeset` no longer work,
-and VGA modes in various bootloaders e.g. syslinux/grub no longer work - 
-whereas enabling just the SeaBIOS payload to load a VGA ROM, without loading
-libgfxinit, works reliable.
-
-Look at [lbmk build system documentation](../docs/maintain/) to know the
-difference between libgfxinit/normal configs. Basically, we only enable
-libgfxinit when available but we provide SeaBIOS as the default payload. If
-a graphics card is used, SeaBIOS scans the VGA ROM from it or one can be
-provided in CBFS.
-
-We should keep doing what we're doing, but also provide configurations where
-only the VGA ROM is used, on setups that use a discrete GPU. Libreboot's
-preference is to use the native initialisation, but sometimes the VGA ROM has
-be to be used instead.
-
 Seek QUBES endorsement
 ======================
 
@@ -906,8 +788,7 @@ util can be used to dump the mxm config. on systems where there is no i2c rom,
 the system firmware (in this case libreboot) must provide it via int15h
 interrupt. riku's seabios patches implement this.
 
-TODO: Merge in libreboot, with elitebook 8560w support. (riku will probably
-merge this himself, but i'm adding it here just in case)
+TODO: Document this properly, if not already documented.
 
 John lane GRUB patches
 ======================
@@ -1347,27 +1228,6 @@ is hardcoded into certain logic, in the build system.
 Coreboot supports configuring which scheme to use, at boot time, but we don't
 use it. Coreboot's default is to always load the fallback, so we use that.
 
-Delete of /tmp files
-====================
-
-Libreboot resets `TMPDIR` to a subdirectory inside `/tmp`, so that further
-calls to `mktemp` will create all further files and directories under a single
-subdirectory, which can then be deleted all at once, when Libreboot's build
-system exits. This is exported to child processes of lbmk, so that it's
-universal at all times, on each run of lbmk.
-
-It's designed this way, specifically to avoid leaving temporary files on the
-file system, after lbmk exits. If lbmk is interrupted, they will remain, but
-that's the same as with any other program.
-
-They are only deleted once lbmk exits, so if there are a lot of files, that
-means `/tmp` can fill up fast. This can be a problem, especially if the user
-has `/tmp` inside a tmpfs (file system mounted in memory).
-
-Therefore, an audit should be done, ensuring that tmpfiles are deleted as soon
-as possible, while lbmk runs. This is especially needed in the script
-at `script/build/roms`.
-
 Improved payload documentation
 ===============================
 
@@ -1378,22 +1238,6 @@ also don't link to them or cross reference them in any way.
 We should start writing about the payloads in more detail, referencing upstream
 documentation whenever possible.
 
-Re-add vendorfile extract
-=========================
-
-We have scripts that auto-download firmware from the vendor when required,
-and a script that removes/adds them after the fact, if done on release ROMs.
-
-We used to have a fallback script that would extract such files from a factory
-ROM image, but it was poorly maintained and then removed from Libreboot. We
-still recommend using the internet-based script instead, but having such a
-fallback option is still desirable. By having this, we could then reliably
-always have access to such firmwares.
-
-Last time the extract script existed in master, it lacked support for certain
-files, such as SCH5545EC firmware or extracting MRC firmware(which probably
-isn't possible anyway).
-
 Static compiled utils in releases
 =================================
 
@@ -1858,13 +1702,6 @@ cheap. It's a low-effort attack.
 So we should cover it, and talk about ways to mitigate the risk (e.g. disable
 USB input devices and networking devices, in the user's operating system).
 
-Coreboot users page
-===================
-
-Update it and also add canoeboot there. The current entry isn't really a problem
-but it could be better, and also be more descriptive about all the features
-lbmk offers.
-
 Auto-configure IFD region limits
 ================================
 
@@ -2140,28 +1977,6 @@ could enable this on all the older desktop machines, where otherwise their
 factory firmware does not and will not enable it (and the above link is for
 UEFI systems only).
 
-./update release -m serprog
-===========================
-
-Support generating release archives that only contain serprog src and roms,
-nothing else. But with the lbmk build system in it, to build them if using
-the serprog src archive (while roms would also be provided).
-
-also:
-
-	./update release -m serprogsrc
-
-^ src only
-
-right now we have:
-
-	./update release # builds all roms and src, coreboot too
-	./update release -m src # same as above, but src only
-
-The `-m serprog` and `-m serprogsrc` arguments would apply the same logic,
-but only handle serprog sources. Specifically, pico-serprog and stm32-vserprog,
-which Riku already automated the handling of in lbmk.
-
 Shrink FSP size (Intel)
 =========================
 
@@ -2192,40 +2007,6 @@ tested this (no problems so far, since mid/late 2022 when we started
 doing this in osboot, and heads did it for years before we did, and
 they never had any problems).
 
-sh set -o pipefail
-==================
-
-Example:
-
-```
-grep "foo" bar.txt | sort
-```
-
-In piped commands, the final command's return value is always used.
-In this case, grep's returning of a non-zero status will *not* result
-in a non-zero exit from a script (where `-e` is set, which we do set in
-most of lbmk).
-
-To remedy this, add:
-
-```
-set -o pipefail
-```
-
-We already set `-u` and `-e`. The `u` switch makes a script exit with
-error status if a variable is used initialised. The `e` switch makes a
-script exit with error-status when any command executed within it exits
-with error, unless the above scenario applies.
-
-Also see:
-
-* <https://gist.github.com/mohanpedala/1e2ff5661761d3abd0385e8223e16425>
-* <http://redsymbol.net/articles/unofficial-bash-strict-mode/>
-
-We already are very strict in how we handle errors, but lbmk does indeed
-used piped logic in a few areas. An audit is in order, to fix any potential
-lack of error handling in such cases.
-
 HP 820 G2 TPM
 =============
 
@@ -2244,24 +2025,6 @@ And also this, straight from the horse's mouth:
 
 <https://www.infineon.com/cms/en/product/security-smart-card-solutions/optiga-embedded-security-solutions/optiga-tpm/slb-9660xt1.2/>
 
-GRUB XHCI support
-=================
-
-Not merged in master yet, but check this patch series from 2020:
-
-https://lists.gnu.org/archive/html/grub-devel/2020-12/msg00111.html
-
-This could very likely be rebased on top of GRUB 2.12.
-
-GRUB seems to have a habit of *not* merging perfectly good patches. It
-took years for John Lane's detached luks header support to be merged.
-
-also see
-
-<https://www.youtube.com/watch?v=SSrFv4a-zgU>
-
-https://blog.3mdeb.com/2020/2020-11-02-grub2mini-summit/
-
 GRUB nvme support
 =================
 
@@ -2309,20 +2072,6 @@ It doesn't affect anything in practise, whether this is on or not, because
 we neuter anyway, so the ME interface is broken by default. Leaving it
 on in devicetree will result in a benign error message on linux dmesg.
 
-audit tmp usage
-===============
-
-some .elf files are left in /tmp, outside of TMPDIR, after lbmk runs,
-and it seems to be when building elfs. in particular, it happened
-when i built gru\_bob but it could be for others
-
-lbmk changes TMPDIR to /tmp/lbmk\_xxxxxxxxx where x numbers are generated,
-and exports that, but things that it runs may or may not respect TMPDIR,
-or it could be buggy in some shells. therefore, audit the way lbmk uses
-tmp, because in some cases it literally does now delete temporary files
-or directories, on the assumption that they are deleted at the end. at the
-end when lbmk exits, the main script deletes /tmp/lbmk\_xxxxxxxx
-
 Switchable Graphics (Optimus)
 =============================
 
@@ -2396,6 +2145,10 @@ then the bug will be in coreboot. Could be either of them.
 Could be a bug in GRUB's memory management. And/or regression in
 coreboot raminit. More testing is needed.
 
+NOTE: May 2024 release is using coreboot from 20230625 on these laptops (i945)
+to work around the issue, but it'll possibly be fixed before that release,
+otherwise afterward.
+
 Intel/AMD errata PDF
 ====================
 
@@ -2408,13 +2161,56 @@ unpatched as of yet, in microcode updates.
 
 Links.
 
-Fork autoport to util/
-======================
+interesting video
+=================
 
-TODO: transfer written notes here
+<https://www.youtube.com/watch?v=5qauRh7eTNY>
 
-Autoport patches are all over the place. The one in coreboot main is horribly
-out of date, for example only goes up to Broadwell even with the out of
-tree patches.
+Automate testing
+================
 
-Port it to skylake and above.
+Even though there's lots of error handling, it's better to be paranoid than
+brick users' machines.
+
+Unit tests
+----------
+
+- Build time or separate?
+- me_cleaner -c: checks that ime was inserted and has valid signatures
+
+CI
+--
+
+Preferably self-hosted. Run tests for every commit. There could be tests of
+different size, and even a periodic nightly release could be done.
+
+Integrating this with an automated test stand would also be doable. At the
+very least, it would assure that the ROM images boot successfully.
+
+Board status
+============
+
+As the number of ports grows, it becomes harder to keep track of what works.
+Let's build a machine-readable repo documenting every release (or commit)
+on every board. What features/payloads work, maybe include errata text field.
+A HTML report could also be generated and published online.
+
+On top of this, an easy to use installer could be developed. It would know
+to not install an unbootable (broken) ROM, and would inform users about any
+known problems and have meaningful options.
+
+haswell board bifircation
+=========================
+
+<https://www.mouser.com/pdfDocs/4th-gen-core-family-desktop-vol-1-datasheet.pdf>
+
+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/>

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)
 
 Потрібні розробники!
 ==================