libreboot
/
lbwww
1
0
Fork 0
Code Packages Projects Releases Activity

Compare commits

base: libreboot:master
Branches Tags
libreboot:master
libreboot:c20230710
libreboot:hslick-master
libreboot:20240612
libreboot:20240504
libreboot:20240225
libreboot:20231106
libreboot:20231101fix2
libreboot:20231101fix
libreboot:20231101
libreboot:20231021
libreboot:20230625
libreboot:20230423
libreboot:20230413_2
libreboot:20230413
libreboot:20220710
libreboot:20211122
..
compare: libreboot:20240225
Branches Tags
libreboot:master
libreboot:c20230710
libreboot:hslick-master
libreboot:20240612
libreboot:20240504
libreboot:20240225
libreboot:20231106
libreboot:20231101fix2
libreboot:20231101fix
libreboot:20231101
libreboot:20231021
libreboot:20230625
libreboot:20230423
libreboot:20230413_2
libreboot:20230413
libreboot:20220710
libreboot:20211122

No commits in common. "master" and "20240225" have entirely different histories.
master ... 20240225

66 changed files with 4233 additions and 3142 deletions
Show Stats Expand all files Collapse all files

1
site.cfg
View File

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

94
site/contrib.md
View File

@ -196,13 +196,33 @@ systems.
Joshua Gay
----------
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 is former FSF staff.
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.
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>
Klemens Nanni
-------------
@ -213,17 +233,55 @@ libreboot, and several tweaks to the build system.
Lisa Marie Maginnis
-------------------
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 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.
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.
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.
Lorenzo Aloe
------------
@ -258,6 +316,10 @@ 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
-----------------

467
site/contrib.uk.md Normal file
View File

@ -0,0 +1,467 @@
---
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

22
site/docs/build/index.md vendored
View File

@ -25,28 +25,6 @@ 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/)
Multi-threaded builds
=====================
Libreboot's build system defaults to a single build thread, but you can change
it by doing e.g.
export XBMK_THREADS=4
This would make lbmk run on 4 threads.
More specifically: when compiling source trees via `script/trees`, `-jTHREADS`
is passed, where THREADS is the number of threads. This is also set when running
xz commands for compression, using the `-t` option.
Environmental variables
=======================
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
=======

49
site/docs/build/index.uk.md vendored
View File

@ -35,55 +35,6 @@ 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
===

89
site/docs/hardware/dell9020.md
View File

@ -48,7 +48,7 @@ P*: Partially works with blobs
| ***Features*** | |
|---------------------------------------------------|----|
| **Internal flashing with original boot firmware** | W+ |
| **Internal flashing with original boot firmware** | ? |
| **Display (if Intel GPU)** | W+ |
| **Display (discrete CPU, SeaBIOS payload only)** | W* |
| **Audio** | W+ |
@ -66,7 +66,7 @@ Introduction
**Unavailable in Libreboot 20240126 or earlier. You must [compile from
source](../build/), or use a version newer than Libreboot 20240126**
Official information about this machine can be found here:
Official information about the laptop can be found here:
<https://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/optiplex-9020-micro-technical-spec-sheet.pdf>
Buy Libreboot preinstalled
@ -91,64 +91,23 @@ Kukri's patch is here:
This patch, at this revision (patchset 31), is what Libreboot uses for this
port.
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
Graphics cards
--------------
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.
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.
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.
Here is an example of the type of errors we got when testing graphics cards
with IOMMU enabled:
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:
<https://av.vimuser.org/error.jpg>
Make sure to configure your image accordingly.
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.
7020 compatibility
------------------
@ -162,11 +121,11 @@ separate targets for MT and SFF.
Build ROM image from source
---------------------------
For the MT variant (7020 MT and 9020 MT):
For the MT variant (7020 MT and 9020 SFF):
./build roms dell9020mt_12mb
For the SFF variant (7020 SFF and 9020 SFF):
For the SFF variant (7020 MT and 7020 SFF):
./build roms dell9020sff_12mb
@ -200,21 +159,6 @@ Flash a ROM image (software)
If you're already running Libreboot, and you don't have flash protection
turned on, [internal flashing](../install/) is possible.
Internal flashing can also be done with the original Dell BIOS, if the
SERVICE_MODE jumper near the PCIe slots is installed. Before flashing,
rmmod spi-intel-platform
needs to be run to prevent errors. Once Libreboot is installed, the
SERVICE_MODE jumper can be removed.
**Note: The Dell BIOS can write EFI variables to flash when shutting
down, which could corrupt the newly flashed Libreboot ROM and render
the system unusable. To prevent this, after flashing internally from
the original Dell BIOS, remove power from the computer instead of
shutting it down normally. It's recommended to use a live USB instead
of the internal drive to prevent potential filesystem corruption.**
Flash a ROM image (hardware)
-----------------
@ -224,7 +168,8 @@ 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.
There are two SOIC-8 chips. You can split up your 12MB ROM image
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
like so:
dd if=libreboot.rom of=4mb.rom bs=1M skip=8

52
site/docs/hardware/dell_thermal.md
View File

@ -1,52 +0,0 @@
---
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.

6
site/docs/hardware/e5520.md
View File

@ -3,12 +3,6 @@ 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

6
site/docs/hardware/e5530.md
View File

@ -3,12 +3,6 @@ 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

6
site/docs/hardware/e6400.md
View File

@ -3,12 +3,6 @@ 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>

6
site/docs/hardware/e6420.md
View File

@ -3,12 +3,6 @@ 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

6
site/docs/hardware/e6430.md
View File

@ -3,12 +3,6 @@ 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

6
site/docs/hardware/e6520.md
View File

@ -3,12 +3,6 @@ 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

6
site/docs/hardware/e6530.md
View File

@ -3,12 +3,6 @@ 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

2
site/docs/hardware/ga-g41m-es2l.md
View File

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

8
site/docs/hardware/hp2560p.md
View File

@ -35,14 +35,6 @@ 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
============

9
site/docs/hardware/hp820g2.md
View File

@ -63,6 +63,15 @@ 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
============

2
site/docs/hardware/hp8560w.md
View File

@ -62,8 +62,6 @@ 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
---

8
site/docs/hardware/index.md
View File

@ -54,11 +54,12 @@ 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/)** - NOTE: W540 also compatible (same mainboard, so flash the same ROM)
- Lenovo ThinkPad X230 - *Also* available on Minifree: <https://minifree.org/product/libreboot-x230/>
buy with Libreboot preinstalled](https://minifree.org/product/libreboot-w541/)**
- [Apple MacBook1,1 and MacBook2,1](macbook21.md)
- [Dell Latitude E6400, E6400 XFR and E6400 ATG, all with Nvidia or Intel
GPU](e6400.md)
@ -68,11 +69,9 @@ 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)
@ -91,6 +90,7 @@ 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

5
site/docs/hardware/index.zh-cn.md
View File

@ -66,11 +66,12 @@ 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.
@ -80,7 +81,6 @@ 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,6 +98,7 @@ 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

31
site/docs/install/e6400.md
View File

@ -104,19 +104,6 @@ variants with Intel graphics.
For Intel GPU variants, Libreboot 20230423 and up have full support. Simply
flash a release ROM, if you wish.
Intel GPU errata
----------------
Systems with a 1440 x 900 display panel instead of the more common 1280 x 800
panel will have garbled graphics before the OS boots (i.e. in SeaBIOS or GRUB)
in Libreboot 20240504 and earlier. This is fixed in releases after 20240504.
This was caused by libgfxinit calculating PLL divider values for the pixel clock
assuming a 96 MHz reference frequency, whereas the E6400 uses a 100 MHz
reference frequency. The error is not large enough to affect the lower
resolution panels, but is enough to affect the 1440 x 900 panels which use a
higher pixel clock.
Nvidia GPU: Video BIOS Option ROM required
==========================================
@ -171,6 +158,24 @@ 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
-------------------

115
site/docs/install/index.md
View File

@ -3,12 +3,6 @@ title: Installation instructions
x-toc-enable: true
...
**SAFETY WARNING!**
====================================================================
**IMPORTANT ADVICE: [PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING/UPDATING
LIBREBOOT](../../news/safety.md).**
Need help?
==========
@ -74,6 +68,12 @@ Otherwise, if you get such errors, it may just be that you're not root. You
must run flashprog as root, at least to use the internal flasher (using external
USB flashing dongles doesn't normally require root).
SAFETY WARNING!
====================================================================
**IMPORTANT ADVICE: [PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING/UPDATING
LIBREBOOT](../../news/safety.md).**
PRECAUTIONS
===========
@ -199,16 +199,48 @@ an option in the boot menu.
ROM images that have `seabios_withgrub` in the file name start with SeaBIOS
first, but also have GRUB available in the boot menu when you press ESC.
ROM images with this and `grubonly` in the image start SeaBIOS, but only load
GRUB from SeaBIOS and the SeaBIOS menu is disabled. Use these images if you
only want GRUB; they are provided on systems that only have VGA ROM-based
initialisation, usually discrete graphics cards on desktop machines.
### seabios\_grubfirst (DEFUNCT)
**DEFUNCT**
This build option is obsolete, and should not be used. It was deleted
in lbmk revision `e1bbdadc9584291cf062660d67128e9f17ab788e`.
It was believed, in earlier theory, that VGA ROM initialisation could
be used in SeaBIOS and then SeaBIOS boots into a GRUB payload (built
for coreboot), where the initialisation would continue to be used, but
it didn't work that way.
It's best to use PC GRUB (normal BIOS GRUB), but compile it into a floppy
image to insert inside CBFS, to then be executed by SeaBIOS. This is referred
to as SeaGRUB by the Libreboot project, and it would be quite useful
for desktop users, but it's largely irrelevant on laptops where
coreboot's own `libgfxinit` is usually available (or the option ROM is
easy to extract from vendor firmware and insert).
Where direct bare metal GRUB is desired, but you use a desktop system with
an add-on graphics card, you must extract the VGA ROM for your card and
insert it into the coreboot ROM, for coreboot itself to execute. This will
require custom configuration on your part, and it is thus beyond the scope
of the Libreboot project, in context of lbmk (automated build system).
Some older Libreboot releases included ROM images built using this option,
and those specific ROM images (`seabios_grubfirst` ones) should not be
used; you should only use `seabios_grubfirst` or `seabios`, in most
scenarios, if SeaBIOS is required.
For most desktop users, if running an external graphics card, it's easier
to simply boot in text mode with a SeaBIOS payload and use only that. This
will Just Work with almost all graphics cards, allowing you to use an
operating system with a full display and (drivers permitting) full 2D/3D
acceleration.
Which systems are supported?
============================
[Refer to the hardware compatibility page](../hardware/)
Sandy/Ivybridge/Haswell MAC address (e.g. X230, X220, T440p, W541, hp8200sff)
Intel GbE MAC address (IFD-based systems)
=====================================================================
@ -423,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 {#flashrom_lenovobios}
#### ThinkPad X60/X60S/X60T/T60 with Lenovo BIOS {#flashprog_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
@ -438,16 +470,9 @@ 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 flashrom. It will *still* work on modern distros, and thus is
bucts and flashprog. 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.**
@ -462,7 +487,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
flashrom. In the Libreboot 20160907 release, there is a *utility* archive, which
flashprog. 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.
@ -477,12 +502,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)
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.
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.
Firstly, make sure that the yellow CMOS battery is installed, and functioning
correctly. You could check the voltage. The battery is a CR2032
@ -493,7 +518,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 flashrom binary, you can easily flash it but the top 64KiB
specially patched flashprog 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*.
@ -507,12 +532,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 use the Libreboot 20160907 utils archive, there will be three
If you build flashprog using the libreboot build system, there will be three
binaries:
* `flashrom`
* `flashrom_i945_sst`
* `flashrom_i945_mx`
* `flashprog`
* `flashprog_i945_sst`
* `flashprog_i945_mx`
It's these last two binaries that you should use. Now compile bucts (just
run `make` in the bucts source directory).
@ -524,19 +549,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 `flashrom_i945_sst` for the SST chip, and `flashrom_i945_mx` for the
use `flashprog_i945_sst` for the SST chip, and `flashprog_i945_mx` for the
Macronix chip.
Now run flashrom from the Libreboot 20160907 utils archive (for SST):
Now run flashprog (for SST):
sudo ./flashrom_i945_sst -p internal -w coreboot.rom
sudo ./flashprog_i945_sst -p internal -w coreboot.rom
Or Macronix:
sudo ./flashrom_i945_mx -p internal -w coreboot.rom
sudo ./flashprog_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 flashrom. In fact, you should do so!
harmless to run both versions of flashprog. In fact, you should do so!
You'll see a lot of errors. This is normal. You should see something like:
@ -564,36 +589,28 @@ 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 flashrom (from Libreboot 20160907 utils) complains
about `/dev/mem` access, please
run `sudo ./bucts 0`. If flashrom is complaining about `/dev/mem`, it means
**WARNING: if flashprog complains about `/dev/mem` access, please
run `sudo ./bucts 0`. If flashprog 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 flashrom output as indicated above.**
you see the expected flashprog output as indicated above.**
If you *did* run flashrom and it failed to flash, but you set bucts to 1 and
If you *did* run flashprog 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 flashrom didn't do
coin-cell and try again from scratch. In this instance, if flashprog 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

7
site/docs/install/ivy_has_common.md
View File

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

7
site/docs/install/ivy_has_common.uk.md
View File

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

3
site/docs/install/spi.md
View File

@ -966,9 +966,6 @@ 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

3
site/docs/install/spi.zh-cn.md
View File

@ -643,9 +643,6 @@ 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。

3
site/docs/install/x230_external.md
View File

@ -3,9 +3,6 @@ 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.

46
site/docs/linux/grub_hardening.md
View File

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

5
site/docs/linux/index.md
View File

@ -46,11 +46,6 @@ 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.

456
site/docs/maintain/index.md
View File

@ -85,31 +85,6 @@ 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
=======================
XBMK\_THREADS
-------------
For example:
export XBMK_THREADS=2
This would build on two threads, when running lbmk. It defaults to 1.
Previous revisions of lbmk used `nproc` by default, but this was set to 1
instead, because nproc is not available on every operating system.
XBMK\_RELEASE
-------------
If set to `y`, it signals to `script/roms` that a release is being built,
and it will honour `release="n"` in target.cfg files. You could also set this
yourself, when doing regular builds, if you wanted to test how `./build roms`
behaves running it in release mode. Do this if you want to:
export XBMK_RELEASE=y
Projects/files downloaded/generated by lbmk
===========================================
@ -127,8 +102,8 @@ This directory is created when running any of the following commands, with the
right arguments:
./build roms ARGUMENTS_HERE
./build roms serprog stm32
./build roms serprog rp2040
./build serprog stm32
./build serprog rp2040
Simply speaking, `bin/` shall contain finished ROM images or firmware, that
can then be installed (flashed) to the target device.
@ -138,6 +113,12 @@ The files under `bin/` are provided in regular Libreboot releases.
**These** are the ROM images that you should flash. Do *not* flash the ROM
images contained under `elf/`!
cbutils/
---------------
The build system compiles `cbfstool` and `ifdtool`, from coreboot, and then
places the executables here for use on coreboot ROM images.
ec/
---------------
@ -167,14 +148,18 @@ lbmk in your own custom coreboot ROM (that you didn't build with lbmk).
This is only used by the build system, but these images are *not* provided in
releases (only the images under `bin/` are provided).
As of Libreboot 20240612, the `elf/` directory must be used by default for all
builds, in an effort to make exclusive use of *out-of-source builds*. As such,
the `cbutils` directory is no longer used.
mrc/
---------------
Intel System Agent downloaded at build time for HP EliteBook 820 G2.
Please also
visit: <https://doc.coreboot.org/northbridge/intel/haswell/mrc.bin.html> - the
handling of this, in Libreboot, is based largely on the information there.
This contains the Intel MRC firmware, auto-downloaded during build
by `script/vendor/download`.
In some cases, libre MRC firmware is also available, and provided
by Libreboot as an alternative choice.
pciroms/
---------------
@ -186,7 +171,7 @@ currently only initialises Intel GPUs natively, on Libreboot systems.
release/
---------------
The script at `build` create tarballs in here, which
The script at `script/update/release` create tarballs in here, which
constitute regular Libreboot releases. It is meticulously maintained, as per
current lbmk behaviour, and executed so as to provide Libreboot release
archives.
@ -196,26 +181,6 @@ containing non-redistributable vendor code are *scrubbed* such that these files
in regular releases, be [re-added manually](../install/ivy_has_common.md) by
the user.
You can create release archives by doing:
./update release
By default, this creates a release under `release/`, but you can change the
directory, for example:
./update release -d path
You can also specify that only a *source archive* be created, like so:
./update release -m src
Or with a custom directory:
./update release -d path -m src
The build system expects there to be a *git tag*, so make sure there is one.
This is used to create the version number for a given release.
src/
----
@ -288,6 +253,23 @@ GRUB image under `elf/grub/`.
NOTE: This is *only* provided for x86 machines, in Libreboot. For ARM, we ship
U-Boot instead.
src/me\_cleaner/
---------------
Please also visit: <https://github.com/corna/me_cleaner/>
This is used by Libreboot, to *neuter* Intel ME images. The intel ME images
are auto-downloaded from the vendor during each build process, cached on
disk and processed by `me_cleaner`. It removes almost all code from Intel ME,
leaving only the basic bringup code (analogous to running coreboot without a
payload). More information available at these pages:
* <https://github.com/corna/me_cleaner/>
* Libreboot [freedom status page](../../freedom-status.md)
The *vendor file* scripts are what handle this, specifically the download script
located at `script/vendor/download`.
src/memtest86plus/
---------------
@ -328,7 +310,7 @@ src/uefitool/
Please also visit: <https://github.com/LongSoft/UEFITool>
This is compiled, so as to provide `UEFIExtract`. Currently used by the
vendor download logic within `include/vendor.sh`, to download SCH5545 EC
vendor download script at `script/vendor/download`, to download SCH5545 EC
firmware (used for fan control on Dell Precision T1650).
src/pico-serprog
@ -392,6 +374,9 @@ desirable, `lbmk.git` provides a few utilities as part of itself, namely:
util/dell-flash-unlock/
---------------
**NOTE (15 October 2023): The util is now called `dell-flash-unlock`, but it
was previously called `e6400-flash-unlock`. Links have been updated.**
This program, written by Nicholas Chin, unlocks the boot flash on Dell Latitude
E6400; it permits internal flashing, from factory firmware to Libreboot, so that
the user need not disassemble and flash externally.
@ -476,25 +461,6 @@ config/
This directory contains configuration files, used by the Libreboot build
system. These next sections will cover specific configuration files.
config/PROJECT\*/nuke.list
--------------------------
The script `include/git.sh` handles deletion of certain files, for downloaded
projects, based on a `nuke.list` file that can (for single-tree projects) be
included at `config/PROJECT/nuke.list` or (multi-tree project)
at `config/PROJECT/TREE/nuke.list` (entries are relative links from the root
directory of the given source tree e.g. `src/coreboot/default/`).
So, if `src/coreboot/default/` contained foo/bar.txt, you could add to
the `nuke.list` file as follows:
```
foo/bar.txt
```
Ditto `src/flashprog/`, if you wanted to delete a file from in there, as one
other example. Deletions occur when the source tree is created.
config/vendor/
---------------
@ -523,7 +489,7 @@ When a given coreboot tree is compiled, for a given target, this file defines
which files to copy from the coreboot directory, which are then copied to
a location under `elf/coreboot`.
The presence of this file affects behaviour in `./update release` commands;
The presence of this file affects behaviour in `script/update/release`;
specifically, PROJECT is then downloaded to `src/PROJECT/PROJECT`, and files
under `config/PROJECT/TARGET/target.cfg` define which tree to use, which then
looks under `config/PROJECT/TREE/target.cfg` to get the git revision; then
@ -564,8 +530,9 @@ 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)
* `xarch="i386-elf"` (example entry)
* `arch="x86_64"` (example entry)
* `payload_grub="y"` (example entry)
* `payload_grub_withseabios="y"` (example entry)
* `payload_seabios="y"` (example entry)
@ -575,23 +542,26 @@ as:
* `payload_seabios_grubonly="y"` (example entry)
* `grub_scan_disk="ata"`
* `uboot_config=default` (specify which U-Boot tree to use)
* `release="n"` (example entry)
* `xtree="default"` (example entry)
* `tree_depend="default"` (example entry)
* `grubtree="nvme" (example entry)`
* `vendorfiles="n"`
* `microcode_required="y"`
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 `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 `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 `payload_grub` entry specifies whether or not GRUB is to be included in
ROM images.
@ -630,20 +600,12 @@ on a ThinkPad X60 with the optical drive may cause GRUB to hang, so on that
machine it is advisable to set this option to `ahci` (becuse the default HDD
slot is AHCI).
The `release` variable can be set to n, which makes the `./update release`
call skip that target, when creating release images. For example, a given
board may not be stable and you don't want images for it to be included in the
release.
The `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.
The `grubtree` option specifies which GRUB tree to use. If unset, it defers to
the `default` GRUB tree.
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).
### config/coreboot/BOARDNAME/config/
@ -751,18 +713,18 @@ of their own; for example, `config/grub/` exists.
Multiple files exist here, and they are *concatenated* in a temporary file by
lbmk, which is then scanned to find information about projects.
GRUB config
config/grub/
---------------
### config/data/grub/background
### config/grub/background
Splash screen images applied duing startup when using the GRUB payload.
### config/data/grub/background/background1024x768.png
### config/grub/background/background1024x768.png
Used on ThinkPad X60 and T60.
### config/data/grub/background/background1280x800.png
### config/grub/background/background1280x800.png
Used on all other machines, besides X60 and T60 thinkpads.
@ -772,11 +734,11 @@ example, `config/coreboot/x60/target.cfg` specifies this:
grub_background="background1024x768.png"
### config/data/grub/background/COPYING
### config/grub/background/COPYING
Licensing info for GRUB bootsplash images.
### config/grub/TREE/config/
### config/grub/config/
GRUB configuration files.
@ -788,7 +750,7 @@ Author info for GRUB configuration files.
Licensing info for GRUB configuration files.
### config/grub/TREE/config/grub.cfg
### config/grub/config/grub.cfg
This is a configuration file. It is used to program GRUB's shell.
@ -802,7 +764,7 @@ A `grubtest.cfg` can be inserted into CBFS, but it will not override the
default `grub.cfg` (either in CBFS or on memdisk); however, the one in memdisk
will provide a menuentry for switching to this, if available.
### config/data/grub/config/memdisk.cfg
### config/grub/config/grub\_memdisk.cfg
This GRUB configuration checks whether `grub.cfg` exists in CBFS and switches
to that first (not provided by default) or, if one is not available in CBFS,
@ -812,12 +774,12 @@ The GRUB memdisk is a file system within `grub.elf`, itself stored within the
coreboot file system named *CBFS*, which is part of the coreboot ROM image on
every coreboot target.
### config/data/grub/keymap/
### config/grub/keymap/
Keymap files used by GRUB. They can alter the character set corresponding to
inputted scancodes.
### config/data/grub/keymap/\*.gkb
### config/grub/keymap/\*.gkb
The keymap files themselves. These are inserted into the GRUB memdisk, and
the `grub.cfg` file can specify which one is to be used.
@ -826,7 +788,7 @@ These files are binary-encoded, defining which characters correspond to which
scancodes. It is handled by `grub-core/commands/keylayouts.c` in the GRUB source
code.
### config/grub/TREE/modules.list
### config/grub/modules.list
This defines which modules are inserted into `grub.elf`. These modules can be
anything from file systems, small applications/utilities, launchers (e.g.
@ -992,56 +954,6 @@ Another interesting config option is `CONFIG_POSITION_INDEPENDENT` for ARM
boards, which has been so far enabled in the ones `lbmk` supports, just to be
safe.
config/submodule
----------------
In here you can find submodule configurations for projects. It works for both
single- and multi-tree projects. Use the existing examples as reference.
Files, in each directory:
* `module.list` lists paths (files and directories) for given modules, which
can be files(via URL) or Git repositories, or both.
* NAME/module.cfg
NAME is the file/directory name for the module, with everything up to the
final forward slash removed. E.g. foo/bar/thing.zip would be thing.zip as
NAME.
In `module.cfg` there can be either, file:
```
subfile="url"
subfile_bkup="url"
subhash="sha512sum for file"
```
or, git repository:
```
subrepo="url"
subrepo_bkup="url"
subhash="sha1 git commit id"
```
You must only use `subfile` or `subrepo`, not both, and there must be a backup
URL. The build system intentionally *avoids* using Git's actual submodules
feature, instead opting to download such repositories manually, because the
official submodules feature doesn't have very good redundancy.
Additionally, a `patches` directory can be included alongside `module.cfg`,
which can be used to patch the submodule (only supported for Git repositories
because files are not extracted, only placed at their configured destination).
The destination path in `module.list` is relative to the location of the main
Git repository under which it is placed.
config/data/PROJECT
-------------------
Random configuration data provided on a per-project basis. Complements
the `config/PROJECT` directory.
U-Boot build system
-------------------
@ -1106,37 +1018,44 @@ Scripts in root directory of lbmk
build
---------------
This is the main script. Symlinks `vendor` and `update` also point to it.
This is the main script in lbmk, Libreboot's build system. It is what executes
all other parts of the Libreboot build system. The rules are as follows:
Take any given file under `script/` and you can do:
* Argument zero, representing the name of the symlink, will be used to
execute `script/LINKNAME/COMMAND` - for example: `./build roms all`
would execute `script/build/roms all` in `sh`.
* In the above example, `LINKNAME` could also be `vendor`. In examples below,
symlinks are described pointing to `build` (the actual script). The script
works by checking argument zero, so it would look in a different directory
under `script/` matching `LINKNAME` - in this case, `script/vendor/`
* `TMPDIR` is exclicitly set, providing a constant location where temporary
files and directories can be made. `TMPDIR` is exported by the parent to
all children; for example, `./build roms all` would export it
to `script/build/roms`, and then anything called by *that* will also
inherit it - the main parent process running `lbmk` will then clean up this
`TMPDIR` directory upon any exit.
* All exits from lbmk are handled by this script. *All* exits, zero or non-zero,
are engineered such that *this* script, in the parent process (the very first
instance) is what ultimately exits back to the user's shell prompt.
* This script is programmed to *exit* with non-zero status, when run as root,
unless the `./build dependencies *` commands are used,
referencing files under `config/dependencies/`
* Under fault conditions, each child process shall output to stderr, and the
main parent process running `lbmk` will output the final error message.
./build file # (THIS IS NOT A VALID COMMAND)
tl;dr break this script and you *break Libreboot*.
For example:
update
---------------
./build roms
./update trees
Symbolic link, pointing to the `build` script. This is executed by the user, or
by lbmk, referencing scripts under `script/update/`.
Special commands available (not provided by files under `script/`):
vendor
---------------
./update release
./vendor download
./vendor inject
The `vendor` commands are handled by the `build` script, calling functions
inside `include/vendor.sh`, and the `./update release` logic is handled
directly by the `build` script.
More information about `./vendor` commands can be found
here: [inserting vendor files](../install/ivy_has_internal.md)
Information about `./update release` is written elsewhere on this page.
You can also know what build system revision you have by running:
./build version
This script is the beating heart of Libreboot. Break it and you break Libreboot.
Symbolic link, pointing to the `build` script. This is executed by the user, or
by lbmk, referincing scripts under `script/vendor/`
include/
===============
@ -1145,6 +1064,27 @@ 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
--------------
@ -1171,31 +1111,37 @@ it is provided as an include to bypass license incompatibility. It has been
heavily modified to use the same style of logic and general control flow used
in the script at `script/vendor/download`, and it is used from there.
include/lib.sh
include/option.sh
---------------
Functions used by scripts under `script/vendor/`, for checking defconfig
files. These files are checked because the scripts need to know whether a given
file is used; if it is, a path is then specified in defconfig, telling the vendor
script either where it is, or where it should be downloaded to.
Several other parts of lbmk also use this file. It is added to as little as
possible, and contains miscallaneous functions that don't belong anywhere else.
The functions here are mostly those that deal with configuration files; scanning
them to set variables and so on.
This file also contains generic error handling, used by all lbmk scripts.
This also contains functions to verify the current libreboot version, and check
whether Git is properly initialised on the host system. It also contains
the `setvars` function, which provides a shorthand way of initialising many
variables (combined with use of `eval`), which lbmk uses heavily.
This function also contains `x_()` which lbmk uses to execute commands
and ensure that they cause an exit (with non-zero status) from lbmk, if they
return an error state.
script/
=======
script/roms
-----------
*All* scripts under `script/` are executed only by the main `lbmk` script,
conforming to the standard `buildpath/option` e.g. `build/roms` - so,
running `./build roms` would run `script/build/roms`.
script/build/
---------------
These are highly specialised build scripts, written for specific tasks, almost
entirely in the context of building firmware images themselves, but some utils
are also handled.
The scripts that create release archives are also located under this directory.
### script/build/roms
This builds coreboot ROM images.
@ -1237,6 +1183,28 @@ It creates ROM images with GRUB, SeaBIOS, U-Boot, optionally with Memtest86+
also included, in various separate configurations in many different ROM images
for user installation.
The `romtype` entry in `target.cfg` tells this script what to do with the ROM,
after it has been built. Currently, it operates based on these possible values
for `romtype`:
* `d8d16sas` will cause *fake* (empty) files named `pci1000,0072.rom`
and `pci1000,3050.rom` to be inserted in CBFS. This prevents SeaBIOS from
loading or executing the option ROM stored on PIKE2008 modules, present on
certain configurations with the ASUS KCMA-D8 or KGPE-D16 mainboards. Those
option ROMs cause the system to hang, so they should never be executed (this
means however that booting Linux kernels from SAS devices is impossible on
those boards, unless a Linux payload is used; Linux can use those SAS drives,
without relying on the PIKE2008 option ROMs). When SeaBIOS runs, it will
default to loading the corresponding option ROM from CBFS, if it exists, for
a given PCI device, overriding whatever option ROM is present on the device
itself, but if the option ROM is invalid/empty, SeaBIOS will not attempt to
load another one, until the empty/invalid one (in CBFS) is deleted.
* `i945 laptop`: in this configuration, the upper 64KB section of the ROM is
copied into the 64KB section below that. This results in there being two
bootblocks in the ROM, and you can decide which one is used by setting `bucts`
* If no declaration is made, or a declaration is made contrary to the above,
no special modifications will be made.
If no payload is defined in `target.cfg`, the `build/roms` script will exit
with error status.
@ -1265,25 +1233,71 @@ 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!
Serprog images:
### 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
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 roms serprog stm32`
Example command: `./build serprog stm32`
Example command: `./build roms serprog rp2040`
Example command: `./build serprog rp2040`
The `list` argument is available:
./build roms serprog stm32 list
./build roms serprog rp2040 list
./build serprog stm32 list
Without arguments, all targets would be compiled, but you can specify a short
list of targets instead, based on the output of `list`.
script/trees
------------
script/update/
--------------
This handles most actual building of source trees, called into by scripts
under `script/build/fw` - it also contains logic for downloading source trees
or vendor files.
### script/update/release
This script builds the release archives, which are then provided in a new
Libreboot release. Most users do not need to look at this file at all, but it
is provided under free license for curious souls.
Command: `./update release`
NOTE: if the `-d` option is used, you can specify a directory other
than `release`. For example:
./update release -d /media/stuff/libreboot_release_test
If `-d` is not passed, they will go under `release/` in your lbmk repository.
The script is engineered to re-initialise git if ran from a release archive.
Libreboot releases after 20230625 include `.gitignore` in the src archive.
This builds release archives, containing ROM images for coreboot and/or serprog
programmers. It works simply: lbmk clones *itself*, and builds itself in its
clone, then cleans itself up and creates tarballs. If you run this script, you
should expect it to take at least 4 hours; slower on really old systems. On
really fast systems, it might take 2-3 hours.
NOTE: This script *scrubs* certain vendor firmware from release ROMs, such as
Intel ME or MRC firmware. The release ROMs shall then exclude these files
within them, requiring manual insertion by the user post-release. See:
[Insert vendor files
on Sandybridge/Ivybridge/Haswell](../install/ivy_has_common.md)
### script/update/trees
*This* is the other beating heart of Libreboot. Used heavily by Libreboot, this
script is what handles defconfig files for SeaBIOS, U-Boot *and* coreboot; it
@ -1403,3 +1417,37 @@ All of this used to about 20 different scripts, all with much-duplicated logic.
Now it is unified, efficiently, under a single script.
Remember: code equals bugs, so less code equals fewer bugs.
script/vendor/
--------------
### script/vendor/download
This downloads vendor code when needed, on a given coreboot target. It does
this by scanning the defconfig files of that board, to know where the files
are (or where they should be) within lbmk. Based on this, it then knows which
files to download.
These files are then inserted at build time by the coreboot build system (as
defined by defconfigs), or post-release by running the `inject` script.
It looks inside `config/vendor/` at the files in there, concatenating them and
then scanning that to find info about the given board; for example, info like
where to download a Lenovo BIOS updater to extract `me.bin` from, to run through
the `me_cleaner` program.
More information is available [here](../install/ivy_has_common.md).
This script is executed automatically, when you compile ROM images, if the given
mainboard requires vendor code to be inserted. In this way, you do not need to
manually extract such files from your original vendor image.
### script/vendor/inject
This is not used during the build process, but it can be run by the user on
release ROMs (which do not contain non-redistributable code handled by these
vendor scripts, even if they are required). This script inserts those files
into the coreboot ROM image; if you're building from source, using lbmk, you
do not need to run the inject script at all.
More information is available [here](../install/ivy_has_common.md).

6
site/docs/misc/emulation.md
View File

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

20
site/download.md
View File

@ -31,13 +31,13 @@ LIBREBOOT](news/safety.md).**
GPG signing key
---------------
**The latest release is Libreboot 20240612, under the `stable` directory.**
**The latest release is Libreboot 20240225, under the `testing` directory.**
### NEW KEY
Full key fingerprint: `8BB1 F7D2 8CF7 696D BF4F 7192 5C65 4067 D383 B1FF`
This key is for Libreboot releases *after* the 20240126 release. It applies to
This key is for Libreboot releases *after* the 20240225 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 20240126 release. This key *expired* during December 2023,
to the Libreboot 20240225 release. This key *expired* during December 2023,
so you should use the *newer* key (see above) for the releases after
Libreboot 20240126.
Libreboot 20240225.
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 20240612, under the `stable` directory.**
**The latest release is Libreboot 20240225, under the `testing` directory.**
These mirrors are recommended, since they use TLS (https://) encryption.
You can download Libreboot from these mirrors:
* <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.math.princeton.edu/pub/libreboot/> (Princeton
university, USA)
* <https://mirror.shapovalov.website/libreboot/> (shapovalov.website, Ukraine)
* <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 20240612, under the `stable` directory.**
**The latest release is Libreboot 20240225, under the `testing` 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 20240612, under the `stable` directory.**
**The latest release is Libreboot 20240225, under the `testing` directory.**
WARNING: FTP is also unencrypted, like HTTP. The same risks are present.

20
site/download.uk.md
View File

@ -31,13 +31,13 @@ LIBREBOOT](news/safety.md).**
Код підпису GPG
---------------
**Останнім випуском є Libreboot 20240612, в директорії `stable`.**
**Останнім випуском є Libreboot 20240225, в директорії `testing`.**
### НОВИЙ КЛЮЧ
Повний відбиток ключа: `8BB1 F7D2 8CF7 696D BF4F 7192 5C65 4067 D383 B1FF`
Вищезазначений ключ для Libreboot 20240126, та наступних випусків. This key
Вищезазначений ключ для Libreboot 20240225, та наступних випусків. 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 20240612 release. This key *expired* during December 2023,
to the Libreboot 20240225 release. This key *expired* during December 2023,
so you should use the *newer* key (see above) for the releases after
Libreboot 20240126.
Libreboot 20240225.
Завантажте ключ тут: [lbkey.asc](lbkeyold.asc)
@ -83,18 +83,18 @@ Libreboot 20240126.
Дзеркала HTTPS {#https}
-------------
**Останнім випуском є Libreboot 20240612, в директорії `stable`.**
**Останнім випуском є Libreboot 20240225, в директорії `testing`.**
Дані дзеркала є рекомендованими, оскільки використовують TLS (https://) шифрування.
Ви можете завантажити 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.math.princeton.edu/pub/libreboot/> (Прінстонський
університет, США)
* <https://mirror.shapovalov.website/libreboot/> (shapovalov.website, Україна)
* <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 20240612, під директорією `stable`.**
**Останнім випуском є Libreboot 20240225, під директорією `testing`.**
УВАГА: ці дзеркала є не-HTTPS, що означає, що вони
незашифровані. Ваш трафік може бути об'єктом втручання
@ -188,7 +188,7 @@ crontab. Ця сторінка розповідає вам, як викорис
Дзеркала FTP {#ftp}
-----------
**Останнім випуском є Libreboot 20240612, під директорією `stable`.**
**Останнім випуском є Libreboot 20240225, під директорією `testing`.**
УВАГА: FTP є також незашифрованим, подібно HTTP. Ті ж самі ризики присутні.

2
site/footer.de.include
View File

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

2
site/footer.include
View File

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

2
site/footer.it.include
View File

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

4
site/footer.uk.include
View File

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

2
site/footer.zh-cn.include
View File

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

5
site/freedom-status.md
View File

@ -214,7 +214,7 @@ Mostly free software, except for the requirement on `daisy` and `peach` mainboar
to include BL1 bootloader files from the vendor. These are:
* HP Chromebook 11 G1 (daisy-spring) **(board removed from Libreboot, due to
issues (will be re-added at a later date))**
issues (will be re-added at a later date)**
* Samsung Chromebook XE303 (daisy-snow) **(ditto)**
* Samsung Chromebook 2 13” (peach-pi) **(ditto)**
* Samsung Chromebook 2 11” (peach-pit) **(ditto)**
@ -243,8 +243,7 @@ Neutered ME required on these targets: `t420_8mb`, `t420s_8mb`, `t430_12mb`,
`w541_12mb`, `w541mrc_12mb`, `x220_8mb`, `x230_12mb`, `x230_16mb`,
`x230edp_12mb`, `x230t_12mb`, `x230t_16mb`, `hp8200sff`, `hp2560p_8mb`,
`hp2570p_16mb`, `hp8300usdt_16mb`, `hp2170p_16mb`, `hp9470m_16mb`,
`hp820g2_12mb`, `t1650_12mb` and the OptiPlex 9020 ports, also
Sandybridge/Ivybridge/Haswell Dell Latitude.
`hp820g2_12mb` and `t1650_12mb`.
As stated, Libreboot provides this in a state where the ME is no longer a
threat to security. It initialises itself, but then does nothing, so it's

3
site/freedom-status.uk.md
View File

@ -333,8 +333,7 @@ Intel/x86
`t440p_12mb`, `t440pmrc_12mb`, `t520_8mb`, `t530_12mb`, `w530_12mb`,
`w541_12mb`, `w541mrc_12mb`, `x220_8mb`, `x230_12mb`, `x230_16mb`,
`x230edp_12mb`, `x230t_12mb`, `x230t_16mb`, `hp8200sff_8mb`, `hp2560p_8mb`,
`hp2570p_16mb`, `hp2170p_16mb`, `hp9470m_16mb`, `hp820g2_12mb`, `t1650_12mb` та
Dell OptiPlex 9020, Sandybridge/Ivybridge/Haswell Dell Latitude.
`hp2570p_16mb`, `hp2170p_16mb`, `hp9470m_16mb`, `hp820g2_12mb` та `t1650_12mb`.
Як заявлено, Libreboot надає це в стані, де ME більше не є
загрозою для безпеки. Він ініціалізує себе, але потім нічого не робить, тому його

6
site/index.de.md
View File

@ -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 20240612, veröffentlicht
am 12. June 2024.
Siehe auch: [Libreboot 20240612 release announcement](news/libreboot20240612.md).**
**NEUESTE VERSION: Die neueste Version von Libreboot ist 20240225, veröffentlicht
am 25. February 2024.
Siehe auch: [Libreboot 20240225 release announcement](news/libreboot20240225.md).**
Warum solltest Du *Libreboot* verwenden?
----------------------------

4
site/index.fr.md
View File

@ -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 20240612](news/libreboot20240612.md), sortie
le 12 June 2024.**
**NOUVELLE VERSION: La dernière version est [Libreboot 20240225](news/libreboot20240225.md), sortie
le 25 February 2024.**
Pourquoi devriez-vous utiliser *Libreboot*?
-----------------------------------

4
site/index.it.md
View File

@ -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 20240612, rilasciato il 12 June 2024.
Vedi: [Libreboot 20240612 annuncio di rilascio](news/libreboot20240612.md).**
**ULTIMO RILASCIO: L'ultimo rilascio e' Libreboot 20240225, rilasciato il 25 February 2024.
Vedi: [Libreboot 20240225 annuncio di rilascio](news/libreboot20240225.md).**
Per quale ragione utilizzare *Libreboot*?
-----------------------------------------

6
site/index.md
View File

@ -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 20240612, released on
12 June 2024.
See: [Libreboot 20240612 release announcement](news/libreboot20240612.md).**
**NEW RELEASE: The latest release is Libreboot 20240225, released on
25 February 2024.
See: [Libreboot 20240225 release announcement](news/libreboot20240225.md).**
*We* believe the freedom to [study, share, modify and use
software](https://writefreesoftware.org/), without any

4
site/index.uk.md
View File

@ -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 20240612, випущено 12 червень 2024.
Дивіться: [Оголошення про випуск Libreboot 20240612](news/libreboot20240612.md).**
**НОВИЙ ВИПУСК: Останній випуск Libreboot 20240225, випущено 25 лютий 2024.
Дивіться: [Оголошення про випуск Libreboot 20240225](news/libreboot20240225.md).**
Чому вам варто використовувати *Libreboot*?
----------------------------

41
site/index.zh-cn.md
View File

@ -3,45 +3,46 @@ 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>
你也可以从 Minifree Ltd [购买特定硬件的 Libreboot 电脑](https://minifree.org/)，
或者将兼容硬件寄来预装 Libreboot。
Libreboot 的创始人和主要开发者，Leah Rowe，也是 Minifree 的所有者和经营者；
销售电脑为 Libreboot 提供资金。
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.
**新版发布: 最新版本 Libreboot 20240612 已在 2024 年 06 月 12 日发布。详见: [Libreboot 20240612 发布公告](news/libreboot20240612.md).**
**新版发布: 最新版本 Libreboot 20240225 已在 2024 年 02 月 25 日发布。详见: [Libreboot 20240225 发布公告](news/libreboot20240225.md).**
为什么要使用 *Libreboot*?
----------------------------
Libreboot 赋予了你从其他大多数引导固件得不到的[自由](https://writefreesoftware.org/)。同时，它启动速度更快，[安全性也更好](docs/linux/grub_hardening.md)。它功能强大，可针对多种使用情况进行配置。
Libreboot 赋予了你[自由](https://writefreesoftware.org/)，而这等自由，是你用其他引导固件得不到的。同时，它的启动速度更加快，[安全性也更加高](docs/linux/grub_hardening.md)。在各种情况下使用，它都十分强大，具有高度[可配置性](docs/maintain/)。
*我们*相信，不受限制地[研究、分享、修改及使用软件](https://writefreesoftware.org/)的自由，是每个人都必须享有的基本人权的一部分。这时，*软件自由*至关重要。你的自由至关重要。教育至关重要。[修理权](https://yewtu.be/watch?v=Npd_xDuNi9k)至关重要。尽管许多人在用[自由的操作系统](https://www.openbsd.org/)，但他们用的引导固件却是专有（非自由）的。专有固件常常[包含](faq.html#intel)了[后门](faq.html#amd)，而且可能有很多缺陷。为了让不懂技术的用户也能使用 coreboot 固件，我们于 2013 年 12 月成立了 Libreboot 项目，
*我们*相信，不受限制地[研究、分享、修改及使用软件](https://writefreesoftware.org/)的自由，是每个人都必须享有的基本人权的一部分。这时，*软件自由*至关重要。你的自由至关重要。教育至关重要。[修理权](https://yewtu.be/watch?v=Npd_xDuNi9k)至关重要。尽管许多人在用[自由的操作系统](https://www.openbsd.org/)，但他们用的引导固件却是专有（非自由）的。专有固件常常[包含](faq.html#intel)了[后门](faq.html#amd)，并且也可能出问题。2013 年 12 月，我们建立了 Libreboot 项目，目的是让不懂技术的用户能使用 coreboot 固件。
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 仓库或者源代码归档，然后运行 `make`，接着就能构建整个 ROM 映像。名为 `lbmk` (Libreboot Make) 的自动构建系统会自动构建这些 ROM 映像，无需任何用户输入或干预。已经提前进行了配置。
Libreboot 是一个 *coreboot 发行版*，就好比 *Alpine Linux* 是一个 *Linux 发行版*。如果你想要从零开始构建 ROM 镜像，那你需要对 coreboot、GRUB 以及其他所需软件进行专业级别的配置，才能准备好 ROM 镜像。有了 *Libreboot*，你只需要下载 Git 仓库或者源代码归档，然后运行 a script，接着就能构建整个 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)
@ -51,19 +52,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)
即使已经有人在进行某种语言的翻译了，我们也总是欢迎更多人。多多益善！
即使已经有人在进行某个语言的翻译了，我们也总是欢迎更多人。多多益善！

1536
site/news/10.md Normal file
View File

File diff suppressed because it is too large Load Diff

4
site/news/MANIFEST
View File

@ -1,6 +1,3 @@
libreboot20240612.md
audit5.md
libreboot20240504.md
libreboot20240225.md
ports202402.md
sourcehut.md
@ -8,6 +5,7 @@ libreboot20240126.md
x201.md
hp820g2.md
audit4.md
10.md
libreboot20231106.md
libreboot20231101.md
libreboot20231021.md

6
site/news/audit3.md
View File

@ -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 blob-free but (in Libreboot)
Dell Latitude E6400, which is otherwise FSDG-compatible 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 that
can run without blobs, in other words.
platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything FSDG
compatible, 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

10
site/news/audit4.md
View File

@ -123,6 +123,16 @@ 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

897
site/news/audit5.md
View File

@ -1,897 +0,0 @@
% Libreboot Build System Audit 5
% Leah Rowe
% 9 June 2024
**A new release is now available, with these changes. Learn more by reading
about the [Libreboot 20240612 release](libreboot20240612.md).**
Introduction
============
Libreboot is a free/opensource boot firmware project. It replaces your
proprietary BIOS/UEFI firmware, on supported x86 and ARM computers. It does
this by providing an automated build system to download, patch and compile
the various upstream sources (e.g. coreboot, GRUB, SeaBIOS). Coreboot is used
for hardware initialisation, configuring everything from your CPU, memory
controller all way to peripherals, readying the hardware so that it can run
software, e.g. Linux/BSD operating systems. You can essentially think of *lbmk*,
which is Libreboot's build system, as a *source-based package manager*. It is
what the Libreboot releases are built with. The *lbmk* build system essentially
implements a *coreboot distro*, the same way you might think of a Linux
distribution.
Extensive auditing has been performed on lbmk, since the Libreboot 20240504
release. These audits fix bugs, reduce code bloat and generally improve the
efficiency of lbmk, adding and removing features in a careful, conservative
way, with a focus on *clean code*. Remember the magic words: code equals bugs.
This article covers changes from Libreboot 20240504, up to
revision `2ee186aee3aa3ab9619ed9549bd3b82909dcfbd0` from 9 June 2024.
You can read about the *previous* audit in the article
for [Libreboot Build System Audit 4](audit4.md).
Modest code size reduction
--------------------------
There are 1482 lines of shell script in the build system, versus 1680 in the
Libreboot 20240504 release. Libreboot's build system is written purely in
POSIX sh; not BASH, not KSH, not ZSH, jush sh!
This is a difference of 198 lines, or a 12% reduction. Despite the reduction,
numerous features have been added and a large number of bugs were fixed.
Summarised list of changes
==========================
Changes are in order per category, from newest to oldest:
Feature changes
---------------
* **Download crossgcc tarballs as dependencies, when cloning coreboot.** We
previously relied on the coreboot build system, which automatically fetches
these when running `make crossgcc`, which we run automatically. However,
the coreboot logic has to be patched for reliability because the GNU HTTP 302
redirect often fails so we use a static mirror, and the logic has no
redundancy. With this new change, we use the same tarballs but we specify
two URLs, a main and a backup. This also means that the tarballs will once
again be included in Libreboot release archives, enabling offline builds.
* **Support downloading files as submodules, in Git repositories.** This
complements the pre-existing feature where sub-repositories (Git) can be
cloned into a subdirectory of a given main repo. We use this for crossgcc,
as referenced above.
* New files under `config/dependencies/` for Fedora 40 and Ubuntu 24.04. Now
you can run `./build dependencies fedora40`
and `./build dependencies ubuntu2404` on each respective distro, to get
the right build dependencies for building Libreboot from lbmk.
* **NEVER** run `git submodule update`, *ever*. Instead, rely *solely* on
config/submodule/ to define which dependencies should be downloaded, to each
given subdirectory within a main project. This is using a feature described
later on (in this audit report), whereby projects can have redundant
submodule repositories defined; initially, this feature was an *override*
where otherwise the submodule update command would be executed if
the `.gitmodules` file existed for a given project; this override is now
the *only* way to do it, and is thus the default behaviour. This may be
considered a preventative bug fix, in case certain projects auto-download
submodules that might cause us trouble in the future. It's better that we
maintain tight control of submodules.
* **Summarising the next few changes mentioned below: out-of-source builds
are now fully supported, for both single- and multi-tree projects.** (it was
previously only supported on multi-tree projects)
* Moved builds of coreboot utilities (e.g. cbfstool) to `elf/utilname`,
e.g. `elf/cbfstool/default/cbfstool` would be the new cbfstool binary location
for the one build from coreboot in the `default` tree.
* script/trees: Now single-tree builds are skipped if a build exists
under `elf/projectname/`, based on the presence of a `build.list` file; this
is consistent with the same behaviour pre-existing for multi-tree projects.
* When building memtest86plus, the binary is now placed out-of-source,
into `elf/memtest86plus`.
* When building flashprog, the binary is now placed out-of-source,
into `elf/flashprog/`.
* Use new function `singletree` to decide whether to use submodules, rather
than hardcoding a check for *coreboot* - NOTE: use of submodules was later
disabled during this audit, replaced with custom handling in lbmk.
* For error exits caused by *improper commands* (as opposed to fault conditions
while processing valid commands), don't directly call `err`; instead, call a
newly written function `badcmd` which says that much, and links to the
website (if `docs/` is present as in releases, it also points there).
* Added a `projectsite` file pointing to libreboot.org, complementing the
existing `projectname` file which contains the word `libreboot`. This is
used in the `version` command.
* **GRUB is now a multi-tree project.** Each given coreboot target can
specify which GRUB tree it wants to use, each containing its own revision
and patches, with its own GRUB configuration file. This can be used later on
to provide specific optimisations on each given mainboard, but it is used
at present to exclude xHCI patches on boards that don't need it; please also
read the bugfix section (of this audit report) pertaining to this same topic,
for more context. Before this change was implemented, all mainboards used
the exact same GRUB revision, with the same patches and the same config.
* grub.cfg: scan `grub2/` last, on each given device/partition; this speeds
up the boot time in most tests, because most setups use `grub/`,
but `grub2/` is still used on legacy setups so we have to support it and, for
reasons mentioned in the bullet point below, GRUB is very inefficient at
generating the list of devices/partitions when using the `*` wildcard, so
we can't scan `grub*/`.
* grub.cfg: it now scans a reduced set of devices/partitions by default, while
still ensuring (in practise, on real systems) that all such devices and
partitions will be scanned. We hardcode this, because the `*` wildcard in
GRUB is *very slow* on some machines, due to the way the GRUB kernel
constantly re-initialises the list of devices and partitions during operation.
Scanning an *excessive* number of hardcoded device/partition numbers slows
down the boot too, so this has been optimised. It has been tested and it
shouldn't cause any issues on machines/setups that people actually use.
* **grub.cfg: scan distro-provided grub.cfg from ESP;** we previously only
scanned the ESP for isolinux/syslinux configurations (which GRUB can parse).
* grub.cfg: Don't search for `*_grub.cfg` as this slows down the bootup
sequence, and nobody really uses this anymore; Libreboot's GRUB is much more
robust these days, pretty much booting anything automatically, but you used
to have to (regularly) use a `libreboot_grub.cfg` file to override the default
one provided by your distro. This legacy cruft has been removed, entirely!
* Added the `nuke()` function to delete files systematically, based on the
presence of a `nuke.list` file which contains files/directory paths relative
to the root directory of a given Git repository. This is used to delete a
poorly licensed source file in U-Boot (strlcat.c).
* **T440p/W541 laptops: Enable NVMe SSDs in `grub_scan_disk`**; an e-key adapter
can be used in the WLAN slot, to add an NVMe SSD. Even though throughput
is limited by the x1 PCI-E width, it's still a viable upgrade as it offers
slightly improved read/write performance compared to any SATA SSD.
* script/roms: Allow to override `grub_scan_disk` via `-s`, for
example: `./build roms -s nvme t1650_12mb`
* **grub.cfg: Use `grub_scan_disk` to set boot order (rather, boot order by
device type).** It is possible now to configure each mainboard with this
variable, so that certain types of devices are scanned in a precise order;
for example, scan NVMe SSDs first.
* **include/git.sh: Allow manual override of `git submodule` handling**, instead
directly downloading Git repositories using `git clone`, into the subdirectory
of a given main Git repository (as per `src/projectname` scheme). With this
feature, it is possible now to specify a *backup* submodule repository, for
redundancy, all while still allowing to reset the revision (and *patch* the
given submodule). This has been used to provide greater redundancy when
downloading coreboot submodules. It also allows to *limit* the number of
submodules, so now we only download the ones we need, thus saving bandwidth
especially during very large and long build sessions. - *NOTE: this was
later changed so as to be the ONLY method for downloading submodules, skipping
the actual git-submodule-update command entirely, on all projects.*
* **Native NVMe driver added to the GRUB payload**, allowing users to boot from
NVMe SSDs where present on a given mainboard. The patch is courtesy of
Mate Kukri, who ported SeaBIOS's own NVMe driver, converting all of the
code to run properly within GRUB's own kernel. NVMe SSDs are now fully
bootable on all machines that can have them, offering vastly superior
read and write performance when compared to SATA SSDs.
* include/git.sh: Allow patching git submodules (NOTE: support for submodules
was removed entirely, later in the audit, in favour of custom logic in lbmk
for the downloading of such dependencies).
* Added Portuguese keyboard support in the GRUB payload (patch courtesy of
the contributor by alias `samuraikid`).
* Removed all help commands, because it's just a duplication of documentation
that is already included in releases anyway, and people using the Git
repository require internet access anyway, so they can just use the website.
* Main build script: removed the functionality for generating source tarballs
where the only source code included is U-Boot; we do not need this, because
the larger source tarball containing all of Libreboot also contains U-Boot.
* include/option.sh: Don't bother checking for GNU Tar, because we were only
using it for reproducible tarball generation which didn't work yet anyway;
there are still ways of doing it with BSD tar and so on.
* Print a two-line break before confirming the location of the generated
release archive, when running release builds. This makes it more obvious
to the operator.
* **Removed the MRC (raminit blob) on Intel Haswell** (4th generation)
hardware, namely the ThinkPad T440p, W541, Dell OptiPlex 9020 MT
and Dell OptiPlex 9020 SFF; the libre raminit now works well, and S3 works.
* Removed all status checks from script/roms (formerly script/build/roms),
because it's better to document this instead, and rely on testing regardless.
Bug fixes
---------
Some of these changes fix actual issues that were found in testing, while
others were fixed *before* being triggered/reported and are thus *preventative
bug fixes*. The logic in lbmk has been very intensively audited as is customary!
The changes are, from newest to earliest:
* script/trees: Exit with error status if a given project is not defined. It
was previously decided that this script could be used to directly run Makefiles
from any given directory, but this is no longer done as it was error-prone;
this change prevents such usage, thereby preventing unstable conditions within
the build system.
* **Create a lock file when running lbmk.** Only do it from the main parent
instance, but not child instances of it; delete it at the end, after exiting
from the parent process. If starting a separate parent process, that one
will now immediately exit (with error status) if the lock file exists. This
prevents the fault condition where the user accidentally runs the same lbmk
instance twice, from the same work directory; it is only designed to be
executed once, per work directory. This is similar to the locking feature
you find in package managers such as apt-get. Also do this in release/
directories, while building (but don't include a lock file inside the tarball).
* include/git.sh: When doing a global check for files in every project all at
once, as defined by each respective (if existent) `nuke.list` file, hide
the output. Only show the output when running it on a specific project, not
the one in the for loop. This prevents user confusion / false bug reports.
* include/git.sh: Download coreboot as defined by `xtree` *before* downloading
the main project that defined it, to prevent a situation where the main project
is downloaded successfully but not the dependency (defined by `xtree`); this
is to maintain the integrity of the build system under fault conditions.
* include/lib.sh: When a download fails (running the `download` function),
don't then say that the file is "missing". Instead, actually say that the
download failed, so that the operator has a better understanding.
* include/lib.sh: Hide stderr on the `download` function, for the initial
check when verifying an existing file; although no problem existed on
technical terms, the output was confusing because it made the user think
there was a problem. The logic then downloads and re-verifies, and the
output indicating *that* verification has not been hidden; if the file
already exists, this is simply indicated by `e()`. This is considered a bug
fix, because it fixes the bug where users made erroneous bug reports, by
re-engineering the situation so that they do not make such erroneous reports.
TL;DR hide a totally benign (non-)error message.
* include/git.sh: Provide better user feedback about what is being downloaded
and where - although nothing was broken before, this lack of feedback was a
bug because it made debugging harder. Provide more clarity for the user.
* include/git.sh: Download dependencies *before*, not *after*, downloading the
project sources that depend on it. For example, pico-serprog depends on
pico-sdk. If you were to download pico-sdk *after* pico-serprog, the latter
may be downloaded and placed in src/, but then the former (sdk) could fail
due to bad internet, and now the overall downloaded code is corrupt, and there
was nothing checking for this after the fact; checking for it would be bloat.
By downloading the dependency *before*, then if *that* download fails, so
does the main one, and integrity is maintained within the build system.
* Preventative bugfix: don't check empty paths in `copy_elf` (of script/trees),
even though this potential bug was not yet triggered. Play it safe.
* script/trees: Don't check pre-existing builds in elf/ if `build.list` is
missing, otherwise it's too soon and builds are prevented in the first place;
this was caused initially when supporting out-of-source builds for single-tree
projects, as was already done on multi-tree. Now this is fixed.
* Documentation: only define the Untitled Static Site Generator
in `config/git` - the dependencies (markdown files and images) are now
defined in config/submodules/ instead. This prevents the bug where you could
download one of the dependencies first which would make the main project,
Untitled, un-downloadable, since the dependency projects go in subdirectories
of the main project that depends on them.
* Handle serprog dependencies in config/submodule instead of relying on
the git submodule update command, and only provide necessary modules. This
prevents the bug where downloading a dependency first later prevented the
main project from being downloaded, if the dependency was in a subdirectory
of what depends on it.
* Build coreboot utilities on a number of threads as defined by `XBMK_THREADS`;
although they already compiled, they would always do so on a single thread,
which is considered a bug. Now they can be compiled on multiple threads.
* include/lib.sh: Don't use `./update trees -f` to build coreboot *utilities*,
because it's quite error prone and not what that script is designed to do;
it is only designed to operate based on strictly defined single- and
multi-tree projects. Instead, call `make` directly.
* Don't use the presence of a `build.list` file to detect a multi-tree project
when running `./update trees`; instead, check the presence of `target.cfg`
down one level from `config/project/`, so: `config/project/*/target.cfg`
instead of `config/project/target.cfg`. This way, if someone working on lbmk
accidentally adds that `build.list` file in the wrong place, lbmk won't
become unusable. This also means that single-tree projects can now provide
a `build.list` file! (and some of them now do - look at the features section
on this page)
* Move check for *root user* to include/lib.sh, *before* the version/versiondate
files are written; these files need to be writeable by the standard user,
otherwise lbmk will exit. If you run lbmk as root, except when running the
dependencies command, it exits with error status; ironically, that very same
check then prevented running as root-root, causing lbmk to become unusable
until those files were either deleted or had ownership changed. This fix
prevents the bug from occuring ever again, but people who were previously
affected still have to fix these files (if they were written as root).
* Move dependency handling to include/lib.sh, *before* the version/versiondate
files are written, and *exit* before they are written; this prevents writing
the version/versiondate files as root, which previously occured when running
a command such as `./build dependencies debian` (installs build dependencies
from apt-get on a Debian machine). This bug ironically prevented lbmk from
running at all, under such conditions, because the dependencies script
required root, but lbmk exits with error status if running anything else as
root, and if version/versiondate are owned by root, that prevents lbmk from
running because writing to these files is the first thing it does, so an exit
with error status would otherwise occur.
* config/git/: Bump to a newer revision of Untitled (static site generator),
which thereby also imports the same fix as described in the next bullet
point below, because Untitled had (and now no longer has) the exact same bug.
* include/lib.sh: check environmental variables properly, for example
check that `${XBMK_RELEASE+x}` isn't unset; it was previously grepping
the output of `set`, which led to a bug report by a user who had the
variable `TMUX_TMPDIR` set, whereas `TMPDIR` was unset and lbmk was checking
the latter; in this example, the bug caused lbmk to act as though `TMPDIR`
was set, when it in fact wasn't, and code that used it then crashed because
lbmk does `set -u -e` (and it does this precisely to catch such bugs like the
one you're reading about now so that they can be fixed, like this one was!)
* **Re-configured GRUB so that only the Haswell and Broadwell machines contain
xHCI support**, where it doesn't cause any issues (and is required), while
other mainboards use a version of GRUB that lacks support for xHCI. This is a
mitigations against the bug reported in [lbmk
issue 216](https://codeberg.org/libreboot/lbmk/issues/216). This is done, by
using the new *multi-tree* GRUB handling, which is mentioned above in
in the section (of this audit report) pertaining to *feature changes*, whereby
each mainboard can have its own GRUB revisions and patches, with its own
GRUB configuration file (that could be uniquely optimised for it).
* **Fix vboot build issue when running lbmk in i686 (32-bit) host machines**.
The patch, courtesy of *Luke T. Schumaker*, adapts vboot's vmlinuz extract
function so that it uses pointer logic directly, instead of defining
integers (of type `ssize_t`) which, the way it was written, caused GCC to
believe that there would be a buffer overflow in code; the new code is more
robust and should prevent such an issue. This is both an *acute* bug fix,
fixing a bug that was actually triggered, and a preventative bug fix as the
original code wasn't correct either, even on AMD64 hosts (where it happened
to compile anyway).
* include/vendor.sh: Skip a given blob if the path to it is `/dev/null` - this
fixes a bug exposed by the previous change two bullet points down (fine
grained error control), because VGA ROMs are handled but the KGPE-D16 target
mitigates a crash bug when PIKE2008's option ROM is executed by SeaBIOS, by
inserting fake (empty) option ROMs for it into CBFS, and it does so by
telling coreboot to insert a *VGA option ROM* with the correct PCI device
and vendor ID, pointing (you guess it) to *`/dev/null`*. This makes the
KGPE-D16 target now return (when run through `./vendor download`) with zero
status, instead of error status.
* Do not allow dashes in coreboot target names, to mitigate a bug exposed by
the previous change listed below (regarding fine-grained error control). This
fixes build errors such
as: `include/lib.sh: line 115: kcma-d8-rdimm=config/vendor: No such file or directory`;
dashes were replaced with underscores, on those target names.
* include/vendor.sh: Much more fine-grained error control, when running
the `download` command. Certain parts need sh error handling to be less
strict, so `set +u +e` is used; when it's safe to turn on strict error
handling again, `set -u -e` is used. It used to be that `set +u +e` was the
only behaviour, when running this command. This actually exposed a number
of bugs that were previously hidden.
* include/vendor.sh: Don't exit with error status when running those commands
on a target that has no configs; instead, skip those targets.
* **GRUB: Never run it as a primary payload on any target but QEMU**. This is
a preventative bug fix, after lbmk bug report issue 216:
<https://codeberg.org/libreboot/lbmk/issues/216> - although it was caused by
the xHCI patches, and only happened on Sandybridge hardware, and although
this was later removed on those boards, GRUB is very complex and likely has
a lot of memory corruption issues. SeaBIOS is more reliable, so: Libreboot
only provides *SeaBIOS* as primary payload, but allows you to execute GRUB
from the SeaBIOS menu (the very same GRUB). Additionally: lbmk already
supported a configuration whereby SeaBIOS reads a `bootorder` file in CBFS,
making it try to run the GRUB payload first, while still allowing you to
interrupt by pressing ESC to bring up an alternative boot select menu. This
is now the *default*, on all x86 mainboards. This is a mitigation against
future instability in GRUB because, if such issues happen again, it will not
cause a brick since you can just use SeaBIOS instead, and skip booting to
the GRUB payload (on the affected machines, BIOS GRUB still worked, which
your distro provides and SeaBIOS executes it). *NOTE: GRUB was later made
into a multi-tree project, with certain mainboards using a version that
has the xHCI patches, if required, because the machines that actually need
xHCI support were not affected by the bug referenced in issue 216.*
* Main build script: Check SUID before checking Git name/email, otherwise the
version/versiondate files could be written as root and thus prevent building
of lbmk, which (for most commands) is intentionally engineered to exit (with
error status) if you run it as root.
* script/trees: Reset variable `makeargs` per target, so as to prevent
pollution of this variable when switching from one build target to the next.
* script/trees: Added `UPDATED_SUBMODULES=1` to the make command when running
any coreboot `make` command, to prevent coreboot from automatically fetching
certain Git submodules; this is a preventative fix, fixed before it became
a bug, which it likely would have become at some point as this is exactly
what the coreboot build system does!
* Main build script: hide the output of `git init` when lbmk re-initialises the
Git history, to prevent its output from being wrongly inserted into the
output of commands such as `./build roms list` - such pollution would cause
build errors, so it's important that the Git initialisation function either
doesn't output anything, or that it should cause an *exit* if output is to be
required.
* Added the `CHANGELOG` file to `.gitignore`. This means `./update release`
will now work, on release archives, because lbmk re-initialises Git history
when doing so, but the CHANGELOG file (when present) causes lbmk to skip
all source downloads (which the release builder relies on).
* **Fix garbled output on 1440x900 monitors when using the Dell Latitude E6400.**
The E6400 uses a reference clock (`DPLL_REF_SSCLK`) set to 100MHz, whereas
libgfxinit assumed 96MHz. This timing descrepancy did not cause an issue on
lower resolution displays, so we never caught it in earlier testing. Patch
courtesy of Nicholas Chin, who debugged this issue alongside the user who
reported it. It was fixed by making such timing configurable, within the
coreboot build system, setting it to 100MHz on Dell Latitude E6400.
* script/roms: Skip a target when its config directory is missing, so that
running a coreboot target with no configs in it will not yield an error;
instead, it will now cause a non-error return.
* include/option.sh: If `.git` is missing, in a bare copy of lbmk (not a
release archive), recreate the version/versiondate files manually so as to
prevent a build error. Use of `lbmk.git` or the release archives is
recommended, but some users directly download snapshots of `lbmk.git` from
sites such as Codeberg, and there's no way for us to turn off this feature;
even if we did, it may be present on other Git hosting sites, where users
might host their own copy of lbmk.
* include/option.sh: Don't return non-zero status from the function
named `mkrom_tarball`, because certain other functions rely on its return
value to always be *zero*; instead, call `err` which will then yield
an *exit* (with non-zero status). This means that the function will now
always *return* zero, when it returns.
* include/vendor.sh: Print an error message when the target is ill-defined,
for downloading and/or insertion of vendor files.
* include/git.sh: Remove `.git` directories *per-project*, as and when each
project is being downloaded, instead of having it done all in bulk by the
main build script. This kicks in when `XBMK_RELEASE` is set (release builds),
to correct the over-use of disk space during such very large builds processes.
This makes the build system less likely to OOM when running it inside tmpfs.
* Main build script: initialise Git history *before* running any command,
because this is required for reliable use of the coreboot build system, which
the *inject* command makes heavy use of. This reduces the number of errors,
when running these commands from a release archive, where lbmk re-initialises
a new Git history when you run it for the first time.
* Main build script: define `xp` as a global variable, to prevent it from
being lost between functions.
* script/roms: Create full release tarball name, when generating releases.
* Main build script: exit (with error status) if not running directly from
the root of the lbmk work directory.
General code cleanup
--------------------
In addition to *general* very sweeping code cleanup, condensing code lines
where possible and so on:
* include/lib.sh: Simplified the `download` function (used for crossgcc tarballs).
* include/lib.sh: Simplified the `singletree` function.
* include/git.sh: Simplified the `link_crossgcc` function.
* include/git.sh: Simplified the `nuke` function, because it was over-engineered
to the extreme. Now it's more reasonable.
* include/lib.sh: Move download logic here from include/vendor.sh, for the
feature where *files* can be downloaded as submodules, within Git repositories.
Please read the notes about this in the *features* section.
* include/lib.sh: Shortened a string in the `e` function, so that the line
does not exceed a length of 80 characters.
* include/git.sh: Unified the handling of git clone/reset/am commands into a
single function, rather than duplicating the same logic across multiple
functions.
* script/trees: simplify the `copy_elf` function; don't create the elf directory,
create one defined by `dest_dir` instead (which is the elf directory with
the subdirectory for that project concatenated). Only create it within
the `copy_elf` function, which is only called if actually compiling the
code. This avoids creating empty directories under elf/, for example under
fault conditions.
* include/git.sh: Additional code cleanup, removing certain code that was in
place because the code used to handle both `git submodule update` and the
custom *override* logic for submodules; now only the override is used, at all
times, so the code was cleaned up and optimised only for this.
* include/git.sh: Reduced code indentation in function `fetch_submodule`.
* include/git.sh: Renamed a few variables for increased code clarity.
* script/trees: Unified handling of coreboot `makeargs`.
* Moved function `handle_coreboot_utils` to script/trees (and renamed it
to `check_coreboot_utils`), as it's only ever used from there.
* Moved variable `cbcfgsdir` to include/vendor.sh, because it's only used there.
* Moved cfgsdir/datadir variables to include/lib.sh, because it's also used
from script/roms and script/trees; unify them under a common location.
* Handle `build.list` from config/data/, not config/ - this avoids needing to
check for `build.list` in the `items` function on include/lib.sh, and it is
now avoided.
* include/lib.sh: More user-friendly output from the `e` function, telling the
user whether or not a file/directory exists. This is regularly used, for
example when trying to download a project and the source code was already
prepared.
* U-Boot on QEMU: removed the (currently) unused x86 target.
* grub.cfg: Split function `try_user_config` into multiple smaller functions.
* grub.cfg: Don't scan ESP on btrfs subvols as the ESP is always on a FAT32
partition. This saves time during the bootup sequence.
* include/vendor.sh: Remove unnecessary assignment; `dl_fail` was being set
to `n` and then immediately to `y`. Now it is simply set to `y`.
* Renamed include/option.sh to include/lib.sh
* Main build script: simplified the logic for Git repository initialisation
by *returning non-zero status*, instead of calling err, and handling this
return status in the calling function.
* Main build script: condensed the logic for Git name/email checking into a
simply for loop running `eval`, rather than having lots of separate but very
similar Git commands.
* script/trees: Removed a few unused variables.
* include/git.sh: Moved logic for copying a Git repository to a new function.
* include/git.sh: Moved function `link_crossgcc` to a different location
within the file, for proper top-down order of logic (required as per the
lbmk coding style).
* include/git.sh: Split logic for crossgcc symlinking into its own function.
* include/git.sh: Skip submodule checks if `.gitmodules` missing (NOTE: later
replaced with custom submodule handling in lbmk).
* include/git.sh: Merged `patch_submodules` in `prep_submodules` (NOTE: ditto
to the same note below).
* include/git.sh: Split up submodule handling into a new function (NOTE: support
for submodules was later replaced with custom logic in lbmk).
* include/git.sh: Shortened a few variable names.
* include/git.sh: Removed redundant check for the existence of the patches
directory, when patching a given project. This is unnecessary, where it was
removed, because the patching function itself also checks this. Reduction
in code size by *one line*.
* include/git.sh: Removed function `fetch_from_upstream` and merged its logic
into calling function `fetch_project_trees`, the only calling function, since
the logic in `fetch_from_upstream` was very small and splitting made no sense.
* include/option.sh: Renamed `mktar_release` to `mkrom_tarball`.
* script/roms: Renamed function `moverom` to `copyrom`, because it runs `cp`,
not `mv`, therefore is is *copying* a file, not moving it.
* script/roms: Simplified the logic for listing available serprog build targets.
* script/roms: General simplification of configuration handling for payloads.
* include/vendor.sh: Removed duplicated (and unnecessary) config check,
because it was already done immediately afterward (I accidentally did the
same check twice, in immediate succession).
* include/vendor.sh: General simplification of defconfig handling logic.
* Main build script: removed the `excmd` function and merged its logic into
the `main` function, and then `main` was cleaned up significantly.
* Main build script: don't make `script_path` a global variable; this allowed
a reduction in code size by precisely *one line of code*.
* Main build script: merged the functionality of function `check_git` into
the `main` function, then deleted function `check_git` (which was in
the file include/option.sh).
* Main build script: general simplification of the logic handling source code
downloads in function `fetch_trees`.
* Main build script: Use `UTC+0000` when initialising git repository commit
dates (for initial commits).
* Removed the `check_project` function, and placed its logic directly
inside `include/option.sh` so that it automatically runs in every script
that sources it.
* Main build script: General cleanup on the code handling file deletions
under function `fetch_trees`.
* Main build script: delete function `mkversion` and, in its calling function,
simply print the string contained in variable `relname`.
* Main build script: general cleanup on the logic that handles tarballs.
* Main build script: Remove `mkrom_images`, and move its logic into the only
calling function within that same file.
* include/option.sh: Removed the function `insert_version_files` and merged
its logic into its only calling function.
* Unified all logic for handling SHA512 checksums, placing it inside
include/option.sh for use elsewhere.
* Move image tarball generation to script/roms (formerly script/build/roms).
* Removed redundant function `extract_ref` from include/mrc.sh
* Removed an errant comment from include/git.sh
* Switched to a one-level directory structure for main scripts, rather than
two-level; for example, script/build/roms is now script/roms
* Merged scripts under script/vendor/ into include/vendor.sh and stub it
from the main build script
* Merged script/update/release into the main build script
* Merged script/build/serprog into script/build/roms
* script/build/roms: remove unnecessary command (errant return)
* Merged include/err.sh with include/option.sh, into include/option.sh
* script/build/roms: fixed improper use of variable outside a function
* build/build/roms: more reliable exit status in `skip_board()`
* script/build/roms: split up `main()` into multiple smaller functions
Revision updates
================
Some revisions were updated as part of standard routine, but happened to be
done during this audit. Those updates are as follows:
SeaBIOS
-------
Bump SeaBIOS to revision `e5f2e4c69643bc3cd385306a9e5d29e11578148c`, which has
these changes relative to the old one:
```
* e5f2e4c6 pciinit: don't misalign large BARs
* 731c88d5 stdvgaio: Only read/write one color palette entry at a time
* c5a361c0 stdvga: Add stdvga_set_vertical_size() helper function
* 22c91412 stdvga: Rename stdvga_get_vde() to stdvga_get_vertical_size()
* 549463db stdvga: Rename stdvga_set_scan_lines() to stdvga_set_character_height()
* c67914ac stdvga: Rename stdvga_set_text_block_specifier() to stdvga_set_font_location()
* aa94925d stdvga: Rework stdvga palette index paging interface functions
* 8de51a5a stdvga: Rename stdvga_toggle_intensity() to stdvga_set_palette_blinking()
* 96c7781f stdvga: Add comments to interface functions in stdvga.c
* 2996819f stdvga: Rename CGA palette functions
* 91368088 stdvgamodes: Improve naming of dac palette tables
* 70f43981 stdvgamodes: No need to store pelmask in vga_modes[]
* 1588fd14 vgasrc: Rename vgahw_get_linesize() to vgahw_minimum_linelength()
* d73e18bb vgasrc: Use curmode_g instead of vmode_g when mode is the current video mode
* 192e23b7 vbe: implement function 09h (get/set palette data)
* 3722c21d vgasrc: round up save/restore size
* 5d87ff25 vbe: Add VBE 2.0+ OemData field to struct vbe_info
* 163fd9f0 fix smbios blob length overflow
* 82faf1d5 Add LBA 64bit support for reads beyond 2TB.
* 3f082f38 Add AHCI Power ON + ICC_ACTIVE into port setup code
* 3ae88886 esp-scsi: terminate DMA transfer when ESP data transfer completes
* a6ed6b70 limit address space used for pci devices.
```
Flashprog
---------
Updated to revision 5b4fdd1 from 2 May 2024, rebasing the MX workaround patch.
This imports upstream changes, relative to the previous revision:
```
* 5b4fdd1 z60_flashprog.rules: Add udev rule for CH347
* 72c9e40 meson: Check for CPU families with known raw mem access
* 3458220 platform/meson: Port pciutils/pci.h workaround to Meson
* f279762 platform/meson: Check for libi386 on NetBSD
* 14da5f7 README: Convert to Markdown
* 8ddea57 README: Document branching and release policy
* 2522456 util/list_yet_unsupported_chips.sh: Fix path
* cbf9c11 spi: Don't cross 16MiB boundaries with long writes
* 823a704 dediprog: Skip warning on first attempt to read device string
* e8463c8 dediprog: Revise prefix check for given programmer id
* 38af1a1 dediprog: Revise id matching
* 4661e7c amd_spi100: Use flashprog_read_chunked() for progress reporting
* cdcfda2 read_memmapped: Use flashprog_read_chunked() for progress reporting
* 7679b5c spi25: Replace spi_read_chunked() with more abstract version
* ca1c7fd spi25: Normalize parameters of spi_nbyte_read()
* e36e3dc dediprog: Use default_spi_write_256
* 522a86d linux_spi: Use default_spi_read()/_write_256()
* 806509b cli_classic: Turn progress reporting into a progress bar
* 842d678 libflashrom: Return progress state to the library user
* aa714dd flashprog.c: Let select_erase_functions() return byte count
* 2eed4cf serprog: Add SPI Mode and CS Mode commands
* 821a085 dediprog: Implement id reading for SF600 and later
* 274e655 dediprog: Read device string early
* 0057822 dediprog: Add protocol detection for SF700 & SF600Plus-G2
* fb176d2 dediprog: Use more general 4BA write mode for newer protocols
* 0ab5c3d dediprog: Split device type and version parsing
* bdef5c2 dediprog: Use unsigned conversions to parse device string
* 5262e29 dediprog: Try to request 32B device string (instead of 16B)
* e76e21f dediprog: Get rid of some unnecessary hex constants
* 5a09d1e udelay: Lower the sleep vs delay threshold
* 03ad4a4 linux_mtd: Provide no-op delay implementation
* 211c6ec serprog: Refine flushing before synchronization
* 383b7fe serprog: Test synchronicity before trying to synchronize
* d7318ea serprog: Move synchronicity test into separate function
* 9a11cbf Let the flash context directly point to the used master
* aabb3e0 writeprotect: Hook wp functions into the chip driver
* 89569d6 memory_mapped: Reduce `decode_sizes` to a single `max_rom_decode`
* 929d2e1 internal: Pass programmer context down into chipset enables
* 7c717c3 internal: Pass programmer context down into board enables
* e3a2688 Pass programmer context to programmer->init()
* 2b66ad9 Start implementing struct flashprog_programmer
* 4517e92 memory_bus: Drop stale `size == 0` workaround and FIXME
* b197402 memory_bus: Split register mapping into own function
* 0e76d99 memory_bus: Move (un)map_flash_region into par master
* 9eec407 Perform default mapping only for respective chips
* 56b53dd wbsio_spi: Request memory mapping locally
* 5596190 it87spi: Request memory mapping locally
* 46449b4 spi25: Drop stale `bus == SPI` guards
* ab6b18f spi25: Move 4BA preparations into spi_prepare_4ba() hook
* 901fb95 Add prepare/finish_access() hooks for chip drivers
* a96aaa3 dediprog: Support long writes of 16MiB and more
* 1338936 Consider 4BA support when filtering erase functions
* 8d36db6 flashprog.8: Fix up serprog example
* d2ac303 flashprog.8: document new serprog cs parameter
* d1b9153 chipset_enable.c: Add Genoa to mendocino entry
```
As a reminder:
Libreboot now uses Flashprog instead of Flashrom; Flashprog is a fork of
Flashrom, lead by Nico Huber after a dispute with the new leadership of
Flashrom, and it was felt that Flashprog is a better choice for Libreboot.
Git log
=======
This entire set of changelogs is based on the precise Git history in lbmk,
relative to Libreboot 20240504 which is from where the audit began.
The latest changes are listed first, going all the way down to earlier changes:
```
* 2ee186ae minor code cleanup in the build system
* c5441bb9 re-add ability to use cbfs grub.cfg as default
* d33556c6 trees: exit with error if project undefined
* 1799a336 build: also make a lock file during release build
* 78426a97 lib.sh: more useful lock message
* e80c4b73 create a lock file during builds
* a0710ef9 git.sh: hide e() output on for loop
* 86eb566b lib.sh: fix regression
* fbcdf33f git.sh: download xtree *before*, not after
* 6a3d8a96 git.sh: fix deletion path in nuke()
* 3478b288 lib.sh: less confusing error in download()
* f3f5b99c lib.sh: hide stderr on download()
* 3440e1f6 lib.sh: simplify download()
* 75b39dbe lib.sh: fix redundancy in download()
* 26df6e7a lib.sh: simplify singletree()
* 9cdf4192 git.sh: further simplify nuke()
* 1cede024 git.sh: simplify link_crossgcc()
* 77e482aa git.sh: simplify nuke()
* 42e97950 Merge pull request 'Add dependency scripts for Fedora 40 and Ubuntu 24.04' (#220) from fuel-pcbox/lbmk:master into master
|\
| * 046007b4 Add dependency scripts for Fedora 40 and Ubuntu 24.04
* | a0eb79df add crossgcc tarballs to config/submodules/
* | b0d1ad32 git.sh: support downloading *files* as submodules
* | 1a44fcfa git.sh: remove unnecessary line break
* | 74ae84af vendor.sh: add a return at the end of mkdirs
* | c202dc61 vendor.sh: move download logic to lib.sh
* | 08d0a1d5 lib.sh: shorten a string in e()
* | 9b00b30a move uefiextract to elf/uefitool/
|/
* 05d301bd git.sh: fix submodule path
* 7e15859b git.sh: simplify prep_submodules()
* acd3608b git.sh: unified handling of git clone/reset/am
* 668bcbf6 trees: simplified copy_elf() handling
* 3eef7f37 git.sh: simplify submodule handling
* 4b1b1f50 git.sh: provide feedback for repository downloads
* d4324768 git.sh: download "depend" projects *before*
* a4549e93 git.sh: reduced indentation in fetch_submodule
* 11c47ba7 git.sh: reduced indentation in prep_submodules
* 9c1ea8f9 git.sh: *never* run git submodule update
* 137321eb lib.sh: rename variable for clarity
* 7bfb1d62 trees: don't check empty path in copy_elf()
* 0b7566cb trees: fix build issue caused by bad elf check
* 7aa9f224 trees: fix listfile check in copy_elf()
* 06c78e13 trees: don't say check elf/ if build.list missing
* dea41f13 trees: don't do elfcheck if build.list missing
* 3bd562a2 define mdfiles/images in config/submodules/docs/
* bff75628 libopencm3 to config/submodules/ on stm32-vserprog
* d9b9f6db add tinyusb to config/submodule/ for pico-sdk
* 099ee3f4 config/git: use "depend" for serprog dependencies
* d0f99c2f trees: unified coreboot makeargs
* a7889c5a trees: use multiple threads to build cbutils
* d41658f1 move handle_coreboot_utils to script/trees
* c0822ac4 put coreboot utils in elf/, not cbutils/
* d1ba0851 fix build issue building coreboot utils
* 7e49fe4b trees: skip single-tree build if a build exists
* 12774274 use correct memtest86plus path in script/roms
* 8511615e put memtest86plus builds in elf/memtest86plus/
* 176b936d put flashprog builds in elf/flashprog/
* 48cbb30d trees: also print "DONE! check elf/dir" on single
* 315fed5f trees: handle build-test on multi-tree projects
* b8112af9 git.sh: use singletree() to decide submodules
* 78f7e429 move cbcfgsdir variable to vendor.sh
* 810ad480 move cfgsdir/datadir variables to lib.sh
* ba36f26d handle build.list from config/data/, not config/
* bea089bb don't use build.list to detect multi-tree projects
* 6e1b8087 move id check to lib.sh too
* 62c25ac7 move root check to lib.sh (bugfix)
* 75382a41 bugfix: move dependencies handling to lib.sh
* c6aff769 bump untitled revision again
* 414a605a bump untitled revision in git config
* 7d562679 lib.sh bugfix: check environmental variables right
* 53dd4bc4 lib.sh: more friendly output from e()
* c2793e7a badcmd: don't print "no context given"
* 49ae4f91 badcmd: link directly to the maintenance manual
* 00653aab better help text on invalid commands
* afac9a06 build: print the project website address on help
* 1e534e7d add projectsite file: point to libreboot.org
* 429e91f9 make GRUB multi-tree and re-add xhci patches
* 9daf7f05 u-boot on qemu: remove currently unused x86 target
* 6d59f1d0 grub.cfg: scan /boot/grub.cfg last
* 2becc736 grub.cfg: scan grub2/ last
* cfc5265f grub.cfg: search a reduced list of devs/partitions
* 42b5b58d grub.cfg: scan grub.cfg from ESP
* b3d58f1e grub.cfg: split up try_user_config
* 2ea5e61c grub.cfg: don't search for *_grub.cfg
* c742a89d grub.cfg: remove unnecessary path for isolinux
* e0b2216f grub.cfg: don't scan EFI on btrfs subvols
* 38135f9e Merge pull request 'Fix building vboot on i686' (#218) from lukeshu/lbmk:lukeshu/i686 into master
|\
| * 221206b4 Fix building vboot on i686
* | a76dda93 vendor.sh: remove unnecessary assignment
* | 17a9d11d git.sh: do not remove .submodules
* | 13d4b6d3 delete u-boot test/lib/strlcat.c using nuke()
* | f6cbc501 import nuke() from cbmk cdce8ba70b
|/
* 7fbcb7be coreboot t440p/w541: enable nvme in grub_scan_disk
* 47f582d4 ./vendor download: skip if blob path is /dev/null
* e7cb10d6 do not allow dashes in coreboot target names
* e9b9e825 ./vendor download: more fine-tuned error control
* 0dd0dfaf vendor.sh: don't error on main targets
* a4bd49de roms: allow user override of grub_scan_disk
* b00800a7 grub.cfg: actually support setting boot order
* 4488745c trees: use CPUS=x on regular coreboot make
* 7d50e09f update gitignore
* b78f62c7 roms: fix bad eval when comparing options
* b11e4c9f grub.cfg: add spdx header
* 3998a3ba re-configure grub_scan_disk on various targets
* 1c4d6498 remove grub_scan_disk in all target.cfg files
* e1883f1d grub.cfg: use grub_scan_disk to set boot order
* c94cecd8 GRUB: remove XHCI patches for now (will re-add)
* ff2997d6 minor correction
* d855408a roms: make grubfirst if seabios_withgrub=y
* ec761c88 coreboot: only run GRUB as a secondary payload
* 64c64bcf flashprog: bump to 5b4fdd1 from 2 May 2024
* 914852dd rename include/option.sh to include/lib.sh
* dc7b72f3 roms: rename bstr variable
* 5c14e8e1 general code cleanup in the build system
* 48c2cef8 build: simplify git_init()
* db06bbdb build: do root check before git check
* 8d199a31 build: simplify git checks
* 8da2559b option.sh: fix bad check for version/versiondate
* d32968c7 trees: reset makeargs per target/project
* 7bab0cf9 trees: also use UPDATED_SUBMODULES=1 on crossgcc
* 0a50eaf2 trees: add UPDATED_SUBMODULES to coreboot make
* ff0840bd trees: write -C on the make command first not last
* b91ee727 config: add backup coreboot submodule repositories
* 4a3ebe84 coreboot/default: remove chromeec from module.list
* 9c5890e9 git.sh: break if a submodule clone succeeds
* fdb08143 coreboot: only download the necessary submodules
* 1cb255e8 git.sh: allow finer control of git submodules
* 5d87eea7 build: hide git-init output
* b8ec7d56 option.sh: generate version file if .git not found
* 87c361f3 update/trees: remove unused variable
* da427272 git.sh: move repo copying to a new function
* 093c4a36 git.sh: move link_crossgcc to end of file
* 73a2d991 git.sh: move xgcc linking to a new function
* d7749876 git.sh: skip submodules if .gitmodules missing
* c3e1aa34 git.sh: merge patch_submodules in prep_submodules
* a4163330 git.sh: split submodule handling to new function
* aa4faf08 git.sh: remove errant line break
* 00142696 git.sh: remove another meaningless check
* fc3b0ba8 git.sh: shorter variable names
* dae10dd4 git.sh: remove meaningless check
* c148fa53 git.sh: remove variable not meaningfully used
* 079afb5b add CHANGELOG to .gitignore
* 0d8781ef Merge pull request 'Fix E6400 display reference clock patches' (#214) from nic3-14159/lbmk:fix-e6400-igpu-ref-clock into master
|\
| * 9f50e362 Fix E6400 display reference clock patches
|/
* e5a5935d fix building coreboot images on i686 hosts
* a2ac4d13 Merge pull request 'Also try unlocking encrypted volume on NVMe' (#213) from mkukri/lbmk:master into master
|\
| * 77ebd050 Also try unlocking encrypted volume on NVMe
* | 287d0555 Merge pull request 'Add NVMe support to GRUB2 payload' (#212) from mkukri/lbmk:master into master
|\|
| * abe6717c Add NVMe support to GRUB2 payload
* | 47d77c94 Merge pull request 'Fix E6400 display issue with 1440 x 900 panel' (#211) from nic3-14159/lbmk:fix-e6400-igpu-ref-clock into master
|\ \
| * | 8629873a Fix E6400 display issue with 1440 x 900 panel
| |/
* | 0beecd1b Merge pull request 'Add pt qwerty keymap to lbmk' (#210) from samuraikid/lbmk:master into master
|\ \
| * | 8d723d14 Add pt qwerty keymap to lbmk
* | | 835e5ad0 git.sh: fix invalid command in git_prep()
| |/
|/|
* | 1e54db29 git.sh: allow patching submodules
* | 00e00a18 git.sh: don't delete .git if src/project/project
* | 245b4eb2 build/roms: skip target if config/ dir missing
* | aadccc59 more minor cleanup in the build system
* | 5b8928c7 git.sh: remove fetch_from_upstream()
* | 71baf653 option.sh: don't return 1 in mkrom_tarball
* | 1fe9c4b8 option.sh: mktar_release to mkrom_tarball
* | cc7ed692 build/roms: rename moverom to copyrom
* | b40118ae minor code cleanup in the build system
|/
* 998f30ad build/roms: simplify serprog list command
* 21a7efaa build/roms: simplified config payload checks
* 5b5dccd6 vendor.sh: further simplify config handling
* 8418ea9a vendor.sh: greatly simplified config handling
* 53b394f5 vendor.sh: move config checks to detect_firmware
* bb7255c3 vendor.sh: print an error upon ill-defined target
* 3f73f3d0 vendor.sh: remove redundant check
* 32923f56 vendor.sh: simplify defconfig check
* f8e3ca3b git.sh: Remove .git if XBMK_RELEASE=y
* dd851caa build: remove initcmd() and simplify main()
* 4ea843a4 build: initialise git first (before commands)
* 5702f5a4 build: remove excmd() and simplify main()
* b76a70c3 build: don't make script_path a global variable
* 839ef680 lbmk: allow easier sync with cbmk
* 885fcebd remove help commands (user should read docs)
* c6ba0a0e option.sh: delete check_git()
* 313c4c01 build: define "xp" in the global variables
* 350857ff build: simplify for loop in fetch_trees()
* 8e05399d build: simplified downloads in fetch_trees()
* 914ff1ad ./build release: don't do u-boot-only archives
* 5c3fb9a4 build: use utc+0 when initialising git repo dates
* e281966f remove check_project() (always set variables)
* ee2bf0d2 build: simplify deletions in fetch_trees()
* 39df6230 build: delete mkversion() (just print relname)
* a40a6129 build/roms: clean up tarball handling
* e5ffb2af rm src/u-boot/*/test/lib/strlcat.c in u-boot
* c149cbb8 build: remove mkrom_images
* 4135ce5e build: use same tarball name on uboot-only release
* 189b70dd build/roms: create full release tarball name
* 36d45474 option.sh: don't bother checking for GNU tar
* f0b604fc option.sh: remove insert_version_files()
* 267c13cc cleanup: remove mkvdir
* 08c9f94a unified sha512sum creation for tarballs
* 1ce7e339 move rom tarball creation to script/roms
* 190495d2 disable x301 for next release (for now)
* 03fae0cf mrc.sh: remove redundant function extract_ref()
* f66ceef6 print two line breaks before confirming release
* cc339741 remove haswell mrc blob (libre raminit stable now)
* 05fbd392 remove all status checks. only handle release.
* 8ba0fd83 git.sh: remove errant comment
* d7ce26dc move script/*/* to script/
* 029291e5 merge script/vendor/* into include/vendor.sh
* c8fb24bb build: print usage for special commands
* 5f63b594 merge script/update/release into build
* e1ea5dd0 bump seabios to e5f2e4c69643bc3cd385306a9e5d29e11578148c
* 052414c0 build: further prevent non-lbmk-work-directory
* fb8d0c86 build: exit if not running from lbmk directory
* 38aaaecf build/roms: print serprog help
* e3cb3a40 merge script/build/serprog with script/build/roms
* 297af7e6 build/roms: remove unnecessary command
* 5e4009b5 merge include/err.sh with include/option.sh
* 58400fc4 err.sh: correct copyright info
* aa5937ed build/roms: don't rely on x in handle_target
* 580a5559 build/roms: don't use exit status from skip_board
* 2fcbff68 build/roms: split up main()
* d13d9308 build/roms: allow searching status by mismatch
```
This is 211 changes, since Libreboot 20240504.

9
site/news/hp820g2.md
View File

@ -23,6 +23,15 @@ 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
============

13
site/news/libreboot20231021.md
View File

@ -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 blob-free but (in Libreboot)
Dell Latitude E6400, which is otherwise FSDG-compatible 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 that
can be blob-free, in other words.
platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything FSDG
compatible, 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,3 +1223,10 @@ 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.

6
site/news/libreboot20231101.md
View File

@ -247,3 +247,9 @@ 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.

5
site/news/libreboot20231106.md
View File

@ -240,6 +240,11 @@ 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
======

16
site/news/libreboot20240126.md
View File

@ -107,6 +107,12 @@ 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
@ -195,6 +201,16 @@ 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

66
site/news/libreboot20240225.md
View File

@ -57,6 +57,8 @@ 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
@ -73,7 +75,6 @@ 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)
@ -186,10 +187,6 @@ 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
---------------------------------------
@ -212,20 +209,15 @@ 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. 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.
Libreboot project over many years. 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, anyone can participate in it) and technological
a social (community-led, not run by an employee of Google) and technological
perspective. This was done because, firstly Nico Huber is a better leader,
and flashprog is very likely to become the dominant project in the future.
and flashrom 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.
@ -240,46 +232,6 @@ 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
-------------
@ -338,9 +290,3 @@ 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/).

497
site/news/libreboot20240504.md
View File

@ -1,497 +0,0 @@
% Libreboot 20240504 released!
% Leah Rowe
% 4 May 2024
**Do not use the 20240504 release. This changelog is still provided as
reference, but there were problems with this release. Please instead use
the [Libreboot 20240612 release](libreboot20240612.md).**
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 major new 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 another 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
============================
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.
Errata
======
See: <https://codeberg.org/libreboot/lbmk/issues/216>
This bug has been *fixed* in lbmk.git, and the fix will be included in
the next release, but it wasn't caught in the 20240504 release.
The bug is quite serious, and it was previously decided that documentation
should be written warning about it (in docs/install/). The bug was *only*
triggered on Intel Sandybridge hardware (e.g. ThinkPad X220) and was never
reported on other boards, but there's no way to fully know; what is known
is that the offending patch that caused the bug has been *removed*; namely,
xHCI GRUB patches, which are now only provided on Haswell and Broadwell
hardware (where the bug has not occured). **Therefore, we know that the
bug will no longer occur.**
The next release will exclude xHCI support on machines that don't need it,
and a mitigation is in place that makes SeaBIOS the primary payload, to prevent
effective bricks in the future; the bug was in GRUB, but if SeaBIOS is the
first payload then the machine remains bootable even if a similar bug occurs.
It is now the default behaviour, in the next release, that certain images
contain a bootorder file in CBFS, making SeaBIOS try GRUB first, but you can
still press ESC to access the SeaBIOS boot menu if you want to directly boot
an OS from that. This, and the other change mentioned above, will guarantee
stability. GRUB is *no longer* the primary payload, on any mainboard.
However, it was later decided to put this release in the `testing`
directory instead; it was initially designated as a stable release.
All ROM images for the 20240504 release have been *removed* from rsync,
but the source tarball remains in place.
You are advised to use the 20240225 release, or the next release
after 20240504.
A new [audit](audit5.md) has been conducted, marked complete as of 9 June 2024,
fixing this and many issues; a new *true* stable release will be made available
some time in June 2024.

940
site/news/libreboot20240612.md
View File

@ -1,940 +0,0 @@
% Libreboot 20240612 released!
% Leah Rowe
% 12 June 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).
This is a *bugfix* release, and is considered stable. It fixes a series of bugs
that were discovered in the previous Libreboot 20240504 release from 4 May 2024.
The [errata](libreboot20240504.md#errata) on Libreboot 20240504 meant that all
ROM images had to be removed, so a new stable release had to be made ASAP to
compensate.
A new *testing* release is planned for July, adding many more new mainboards;
today's stable release only fixes bugs and adds some new features to the build
system, which have been rigorously tested during the course of the recent audit.
The changes of the recent [5th build system audit](audit5.md) are included, in
this release, in addition to a few minor fixes made since that date. The audit
was completed on 9 June 2024 and today is 12 June 2024. The release came unstuck.
Changes since Audit 5
=====================
Audit 5 was only recent, and forms most of the changes in this release, so look
further down for a list of those changes or read [the audit 5 page](audit5.md).
Some minor changes have been made in the few days since completion of that
audit, namely:
* Add a patch from Nico Huber fixing the Intel graphics device on certain
Xeon processors that can be used on Haswell macchines. Unlikely to be used
by Libreboot users, but for example it has been discovered that the Dell
Precision T1700 is mostly compatible with the 9020 MT images; some GPIOs and
such may not be configured correctly yet, and a proper T1700 port is not yet
available.
* Add a patch from Mate Kukri fixing DP++ on Dell OptiPlex 9020 ports; enables
use of a passive adapter for HDMI/DVI on the displayport.
* Coreboot trees: use coreboot's own nasm mirror as backup, instead of the
macports mirror that was used in audit5. In audit5, a feature was added where
crossgcc tarballs are downloaded by lbmk, with redundant links, rather than
relying on the coreboot build system to do this. (and this means that cross
gcc tarballs are now included in the release tarballs, enabling fully offline
builds on boards that don't need to download vendor files at build time)
* NVMe patch for GRUB payload: it is still present, but it is now *only* enabled
on boards that can physically *have* NVMe SSDs; on boards that don't need the
patch, it is not present. This means there are three GRUB trees: `default`
which most boards use and lacks nvme/xhci support, `nvme` which contains the
NVMe support and `xhci` which contains both xHCI and NVMe support. Each board
is configured to use the appropriate GRUB tree, as required.
The reason for separating the NVMe patch to only those boards that need it, is
precisely to avoid any potential issues if a board doesn't need it. The NVMe
patch has been extensively tested, on all of the boards that actually have it.
Audit 5 changes
===============
Since the recent audit 5 changes are included in this release, the changelog
of that audit has simply been copied for sake of efficiency. Firstly:
Modest code size reduction
--------------------------
There are 1482 lines of shell script in the build system, versus 1680 in the
Libreboot 20240504 release. Libreboot's build system is written purely in
POSIX sh; not BASH, not KSH, not ZSH, jush sh!
This is a difference of 198 lines, or a 12% reduction. Despite the reduction,
numerous features have been added and a large number of bugs were fixed.
Summarised list of changes
==========================
Changes are in order per category, from newest to oldest:
Feature changes
---------------
* **Download crossgcc tarballs as dependencies, when cloning coreboot.** We
previously relied on the coreboot build system, which automatically fetches
these when running `make crossgcc`, which we run automatically. However,
the coreboot logic has to be patched for reliability because the GNU HTTP 302
redirect often fails so we use a static mirror, and the logic has no
redundancy. With this new change, we use the same tarballs but we specify
two URLs, a main and a backup. This also means that the tarballs will once
again be included in Libreboot release archives, enabling offline builds.
* **Support downloading files as submodules, in Git repositories.** This
complements the pre-existing feature where sub-repositories (Git) can be
cloned into a subdirectory of a given main repo. We use this for crossgcc,
as referenced above.
* New files under `config/dependencies/` for Fedora 40 and Ubuntu 24.04. Now
you can run `./build dependencies fedora40`
and `./build dependencies ubuntu2404` on each respective distro, to get
the right build dependencies for building Libreboot from lbmk.
* **NEVER** run `git submodule update`, *ever*. Instead, rely *solely* on
config/submodule/ to define which dependencies should be downloaded, to each
given subdirectory within a main project. This is using a feature described
later on (in this audit report), whereby projects can have redundant
submodule repositories defined; initially, this feature was an *override*
where otherwise the submodule update command would be executed if
the `.gitmodules` file existed for a given project; this override is now
the *only* way to do it, and is thus the default behaviour. This may be
considered a preventative bug fix, in case certain projects auto-download
submodules that might cause us trouble in the future. It's better that we
maintain tight control of submodules.
* **Summarising the next few changes mentioned below: out-of-source builds
are now fully supported, for both single- and multi-tree projects.** (it was
previously only supported on multi-tree projects)
* Moved builds of coreboot utilities (e.g. cbfstool) to `elf/utilname`,
e.g. `elf/cbfstool/default/cbfstool` would be the new cbfstool binary location
for the one build from coreboot in the `default` tree.
* script/trees: Now single-tree builds are skipped if a build exists
under `elf/projectname/`, based on the presence of a `build.list` file; this
is consistent with the same behaviour pre-existing for multi-tree projects.
* When building memtest86plus, the binary is now placed out-of-source,
into `elf/memtest86plus`.
* When building flashprog, the binary is now placed out-of-source,
into `elf/flashprog/`.
* Use new function `singletree` to decide whether to use submodules, rather
than hardcoding a check for *coreboot* - NOTE: use of submodules was later
disabled during this audit, replaced with custom handling in lbmk.
* For error exits caused by *improper commands* (as opposed to fault conditions
while processing valid commands), don't directly call `err`; instead, call a
newly written function `badcmd` which says that much, and links to the
website (if `docs/` is present as in releases, it also points there).
* Added a `projectsite` file pointing to libreboot.org, complementing the
existing `projectname` file which contains the word `libreboot`. This is
used in the `version` command.
* **GRUB is now a multi-tree project.** Each given coreboot target can
specify which GRUB tree it wants to use, each containing its own revision
and patches, with its own GRUB configuration file. This can be used later on
to provide specific optimisations on each given mainboard, but it is used
at present to exclude xHCI patches on boards that don't need it; please also
read the bugfix section (of this audit report) pertaining to this same topic,
for more context. Before this change was implemented, all mainboards used
the exact same GRUB revision, with the same patches and the same config.
* grub.cfg: scan `grub2/` last, on each given device/partition; this speeds
up the boot time in most tests, because most setups use `grub/`,
but `grub2/` is still used on legacy setups so we have to support it and, for
reasons mentioned in the bullet point below, GRUB is very inefficient at
generating the list of devices/partitions when using the `*` wildcard, so
we can't scan `grub*/`.
* grub.cfg: it now scans a reduced set of devices/partitions by default, while
still ensuring (in practise, on real systems) that all such devices and
partitions will be scanned. We hardcode this, because the `*` wildcard in
GRUB is *very slow* on some machines, due to the way the GRUB kernel
constantly re-initialises the list of devices and partitions during operation.
Scanning an *excessive* number of hardcoded device/partition numbers slows
down the boot too, so this has been optimised. It has been tested and it
shouldn't cause any issues on machines/setups that people actually use.
* **grub.cfg: scan distro-provided grub.cfg from ESP;** we previously only
scanned the ESP for isolinux/syslinux configurations (which GRUB can parse).
* grub.cfg: Don't search for `*_grub.cfg` as this slows down the bootup
sequence, and nobody really uses this anymore; Libreboot's GRUB is much more
robust these days, pretty much booting anything automatically, but you used
to have to (regularly) use a `libreboot_grub.cfg` file to override the default
one provided by your distro. This legacy cruft has been removed, entirely!
* Added the `nuke()` function to delete files systematically, based on the
presence of a `nuke.list` file which contains files/directory paths relative
to the root directory of a given Git repository. This is used to delete a
poorly licensed source file in U-Boot (strlcat.c).
* **T440p/W541 laptops: Enable NVMe SSDs in `grub_scan_disk`**; an e-key adapter
can be used in the WLAN slot, to add an NVMe SSD. Even though throughput
is limited by the x1 PCI-E width, it's still a viable upgrade as it offers
slightly improved read/write performance compared to any SATA SSD.
* script/roms: Allow to override `grub_scan_disk` via `-s`, for
example: `./build roms -s nvme t1650_12mb`
* **grub.cfg: Use `grub_scan_disk` to set boot order (rather, boot order by
device type).** It is possible now to configure each mainboard with this
variable, so that certain types of devices are scanned in a precise order;
for example, scan NVMe SSDs first.
* **include/git.sh: Allow manual override of `git submodule` handling**, instead
directly downloading Git repositories using `git clone`, into the subdirectory
of a given main Git repository (as per `src/projectname` scheme). With this
feature, it is possible now to specify a *backup* submodule repository, for
redundancy, all while still allowing to reset the revision (and *patch* the
given submodule). This has been used to provide greater redundancy when
downloading coreboot submodules. It also allows to *limit* the number of
submodules, so now we only download the ones we need, thus saving bandwidth
especially during very large and long build sessions. - *NOTE: this was
later changed so as to be the ONLY method for downloading submodules, skipping
the actual git-submodule-update command entirely, on all projects.*
* **Native NVMe driver added to the GRUB payload**, allowing users to boot from
NVMe SSDs where present on a given mainboard. The patch is courtesy of
Mate Kukri, who ported SeaBIOS's own NVMe driver, converting all of the
code to run properly within GRUB's own kernel. NVMe SSDs are now fully
bootable on all machines that can have them, offering vastly superior
read and write performance when compared to SATA SSDs.
* include/git.sh: Allow patching git submodules (NOTE: support for submodules
was removed entirely, later in the audit, in favour of custom logic in lbmk
for the downloading of such dependencies).
* Added Portuguese keyboard support in the GRUB payload (patch courtesy of
the contributor by alias `samuraikid`).
* Removed all help commands, because it's just a duplication of documentation
that is already included in releases anyway, and people using the Git
repository require internet access anyway, so they can just use the website.
* Main build script: removed the functionality for generating source tarballs
where the only source code included is U-Boot; we do not need this, because
the larger source tarball containing all of Libreboot also contains U-Boot.
* include/option.sh: Don't bother checking for GNU Tar, because we were only
using it for reproducible tarball generation which didn't work yet anyway;
there are still ways of doing it with BSD tar and so on.
* Print a two-line break before confirming the location of the generated
release archive, when running release builds. This makes it more obvious
to the operator.
* **Removed the MRC (raminit blob) on Intel Haswell** (4th generation)
hardware, namely the ThinkPad T440p, W541, Dell OptiPlex 9020 MT
and Dell OptiPlex 9020 SFF; the libre raminit now works well, and S3 works.
* Removed all status checks from script/roms (formerly script/build/roms),
because it's better to document this instead, and rely on testing regardless.
Bug fixes
---------
Some of these changes fix actual issues that were found in testing, while
others were fixed *before* being triggered/reported and are thus *preventative
bug fixes*. The logic in lbmk has been very intensively audited as is customary!
The changes are, from newest to earliest:
* script/trees: Exit with error status if a given project is not defined. It
was previously decided that this script could be used to directly run Makefiles
from any given directory, but this is no longer done as it was error-prone;
this change prevents such usage, thereby preventing unstable conditions within
the build system.
* **Create a lock file when running lbmk.** Only do it from the main parent
instance, but not child instances of it; delete it at the end, after exiting
from the parent process. If starting a separate parent process, that one
will now immediately exit (with error status) if the lock file exists. This
prevents the fault condition where the user accidentally runs the same lbmk
instance twice, from the same work directory; it is only designed to be
executed once, per work directory. This is similar to the locking feature
you find in package managers such as apt-get. Also do this in release/
directories, while building (but don't include a lock file inside the tarball).
* include/git.sh: When doing a global check for files in every project all at
once, as defined by each respective (if existent) `nuke.list` file, hide
the output. Only show the output when running it on a specific project, not
the one in the for loop. This prevents user confusion / false bug reports.
* include/git.sh: Download coreboot as defined by `xtree` *before* downloading
the main project that defined it, to prevent a situation where the main project
is downloaded successfully but not the dependency (defined by `xtree`); this
is to maintain the integrity of the build system under fault conditions.
* include/lib.sh: When a download fails (running the `download` function),
don't then say that the file is "missing". Instead, actually say that the
download failed, so that the operator has a better understanding.
* include/lib.sh: Hide stderr on the `download` function, for the initial
check when verifying an existing file; although no problem existed on
technical terms, the output was confusing because it made the user think
there was a problem. The logic then downloads and re-verifies, and the
output indicating *that* verification has not been hidden; if the file
already exists, this is simply indicated by `e()`. This is considered a bug
fix, because it fixes the bug where users made erroneous bug reports, by
re-engineering the situation so that they do not make such erroneous reports.
TL;DR hide a totally benign (non-)error message.
* include/git.sh: Provide better user feedback about what is being downloaded
and where - although nothing was broken before, this lack of feedback was a
bug because it made debugging harder. Provide more clarity for the user.
* include/git.sh: Download dependencies *before*, not *after*, downloading the
project sources that depend on it. For example, pico-serprog depends on
pico-sdk. If you were to download pico-sdk *after* pico-serprog, the latter
may be downloaded and placed in src/, but then the former (sdk) could fail
due to bad internet, and now the overall downloaded code is corrupt, and there
was nothing checking for this after the fact; checking for it would be bloat.
By downloading the dependency *before*, then if *that* download fails, so
does the main one, and integrity is maintained within the build system.
* Preventative bugfix: don't check empty paths in `copy_elf` (of script/trees),
even though this potential bug was not yet triggered. Play it safe.
* script/trees: Don't check pre-existing builds in elf/ if `build.list` is
missing, otherwise it's too soon and builds are prevented in the first place;
this was caused initially when supporting out-of-source builds for single-tree
projects, as was already done on multi-tree. Now this is fixed.
* Documentation: only define the Untitled Static Site Generator
in `config/git` - the dependencies (markdown files and images) are now
defined in config/submodules/ instead. This prevents the bug where you could
download one of the dependencies first which would make the main project,
Untitled, un-downloadable, since the dependency projects go in subdirectories
of the main project that depends on them.
* Handle serprog dependencies in config/submodule instead of relying on
the git submodule update command, and only provide necessary modules. This
prevents the bug where downloading a dependency first later prevented the
main project from being downloaded, if the dependency was in a subdirectory
of what depends on it.
* Build coreboot utilities on a number of threads as defined by `XBMK_THREADS`;
although they already compiled, they would always do so on a single thread,
which is considered a bug. Now they can be compiled on multiple threads.
* include/lib.sh: Don't use `./update trees -f` to build coreboot *utilities*,
because it's quite error prone and not what that script is designed to do;
it is only designed to operate based on strictly defined single- and
multi-tree projects. Instead, call `make` directly.
* Don't use the presence of a `build.list` file to detect a multi-tree project
when running `./update trees`; instead, check the presence of `target.cfg`
down one level from `config/project/`, so: `config/project/*/target.cfg`
instead of `config/project/target.cfg`. This way, if someone working on lbmk
accidentally adds that `build.list` file in the wrong place, lbmk won't
become unusable. This also means that single-tree projects can now provide
a `build.list` file! (and some of them now do - look at the features section
on this page)
* Move check for *root user* to include/lib.sh, *before* the version/versiondate
files are written; these files need to be writeable by the standard user,
otherwise lbmk will exit. If you run lbmk as root, except when running the
dependencies command, it exits with error status; ironically, that very same
check then prevented running as root-root, causing lbmk to become unusable
until those files were either deleted or had ownership changed. This fix
prevents the bug from occuring ever again, but people who were previously
affected still have to fix these files (if they were written as root).
* Move dependency handling to include/lib.sh, *before* the version/versiondate
files are written, and *exit* before they are written; this prevents writing
the version/versiondate files as root, which previously occured when running
a command such as `./build dependencies debian` (installs build dependencies
from apt-get on a Debian machine). This bug ironically prevented lbmk from
running at all, under such conditions, because the dependencies script
required root, but lbmk exits with error status if running anything else as
root, and if version/versiondate are owned by root, that prevents lbmk from
running because writing to these files is the first thing it does, so an exit
with error status would otherwise occur.
* config/git/: Bump to a newer revision of Untitled (static site generator),
which thereby also imports the same fix as described in the next bullet
point below, because Untitled had (and now no longer has) the exact same bug.
* include/lib.sh: check environmental variables properly, for example
check that `${XBMK_RELEASE+x}` isn't unset; it was previously grepping
the output of `set`, which led to a bug report by a user who had the
variable `TMUX_TMPDIR` set, whereas `TMPDIR` was unset and lbmk was checking
the latter; in this example, the bug caused lbmk to act as though `TMPDIR`
was set, when it in fact wasn't, and code that used it then crashed because
lbmk does `set -u -e` (and it does this precisely to catch such bugs like the
one you're reading about now so that they can be fixed, like this one was!)
* **Re-configured GRUB so that only the Haswell and Broadwell machines contain
xHCI support**, where it doesn't cause any issues (and is required), while
other mainboards use a version of GRUB that lacks support for xHCI. This is a
mitigations against the bug reported in [lbmk
issue 216](https://codeberg.org/libreboot/lbmk/issues/216). This is done, by
using the new *multi-tree* GRUB handling, which is mentioned above in
in the section (of this audit report) pertaining to *feature changes*, whereby
each mainboard can have its own GRUB revisions and patches, with its own
GRUB configuration file (that could be uniquely optimised for it).
* **Fix vboot build issue when running lbmk in i686 (32-bit) host machines**.
The patch, courtesy of *Luke T. Schumaker*, adapts vboot's vmlinuz extract
function so that it uses pointer logic directly, instead of defining
integers (of type `ssize_t`) which, the way it was written, caused GCC to
believe that there would be a buffer overflow in code; the new code is more
robust and should prevent such an issue. This is both an *acute* bug fix,
fixing a bug that was actually triggered, and a preventative bug fix as the
original code wasn't correct either, even on AMD64 hosts (where it happened
to compile anyway).
* include/vendor.sh: Skip a given blob if the path to it is `/dev/null` - this
fixes a bug exposed by the previous change two bullet points down (fine
grained error control), because VGA ROMs are handled but the KGPE-D16 target
mitigates a crash bug when PIKE2008's option ROM is executed by SeaBIOS, by
inserting fake (empty) option ROMs for it into CBFS, and it does so by
telling coreboot to insert a *VGA option ROM* with the correct PCI device
and vendor ID, pointing (you guess it) to *`/dev/null`*. This makes the
KGPE-D16 target now return (when run through `./vendor download`) with zero
status, instead of error status.
* Do not allow dashes in coreboot target names, to mitigate a bug exposed by
the previous change listed below (regarding fine-grained error control). This
fixes build errors such
as: `include/lib.sh: line 115: kcma-d8-rdimm=config/vendor: No such file or directory`;
dashes were replaced with underscores, on those target names.
* include/vendor.sh: Much more fine-grained error control, when running
the `download` command. Certain parts need sh error handling to be less
strict, so `set +u +e` is used; when it's safe to turn on strict error
handling again, `set -u -e` is used. It used to be that `set +u +e` was the
only behaviour, when running this command. This actually exposed a number
of bugs that were previously hidden.
* include/vendor.sh: Don't exit with error status when running those commands
on a target that has no configs; instead, skip those targets.
* **GRUB: Never run it as a primary payload on any target but QEMU**. This is
a preventative bug fix, after lbmk bug report issue 216:
<https://codeberg.org/libreboot/lbmk/issues/216> - although it was caused by
the xHCI patches, and only happened on Sandybridge hardware, and although
this was later removed on those boards, GRUB is very complex and likely has
a lot of memory corruption issues. SeaBIOS is more reliable, so: Libreboot
only provides *SeaBIOS* as primary payload, but allows you to execute GRUB
from the SeaBIOS menu (the very same GRUB). Additionally: lbmk already
supported a configuration whereby SeaBIOS reads a `bootorder` file in CBFS,
making it try to run the GRUB payload first, while still allowing you to
interrupt by pressing ESC to bring up an alternative boot select menu. This
is now the *default*, on all x86 mainboards. This is a mitigation against
future instability in GRUB because, if such issues happen again, it will not
cause a brick since you can just use SeaBIOS instead, and skip booting to
the GRUB payload (on the affected machines, BIOS GRUB still worked, which
your distro provides and SeaBIOS executes it). *NOTE: GRUB was later made
into a multi-tree project, with certain mainboards using a version that
has the xHCI patches, if required, because the machines that actually need
xHCI support were not affected by the bug referenced in issue 216.*
* Main build script: Check SUID before checking Git name/email, otherwise the
version/versiondate files could be written as root and thus prevent building
of lbmk, which (for most commands) is intentionally engineered to exit (with
error status) if you run it as root.
* script/trees: Reset variable `makeargs` per target, so as to prevent
pollution of this variable when switching from one build target to the next.
* script/trees: Added `UPDATED_SUBMODULES=1` to the make command when running
any coreboot `make` command, to prevent coreboot from automatically fetching
certain Git submodules; this is a preventative fix, fixed before it became
a bug, which it likely would have become at some point as this is exactly
what the coreboot build system does!
* Main build script: hide the output of `git init` when lbmk re-initialises the
Git history, to prevent its output from being wrongly inserted into the
output of commands such as `./build roms list` - such pollution would cause
build errors, so it's important that the Git initialisation function either
doesn't output anything, or that it should cause an *exit* if output is to be
required.
* Added the `CHANGELOG` file to `.gitignore`. This means `./update release`
will now work, on release archives, because lbmk re-initialises Git history
when doing so, but the CHANGELOG file (when present) causes lbmk to skip
all source downloads (which the release builder relies on).
* **Fix garbled output on 1440x900 monitors when using the Dell Latitude E6400.**
The E6400 uses a reference clock (`DPLL_REF_SSCLK`) set to 100MHz, whereas
libgfxinit assumed 96MHz. This timing descrepancy did not cause an issue on
lower resolution displays, so we never caught it in earlier testing. Patch
courtesy of Nicholas Chin, who debugged this issue alongside the user who
reported it. It was fixed by making such timing configurable, within the
coreboot build system, setting it to 100MHz on Dell Latitude E6400.
* script/roms: Skip a target when its config directory is missing, so that
running a coreboot target with no configs in it will not yield an error;
instead, it will now cause a non-error return.
* include/option.sh: If `.git` is missing, in a bare copy of lbmk (not a
release archive), recreate the version/versiondate files manually so as to
prevent a build error. Use of `lbmk.git` or the release archives is
recommended, but some users directly download snapshots of `lbmk.git` from
sites such as Codeberg, and there's no way for us to turn off this feature;
even if we did, it may be present on other Git hosting sites, where users
might host their own copy of lbmk.
* include/option.sh: Don't return non-zero status from the function
named `mkrom_tarball`, because certain other functions rely on its return
value to always be *zero*; instead, call `err` which will then yield
an *exit* (with non-zero status). This means that the function will now
always *return* zero, when it returns.
* include/vendor.sh: Print an error message when the target is ill-defined,
for downloading and/or insertion of vendor files.
* include/git.sh: Remove `.git` directories *per-project*, as and when each
project is being downloaded, instead of having it done all in bulk by the
main build script. This kicks in when `XBMK_RELEASE` is set (release builds),
to correct the over-use of disk space during such very large builds processes.
This makes the build system less likely to OOM when running it inside tmpfs.
* Main build script: initialise Git history *before* running any command,
because this is required for reliable use of the coreboot build system, which
the *inject* command makes heavy use of. This reduces the number of errors,
when running these commands from a release archive, where lbmk re-initialises
a new Git history when you run it for the first time.
* Main build script: define `xp` as a global variable, to prevent it from
being lost between functions.
* Fixed missing deletion of strlcat.c in U-Boot sources
* script/roms: Create full release tarball name, when generating releases.
* Main build script: exit (with error status) if not running directly from
the root of the lbmk work directory.
General code cleanup
--------------------
In addition to *general* very sweeping code cleanup, condensing code lines
where possible and so on:
* include/lib.sh: Simplified the `download` function (used for crossgcc tarballs).
* include/lib.sh: Simplified the `singletree` function.
* include/git.sh: Simplified the `link_crossgcc` function.
* include/git.sh: Simplified the `nuke` function, because it was over-engineered
to the extreme. Now it's more reasonable.
* include/lib.sh: Move download logic here from include/vendor.sh, for the
feature where *files* can be downloaded as submodules, within Git repositories.
Please read the notes about this in the *features* section.
* include/lib.sh: Shortened a string in the `e` function, so that the line
does not exceed a length of 80 characters.
* include/git.sh: Unified the handling of git clone/reset/am commands into a
single function, rather than duplicating the same logic across multiple
functions.
* script/trees: simplify the `copy_elf` function; don't create the elf directory,
create one defined by `dest_dir` instead (which is the elf directory with
the subdirectory for that project concatenated). Only create it within
the `copy_elf` function, which is only called if actually compiling the
code. This avoids creating empty directories under elf/, for example under
fault conditions.
* include/git.sh: Additional code cleanup, removing certain code that was in
place because the code used to handle both `git submodule update` and the
custom *override* logic for submodules; now only the override is used, at all
times, so the code was cleaned up and optimised only for this.
* include/git.sh: Reduced code indentation in function `fetch_submodule`.
* include/git.sh: Renamed a few variables for increased code clarity.
* script/trees: Unified handling of coreboot `makeargs`.
* Moved function `handle_coreboot_utils` to script/trees (and renamed it
to `check_coreboot_utils`), as it's only ever used from there.
* Moved variable `cbcfgsdir` to include/vendor.sh, because it's only used there.
* Moved cfgsdir/datadir variables to include/lib.sh, because it's also used
from script/roms and script/trees; unify them under a common location.
* Handle `build.list` from config/data/, not config/ - this avoids needing to
check for `build.list` in the `items` function on include/lib.sh, and it is
now avoided.
* include/lib.sh: More user-friendly output from the `e` function, telling the
user whether or not a file/directory exists. This is regularly used, for
example when trying to download a project and the source code was already
prepared.
* U-Boot on QEMU: removed the (currently) unused x86 target.
* grub.cfg: Split function `try_user_config` into multiple smaller functions.
* grub.cfg: Don't scan ESP on btrfs subvols as the ESP is always on a FAT32
partition. This saves time during the bootup sequence.
* include/vendor.sh: Remove unnecessary assignment; `dl_fail` was being set
to `n` and then immediately to `y`. Now it is simply set to `y`.
* Renamed include/option.sh to include/lib.sh
* Main build script: simplified the logic for Git repository initialisation
by *returning non-zero status*, instead of calling err, and handling this
return status in the calling function.
* Main build script: condensed the logic for Git name/email checking into a
simply for loop running `eval`, rather than having lots of separate but very
similar Git commands.
* script/trees: Removed a few unused variables.
* include/git.sh: Moved logic for copying a Git repository to a new function.
* include/git.sh: Moved function `link_crossgcc` to a different location
within the file, for proper top-down order of logic (required as per the
lbmk coding style).
* include/git.sh: Split logic for crossgcc symlinking into its own function.
* include/git.sh: Skip submodule checks if `.gitmodules` missing (NOTE: later
replaced with custom submodule handling in lbmk).
* include/git.sh: Merged `patch_submodules` in `prep_submodules` (NOTE: ditto
to the same note below).
* include/git.sh: Split up submodule handling into a new function (NOTE: support
for submodules was later replaced with custom logic in lbmk).
* include/git.sh: Shortened a few variable names.
* include/git.sh: Removed redundant check for the existence of the patches
directory, when patching a given project. This is unnecessary, where it was
removed, because the patching function itself also checks this. Reduction
in code size by *one line*.
* include/git.sh: Removed function `fetch_from_upstream` and merged its logic
into calling function `fetch_project_trees`, the only calling function, since
the logic in `fetch_from_upstream` was very small and splitting made no sense.
* include/option.sh: Renamed `mktar_release` to `mkrom_tarball`.
* script/roms: Renamed function `moverom` to `copyrom`, because it runs `cp`,
not `mv`, therefore is is *copying* a file, not moving it.
* script/roms: Simplified the logic for listing available serprog build targets.
* script/roms: General simplification of configuration handling for payloads.
* include/vendor.sh: Removed duplicated (and unnecessary) config check,
because it was already done immediately afterward (I accidentally did the
same check twice, in immediate succession).
* include/vendor.sh: General simplification of defconfig handling logic.
* Main build script: removed the `excmd` function and merged its logic into
the `main` function, and then `main` was cleaned up significantly.
* Main build script: don't make `script_path` a global variable; this allowed
a reduction in code size by precisely *one line of code*.
* Main build script: merged the functionality of function `check_git` into
the `main` function, then deleted function `check_git` (which was in
the file include/option.sh).
* Main build script: general simplification of the logic handling source code
downloads in function `fetch_trees`.
* Main build script: Use `UTC+0000` when initialising git repository commit
dates (for initial commits).
* Removed the `check_project` function, and placed its logic directly
inside `include/option.sh` so that it automatically runs in every script
that sources it.
* Main build script: General cleanup on the code handling file deletions
under function `fetch_trees`.
* Main build script: delete function `mkversion` and, in its calling function,
simply print the string contained in variable `relname`.
* Main build script: general cleanup on the logic that handles tarballs.
* Main build script: Remove `mkrom_images`, and move its logic into the only
calling function within that same file.
* include/option.sh: Removed the function `insert_version_files` and merged
its logic into its only calling function.
* Unified all logic for handling SHA512 checksums, placing it inside
include/option.sh for use elsewhere.
* Move image tarball generation to script/roms (formerly script/build/roms).
* Removed redundant function `extract_ref` from include/mrc.sh
* Removed an errant comment from include/git.sh
* Switched to a one-level directory structure for main scripts, rather than
two-level; for example, script/build/roms is now script/roms
* Merged scripts under script/vendor/ into include/vendor.sh and stub it
from the main build script
* Merged script/update/release into the main build script
* Merged script/build/serprog into script/build/roms
* script/build/roms: remove unnecessary command (errant return)
* Merged include/err.sh with include/option.sh, into include/option.sh
* script/build/roms: fixed improper use of variable outside a function
* build/build/roms: more reliable exit status in `skip_board()`
* script/build/roms: split up `main()` into multiple smaller functions
Revision updates
================
Some revisions were updated as part of standard routine, but happened to be
done during this audit. Those updates are as follows:
SeaBIOS
-------
Bump SeaBIOS to revision `e5f2e4c69643bc3cd385306a9e5d29e11578148c`, which has
these changes relative to the old one:
```
* e5f2e4c6 pciinit: don't misalign large BARs
* 731c88d5 stdvgaio: Only read/write one color palette entry at a time
* c5a361c0 stdvga: Add stdvga_set_vertical_size() helper function
* 22c91412 stdvga: Rename stdvga_get_vde() to stdvga_get_vertical_size()
* 549463db stdvga: Rename stdvga_set_scan_lines() to stdvga_set_character_height()
* c67914ac stdvga: Rename stdvga_set_text_block_specifier() to stdvga_set_font_location()
* aa94925d stdvga: Rework stdvga palette index paging interface functions
* 8de51a5a stdvga: Rename stdvga_toggle_intensity() to stdvga_set_palette_blinking()
* 96c7781f stdvga: Add comments to interface functions in stdvga.c
* 2996819f stdvga: Rename CGA palette functions
* 91368088 stdvgamodes: Improve naming of dac palette tables
* 70f43981 stdvgamodes: No need to store pelmask in vga_modes[]
* 1588fd14 vgasrc: Rename vgahw_get_linesize() to vgahw_minimum_linelength()
* d73e18bb vgasrc: Use curmode_g instead of vmode_g when mode is the current video mode
* 192e23b7 vbe: implement function 09h (get/set palette data)
* 3722c21d vgasrc: round up save/restore size
* 5d87ff25 vbe: Add VBE 2.0+ OemData field to struct vbe_info
* 163fd9f0 fix smbios blob length overflow
* 82faf1d5 Add LBA 64bit support for reads beyond 2TB.
* 3f082f38 Add AHCI Power ON + ICC_ACTIVE into port setup code
* 3ae88886 esp-scsi: terminate DMA transfer when ESP data transfer completes
* a6ed6b70 limit address space used for pci devices.
```
Flashprog
---------
Updated to revision 5b4fdd1 from 2 May 2024, rebasing the MX workaround patch.
This imports upstream changes, relative to the previous revision:
```
* 5b4fdd1 z60_flashprog.rules: Add udev rule for CH347
* 72c9e40 meson: Check for CPU families with known raw mem access
* 3458220 platform/meson: Port pciutils/pci.h workaround to Meson
* f279762 platform/meson: Check for libi386 on NetBSD
* 14da5f7 README: Convert to Markdown
* 8ddea57 README: Document branching and release policy
* 2522456 util/list_yet_unsupported_chips.sh: Fix path
* cbf9c11 spi: Don't cross 16MiB boundaries with long writes
* 823a704 dediprog: Skip warning on first attempt to read device string
* e8463c8 dediprog: Revise prefix check for given programmer id
* 38af1a1 dediprog: Revise id matching
* 4661e7c amd_spi100: Use flashprog_read_chunked() for progress reporting
* cdcfda2 read_memmapped: Use flashprog_read_chunked() for progress reporting
* 7679b5c spi25: Replace spi_read_chunked() with more abstract version
* ca1c7fd spi25: Normalize parameters of spi_nbyte_read()
* e36e3dc dediprog: Use default_spi_write_256
* 522a86d linux_spi: Use default_spi_read()/_write_256()
* 806509b cli_classic: Turn progress reporting into a progress bar
* 842d678 libflashrom: Return progress state to the library user
* aa714dd flashprog.c: Let select_erase_functions() return byte count
* 2eed4cf serprog: Add SPI Mode and CS Mode commands
* 821a085 dediprog: Implement id reading for SF600 and later
* 274e655 dediprog: Read device string early
* 0057822 dediprog: Add protocol detection for SF700 & SF600Plus-G2
* fb176d2 dediprog: Use more general 4BA write mode for newer protocols
* 0ab5c3d dediprog: Split device type and version parsing
* bdef5c2 dediprog: Use unsigned conversions to parse device string
* 5262e29 dediprog: Try to request 32B device string (instead of 16B)
* e76e21f dediprog: Get rid of some unnecessary hex constants
* 5a09d1e udelay: Lower the sleep vs delay threshold
* 03ad4a4 linux_mtd: Provide no-op delay implementation
* 211c6ec serprog: Refine flushing before synchronization
* 383b7fe serprog: Test synchronicity before trying to synchronize
* d7318ea serprog: Move synchronicity test into separate function
* 9a11cbf Let the flash context directly point to the used master
* aabb3e0 writeprotect: Hook wp functions into the chip driver
* 89569d6 memory_mapped: Reduce `decode_sizes` to a single `max_rom_decode`
* 929d2e1 internal: Pass programmer context down into chipset enables
* 7c717c3 internal: Pass programmer context down into board enables
* e3a2688 Pass programmer context to programmer->init()
* 2b66ad9 Start implementing struct flashprog_programmer
* 4517e92 memory_bus: Drop stale `size == 0` workaround and FIXME
* b197402 memory_bus: Split register mapping into own function
* 0e76d99 memory_bus: Move (un)map_flash_region into par master
* 9eec407 Perform default mapping only for respective chips
* 56b53dd wbsio_spi: Request memory mapping locally
* 5596190 it87spi: Request memory mapping locally
* 46449b4 spi25: Drop stale `bus == SPI` guards
* ab6b18f spi25: Move 4BA preparations into spi_prepare_4ba() hook
* 901fb95 Add prepare/finish_access() hooks for chip drivers
* a96aaa3 dediprog: Support long writes of 16MiB and more
* 1338936 Consider 4BA support when filtering erase functions
* 8d36db6 flashprog.8: Fix up serprog example
* d2ac303 flashprog.8: document new serprog cs parameter
* d1b9153 chipset_enable.c: Add Genoa to mendocino entry
```
As a reminder:
Libreboot now uses Flashprog instead of Flashrom; Flashprog is a fork of
Flashrom, lead by Nico Huber after a dispute with the new leadership of
Flashrom, and it was felt that Flashprog is a better choice for Libreboot.
Git log
=======
This entire set of changelogs is based on the precise Git history in lbmk,
relative to Libreboot 20240504 which is from where the audit began.
The latest changes are listed first, going all the way down to earlier changes:
```
* 2ee186ae minor code cleanup in the build system
* c5441bb9 re-add ability to use cbfs grub.cfg as default
* d33556c6 trees: exit with error if project undefined
* 1799a336 build: also make a lock file during release build
* 78426a97 lib.sh: more useful lock message
* e80c4b73 create a lock file during builds
* a0710ef9 git.sh: hide e() output on for loop
* 86eb566b lib.sh: fix regression
* fbcdf33f git.sh: download xtree *before*, not after
* 6a3d8a96 git.sh: fix deletion path in nuke()
* 3478b288 lib.sh: less confusing error in download()
* f3f5b99c lib.sh: hide stderr on download()
* 3440e1f6 lib.sh: simplify download()
* 75b39dbe lib.sh: fix redundancy in download()
* 26df6e7a lib.sh: simplify singletree()
* 9cdf4192 git.sh: further simplify nuke()
* 1cede024 git.sh: simplify link_crossgcc()
* 77e482aa git.sh: simplify nuke()
* 42e97950 Merge pull request 'Add dependency scripts for Fedora 40 and Ubuntu 24.04' (#220) from fuel-pcbox/lbmk:master into master
|\
| * 046007b4 Add dependency scripts for Fedora 40 and Ubuntu 24.04
* | a0eb79df add crossgcc tarballs to config/submodules/
* | b0d1ad32 git.sh: support downloading *files* as submodules
* | 1a44fcfa git.sh: remove unnecessary line break
* | 74ae84af vendor.sh: add a return at the end of mkdirs
* | c202dc61 vendor.sh: move download logic to lib.sh
* | 08d0a1d5 lib.sh: shorten a string in e()
* | 9b00b30a move uefiextract to elf/uefitool/
|/
* 05d301bd git.sh: fix submodule path
* 7e15859b git.sh: simplify prep_submodules()
* acd3608b git.sh: unified handling of git clone/reset/am
* 668bcbf6 trees: simplified copy_elf() handling
* 3eef7f37 git.sh: simplify submodule handling
* 4b1b1f50 git.sh: provide feedback for repository downloads
* d4324768 git.sh: download "depend" projects *before*
* a4549e93 git.sh: reduced indentation in fetch_submodule
* 11c47ba7 git.sh: reduced indentation in prep_submodules
* 9c1ea8f9 git.sh: *never* run git submodule update
* 137321eb lib.sh: rename variable for clarity
* 7bfb1d62 trees: don't check empty path in copy_elf()
* 0b7566cb trees: fix build issue caused by bad elf check
* 7aa9f224 trees: fix listfile check in copy_elf()
* 06c78e13 trees: don't say check elf/ if build.list missing
* dea41f13 trees: don't do elfcheck if build.list missing
* 3bd562a2 define mdfiles/images in config/submodules/docs/
* bff75628 libopencm3 to config/submodules/ on stm32-vserprog
* d9b9f6db add tinyusb to config/submodule/ for pico-sdk
* 099ee3f4 config/git: use "depend" for serprog dependencies
* d0f99c2f trees: unified coreboot makeargs
* a7889c5a trees: use multiple threads to build cbutils
* d41658f1 move handle_coreboot_utils to script/trees
* c0822ac4 put coreboot utils in elf/, not cbutils/
* d1ba0851 fix build issue building coreboot utils
* 7e49fe4b trees: skip single-tree build if a build exists
* 12774274 use correct memtest86plus path in script/roms
* 8511615e put memtest86plus builds in elf/memtest86plus/
* 176b936d put flashprog builds in elf/flashprog/
* 48cbb30d trees: also print "DONE! check elf/dir" on single
* 315fed5f trees: handle build-test on multi-tree projects
* b8112af9 git.sh: use singletree() to decide submodules
* 78f7e429 move cbcfgsdir variable to vendor.sh
* 810ad480 move cfgsdir/datadir variables to lib.sh
* ba36f26d handle build.list from config/data/, not config/
* bea089bb don't use build.list to detect multi-tree projects
* 6e1b8087 move id check to lib.sh too
* 62c25ac7 move root check to lib.sh (bugfix)
* 75382a41 bugfix: move dependencies handling to lib.sh
* c6aff769 bump untitled revision again
* 414a605a bump untitled revision in git config
* 7d562679 lib.sh bugfix: check environmental variables right
* 53dd4bc4 lib.sh: more friendly output from e()
* c2793e7a badcmd: don't print "no context given"
* 49ae4f91 badcmd: link directly to the maintenance manual
* 00653aab better help text on invalid commands
* afac9a06 build: print the project website address on help
* 1e534e7d add projectsite file: point to libreboot.org
* 429e91f9 make GRUB multi-tree and re-add xhci patches
* 9daf7f05 u-boot on qemu: remove currently unused x86 target
* 6d59f1d0 grub.cfg: scan /boot/grub.cfg last
* 2becc736 grub.cfg: scan grub2/ last
* cfc5265f grub.cfg: search a reduced list of devs/partitions
* 42b5b58d grub.cfg: scan grub.cfg from ESP
* b3d58f1e grub.cfg: split up try_user_config
* 2ea5e61c grub.cfg: don't search for *_grub.cfg
* c742a89d grub.cfg: remove unnecessary path for isolinux
* e0b2216f grub.cfg: don't scan EFI on btrfs subvols
* 38135f9e Merge pull request 'Fix building vboot on i686' (#218) from lukeshu/lbmk:lukeshu/i686 into master
|\
| * 221206b4 Fix building vboot on i686
* | a76dda93 vendor.sh: remove unnecessary assignment
* | 17a9d11d git.sh: do not remove .submodules
* | 13d4b6d3 delete u-boot test/lib/strlcat.c using nuke()
* | f6cbc501 import nuke() from cbmk cdce8ba70b
|/
* 7fbcb7be coreboot t440p/w541: enable nvme in grub_scan_disk
* 47f582d4 ./vendor download: skip if blob path is /dev/null
* e7cb10d6 do not allow dashes in coreboot target names
* e9b9e825 ./vendor download: more fine-tuned error control
* 0dd0dfaf vendor.sh: don't error on main targets
* a4bd49de roms: allow user override of grub_scan_disk
* b00800a7 grub.cfg: actually support setting boot order
* 4488745c trees: use CPUS=x on regular coreboot make
* 7d50e09f update gitignore
* b78f62c7 roms: fix bad eval when comparing options
* b11e4c9f grub.cfg: add spdx header
* 3998a3ba re-configure grub_scan_disk on various targets
* 1c4d6498 remove grub_scan_disk in all target.cfg files
* e1883f1d grub.cfg: use grub_scan_disk to set boot order
* c94cecd8 GRUB: remove XHCI patches for now (will re-add)
* ff2997d6 minor correction
* d855408a roms: make grubfirst if seabios_withgrub=y
* ec761c88 coreboot: only run GRUB as a secondary payload
* 64c64bcf flashprog: bump to 5b4fdd1 from 2 May 2024
* 914852dd rename include/option.sh to include/lib.sh
* dc7b72f3 roms: rename bstr variable
* 5c14e8e1 general code cleanup in the build system
* 48c2cef8 build: simplify git_init()
* db06bbdb build: do root check before git check
* 8d199a31 build: simplify git checks
* 8da2559b option.sh: fix bad check for version/versiondate
* d32968c7 trees: reset makeargs per target/project
* 7bab0cf9 trees: also use UPDATED_SUBMODULES=1 on crossgcc
* 0a50eaf2 trees: add UPDATED_SUBMODULES to coreboot make
* ff0840bd trees: write -C on the make command first not last
* b91ee727 config: add backup coreboot submodule repositories
* 4a3ebe84 coreboot/default: remove chromeec from module.list
* 9c5890e9 git.sh: break if a submodule clone succeeds
* fdb08143 coreboot: only download the necessary submodules
* 1cb255e8 git.sh: allow finer control of git submodules
* 5d87eea7 build: hide git-init output
* b8ec7d56 option.sh: generate version file if .git not found
* 87c361f3 update/trees: remove unused variable
* da427272 git.sh: move repo copying to a new function
* 093c4a36 git.sh: move link_crossgcc to end of file
* 73a2d991 git.sh: move xgcc linking to a new function
* d7749876 git.sh: skip submodules if .gitmodules missing
* c3e1aa34 git.sh: merge patch_submodules in prep_submodules
* a4163330 git.sh: split submodule handling to new function
* aa4faf08 git.sh: remove errant line break
* 00142696 git.sh: remove another meaningless check
* fc3b0ba8 git.sh: shorter variable names
* dae10dd4 git.sh: remove meaningless check
* c148fa53 git.sh: remove variable not meaningfully used
* 079afb5b add CHANGELOG to .gitignore
* 0d8781ef Merge pull request 'Fix E6400 display reference clock patches' (#214) from nic3-14159/lbmk:fix-e6400-igpu-ref-clock into master
|\
| * 9f50e362 Fix E6400 display reference clock patches
|/
* e5a5935d fix building coreboot images on i686 hosts
* a2ac4d13 Merge pull request 'Also try unlocking encrypted volume on NVMe' (#213) from mkukri/lbmk:master into master
|\
| * 77ebd050 Also try unlocking encrypted volume on NVMe
* | 287d0555 Merge pull request 'Add NVMe support to GRUB2 payload' (#212) from mkukri/lbmk:master into master
|\|
| * abe6717c Add NVMe support to GRUB2 payload
* | 47d77c94 Merge pull request 'Fix E6400 display issue with 1440 x 900 panel' (#211) from nic3-14159/lbmk:fix-e6400-igpu-ref-clock into master
|\ \
| * | 8629873a Fix E6400 display issue with 1440 x 900 panel
| |/
* | 0beecd1b Merge pull request 'Add pt qwerty keymap to lbmk' (#210) from samuraikid/lbmk:master into master
|\ \
| * | 8d723d14 Add pt qwerty keymap to lbmk
* | | 835e5ad0 git.sh: fix invalid command in git_prep()
| |/
|/|
* | 1e54db29 git.sh: allow patching submodules
* | 00e00a18 git.sh: don't delete .git if src/project/project
* | 245b4eb2 build/roms: skip target if config/ dir missing
* | aadccc59 more minor cleanup in the build system
* | 5b8928c7 git.sh: remove fetch_from_upstream()
* | 71baf653 option.sh: don't return 1 in mkrom_tarball
* | 1fe9c4b8 option.sh: mktar_release to mkrom_tarball
* | cc7ed692 build/roms: rename moverom to copyrom
* | b40118ae minor code cleanup in the build system
|/
* 998f30ad build/roms: simplify serprog list command
* 21a7efaa build/roms: simplified config payload checks
* 5b5dccd6 vendor.sh: further simplify config handling
* 8418ea9a vendor.sh: greatly simplified config handling
* 53b394f5 vendor.sh: move config checks to detect_firmware
* bb7255c3 vendor.sh: print an error upon ill-defined target
* 3f73f3d0 vendor.sh: remove redundant check
* 32923f56 vendor.sh: simplify defconfig check
* f8e3ca3b git.sh: Remove .git if XBMK_RELEASE=y
* dd851caa build: remove initcmd() and simplify main()
* 4ea843a4 build: initialise git first (before commands)
* 5702f5a4 build: remove excmd() and simplify main()
* b76a70c3 build: don't make script_path a global variable
* 839ef680 lbmk: allow easier sync with cbmk
* 885fcebd remove help commands (user should read docs)
* c6ba0a0e option.sh: delete check_git()
* 313c4c01 build: define "xp" in the global variables
* 350857ff build: simplify for loop in fetch_trees()
* 8e05399d build: simplified downloads in fetch_trees()
* 914ff1ad ./build release: don't do u-boot-only archives
* 5c3fb9a4 build: use utc+0 when initialising git repo dates
* e281966f remove check_project() (always set variables)
* ee2bf0d2 build: simplify deletions in fetch_trees()
* 39df6230 build: delete mkversion() (just print relname)
* a40a6129 build/roms: clean up tarball handling
* e5ffb2af rm src/u-boot/*/test/lib/strlcat.c in u-boot
* c149cbb8 build: remove mkrom_images
* 4135ce5e build: use same tarball name on uboot-only release
* 189b70dd build/roms: create full release tarball name
* 36d45474 option.sh: don't bother checking for GNU tar
* f0b604fc option.sh: remove insert_version_files()
* 267c13cc cleanup: remove mkvdir
* 08c9f94a unified sha512sum creation for tarballs
* 1ce7e339 move rom tarball creation to script/roms
* 190495d2 disable x301 for next release (for now)
* 03fae0cf mrc.sh: remove redundant function extract_ref()
* f66ceef6 print two line breaks before confirming release
* cc339741 remove haswell mrc blob (libre raminit stable now)
* 05fbd392 remove all status checks. only handle release.
* 8ba0fd83 git.sh: remove errant comment
* d7ce26dc move script/*/* to script/
* 029291e5 merge script/vendor/* into include/vendor.sh
* c8fb24bb build: print usage for special commands
* 5f63b594 merge script/update/release into build
* e1ea5dd0 bump seabios to e5f2e4c69643bc3cd385306a9e5d29e11578148c
* 052414c0 build: further prevent non-lbmk-work-directory
* fb8d0c86 build: exit if not running from lbmk directory
* 38aaaecf build/roms: print serprog help
* e3cb3a40 merge script/build/serprog with script/build/roms
* 297af7e6 build/roms: remove unnecessary command
* 5e4009b5 merge include/err.sh with include/option.sh
* 58400fc4 err.sh: correct copyright info
* aa5937ed build/roms: don't rely on x in handle_target
* 580a5559 build/roms: don't use exit status from skip_board
* 2fcbff68 build/roms: split up main()
* d13d9308 build/roms: allow searching status by mismatch
```
This is 211 changes, since Libreboot 20240504.

362
site/news/policy.de.md
View File

@ -176,3 +176,365 @@ 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/>

388
site/news/policy.md
View File

@ -2,6 +2,22 @@
% 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
============
@ -168,3 +184,375 @@ 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/>

360
site/news/policy.uk.md
View File

@ -170,3 +170,363 @@ 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/>

8
site/news/safety.md
View File

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

8
site/news/update202308.md
View File

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

579
site/tasks/index.md
View File

@ -21,6 +21,33 @@ how to submit patches, and it describes the Libreboot project infrastructure.
You may also benefit from *assimilating* all knowledge contained in
the *[lbmk maintenance manual](../docs/maintain/).*
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
================================
@ -46,7 +73,41 @@ TF-A is quite an interesting project:
It is essentially an analog of coreboot; coreboot even uses parts of this, on
some boards.
general auditing
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
================
Libreboot's build system design is already extremely efficient. See:
@ -108,6 +169,24 @@ 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
------
@ -116,9 +195,11 @@ Boards
* HP Revolve 810 G1
* HP EliteBook Folio 9480m
* HP EliteBook 8770w
* HP EliteBook 820 G2
* HP EliteBook 840 G2 (not in coreboot yet, but should be similar to 820 G2)
* HP Z220 CMI and SFF mainboards
* Dell OptiPlex 7010 and 9010
* Dell OptiPlex 7020 and 9020
* MSI PRO Z690-A mainboard (supported by Dasharo, not sure about coreboot) -
also, Dasharo supports several more mainboards that aren't in coreboot
proper.
@ -141,6 +222,18 @@ 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)
-------------------------
@ -183,7 +276,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.
easily flashable, and blob-free configs (Canoeboot could also support them).
Broadwell Dell
--------------
@ -342,6 +435,9 @@ 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
@ -604,6 +700,36 @@ 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
======================
@ -765,6 +891,63 @@ specs for it, are provided for in the above linked issue page.
Several more high-end HP EliteBook machines use MXM graphics modules,
e.g. HP EliteBook 8560w.
MXM works! TODO: merge
----------------------
Riku got it working. See:
* SeaBIOS patch 1: <https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/ZHVOSUEYILGFNBKWOFNSDQ7PGCADSMU4/>
* SeaBIOS patch 2: <https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/LK2ZHY6BSKRBUCZ5LMND5IBW3HGLZTMV/>
* mxmdump util: <https://codeberg.org/Riku_V/mxmdump/>
* int tool: <https://codeberg.org/Riku_V/int>
the "int" tool can be used to determine what mxm spec you have, and the mxmdump
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)
John lane GRUB patches
======================
The GRUB project itself has started merging some of this functionality, for
things like detached LUKS headers. We had these for GRUB in Libreboot 2016
releases, but they were since removed.
Current functionality works on most setups, and we merge [Argon2
KDF support](../news/argon2.md) into GRUB, out-of-tree.
See: <https://grub.johnlane.ie/>
Interesting, the Arch Linux AUR has several of these patches for its
GRUB 2.06 package. See:
<https://aur.archlinux.org/packages/grub-luks-keyfile>
These could be re-based for GRUB 2.12, which is what Libreboot uses.
Already merged
--------------
GRUB 2.12 has these patches already, so we don't need to do anything. The
above pertains to GRUB 2.06, but they were upstreamed for 2.12. That being
said, we do have some users who like 2.06 for some reason!
Document how to use
-------------------
John lane's site even has instructions for how to use detached LUKS headers
in GRUB.
Maybe we could do something for it in automation too. When scanning for
grub.cfg files, at the stage where cryptomount -a is executed, we could
also check for LUKS header files and handle them if found. Yes, we could make
the default Libreboot setup work out of the box, with detached LUKS headers.
We already have this functionality, as described above, but we need to
configure it. Read John Lane's site for more information, and the upstream
GRUB documentation will also cover it.
lbmk-c: clustered builds
========================
@ -1009,6 +1192,133 @@ some boards, though it's seldom-used and not very universally supported.
It might be useful on some machines. The research here (by Angel Pons) may be
transferrable to other platforms.
Better dependencies handling
============================
Lbmk supports handling dependencies, in such a way that a required program is
automatically downloaded *after* the main one. For example, GRUB requires gnulib.
The problem is that it doesn't work in reverse. For example, when you download
gnulib, it's actually saved under `src/grub/gnulib`, and `src/grub/` is the
directory created when downloading GRUB.
Illustration:
```
./update trees -f gnulib
./update trees -f grub
```
This will first download gnulib, but then `src/grub` now exists, and the second
command to download GRUB will fail, because that directory now exists, but does
not have anything in it. Some checks for GRUB may then pass, thinking that
GRUB has already been downloaded, when it hasn't.
Observe:
```
no u lbmk$ git clone . test
Cloning into 'test'...
cdone.
dno u lbmk$ c dtest
bash: c: command not found
no u lbmk$ l^C
no u lbmk$ cd test
no u test$ ls
build COPYING projectname script util
config include README.md update vendor
no u test$ ./update trees -f gnulib
Cloning into '/home/leah/Project/lbdev/lbmk/test/tmp/gitclone'...
remote: Counting objects: 281482, done.
remote: Compressing objects: 100% (33030/33030), done.
remote: Total 281482 (delta 248520), reused 281273 (delta 248367)
Receiving objects: 100% (281482/281482), 69.48 MiB | 7.98 MiB/s, done.
Resolving deltas: 100% (248520/248520), done.
HEAD is now at 9f48fb992a filevercmp: fix several unexpected results
no u test$ ./update trees -f grub
src/grub already exists, so skipping download
src/grub/gnulib already exists, so skipping download
```
In this case, GRUB will now *always* fail to download, until the `src/grub`
directory is deleted, which would delete gnulib.
The following could be done:
* Check whether a given location for a download is within a location used by
another project, and refuse to do anything if that's the case (exit with error)
OR:
* Automatically download that other program first
It's probably cleaner to go with the first one. Prevent a program downloaded by
lbmk from being included within another. If another such program is needed
inside another, for example as a submodule, then the program could be modified.
For example, modify GRUB to use the location of `../gnulib` as the directory
for gnulib, where you would then have `src/grub` and `src/gnulib` - this can
already be done, simply by configuring everything in `config/git/`, but lbmk
currently does not check this.
For comparison, here's what happens if you download GRUB (which defines gnulib
as a dependency):
```
no u test$ rm -Rf src/grub
no u test$ ./update trees -f grub
Cloning into '/home/leah/Project/lbdev/lbmk/test/tmp/gitclone'...
remote: Counting objects: 101717, done.
remote: Compressing objects: 100% (23307/23307), done.
remote: Total 101717 (delta 76079), reused 101552 (delta 75971)
Receiving objects: 100% (101717/101717), 71.90 MiB | 12.85 MiB/s, done.
Resolving deltas: 100% (76079/76079), done.
HEAD is now at 64e3cee72 gpt: Add compile time asserts for guid and gpt_partentry sizes
Applying: mitigate grub's missing characters for borders/arrow characters
Applying: say the name libreboot, in the grub menu
Applying: Add CC0 license
Applying: Define GRUB_UINT32_MAX
Applying: Add Argon2 algorithm
Applying: Error on missing Argon2id parameters
Applying: Compile with Argon2id support
Applying: Make grub-install work with Argon2
Applying: at_keyboard coreboot: force scancodes2+translate
Applying: keylayouts: don't print "Unknown key" message
Applying: don't print missing prefix errors on the screen
Applying: don't print error if module not found
Applying: don't print empty error messages
Cloning into '/home/leah/Project/lbdev/lbmk/test/tmp/gitclone'...
remote: Counting objects: 281482, done.
remote: Compressing objects: 100% (33030/33030), done.
remote: Total 281482 (delta 248520), reused 281273 (delta 248367)
Receiving objects: 100% (281482/281482), 69.48 MiB | 9.55 MiB/s, done.
Resolving deltas: 100% (248520/248520), done.
HEAD is now at 9f48fb992a filevercmp: fix several unexpected results
no u test$ ls src/grub
acinclude.m4 BUGS docs INSTALL po TODO
asm-tests conf geninit.sh linguas.sh README unicode
AUTHORS config.h.in gentpl.py MAINTAINERS SECURITY util
autogen.sh configure.ac gnulib Makefile.am tests
bootstrap COPYING grub-core Makefile.util.def THANKS
bootstrap.conf coreboot.cfg include NEWS themes
no u test$ ls src/grub/gnulib
build-aux COPYING gnulib-tool.py.TODO posix-modules
cfg.mk DEPENDENCIES lib pygnulib
ChangeLog doc m4 README
check-AC_LIBOBJ etc Makefile STATUS-libposix
check-copyright examples modules tests
check-module gnulib-tool MODULES.html.sh top
config gnulib-tool.py NEWS users.txt
```
A more general audit is in order, overhauling the entire dependencies
infrastracture, within lbmk. A lot of the sanity checking is done manually, just
by configuring everything sensibly and knowing what pitfalls to avoid.
Libreboot is essentially no different to apt-get, in so far an lbmk is
concerned. The *apk* package manager in Alpine Linux is the closest to lbmk
mentality; their package manager is highly advanced, but written with a very
minimalist and efficient design. Libreboot's handling of packages and
dependencies could be re-modelled
using [apk-tools](https://git.alpinelinux.org/apk-tools/) as inspiration.
Detect module changes
=====================
@ -1037,6 +1347,27 @@ 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
===============================
@ -1047,6 +1378,22 @@ 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
=================================
@ -1127,6 +1474,41 @@ way to ensure that they were correctly extracted, though it could default back
to current behaviour (only check the main file) if individual checksums for
inside files are not defined.
Handle submodules manually
==========================
Lbmk automatically downloads git submodules (all of them) on a given downloaded
repository, when a `.gitmodules` file is present. This functionality should
be *retained*, but submodules are also not to be relied upon for redundancy.
In some cases, especially critical projects like coreboot, these submodules
should be defined by lbmk `config/git/` files instead, with redundant
repositories, and the host projects (e.g. coreboot) modified to use these,
instead of gitmodules.
Git's own submodules logic doesn't handle redundancy really well and it's not
very fault tolerant either. Libreboot's lbmk, while less featureful, is
designed for redundancy.
What if someone is compiling a given revision of lbmk in 10 years from now?
Some of those repository links might have died, or those projects might have
experienced a hostile takeover and been overwritten. Anything can happen.
If there are backup repository links already baked into lbmk configs, it offers
some redundancy in the future.
It also offers some redundancy now, in the present, if a given git server goes
offline for a break period of time. Libreboot's design is quite simple, and done
with this philosophy in mind, that everything should always have a backup.
Auto-update repositories
------------------------
Already written elsewhere on this TODO page is to automatically decide which
repositories need updating, when running any part of lbmk. This is thought of
with the same mentality in mind, always thinking about what someone will be
running in the future. You can't predict what will happen, so you have to be
prepared. Users are unpredictable.
Reproducible builds
===================
@ -1411,6 +1793,14 @@ reducing the amount of deltas that need to be resolved when cloning).
In particular, Git Work Trees are a useful feature that we might use in lbmk.
Scan submodules for backups
---------------------------
Where a project does use submodules, it's possible that we may already define
how to download it, with redundant links. We could scan for this, by parsing
the `.gitmodules` file within a project and comparing to what we have
under `config/git/`.
Chinese users can't run lbmk
==========================
@ -1468,6 +1858,13 @@ 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
================================
@ -1743,6 +2140,28 @@ 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)
=========================
@ -1773,6 +2192,40 @@ 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
=============
@ -1791,6 +2244,38 @@ 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
=================
GRUB doesn't support nvme on bare metal.
SeaBIOS does.
Libreboot is getting a lot of new ports, and some of them can use nvme
drives. We need nvme support in GRUB.
TODO: adapt SeaBIOS nvme code for GRUB. Also submit upstream.
GRUB can do nvme but only if it's supported by the (UEFI) vendor firmware.
4th SSD on T440p
================
@ -1824,6 +2309,20 @@ 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)
=============================
@ -1897,10 +2396,6 @@ 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
====================
@ -1913,71 +2408,13 @@ unpatched as of yet, in microcode updates.
Links.
interesting video
=================
Fork autoport to util/
======================
<https://www.youtube.com/watch?v=5qauRh7eTNY>
TODO: transfer written notes here
Automate testing
================
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.
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/>
DELL 7th gen
============
3050 micro is being worked on.
3050 sff and mt are TODO
5050 models also.
Dell 3020
=========
another haswell. different to 9020, but could be added.
Port it to skylake and above.

8
site/who.uk.md
View File

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