site/docs/build/index.uk.md

@@ -0,0 +1,301 @@
+---
+title: Побудова з джерельного коду
+x-toc-enable: true
+...
+
+Система побудови libreboot, називається `lbmk`, скорочення від `Libreboot Make`, і цей
+документ описує те, як використовувати її. З цим керівництвом ви можете узнати те, як побудувати
+libreboot з доступного джерельного коду.
+Ця версія, якщо розміщена наживо на libreboot.org, передбачає, що ви використовуєте
+сховище git `lbmk`, яке
+ви можете завантажити, використовуючи інструкції на [сторінці огляду коду page](../../git.uk.md).
+
+Якщо ви використовуєте архів випуску libreboot, будь ласка, зверніться до
+документації, включеної до *того* випуску. Випуски libreboot розраховані тільки,
+як *знімки*, не для розробки. Для належної розробки ви маєте завжди
+працювати безпосередньо в сховищі git libreboot.
+
+Наступний документ описує те, як працює `lbmk`, і як ви можете робити зміни
+до нього: [керівництво обслуговування libreboot](../maintain/)
+
+Git
+===
+
+Система побудови Libreboot використовує Git, обширно. Ви маєте виконати кроки
+знизу, *навіть, якщо ви використовуєте архів випуску*.
+
+Перед тим, як вам використовувати систему побудови, будь ласка, знайте: система побудови, сама по собі,
+використовує Git обширно, коли завантажує програмне забезпечення, таке як coreboot, та проводить застосування виправлень.
+
+Ви маєте переконатись в тому, щоб ініціалізувати ваш Git належним чином, перед тим, як почати, або інакше
+система побудови не буде працювати належно. Зробіть це:
+
+	git config --global user.name "John Doe"
+	git config --global user.email johndoe@example.com
+
+Змініть ім'я та адресу електронної пошти на будь-яку, що забажаєте, коли робите це.
+
+Ви також можете захотіти прослідувати більшій кількості етапів тут:
+<https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup>
+
+Python
+======
+
+Python2 не використовується lbmk або будь-чим, що завантажується в якості модулів. Ви
+маєте переконатись, що команда `python` виконує python 3 на вашій системі.
+
+GNU Make
+========
+
+libreboot Make включає файл, який названо `Makefile`. Ви досі можете
+використовувати систему побудови `lbmk` безпосередньо, або ви можете використовувати GNU Make. `Makefile`
+просто виконує команди `lbmk`. Однак, використання `lbmk` безпосередньо запропонує вам
+набагато більше гнучкості; наприклад, Makefile наразі не можу побудувати один
+образ ROM (він лише будує всі з них, для всіх плат).
+
+Ви мусите переконатись, що всі залежності побудови встановлено. Якщо ви використовуєте
+Ubuntu або подібний дистрибутив (Debian, Trisquel і тому подібні), можете виконати це:
+
+	sudo make install-dependencies-ubuntu
+
+Існує конкретно для Debian:
+
+	sudo make install-dependencies-debian
+
+Інша існує для Arch:
+
+	sudo make install-dependencies-arch
+
+Тепер, просто побудуйте образи coreboot подібним чином:
+
+	make
+
+Ця єдина команда побудує образи ROM для *кожної* плати, інтегрованої до
+libreboot. Якщо ви тільки хочете побудувати обмежену вибірку, можете використовувати `lbmk` безпосередньо:
+
+	./build boot roms x200_8mb
+
+Ви можете вказати більше одного аргумента:
+
+	./build boot roms x200_8mb x60
+
+Образи ROM з'явяться під щойно створеною директорією `bin/` в системі побудови.
+
+Для інших команд просто прочитайте `Makefile` в своєму улюбленому текстовому редакторі.
+`Makefile` є простим, тому що він виконує виключно команди `lbmk`, таким чином дуже
+просто знати те, які команди є в доступності, просто читаючи його.
+
+Стандартна команда `clean` доступна (чистить всі модулі, окрім `crossgcc`):
+
+	make clean
+
+Щоб почистити ваші побудови `crossgcc`:
+
+	make crossgcc-clean
+
+Для побудови архівів випуску:
+
+	make release
+
+Побудова без використання GNU Make
+============================
+
+`Makefile` включено лише для *сумісності*, щоб якщо хтось
+інстиктивно пише `make`, то було отримано результат.
+
+Фактична розробка/тестування завжди виконується безпосередньо за допомогою `lbmk`, і це також
+стосується збирання з джерельного коду. Ось кілька інструкцій, щоб
+почати:
+
+Спочатку встановіть залежності побудови
+---------------------------------
+
+libreboot включає сценарій, який автоматично встановлює apt-get залежності
+в Ubuntu 20.04. Він працює добре в інших дистрибутивах apt-get (таких як Trisquel та
+Debian):
+
+	sudo ./build dependencies ubuntu2004
+
+Окремі сценарії також існують:
+
+	sudo ./build dependencies debian
+
+	sudo ./build dependencies arch
+
+	sudo ./build dependencies void
+
+Технічно, будь-який дистрибутив GNU+Linux може бути використано для побудови libreboot.
+Однак, вам потрібно буде написано свій власний сценарій для встановлення залежностей
+побудови. 
+
+libreboot Make (lbmk) автоматично виконує всі необхідні команди; наприклад,
+`./build payload grub` автоматично виконає `./build module grub`,
+якщо затребувані утиліти для GRUB не збудовано, для виготовлення корисних навантажень.
+
+В якості результату, ви тепер можете (після встановлення правильних залежностей побудови) виконати
+лише одну команду, з свіжого Git clone, для побудови образів ROM:
+
+	./build boot roms
+
+або навіть побудувати конкретні образи ROM, такі як:
+
+	./build boot roms x60
+
+Якщо ви бажаєте побудувати корисні навантаження, можете зробити це. Наприклад:
+
+	./build payload grub
+
+	./build payload seabios
+
+	./build payload u-boot qemu_x86_12mb
+
+Попередні кроки буде виконано автоматично. Однак, ви можете *досі* виконати
+окремі частини системи побудови власноруч, якщо виберете. Це може бути
+вигідно, коли ви робити зміни, та бажаєте протестувати конкретну частину
+lbmk.
+
+Отже, якщо ви лише хочете побудувати образи ROM, просто зробіть наведене вище. В іншому випадку,
+будь ласка, продовжіть читати!
+
+Опціонально: видобути двійкові блоби
+------------------------------
+
+Деякі плати, включаючи всі плати sandy/ivybridge, вимагають невільні блоби, які не можуть бути включеними до  libreboot.
+Для плат, які вимагають ці блоби, libreboot спробує завантажити блоби власноруч.
+Якщо ваша плата не має джерел блоба в наявності, тоді ви мусите видобути їх з резервної копії вашого rom постачальника.
+Ви маєте вказати libreboot резервну копію rom та сказати системі побудові те, для якої плати ви хочете видобути блоби
+Наприклад, щоб видобути блоби для t440p, ви маєте виконати:
+
+	./blobutil extract t440p_12mb /path/to/12mb_backup.rom
+
+Ви потім можете побудувати rom для цієї плати нормально:
+
+	./build boot roms t440p_12mb
+
+
+Друге, завантажити всі програмні компоненти, які вимагаються
+--------------------------------------------------------
+
+Якщо ви не виконали просто `./build boot roms` (з або без надлишкових
+аргументів), ви все одно можете виконати залишок процесу побудови власноруч. Читайте
+далі! Ви можете прочитати про всі доступні сценарії в `lbmk`, читаючи
+[керівництво обслуговування libreboot](../maintain/); lbmk розроблено бути модулярним,
+що означає те, що кожен сценарій *може* бути використано самостійно (якщо це не є правдою, для
+будь-якого сценарія, це є помилкою, яка має бути виправлена).
+
+Це настільки просто, як це:
+
+	./download all
+
+Вищезазначена команда завантажує всі модулі, які означено в системі побудови libreboot.
+Однак, ви можете завантажити модулі індивідуально.
+
+Ця команда показує вам список доступних модулів:
+
+	./download list
+
+Приклад завантаження індивідуального модуля:
+
+	./download coreboot
+
+	./download seabios
+
+	./download grub
+
+	./download flashrom
+
+	./download u-boot
+
+Третє, побудова кожного з модулів:
+--------------------------------
+
+Побудова модуля означає, що він має вже бути завантаженим.
+В цей момент, система побудови не виконує автоматично кроки передумови,
+такі як цей, тому ви мусите перевірити це власноруч.
+
+Знову, дуже просто:
+
+	./build module all
+
+Це будує кожен модуль, означений в системі побудови libreboot, але ви можете
+будувати модулі індивідуально.
+
+Наступна команда перелічує доступні модулі:
+
+	./build module list
+
+Приклад побудови конкретних модулів:
+
+	./build module grub
+
+	./build module seabios
+
+	./build module flashrom
+
+Команди доступні для *очищення* модуля, які, по суті, виконують make-clean.
+Ви можете перелічити ці команди:
+
+	./build clean list
+
+Видаліть всі модулі таким чином:
+
+	./build clean all
+
+Приклад видалення конкретних модулів:
+
+	./build clean grub
+
+	./build clean cbutils
+
+Четверте, побудуйте всі корисні навантаження:
+---------------------------------
+
+Дуже просто:
+
+	./build payload all
+
+Ви можете перелічити доступні корисні навантаження таким чином:
+
+	./build payload list
+
+Приклад побудови конкретних корисних навантажень:
+
+	./build payload grub
+
+	./build payload seabios
+
+Кожна плата має свою власну конфігурацію побудови U-Boot в `lbmk` під
+`resources/u-boot`. Для побудови корисних навантажень U-Boot, вам потрібно вказати
+цільову плату і мабуть крос-компілятор для її архітектури ЦП. Вони
+керуються автоматично під час побудови образів ROM, але для прикладу:
+
+	./build payload u-boot qemu_x86_12mb	# на хостах x86
+
+	CROSS_COMPILE=aarch64-linux-gnu- ./build payload u-boot gru_kevin
+
+	CROSS_COMPILE=arm-linux-gnueabi- ./build payload u-boot veyron_speedy
+
+Команда build-payload є попередньою умовою для побудови образів ROM.
+
+П'яте, побудуйте ROM!
+----------------------
+
+Виконайте цю команду:
+
+	./build boot roms
+
+Кожна плата має свою власну конфігурацію в `lbmk` під `resources/coreboot/`,
+яка вказує, які корисні навантаження підтримуються.
+
+За замовчуванням, всі образи ROM будуються, для всіх плат. Якщо ви бажаєте побудувати лише
+конкретну плату, ви можете вказати назву плати, засновану на імені директорії
+для неї під `resources/coreboot/`. Наприклад:
+
+	./build boot roms x60
+
+Імена плат, як вище, такі самі, як імена директорій для кожної плати,
+під `resources/coreboot/` в системі побудови.
+
+Ось так!
+
+Якщо все пройшло добре, образи ROM мають бути доступними вам під bin/

site/docs/install/spi.md

@@ -54,22 +54,52 @@ In practise, most people will not fix their ch341a and instead just risk it,
 so no documentation will be provided for ch341a on this website. It is best
 to discourage use of that device.
 
-**Not covered on that eevblog page: the WP/HOLD pins (pins 3 and 7) must be held high via pull-up resistors, but on CH341A dongles, they are directly connected to 3.3V DC (continuity with pin 8). It is advisable to cut these two connections, to the WP and HOLD pins, and jump the cuts using pull-up resistors instead. A value between 1k to 10k (ohms) should be fine.**
-
-Alternatively, you might work around this by using an adapter or logic-level
-converter that can tolerate the overvoltage (which you would need for 1.8V chips
-anyway).
+**Not covered on that eevblog page: the WP/HOLD pins (pins 3 and 7) must be
+held high via pull-up resistors, but on CH341A dongles, they are directly
+connected to 3.3V DC (continuity with pin 8). It is advisable to cut these
+two connections, to the WP and HOLD pins, and jump the cuts using pull-up
+resistors instead. A value between 1k to 10k (ohms) should be fine.**
+
+**In the event of a surge, like for example you connect the clip wrongly and
+cause a short circuit between two pins, lack of pull-up resistors on WP/HOLD
+could cause a direct short between VCC/ground, which would cause a lot of heat
+build up and possibly fire (and definitely damaged circuitry). On SOIC8, pin 3
+is WP and 4 is GND, so a direct 3.3v connection there is quite hazardous for
+that reason; all the more reason to use a pull-up resistor.**
+
+The mainboard that you want to flash (if using e.g. pomona clip) will probably
+have pull-up resistors on it already for WP/HOLD, so simply cutting WP/HOLD
+on the CH341A would also be acceptable. The pull-up resistors that you
+place (in such a mod) on the CH341A are only useful if you also want to flash
+chips in the ZIF socket. If pull-up resistors exist both on e.g. the laptop
+mainboard and on the CH341A, it just means the equivalent series resistance
+will be of the two resistors (on each line) in parallel. If we assume that
+a laptop is likely to have a resistor size of ~3.3k for pull-ups, then a value
+of ~5.6k ohms on the CH341A side seems reasonable.
+
+Alternatively, you might work around the voltage issue by using an adapter with
+logic-level converter, making sure to have matching vcc going into the flash.
+Use of a logic level converter would be quite flexible, in this scenario, and
+you could use it to set many voltages such as 1.8v or 3.3v.
 
 In case it's not clear:
 
-Please do not buy the ch341a! It is incorrectly engineered for the purpose of
-ROM flashing on systems with 3.3v SPI (which is most coreboot systems). DO NOT
-USE IT! This issue still isn't fixed by the manufacturer, and it doesn't look
-like they will ever fix it.
+**Please do not buy the ch341a!** It is incorrectly engineered for the purpose
+of ROM flashing on systems with 3.3v SPI (which is most coreboot systems). DO
+NOT USE IT! This issue still isn't fixed by the manufacturer, and it doesn't
+look like they will ever fix it.
 
 If you see someone talking about CH341A, please direct them to this page and
 tell them why the CH341A is bad.
 
+These photos show both modifications (3.3v logic and WP/HOLD pull-up
+resistors) performed, on the black CH341A:\
+<img tabindex=1 src="https://av.libreboot.org/ch341a/0000_th.jpg" /><span class="f"><img src="https://av.libreboot.org/ch341a/0000.jpg" /></span>
+<img tabindex=1 src="https://av.libreboot.org/ch341a/0001_th.jpg" /><span class="f"><img src="https://av.libreboot.org/ch341a/0001.jpg" /></span>
+
+The green version (not shown above) may come with 3.3v logic already wired, but
+still needs to have pull-up resistors placed for WP/HOLD.
+
 Identify which flash type you have
 ==================================
 

site/faq.md

@@ -891,8 +891,9 @@ as well as a computer.
 Based on this, it's safe to say that use of USB instead of SATA is
 advisable if security is a concern. USB 2.0 has plenty of bandwidth for
 many HDDs (a few high-end ones can use more bandwidth than USB 2.0 is
-capable of), but for SSDs it might be problematic (unless you're using
-USB 3.0, which is not yet usable in freedom. See
+capable of), but for SSDs it might be problematic. USB 3.0 will provide more
+reasonable performance, though note that depending on the system, you may have
+to deal with binary blob XHCI firmware in your kernel (if that bothers you).
 
 Use of USB is also not an absolute guarantee of safety, so do beware.
 The attack surface becomes much smaller, but a malicious drive could

site/news/MANIFEST

@@ -1,3 +1,4 @@
+kgpe-d16.md
 freedom.md
 libreboot20230319.md
 usa-libre-part3.md

site/news/kgpe-d16.md

@@ -0,0 +1,56 @@
+% ASUS KGPE-D16 hardware donation needed
+% Leah Rowe
+% 30 March 2023
+
+This page will be updated after I've acquired the hardware.
+
+Please donate a D16 machine if you can
+======================================
+
+If someone can donate one to me, that would be a great service to the Libreboot
+project. Preferably assembled, with CPU, cooler, working RAM (in coreboot), in
+a case with PSU... throw in a graphics card if you can.
+
+ASUS KGPE-D16 support was removed from Libreboot a while ago, because I didn't
+have enough testers to be confident in providing ROM images for it.
+
+I would like to re-add support for ASUS KGPE-D16 in a future Libreboot release,
+but this time I'd like to be able to test it myself.
+
+I don't currently have a KGPE-D16 set up at my lab, because finding parts
+and (especially) the coolers is a challenge, to say the least.
+
+If you would like to help, and have a machine to spare, please can you contact
+me at my email address: [info@minifree.org](mailto:info@minifree.org)
+
+KCMA-D8 also needed
+-------------------
+
+I'm also arranging for an assembled machine with KCMA-D8 in it to be sent to
+me - though I'm not yet sure if that will go through, so if you have one of
+those aswell, I'd be interested too.
+
+How I plan to re-add
+====================
+
+Dasharo produces updated coreboot images for KGPE-D16, with source code. They
+took coreboot from release 4.11 and updated the code. I plan to add support in
+lbmk (Libreboot's build system) for using other coreboot repositories besides
+the official one, when downloading, patching and compiling for each board.
+
+In other words, I would integrate Dasharo's coreboot repository in Libreboot,
+alongside the default one on coreboot.org.
+
+As far as I know, Dasharo does not yet work on KCMA-D8 (that was the case,
+last time I checked), but I could inspect code differences between D8/D16 in
+coreboot's branch `4.11_branch` and try to port those to Dasharo, to then put
+in Libreboot.
+
+Failing that (for KCMA-D8), I would just use `4.11_branch` from coreboot.
+D8/D16 support was dropped in coreboot after release 4.11, but updated code
+mostly fixing compiler issues and such, is available in a branch off
+of 4.11 called `4.11_branch`.
+
+When Libreboot dropped support for D8/D16, it wasn't using `4.11_branch`.
+Instead, it was using the normal 4.11 tag in coreboot.git, with some extra
+patches on top provided by Libreboot.