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

replace all occurances of osboot with libreboot

hslick-master
shmalebx9 2022-11-13 19:31:12 -07:00
parent 0d073ce09c
commit a3bd73a1c2
58 changed files with 1058 additions and 735 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
site/contact.md
View File

@ -22,11 +22,11 @@ Instructions are also on that page for sending patches (via pull requests).
IRC chatroom
============
IRC is the main way to contact the osboot project. `#osboot` on Libera
IRC is the main way to contact the libreboot project. `#libreboot` on Libera
IRC.
Webchat:
<https://web.libera.chat/#osboot>
<https://web.libera.chat/#libreboot>
Libera is one of the largest IRC networks, used for Free Software projects.
Find more about them here: <https://libera.chat/>
@ -35,7 +35,7 @@ If you wish to connect using your preferred client (such as weechat or irssi),
the connection info is as follows:
* Server: `irc.libera.chat`
* Channel: `#osboot`
* Channel: `#libreboot`
* Port (TLS): `6697`
* Port (non-TLS): `6667`
@ -53,12 +53,12 @@ In general, you should check the documentation provided by your IRC software.
Social media
============
osboot exists officially on many places.
libreboot exists officially on many places.
Twitter and Mastodon
--------------------
News announcements: <https://twitter.com/OSBootFirmware/>
News announcements: <https://twitter.com/libreboot/>
The founder and lead developer, Leah Rowe, is also on Twitter and Mastodon:
@ -72,4 +72,4 @@ Reddit
------
Mostly used as a support channel, and also for news announcements:
<https://www.reddit.com/r/osboot/>
<https://www.reddit.com/r/libreboot/>

406
site/contrib.md
View File

@ -10,36 +10,36 @@ If we forgot to mention you here, let us know and we'll add you. (or if
you don't want to be mentioned, let us know and we'll remove your
entry)
Information about who works on osboot, and how the project is run, can
Information about who works on libreboot, and how the project is run, can
be found on this page: [who.md](who.md)
You can know the history of the osboot project, simply by reading this page.
You can know the history of the libreboot project, simply by reading this page.
It goes into detail about all of the major contributions to the project, and in
general how the project was created (and who helped create it).
Leah Rowe
---------
**Founder of the osbootboot project, and currently the lead developer.** Leah
works on all aspects of osboot, such as:
**Founder of the librebootboot project, and currently the lead developer.** Leah
works on all aspects of libreboot, such as:
* General management. Leah handles all outside contributions to osboot,
* General management. Leah handles all outside contributions to libreboot,
reviews pull requests, deals with bug reports, delegates tasks when necessary
or desirable. Leah controls the osboot.org server infrastructure, hosted
or desirable. Leah controls the libreboot.org server infrastructure, hosted
in her lab.
* Leah has the final say on all decisions, taking input via discussion with
members of the public, mostly on IRC. Leah oversees releases of osboot,
members of the public, mostly on IRC. Leah oversees releases of libreboot,
and generally keeps the project going. Without Leah, there would be no Osboot!
* The build system (osbmk, short for osboot Make). This is the automated build
system that sits at the heart of osboot; it downloads, patches, configures
* The build system (lbmk, short for libreboot Make). This is the automated build
system that sits at the heart of libreboot; it downloads, patches, configures
and compiles the relevant components like coreboot, GNU GRUB and generates
the osboot ROM images that you can find in release archives (as of 23 March
the libreboot ROM images that you can find in release archives (as of 23 March
2022, there are not yet any binary releases, it's rolling release, built from
source. see: <https://osboot.org/docs/build/>)
* Upstream work on coreboot, when necessary (and other projects that osboot
uses). This means also working with people from outside of the osboot
source. see: <https://libreboot.org/docs/build/>)
* Upstream work on coreboot, when necessary (and other projects that libreboot
uses). This means also working with people from outside of the libreboot
project, to get patches merged (among other things) on the upstream projects
that osboot uses
that libreboot uses
* Providing user support on IRC
Leah is also responsible for [libreboot.org](https://libreboot.org/) which is heavily
@ -48,52 +48,394 @@ based on Osboot, but with different project goals.
Caleb La Grange
---------------
**Secondary developer, number two to Leah.** Caleb is a full time osboot developer
**Secondary developer, number two to Leah.** Caleb is a full time libreboot developer
with a narrower focus. Caleb focuses on several areas of development:
* Build system. Caleb is responsible for improving and fixing the osboot Make build
* Build system. Caleb is responsible for improving and fixing the libreboot Make build
system. Specifically: binary blob management, automation, and reproducibility.
* Hardware modification. Caleb has a passion for hardware alteration; soldering,
desoldering, and testing osboot software on the resulting hardware.
* Board porting. Anything supported in Coreboot can be ported to osboot, Caleb
desoldering, and testing libreboot software on the resulting hardware.
* Board porting. Anything supported in Coreboot can be ported to libreboot, Caleb
will test and port any board he can get his hands on. Additionally, anyone can
contact Caleb to generate osboot roms for testing on their board.
contact Caleb to generate libreboot roms for testing on their board.
* Documentation. Caleb actively maintains documentation on the above areas of
interest. Additionally, Caleb is responsible for disassembly guides with his own
pictures and diagrams for several boards.
* User support. Caleb is active on irc and willing to help any user interested in
using osboot or in need of help.
using libreboot or in need of help.
* Project goals. Caleb collaborates with Leah on determining project goals.
Leah has the final say in every decision.
Coreboot project
----------------
Without coreboot, the osboot project simply would not be possible.
Without coreboot, the libreboot project simply would not be possible.
The people and companies that work on coreboot are numerous, and they make the
osboot project what it is. The osboot project makes heavy use of coreboot, to
libreboot project what it is. The libreboot project makes heavy use of coreboot, to
provide hardware initialization.
GNU GRUB
--------
GRUB is the bootloader used by osboot. It goes without saying that the GRUB
developers enable osboot, through their work.
GRUB is the bootloader used by libreboot. It goes without saying that the GRUB
developers enable libreboot, through their work.
SeaBIOS
-------
The osboot firmware provides SeaBIOS as a payload option. SeaBIOS provides a
The libreboot firmware provides SeaBIOS as a payload option. SeaBIOS provides a
legacy x86 BIOS implementation.
Libreboot contributors
----------------------
Alyssa Rosenzweig
-----------------
Since osboot is a fork of Libreboot, it goes without saying that many of the
contributions to Libreboot have also helped shape the osboot project.
Switched the website to use markdown in lieu of handwritten HTML and custom
PHP. **Former libreboot project maintainer (sysadmin for libreboot.org).**
There is a separate list of contributors is maintained by the Libreboot
project.
Alyssa wrote the original static site generator (bash scripts converting
markdown to html, via pandoc) for libreboot.org. This static site generator has
now been heavily modified and forked into a formal project, by Leah Rowe:
Please read: <https://libreboot.org/contrib.html>
<https://untitled.vimuser.org/> (untitled is Leah's work, not Alyssa's, but it's based on
Alyssa's original work on the static site generator that Libreboot used to use;
the Libreboot website is now built with Untitled)
Andrew Robbins
--------------
Worked on large parts of Libreboot's old build system and related documentation.
Andrew joined the Libreboot project as a full time developer during June 2017,
until his departure in March 2021.
I, Leah Rowe, am very grateful to Andrew Robbins for his numerous contributions
over the years.
Arthur Heymans
--------------
Merged a patch from coreboot into libreboot, enabling C3 and C4 power
states to work correctly on GM45 laptops. This was a long-standing issue
before Athur's contribution. Arthur also fixed VRAM size on i945 on
GM45 systems, allowing maximum VRAM allocation for the onboard GPUs on
these systems, another longstanding issue in libreboot.
Arthur also did work on the Libreboot build system, when he was a member of the
project. He still works on coreboot, to this day, and Libreboot greatly
benefits from his work. His contributions to the coreboot project, and Libreboot,
are invaluable.
Damien Zammit
-------------
Maintains the Gigabyte GA-G41M-ES2L coreboot port, which is integrated
in libreboot. Also works on other hardware for the benefit of the
libreboot project.
Damien didn't work directly on Libreboot itself, but he worked heavily with
Leah Rowe, integrating patches and new board ports into Libreboot, based on
Damien's upstream work on coreboot.
Denis Carikli
-------------
Based on the work done by Peter Stuge, Vladimir Serbineko and others in
the coreboot project, got native graphics initialization to work on the
ThinkPad X60, allowing it to be supported in libreboot. Denis gave
a lot of advice and helped found the libreboot project.
Denis was a mentor to Leah Rowe in the early days, when she founded the
Libreboot project. A lot of the decision decisions taken, especially with the
Libreboot build system (lbmk), were inspired from talks with Denis.
Denis taught Leah about registers used by Intel GPUs for backlight control. In
the early days, the ThinkPad X60 and T60 laptops in Libreboot did not have
backlight control working, so the brightness was always 100%. With Denis's help,
Leah was able to get backlight controls working by reverse engineering the
correct values to write in those registers. Based on this, a simple fix was
written in coreboot; however, the fix just wrote directly to the register and
didn't work with ACPI based brightness controls. Others in coreboot later
improved it, making ACPI-based backlight controls work properly, based on this
earlier work.
Jeroen Quint
------------
Contributed several fixes to the libreboot documentation, relating to
installing Parabola with full disk encryption on libreboot systems.
Joshua Gay
----------
Joshua is former FSF staff.
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:
A project needed to exist, providing a fully free version of coreboot, without
any binary blobs. At the time (and this is still true today), coreboot was not
entirely free software and shipped with binary blobs by default. In particular,
CPU microcode updates were included by default, on all x86 machines. Working
with Joshua who reviewed my work, I created a fully free version of coreboot.
At first, it wasn't called Libreboot, and the work was purely intended for my
company (at that time called Gluglug) to be promoted by the FSF.
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://www.fsf.org/blogs/licensing/replace-your-proprietary-bios-with-libreboot>
Klemens Nanni
-------------
Made many fixes and improvements to the GRUB configuration used in
libreboot, and several tweaks to the build system.
Leah Rowe initially helped Klemens get his project, autoboot, off the ground.
Autoboot (website autoboot.org) is no longer online, but was a fork of Libreboot
with different project goals; in late 2020, Leah Rowe decided to create her
own new fork of Libreboot called *osboot*, heavily inspired by Klemens's earlier
work. See: <https://osboot.org/>
The following is an archive of autoboot.org, from when it was online back in
2016: <http://web.archive.org/web/20160414205513/http://autoboot.org/> (the
autoboot website went offline a few months later, after Klemens abandoned the
project)
Lisa Marie Maginnis
-------------------
Lisa is a former sysadmin at the Free Software Foundation. In the early days of
the project, she provided Leah with a lot of technical advice. She initially
created Libreboot IRC channel, when Leah did not know how to
use IRC, and also handed +F founder status to Leah for the channel. As an FSF
sysadmin, it was Lisa's job to maintain a lot of the infrastructure used by
Libreboot; at the time, mailing lists on the GNU Savannah website were used by
the Libreboot project. Lisa was also the one who originally encouraged Leah to
have Libreboot join the GNU project (a decision that was later, rather
regrettably, reversed). When Paul Kocialkowski was a member of the project in
2016, she helped him get help from the FSF; he was the leader of the Replicant
project at the time, which had funding from the FSF, and the FSF authorized him
to use some of that funding for his work on Libreboot, thanks to Lisa's
encouragement while she worked at the FSF.
Lisa 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):
<https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>
(archive link: <http://web.archive.org/web/20170319043913/https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>)
<https://media.libreplanet.org/u/libreplanet/m/session-02-c-wide-png-libreplanet-2016-sessions/>
(archive link: <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 <https://www.gnu.org/> and <https://www.fsf.org/> 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); for example, Trisquel uses a D16 provided by the FSF
for their development server used for building Trisquel releases and testing
changes to the Trisquel GNU+Linux distribution. Trisquel is a fully free
GNU+Linux distribution, heavily promoted by the FSF.
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.
Marcus Moeller
--------------
Made the libreboot logo.
Patrick "P. J." McDermott
---------------------------
Patrick also did a lot of research and wrote the libreboot FAQ section
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
-----------------
Ported the ARM (Rockchip RK3288 SoC) based *Chromebook* laptops to
libreboot. Also one of the main [Replicant](http://www.replicant.us/)
developers.
Paul Menzel
-----------
Investigated and fixed a bug in coreboot on the ThinkPad X60/T60 exposed
by Linux kernel 3.12 and up, which caused 3D acceleration to stop
working and video generally to become unstable. The issue was that coreboot,
when initializing the Intel video chipset, was mapping *GTT Stolen Memory* in
the wrong place, because the code was based on kernel code and the Linux kernel
had the same bug. When Linux fixed it, it exposed the same bug in coreboot.
Paul worked with Libreboot on
this, sending patches to test periodically until the bug was fixed
in coreboot, and then helped her integrate the fix in libreboot.
Peter Stuge
-----------
Helped write the [FAQ section about DMA](../faq.md#hddssd-firmware), and provided
general advice in the early days of the project. Peter was a coreboot developer
in those days, and a major developer in the *libusb* project (which flashrom
makes heavy use of).
Peter also wrote the *bucts* utility used to set Backup Control (BUC) Top Swap
(TS) bit on i945 laptops such as ThinkPad X60/T60, which is useful for a
workaround to flash Libreboot without using external hardware; on this machine,
with Lenovo BIOS present, it's possible to flash everything except the main
bootblock, but Intel platforms have 2 bootblocks, and you specify which one is
to be used by setting the TS bit. You then boot with only one bootblock flashed
(by the coreboot project's bootblock on that machine), and afterwards you reset
bucts before flashing the ROM again, to flash the main bootblock. Libreboot
hosts a copy of his work, because his website hosting bucts is no longer
responsive.
Steve Shenton
-------------
Steve did the early reverse engineering work on the Intel Flash Descriptor used
by ICH9M machines such as ThinkPad X200. He created a C struct defining (using
bitfields in C) this descriptor region. With some clever tricks, he was able to
discover the existence of a bit in the descriptor for *disabling* the Intel ME
(management engine) on those platforms.
His initial proof of concept only defined the descriptor, and would do this:
* Read the default descriptor and GbE regions from a Lenovo X200 ROM (default
firmware, not coreboot)
* Disable the ME, by setting 2 bits in the descriptor
* Disable the ME region
* Move descriptor+GbE (12KiB in total) next to each other
* Allocate the remaining flash space to the BIOS region
* Generated the 12KiB descriptor+GbE region, based on this, to insert into a
coreboot ROM image.
In the early days, before Libreboot supported GM45+ICH9M platforms such as
ThinkPad X200/T400, you could use those machines but to avoid the Intel ME you
had to flash it without a descriptor region. This worked fine in those days,
because the ME only handled TPM and AMT on those machines, and the system would
work normally, but that Intel Flash Descriptor also handles the Intel GbE NVM
region in flash, which is used for the Intel Gigabit Ethernet interface.
So you either had Intel ME, or no ethernet support. Steve figured out how to
disable the Intel ME via 2 toggle bits in the descriptor, and also how to
remove the Intel ME region from flash.
Based on his research, I, Leah Rowe, working alongside Steve, also reverse
engineered the layout of the Intel GbE NVM (non-volatile memory) region in the
boot flash. This region defines configuration options for the onboard Intel
GbE NIC, if present.
Based on this, I was able to take Steve's initial proof of concept and write
the `ich9gen` utility, which generates an Intel Flash Descriptor and GbE NVM
region, from scratch, without an Intel ME region defined. It is this tool,
the `ich9gen` tool, that Libreboot uses to provide ROM images for GM45+ICH9M
platforms (such as ThinkPad X200/T400/T500/W500), with a fully functional
descriptor and functional Gigabit Ethernet, but *without* needing Intel
Management Engine (ME) firmware, thus making those machines *libre* (the ME
is fully disabled, when you use a descriptor+gbe image generated by `ich9gen`).
With *my* `ich9gen` tool (Steve's tool was called `ich9deblob`), you didn't
need a dump of the original Lenovo BIOS firmware anymore! I could not have
written this tool, without Steve's initial proof of concept. I worked with him,
extensively, for many months. All GM45+ICH9M support (X200, T400, etc) in
Libreboot is made possible because of the work he did, back in 2014.
Swift Geek
----------
Contributed a patch for ich9gen to generate 16MiB descriptors.
After that, Swift Geek slowly became more involved until he became a full time
developer. Swift Geeks contributions were never really in the form of *code*,
but what he lacked in code, he made up for in providing excellent support, both
to users and other developers, helping others learn more about technology at a
low level.
When Swift Geek was a member of the project, his role was largely providing
user support (in the IRC channel), and conducting research. Swift Geek knows a
lot about hardware. Swift Geek also did some upstream development on GNU GRUB.
Swift Geek has provided technical advice on numerous occasions, to Leah Rowe,
and helped her to improve her soldering skills in addition to teaching her
some repair skills, to the point where she can now repair most faults on
ThinkPad mainboards (while looking at the schematics and boardview).
Swiftgeek left the project in March 2021. I, Leah Rowe, wish him all the best
in his endeavours, and I'm very grateful to his numerous contributions over the
years.
Timothy Pearson
---------------
Ported the ASUS KGPE-D16 board to coreboot for the company Raptor
Engineering of which Timothy is the CEO.
Timothy maintains this code in coreboot,
helping the project with the libreboot integration for it. This person's
contact details are on the raptor site, or you can ping **tpearson** on
the Libera IRC network.
vitali64
--------
Added cstate 3 support on macbook21, enabling higher battery life and cooler
CPU temperatures on idle usage. vitali64 on irc
Vladimir Serbinenko
-------------------
Ported many of the thinkpads supported in libreboot, to coreboot, and
made many fixes in coreboot which benefited the libreboot project.
Vladimir wrote a lot of the original video initialization code used by various
Intel platforms in Libreboot, when flashing it (now rewritten
by others in Ada, for libgfxinit in coreboot, but originally it was written in
C and included directly in coreboot; libgfxinit is a 3rdparty submodule of
coreboot).

14
site/docs/bsd/index.md
View File

@ -5,8 +5,8 @@ x-toc-enable: true
Guide last updated on 24 August 2022.
osboot is capable of booting many BSD systems. This section mostly documents
the peculiarities of osboot as it pertains to BSD; you can otherwise refer to
libreboot is capable of booting many BSD systems. This section mostly documents
the peculiarities of libreboot as it pertains to BSD; you can otherwise refer to
the official documentation for whatever BSD system you would like to use.
Kernel Mode Setting
@ -19,7 +19,7 @@ you read this article.
Boot BSD, using SeaBIOS
=======================
On x86 platforms, osboot/libreboot both provide the choice of GNU GRUB and/or
On x86 platforms, libreboot/libreboot both provide the choice of GNU GRUB and/or
SeaBIOS payload. GRUB can technically boot BSD kernels, but the code is
poorly maintained and unreliable for this use-case scenario; on BIOS systems,
GRUB can chainload BSD bootloaders, but on bare metal (as coreboot payload),
@ -37,7 +37,7 @@ probably don't mind running in text mode all the time.
Warnings for X11 users
----------------------
One important peculiarity of most libreboot and osboot systems is: VGA mode
One important peculiarity of most libreboot and libreboot systems is: VGA mode
support exists, if booting with corebootfb (coreboot's own framebuffer) and
the SeaVGABIOS option ROM used in the SeaBIOS payload; however, the ability
to switch modes is not present, which means you can't switch to text mode
@ -56,7 +56,7 @@ on most systems, but not on most coreboot systems with native video
initialisation used, due to the quirks already described. If you see any
documentation (in BSD land) pertaining to VESA modes, ignore it entirely;
unless you're using the proprietary VGA ROM for your device, it won't work,
and osboot/libreboot don't distribute these (instead, coreboot's own video
and libreboot/libreboot don't distribute these (instead, coreboot's own video
initialisation is used where possible, or a headless SeaBIOS payload setup
is provided, where you would either run it headless or install a graphics
card).
@ -111,7 +111,7 @@ Dubious mention: Tianocore
--------------------------
Tianocore is extremely bloated, and unauditable, so it is not included
in libreboot or osboot, but it is the reference UEFI implementation by
in libreboot or libreboot, but it is the reference UEFI implementation by
Intel and contributors. It can boot most BSD systems very well.
More robust ways to provide UEFI services in Libreboot and Osboot are
@ -121,7 +121,7 @@ in any current or future releases of either project.
Desktop users
-------------
Desktop users on libreboot/osboot should just install a graphics card,
Desktop users on libreboot/libreboot should just install a graphics card,
and again boot with SeaBIOS in text mode; however, when you do this,
SeaBIOS will execute the VGA option ROM on the card which will provide
early video initialisation instead of coreboot's initialisation, and that

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

@ -3,27 +3,27 @@ title: Build from source
x-toc-enable: true
...
osboot's build system is named `osbmk`, short for `osboot Make`, and this
libreboot's build system is named `lbmk`, short for `Libreboot Make`, and this
document describes how to use it. With this guide, you can know how to compile
osboot from the available source code.
This version, if hosted live on osboot.org, assumes that you are using
the `osbmk` git repository, which
libreboot from the available source code.
This version, if hosted live on libreboot.org, assumes that you are using
the `lbmk` git repository, which
you can download using the instructions on [the code review page](../../git.md).
If you're using a release archive of osboot, please refer to the
documentation included with *that* release. osboot releases are only intended
If you're using a release archive of libreboot, please refer to the
documentation included with *that* release. libreboot releases are only intended
as *snapshots*, not for development. For proper development, you should always
be working directly in the osboot git repository.
be working directly in the libreboot git repository.
The following document describes how `osbmk` works, and how you can make changes
to it: [osboot maintenance manual](../maintain/)
The following document describes how `lbmk` works, and how you can make changes
to it: [libreboot maintenance manual](../maintain/)
GNU Make
========
osboot Make includes a file called `Makefile`. You can still use
the `osbmk` build system directly, or you can use GNU Make. The `Makefile`
simply runs `osbmk` commands. However, using `osbmk` directly will offer you
libreboot Make includes a file called `Makefile`. You can still use
the `lbmk` build system directly, or you can use GNU Make. The `Makefile`
simply runs `lbmk` commands. However, using `osbmk` directly will offer you
much more flexibility; for example, the Makefile currently cannot build single
ROM images (it just builds all of them, for all boards).
@ -45,7 +45,7 @@ Now, simply build the coreboot images like so:
make
This single command will build ROM images for *every* board integrated in
osboot. If you only wish to build a limited set, you can use `osbmk` directly:
libreboot. If you only wish to build a limited set, you can use `lbmk` directly:
./build boot roms x200_8mb
@ -56,7 +56,7 @@ You can specify more than one argument:
ROM images appear under the newly created `bin/` directory in the build system.
For other commands, simply read the `Makefile` in your favourite text editor.
The `Makefile` is simple, because it merely runs `osbmk` commands, so it's very
The `Makefile` is simple, because it merely runs `lbmk` commands, so it's very
easy to know what commands are available by simply reading it.
Standard `clean` command available (cleans all modules except `crossgcc`):
@ -77,14 +77,14 @@ Build without using GNU Make
The `Makefile` is included just for *compatibility*, so that someone who
instictively types `make` will get a result.
Actual development/testing is always done using `osbmk` directly, and this
Actual development/testing is always done using `lbmk` directly, and this
includes when building from source. Here are some instructions to get you
started:
First, install build dependencies
---------------------------------
osboot includes a script that automatically installs apt-get dependencies
libreboot includes a script that automatically installs apt-get dependencies
in Ubuntu 20.04. It works well in other apt-get distros (such as Trisquel and
Debian):
@ -98,11 +98,11 @@ Separate scripts also exist:
sudo ./build dependencies void
Technically, any GNU+Linux distribution can be used to build osboot.
Technically, any GNU+Linux distribution can be used to build libreboot.
However, you will have to write your own script for installing build
dependencies.
osboot Make (osbmk) automatically runs all necessary commands; for example
libreboot Make (lbmk) automatically runs all necessary commands; for example
`./build payload grub` will automatically run `./build module grub` if the
required utilities for GRUB are not built, to produce payloads.
@ -124,7 +124,7 @@ If you wish to build payloads, you can also do that. For example:
Previous steps will be performed automatically. However, you can *still* run
individual parts of the build system manually, if you choose. This may be
beneficial when you're making changes, and you wish to test a specific part of
osbmk.
lbmk.
Therefore, if you only want to build ROM images, just do the above. Otherwise,
please continue reading!
@ -132,10 +132,10 @@ please continue reading!
Optional: extract binary blobs
------------------------------
Some boards, including all sandy/ivybridge boards require nonfree blobs which cannot be included in osboot.
For boards requiring these blobs, osboot will attempt to download the blobs itself.
Some boards, including all sandy/ivybridge boards require nonfree blobs which cannot be included in libreboot.
For boards requiring these blobs, libreboot will attempt to download the blobs itself.
If your board does not have blob sources available, then you must extract them from a backup of you vendor rom.
You must point osboot to the backup rom and tell the build system which board you want to extract blobs for.
You must point libreboot to the backup rom and tell the build system which board you want to extract blobs for.
For example, to extract blobs for the t440p you must run:
./build descriptors intel_blobs t440p_12mb /path/to/12mb_backup.rom
@ -150,8 +150,8 @@ Second, download all of the required software components
If you didn't simply run `./build boot roms` (with or without extra
arguments), you can still perform the rest of the build process manually. Read
on! You can read about all available scripts in `osbmk` by reading
the [osboot maintenance manual](../maintain/); osbmk is designed to be modular
on! You can read about all available scripts in `lbmk` by reading
the [libreboot maintenance manual](../maintain/); lbmk is designed to be modular
which means that each script *can* be used on its own (if that's not true, for
any script, it's a bug that should be fixed).
@ -159,7 +159,7 @@ It's as simple as that:
./download all
The above command downloads all modules defined in the osboot build system.
The above command downloads all modules defined in the libreboot build system.
However, you can download modules individually.
This command shows you the list of available modules:
@ -187,7 +187,7 @@ Again, very simple:
./build module all
This builds every module defined in the osboot build system, but you can
This builds every module defined in the libreboot build system, but you can
build modules individually.
The following command lists available modules:
@ -243,7 +243,7 @@ Run this command:
./build boot roms
Each board has its own configuration in `osbmk` under `resources/coreboot/`
Each board has its own configuration in `lbmk` under `resources/coreboot/`
which specifies which payloads are supported.
By default, all ROM images are built, for all boards. If you wish to build just

12
site/docs/gnulinux/encrypted_debian.md
View File

@ -18,7 +18,7 @@ and no other coreboot payload provides this functionality.
If booting in text mode
=======================
osboot ROM images are provided, which will either boot the system in classic
libreboot ROM images are provided, which will either boot the system in classic
text mode, or with a framebuffer implemented by coreboot for video display
initialization (not to be confused with int10h VGA modes).
@ -44,10 +44,10 @@ would presumably handle INT10H VGA modes.
Boot the installer
==================
osboot on x86 can use the GNU GRUB bootloader as a bare metal coreboot
libreboot on x86 can use the GNU GRUB bootloader as a bare metal coreboot
[payload](http://www.coreboot.org/Payloads#GRUB_2) if you wish, which
means that the GRUB configuration file (where your GRUB menu comes from)
is stored directly alongside osboot and its GRUB payload executable,
is stored directly alongside libreboot and its GRUB payload executable,
inside the flash chip. In context, this means that installing
distributions and managing them is handled slightly differently compared
to traditional BIOS or UEFI systems.
@ -55,7 +55,7 @@ to traditional BIOS or UEFI systems.
On most systems, the `/boot/` partition has to be left unencrypted while
the others are encrypted. This is so that GRUB, and therefore the
kernel, can be loaded and executed since the firmware can't open a LUKS
volume. Not so with osboot! Since GRUB is already included directly
volume. Not so with libreboot! Since GRUB is already included directly
as a payload, even `/boot/` can be encrypted. This protects /boot from
tampering by someone with physical access to the system.
@ -163,7 +163,7 @@ Tasksel
=======
For Debian, use the *MATE* option, or one of the others if you want. The
osboot project recommends MATE, unless you're saavy enough to choose
libreboot project recommends MATE, unless you're saavy enough to choose
something else.
If you want debian-testing, then you should only select barebones
@ -208,7 +208,7 @@ Booting your system
If you didn't install GRUB during the net installation process, don't worry.
You can boot your installed system manually, using the *terminal* in GRUB on
your boot flash (the version that osboot gives you).
your boot flash (the version that libreboot gives you).
At this point, you will have finished the installation. At your GRUB
payload, press C to get to reach the GRUB terminal and enter these commands:

4
site/docs/gnulinux/grub_boot_installer.md
View File

@ -9,7 +9,7 @@ This guide assumes that you are using the GNU GRUB bootloader directly.
If you're using SeaBIOS, it's quite intuitive and works similarly to other BIOS
software; refer to the documentation on <https://seabios.org/SeaBIOS>.
This guide explains how to prepare a bootable USB for osboot systems that
This guide explains how to prepare a bootable USB for libreboot systems that
can be used to install several GNU+Linux distributions. For this guide, you
will only need a USB flash drive and the `dd` utility (it's installed into all
GNU+Linux distributions, by default).
@ -156,7 +156,7 @@ to distro. If you did all of that correctly, then it should now be booting your
USB drive in the way that you specified.
## Troubleshooting
Most of these issues occur when using osboot with coreboot's `text-mode`
Most of these issues occur when using libreboot with coreboot's `text-mode`
with libgfxinit for video initialization. This mode is useful for text mode
payloads, like `MemTest86+`, which expect `text-mode`, but for GNU+Linux
distributions it can be problematic when they are trying to switch to a

40
site/docs/gnulinux/grub_cbfs.md
View File

@ -12,10 +12,10 @@ on *bare metal* as a native coreboot payload and does *not* use BIOS or UEFI
services (but it *can* load and execute SeaBIOS, in addition to any other
coreboot payload, by chainloading it).
In most circumstances, this guide will not benefit you. osboot's default
In most circumstances, this guide will not benefit you. libreboot's default
GRUB configuration file contains scripting logic within it that intelligently
searches for GRUB partitions installed onto a partition on your SSD, HDD or
USB drive installed on your computer. If such a file is found, osboot's
USB drive installed on your computer. If such a file is found, libreboot's
default GRUB configuration is configured to switch automatically to that
configuration. While not perfect, the logic *does* work with most
configurations.
@ -30,31 +30,31 @@ a known state.
Compile flashrom and cbfstool
=============================
osboot does not currently distribute utilities pre-compiled. It only
libreboot does not currently distribute utilities pre-compiled. It only
provides ROM images pre-compiled, where feasible. Therefore, you have to build
the utilities from source.
As for the ROM, there are mainly three methods for obtaining a osboot ROM
As for the ROM, there are mainly three methods for obtaining a libreboot ROM
image:
1. Dump the contents of the the main *boot flash* on your system, which already
has osboot installed (with GNU GRUB as the default payload). Extract the
has libreboot installed (with GNU GRUB as the default payload). Extract the
GRUB configuration from *that* ROM image.
2. Extract it from a osboot ROM image supplied by the osboot project, on
the osboot website or mirrors of the osboot website.
3. Build the ROM yourself, using the osboot build system. Instructions for
2. Extract it from a libreboot ROM image supplied by the libreboot project, on
the libreboot website or mirrors of the libreboot website.
3. Build the ROM yourself, using the libreboot build system. Instructions for
how to do this are covered in the following article:
[How to build osboot from source](../build/)
[How to build libreboot from source](../build/)
In either case, you will use the `cbfstool` supplied in the osboot build
In either case, you will use the `cbfstool` supplied in the libreboot build
system.
This can be found under `coreboot/*/util/cbfstool/` as source code,
where `*` can be any coreboot source code directory for a given mainboard.
The directory named `default` should suffice.
Install the build dependencies. For Ubuntu 20.04 and similar, you can run
the following command in the osboot build system, from the root directory
of the osboot Git repository.
the following command in the libreboot build system, from the root directory
of the libreboot Git repository.
./build dependencies ubuntu2004
@ -73,10 +73,10 @@ For example: `coreboot/default/util/cbfstool/cbfstool`
The `cbfstool` utility is what you shall use. It is used to manipulate CBFS
(coreboot file system) which is a file system contained within the coreboot
ROM image; as a *coreboot distribution*, osboot inherits this technology.
ROM image; as a *coreboot distribution*, libreboot inherits this technology.
You will also want to build `flashrom` which osboot recommends for reading
from and/or writing to the boot flash. In the osboot build system, you can
You will also want to build `flashrom` which libreboot recommends for reading
from and/or writing to the boot flash. In the libreboot build system, you can
build it by running this command:
./build module flashrom
@ -87,10 +87,10 @@ this.
Dump the boot flash
===================
If you wish to modify your *existing* osboot ROM, which was installed on
If you wish to modify your *existing* libreboot ROM, which was installed on
your computer, you can use `flashrom` to acquire it.
Simply run the following, after using osboot's build system to compile
Simply run the following, after using libreboot's build system to compile
flashrom:
sudo ./flashrom/flashrom -p internal -r dump.bin
@ -117,7 +117,7 @@ machine powered down) and read the contents of the boot flash.
Extract grub.cfg
================
osboot images that use the GNU GRUB bootloader will have *two* configuration
libreboot images that use the GNU GRUB bootloader will have *two* configuration
files in CBFS:
* `grub.cfg`
@ -130,7 +130,7 @@ When that it done, copy the changes over to `grub.cfg
You can use the following commands to modify the contents of CBFS, where
GRUB's configuration file is concerned (dump.bin is the ROM that you dumped,
or it could refer to the osboot ROM image that you compiled or otherwise
or it could refer to the libreboot ROM image that you compiled or otherwise
acquired).
Show the contents of CBFS, in your ROM:
@ -160,7 +160,7 @@ Add your modified `grub.cfg` (substitute with `grubtest.cfg` as desired):
Flash the modified ROM image
============================
Your modified `dump.bin` or other modified osboot ROM can then be re-flashed
Your modified `dump.bin` or other modified libreboot ROM can then be re-flashed
using:
sudo ./flashrom -p internal -w dump.bin

40
site/docs/gnulinux/grub_hardening.md
View File

@ -5,21 +5,21 @@ x-toc-enable: true
This article only applies to those people who use the GNU GRUB bootloader as
their default payload (options besides GNU GRUB are also available in
osboot). Whenever this article refers to GNU GRUB, or configuration files
libreboot). Whenever this article refers to GNU GRUB, or configuration files
used in GNU GRUB, it is referring exclusively to those files hosted in CBFS
(coreboot file system) in the osboot ROM image. In this configuration, GNU
(coreboot file system) in the libreboot ROM image. In this configuration, GNU
GRUB is running on *bare metal* as a coreboot payload (instead of relying on
BIOS or UEFI services, like it does on *most* x86 based configurations).
This guide deals with various ways in which you can harden your GNU GRUB
configuration, for security purposes. These steps are optional, but *strongly*
recommended by the osboot project.
recommended by the libreboot project.
GNU GRUB provides *many* advanced security features, which most people don't
know about but are fully documented on the osboot website. Read on!
know about but are fully documented on the libreboot website. Read on!
This article doesn't cover how to dump your ROM, or flash a new one. Please
read other sections in the osboot documentation if you don't know how to do
read other sections in the libreboot documentation if you don't know how to do
that. As such, this is an *expert only* guide. There is a great possibility for
bricking your system if you follow this guide incorrectly, or otherwise don't
know what you're doing.
@ -32,7 +32,7 @@ PGP signatures on *any* type of file, on any storage medium supported by
GNU GRUB (it supports basically everything, including CBFS which is short
for coreboot file system and it is what we will focus on in this article).
We will be using this functionality to verify the signature of a Linux kernel,
at boot time. In conjunction with reproducible builds (both osboot and your
at boot time. In conjunction with reproducible builds (both libreboot and your
Linux kernel), this can greatly improve system security; Debian is an excellent
example of a GNU+Linux distribution that is fully reproducible nowadays (in
stable releases).
@ -49,9 +49,9 @@ repository). More information about reproducible builds can be found here:
<https://reproducible-builds.org/>
Reproducibility is a key goal of the osboot project, though it has not yet
Reproducibility is a key goal of the libreboot project, though it has not yet
achieved that goal. However, it is an important part of any secure system. We
suggest that, when securing your osboot system as instructed by this guide,
suggest that, when securing your libreboot system as instructed by this guide,
you should also use a reproducible GNU+Linux distribution (because checking GPG
signatures on a non-reproducible binary, such as a Linux kernel, is meaningless
if that binary can be compromised as a result of literally not being able to
@ -63,7 +63,7 @@ they gave you. Based on these facts, we can observe that checking GPG
signatures will improve your *operational* security, but only in specific
circumstances under *controlled conditions*.
This tutorial assumes you have a osboot image (ROM) that you wish to modify,
This tutorial assumes you have a libreboot image (ROM) that you wish to modify,
which from now on we will refer to simply as *`my.rom`*. It should go without
saying that this ROM uses the GNU GRUB bootloader as payload. This page shows
how to modify grubtest.cfg, which means that signing and password protection
@ -72,13 +72,13 @@ incorrect configuration will be impossible. After you are satisfied with the
new setup, you should transfer the new settings to grub.cfg to make your
machine truly secure.
First, extract the old grubtest.cfg and remove it from the osboot
First, extract the old grubtest.cfg and remove it from the libreboot
image:
cbfstool my.rom extract -n grubtest.cfg -f my.grubtest.cfg
cbfstool my.rom remove -n grubtest.cfg
You can build `cbfstool` in the osboot build system. Run this command:
You can build `cbfstool` in the libreboot build system. Run this command:
./build module cbutils
@ -87,13 +87,13 @@ This assumes that you already downloaded coreboot:
./download coreboot
This, in turn, assumes that you have installed the build dependencies for
osboot. On Ubuntu 20.04 and other apt-get distros, you can do this:
libreboot. On Ubuntu 20.04 and other apt-get distros, you can do this:
./build dependencies ubuntu2004
The `cbfstool` executables will be under each coreboot directory, under
each `coreboot/boardname/` directory for each board. Just pick one, presumably
from the coreboot directory for your board. osboot creates multiple coreboot
from the coreboot directory for your board. libreboot creates multiple coreboot
archives for different board revisions, on different boards.
References:
@ -152,9 +152,9 @@ done using the `grub-mkpasswd-pbkdf2` utility. You can get it by
installing GRUB version 2. Generate a key by giving it a password:
NOTE: This utility is included under the `grub/` directory, when you build
GRUB using the osboot build system. Run the following commands (assuming
GRUB using the libreboot build system. Run the following commands (assuming
you have the correct build dependencies installed) to build GNU GRUB, from the
osboot Git repository:
libreboot Git repository:
./download grub
@ -208,9 +208,9 @@ function try\_user\_config:
The `unset superusers` command disables password authentication, which will
allow the attacker to boot an arbitrary operating system, regardless of
signature checking. The default osboot configuration is tweaked for *easy of
signature checking. The default libreboot configuration is tweaked for *easy of
use* by end users, and it is *not* done with security in mind (though security
is preferred). Thus, osboot is less restrictive by default. What you are
is preferred). Thus, libreboot is less restrictive by default. What you are
doing, per this article, is making your system *more secure* but at the expense
of user-friendliness.
@ -240,12 +240,12 @@ Now that we have a key, we can sign some files with it. We must sign:
but, afterwards, `grubtest.cfg` is not signed and it will not load.
Suppose that we have a pair of `my.kernel` and `my.initramfs` and an
on-disk `osboot_grub.cfg`. We will sign them by running the following
on-disk `libreboot_grub.cfg`. We will sign them by running the following
commands:
gpg --homedir keys --detach-sign my.initramfs
gpg --homedir keys --detach-sign my.kernel
gpg --homedir keys --detach-sign osboot_grub.cfg
gpg --homedir keys --detach-sign libreboot_grub.cfg
gpg --homedir keys --detach-sign my.grubtest.cfg
Of course, some further modifications to my.grubtest.cfg will be required. We
@ -255,7 +255,7 @@ entries):
trust (cbfsdisk)/boot.key
set check_signatures=enforce
What remains now is to include the modifications into the osboot image
What remains now is to include the modifications into the libreboot image
(ROM):
cbfstool my.rom add -n boot.key -f boot.key -t raw

16
site/docs/gnulinux/guix.md
View File

@ -7,7 +7,7 @@ Objective
=========
To provide step-by-step guide for setting up guix system (stand-alone guix) with
full disk encryption (including /boot) on devices powered by osboot.
full disk encryption (including /boot) on devices powered by libreboot.
Scope
=====
@ -317,7 +317,7 @@ Post-Installation
On reboot, as soon as you see the GNU GRUB menu, choose the option
'Load Operating System [o]'
Enter LUKS Key, for osboot's grub, as prompted.
Enter LUKS Key, for libreboot's grub, as prompted.
You may have to go through warning prompts by repeatedly pressing the
"enter/return" key.
@ -362,7 +362,7 @@ update/upgrade part of post-installation section, to keep your guix distribution
and guix system updated.
That is it! You have now setup guix system with full-disk encryption on your
device powered by osboot. Enjoy!
device powered by libreboot. Enjoy!
References
==========
@ -376,14 +376,14 @@ Acknowledgements
for helping me with the Guile Scheme Code for the Bootloader Configuration.
This guide was originally written for the Libreboot project, and later adapted
for the osboot project. This fact is clearly stated, out of respect to the
for the libreboot project. This fact is clearly stated, out of respect to the
Guix project; it is a GNU project, and therefore probably does not agree with
the policies of the osboot project. Rather, they most likely agree with the
the policies of the libreboot project. Rather, they most likely agree with the
Libreboot policies instead. This paragraph is written simply to provide such
clarification, so that people do not think the GNU project (or FSF) endorse or
condone osboot in any way; they do not.
condone libreboot in any way; they do not.
The osboot project respects GNU, and it is itself a project that aims to bring
The libreboot project respects GNU, and it is itself a project that aims to bring
as much free software as possible to everyone, on as much hardware as possible.
Without the GNU project, it is unlikely that we would have much Free Software
today; there were others that started around the same time, but GNU was the
@ -392,7 +392,7 @@ Today, GNU is still a driving force in the Free Software movement.
Respect the GNU project. Cherish it.
The osboot policies are written here: [binary blob reduction
The libreboot policies are written here: [binary blob reduction
policy](../../news/policy.md)
The *libreboot* policies are here: [binary blob deletion

14
site/docs/gnulinux/index.md
View File

@ -8,7 +8,7 @@ If you're using SeaBIOS, the boot process will work similarly to traditional
BIOS systems; refer to the SeaBIOS documentation
on <https://seabios.org/SeaBIOS>
GNU+Linux is the operating system of choice, for osboot development. It is
GNU+Linux is the operating system of choice, for libreboot development. It is
highly recommended over any other operating system, precisely because it consists
of [Free Software](https://www.gnu.org/philosophy/free-sw.html) (free as in
freedom). There *are* other free operating systems, such as BSD, but most of
@ -21,8 +21,8 @@ Useful links
Refer to the following pages:
* [How to Prepare and Boot a USB Installer in osboot Systems](grub_boot_installer.md)
* [Modifying the GRUB Configuration in osboot Systems](grub_cbfs.md)
* [How to Prepare and Boot a USB Installer in libreboot Systems](grub_boot_installer.md)
* [Modifying the GRUB Configuration in libreboot Systems](grub_cbfs.md)
* [Installing Hyperbola GNU+Linux, with Full-Disk Encryption (including /boot)](https://wiki.hyperbola.info/en:guide:encrypted_installation)
* [Installing Debian or Devuan GNU+Linux-Libre, with Full-Disk Encryption (including /boot)](encrypted_debian.md)
* [Installing Guix System, with Full-Disk Encryption (including /boot)](guix.md)
@ -42,7 +42,7 @@ In general, it is recommended that you use SeaBIOS but if you want extra securit
GRUB payload is recommended where you can then have a fully encrypted /boot
directory.
TODO: Nuke *all* distro-specific guides on osboot.org. Instead, move these
TODO: Nuke *all* distro-specific guides on libreboot.org. Instead, move these
instructions to the wiki pages of these projects, on their websites. The reasons
are explained in the above issue page.
@ -73,9 +73,9 @@ This may also apply to CentOS or Redhat. Chroot guide can be found on
linux16 issue
-------------
When you use osboot's default GRUB config, and osboot's grub uses fedora's
default `grub.cfg` (in `/boot/grub2/grub.cfg`), fedora by default makes use of the
`linux16` command, whereas it should be saying `linux`
Libreboot's default GRUB config sources fedora's grub config
`grub.cfg` (in `/boot/grub2/grub.cfg`), fedora by default makes use of the
`linux16` command, where it should be saying `linux`
Do this in fedora:

18
site/docs/grub/index.md
View File

@ -7,11 +7,11 @@ TODO: this guide should be reviewed and updated. Some info might be out of
date.
[GNU GRUB](https://www.gnu.org/software/grub/) already has excellent
documentation, but there are aspects of osboot that deserve special
treatment. osboot provides the option to boot GNU GRUB directly, running on
documentation, but there are aspects of libreboot that deserve special
treatment. libreboot provides the option to boot GNU GRUB directly, running on
bare metal (instead of using BIOS or UEFI services).
[The GNU+Linux section](../gnulinux/) also has osboot-specific guides for
[The GNU+Linux section](../gnulinux/) also has libreboot-specific guides for
dealing with GNU+Linux distributions when using GNU GRUB directly, in this
setup. [A similar section exists for BSD operating systems](../bsd/)
@ -33,20 +33,20 @@ files:
When you build GRUB from source, you can use the `grub-mklayout` program to
create a special keymap file for GRUB. [Learn how to build GRUB](../build/)
When you've built GRUB, using `osbmk` (osboot build system), take your kepmap
When you've built GRUB, using `lbmk` (libreboot build system), take your kepmap
file (generated by ckbcomp) and run it through `grub-mklayout` like so:
cat frazerty | ./grub/grub-mklayout -o frazerty.gkb
Place the newly created `.gkb` file under `resources/grub/keymap` in osbmk. When
you build osboot, a ROM image with GRUB payload and your newly created
Place the newly created `.gkb` file under `resources/grub/keymap` in lbmk. When
you build libreboot, a ROM image with GRUB payload and your newly created
keymap will be available under the `bin/` directory.
[Learn how to build osboot ROM images](../build/)
[Learn how to build libreboot ROM images](../build/)
Many keymaps exist in the osboot build system, but sometimes you must
Many keymaps exist in the libreboot build system, but sometimes you must
manually tweak the file created by `ckbcomp`, adjusting the scan codes in that
file, before converting to a GRUB keymap file. Therefore, it would be unwise to
automatically add all keymaps in GRUB.
If you've added a keymap to osbmk, and it works,
If you've added a keymap to lbmk, and it works,
[please submit a patch!](../../git.md)

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

@ -4,7 +4,7 @@ title: Intel D510MO and D410PT desktop boards
This is a desktop board using intel hardware (circa \~2009, ICH7
southbridge, similar performance-wise to the ThinkPad X200. It can make
for quite a nifty desktop. Powered by osboot.
for quite a nifty desktop. Powered by libreboot.
NOTE: D410PT is another name and it's the same board. Flash the exact same
ROM and it should work.

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

@ -14,7 +14,7 @@ Introduction
This board is a mini-itx desktop board for 2008. It uses an atom 230,
which is a singe core CPU but it is hyperthreaded so it appears to have
2 thread to the OS. The flash chip is very small, 512KiB, so grub2 does
not fit, which is why osboot has to use seabios on this target. Full
not fit, which is why libreboot has to use seabios on this target. Full
disk encryption like on other supported targets will not be possible, so
plan accordingly.
@ -35,13 +35,13 @@ that it should also work but this is untested.
Remarks about vendor bios:
--------------------------
- Without coreboot/osboot this board is completely useless, since the
- Without coreboot/libreboot this board is completely useless, since the
vendor bios is very bad. It cannot boot from any HDD whether it is
connected to the SATA port or USB. With osboot it works just
connected to the SATA port or USB. With libreboot it works just
fine.
- The vendor bios write protects the flash so it requires external
flashing to install osboot on this device. Once osboot is
flashing to install libreboot on this device. Once libreboot is
flashed there is no problem to update the firmware internally
Here is an image of the board:\

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

@ -4,14 +4,14 @@ title: Gigabyte GA-G41M-ES2L desktop board
This is a desktop board using intel hardware (circa \~2009, ICH7
southbridge, similar performance-wise to the ThinkPad X200. It can make
for quite a nifty desktop. Powered by osboot.
for quite a nifty desktop. Powered by libreboot.
NOTE: As of January 4th, 2021, video initialization is broken on this machine.
It is advisable to use Libreboot 20160907, for the time being. You can build a
ROM image from osboot, and extract the CPU microcode updates to then insert in
ROM image from libreboot, and extract the CPU microcode updates to then insert in
the Libreboot 20160907 ROM image, like so (using cbfstool):
cbfstool osboot.rom extract -n cpu_microcode_blob.bin -f cpu_microcode_blob.bin
cbfstool libreboot.rom extract -n cpu_microcode_blob.bin -f cpu_microcode_blob.bin
cbfstool libreboot.rom add -n cpu_microcode_blob.bin -f cpu_microcode_blob.bin -t microcode
With this, you will then have a Libreboot ROM image, but with improved stability
@ -23,7 +23,7 @@ express slots don't work).
The advice above is only useful for the onboard graphics chipset (the Intel
one). If you're using an add-on graphics card (PCI express), you can simply
use osboot, and it will work. If you're doing *that*, please use one of the
use libreboot, and it will work. If you're doing *that*, please use one of the
ROM images with the *SeaBIOS* payload, booting in text mode. SeaBIOS will
automatically execute the option ROM on your graphics card, implementing VBE
(Video BIOS extension).
@ -40,22 +40,22 @@ hwaddress ether macaddressgoeshere
Alternatively:
cbfstool osboot.rom extract -n rt8168-macaddress -f rt8168-macaddress
cbfstool libreboot.rom extract -n rt8168-macaddress -f rt8168-macaddress
Modify the MAC address in the file `rt8168-macaddress` and then:
cbfstool osboot.rom remove -n rt8168-macaddress
cbfstool osboot.rom add -f rt8168-macaddress -n rt8168-macaddress -t raw
cbfstool libreboot.rom remove -n rt8168-macaddress
cbfstool libreboot.rom add -f rt8168-macaddress -n rt8168-macaddress -t raw
Now you have a different MAC address hardcoded. In the above example, the ROM
image is named `osboot.rom` for your board. You can find cbfstool
image is named `libreboot.rom` for your board. You can find cbfstool
under `coreboot/default/util/cbfstool/` after running the following command
in the build system:
./build module cbutils
You can learn more about using the build system, osbmk, here:\
[osboot build instructions](../build/)
You can learn more about using the build system, lbmk, here:\
[libreboot build instructions](../build/)
Flashing instructions can be found at
[../install/](../install/)

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

@ -2,6 +2,6 @@
title: Apple iMac 5,2
...
Information to be written soon, but this board is merged in osboot.
Information to be written soon, but this board is merged in libreboot.
Just refer back to the [hardware section](./) and [install guides](../install/)

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

@ -3,20 +3,20 @@ title: Hardware compatibility list
x-toc-enable: true
...
**The osboot project was rebooted on January 4th, 2022. Some boards were
**The libreboot project was rebooted on January 4th, 2022. Some boards were
deleted as a result, but they will be re-added later, with documentation also
re-added. The Libreboot and osboot projects went completely out of sync, but
the Libreboot project was more up to date, so osboot, itself a fork of
re-added. The Libreboot and libreboot projects went completely out of sync, but
the Libreboot project was more up to date, so libreboot, itself a fork of
Libreboot originally, was PURGED and then RE-FORKED once again, but from
Libreboot in late 2021. From now on, greater care will be taken to keep the
two projects in sync. Both projects are lead and were also founded by Leah
Rowe.**
The current version of osboot already has several major differences. For
The current version of libreboot already has several major differences. For
example, microcode updates are enabled by default, on all boards, even those
that Libreboot supports (this greatly increases system stability).
This sections relates to known hardware compatibility in osboot.
This sections relates to known hardware compatibility in libreboot.
For installation instructions, refer to [../install/](../install/).
@ -25,12 +25,12 @@ because coreboot lacks native video initialization for the ATI GPUs on these
machines.
(for later machines like T500, T400, ATI GPU doesn't matter, because it also
has an Intel GPU, and osboot uses the Intel one)
has an Intel GPU, and libreboot uses the Intel one)
Supported hardware
==================
osboot currently supports the following systems in this release:
libreboot currently supports the following systems in this release:
### Desktops (AMD, Intel, x86)
@ -67,7 +67,7 @@ osboot currently supports the following systems in this release:
- [Lenovo Thinkpad X230](../install/x230_external.md)
- [Lenovo Thinkpad X230t](../install/x230_external.md)
TODO: More hardware is supported. See `resources/coreboot/` in osbmk. Update
TODO: More hardware is supported. See `resources/coreboot/` in lbmk. Update
the above list!
'Supported' means that the build scripts know how to build ROM images
@ -80,7 +80,7 @@ EC update on i945 (X60, T60) and GM45 (X200, X301, T400, T500, R400, W500, R500)
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
osboot, so we don't actually provide that, but if you still have
libreboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
@ -88,7 +88,7 @@ will update both the BIOS and EC version. See:
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running osboot is unknown. osboot
update the EC firmware while running libreboot is unknown. libreboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. better battery

20
site/docs/hardware/kcma-d8.md
View File

@ -16,9 +16,9 @@ CPU cores).
This is a desktop board using AMD hardware (Fam10h *and Fam15h* CPUs
available). It can also be used for building a high-powered workstation.
osboot also supports it. The coreboot port was done by Timothy Pearson of
libreboot also supports it. The coreboot port was done by Timothy Pearson of
Raptor Engineering Inc. and, working with them, merged into libreboot many
years ago. It is also supported by osboot.
years ago. It is also supported by libreboot.
Note that not all boards are compatible. See [board status](#boardstatus)
below to determine compatibility with your board.
@ -26,7 +26,7 @@ below to determine compatibility with your board.
Flashing instructions can be found at
[../install/](../install/) - note that external
flashing is required (e.g. RPi), if the proprietary (ASUS) firmware is
currently installed. If you already have libreboot/osboot/coreboot, by default
currently installed. If you already have libreboot/libreboot/coreboot, by default
it is possible to re-flash using software running in GNU+Linux on the kcma-d8,
without using external hardware.
@ -46,7 +46,7 @@ this:
The default chip is a 2MiB one, but we recommend upgrading it to a 16MiB chip.
NOTE: If you're already running osboot, you probably don't
NOTE: If you're already running libreboot, you probably don't
need to re-flash externally. Refer instead to the generic instructions on
this page: [../install/](../install/)
@ -58,7 +58,7 @@ PCI option ROMs
Unlike Libreboot 20160907, Libreboot in newer releases now supports finding and
loading PCI option ROMs automatically, both in GRUB and SeaBIOS on this machine.
This was inherited by osboot, when the Libreboot project was forked.
This was inherited by libreboot, when the Libreboot project was forked.
So for example, if you wish to use an add-on graphics card, you can! It's no
problem, and should work just fine.
@ -88,7 +88,7 @@ There are two ways to identify a supported KCMA-D8 board:
Supported boards begin with a serial number of **B9S2xxxxxxxx** or above where
the first character refers to the year of manufacture (A = 2010, B = 2011, etc.)
and the following character the month in hexadecimal (1...9, A, B, C). Thus, any
board produced September 2011 *or later* are compatible with osboot. Boards
board produced September 2011 *or later* are compatible with libreboot. Boards
originally shipped with BIOS version **2001** or higher are also compatible.
For help locating these identifying markers, see [ASUS documentation for determining Opteron 4200 series compatibility](https://web.archive.org/web/20200710022605/https://dlcdnets.asus.com/pub/ASUS/mb/SocketC%281027%29/KCMA-D8/Manual&QVL/How_to_identify_MB_supporting_Opteron_4200_CPU.pdf)
@ -138,7 +138,7 @@ framebuffer display (if it has KMS - kernel mode setting).
NOTE: This section relates to the onboard ASpeed GPU. You *can* use an add-on
PCI-E GPU in one of the available slots on the mainboard. Nvidia GTX 780 cards
are what osboot recommends; it has excellent support in Nouveau (free Linux
are what libreboot recommends; it has excellent support in Nouveau (free Linux
kernel / mesa driver for Nvidia cards) and generally works well; however, the
performance won't be as high in Nouveau, compared to the non-free Nvidia driver
because the Nouveau driver can't increase the GPU clock (it doesn't know how,
@ -166,7 +166,7 @@ considerations:
and as such a workaround using SGABIOS is necessary. You can find
instructions on how to do this on the
[Notabug issue tracker](http://web.archive.org/web/20210416011941/https://notabug.org/libreboot/libreboot/issues/736)
TODO: test whether this is still the case in osboot, which uses a newer
TODO: test whether this is still the case in libreboot, which uses a newer
version of coreboot nowadays)
- SAS (via PIKE 2008 module) requires non-free option ROM (and
SeaBIOS) to boot from it (theoretically possible to replace, but you
@ -174,7 +174,7 @@ considerations:
can be on a SAS drive. The linux kernel can use those SAS drives
(via PIKE module) without an option ROM).
NOTE: SeaBIOS can load PCI-E option ROMs, and by default it will do so in
osboot, so you could use it. However, you could *also* simply
libreboot, so you could use it. However, you could *also* simply
install 16MiB NOR flash with linuxboot payload in it, and use linuxboot
which has the Linux kernel, which can use SAS drives without needing that
option ROM; then it can kexec another linux kernel, which in turn also can
@ -184,7 +184,7 @@ considerations:
Since it's for remote out-of-band management, it's theoretically a
backdoor similar to the Intel Management Engine. Fortunately, unlike
the ME, this firmware is unsigned which means that a free
replacement is theoretically possible. For now, the osboot
replacement is theoretically possible. For now, the libreboot
project recommends not installing the module. [This
project](https://github.com/facebook/openbmc) might be interesting
to derive from, for those who want to work on a free replacement. In

4
site/docs/hardware/kfsn4-dre.md
View File

@ -4,7 +4,7 @@ x-toc-enable: true
...
This is a server board using AMD hardware (Fam10h). It can also be used
for building a high-powered workstation. Powered by osboot.
for building a high-powered workstation. Powered by libreboot.
Flashing instructions can be found at
[../install/\#flashrom](../install/#flashrom)
@ -68,7 +68,7 @@ the same as the non-iKVM ones.
The SAS versions have a 4-port SAS controller and a four 7-pin SAS connectors
instead of the PCI-E 8x slot which is present in all the other board configurations.
Note: the SAS functionality is **not supported** by osboot.
Note: the SAS functionality is **not supported** by libreboot.
The IST versions with PCB revision 1.05G are the ones who are believed to
support the six core Opteron Istanbul processors (2400 and 8400 series).

16
site/docs/hardware/kgpe-d16.md
View File

@ -8,9 +8,9 @@ Introduction
This is a server board using AMD hardware (Fam10h *and Fam15h* CPUs
available). It can also be used for building a high-powered workstation.
Powered by osboot. The coreboot port was done by Timothy Pearson of
Powered by libreboot. The coreboot port was done by Timothy Pearson of
Raptor Engineering Inc. and, working with them (and sponsoring the
work), merged into libreboot. It is also supported by osboot.
work), merged into libreboot. It is also supported by libreboot.
*Memory initialization is still problematic, for some modules. We
recommend avoiding Kingston modules.*
@ -19,7 +19,7 @@ recommend avoiding Kingston modules.*
Flashing instructions can be found at
[../install/\#flashrom](../install/#flashrom) - note that external
flashing is required (e.g. BBB), if the proprietary (ASUS) firmware is
currently installed. If you already have osboot, by default it is
currently installed. If you already have libreboot, by default it is
possible to re-flash using software running in GNU+Linux on the
KGPE-D16, without using external hardware.
@ -59,7 +59,7 @@ P-DIP 8 slot (SPI chip). The flash chip can be upgraded to higher sizes:
compressed linux+initramfs image (BusyBox+Linux system) into CBFS and
boot that, loading it into memory.
osboot has configs for 2, 4, 8 and 16 MiB flash chip sizes (default
libreboot has configs for 2, 4, 8 and 16 MiB flash chip sizes (default
flash chip is 2MiB).
*DO NOT hot-swap the chip with your bare hands. Use a P-DIP 8 chip
@ -92,7 +92,7 @@ Current issues {#issues}
Since it's for remote out-of-band management, it's theoretically a
backdoor similar to the Intel Management Engine. Fortunately, unlike
the ME, this firmware is unsigned which means that a free
replacement is theoretically possible. For now, the osboot
replacement is theoretically possible. For now, the libreboot
project recommends not installing the module. [This
project](https://github.com/facebook/openbmc) might be interesting
to derive from, for those who want to work on a free replacement. In
@ -114,9 +114,9 @@ The information here is adapted, from the ASUS website.
recommended - old. View errata datasheet here:
<http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf>)
- AMD Opteron 6200 series (Fam15h, with full IOMMU support in
osboot.
libreboot.
- AMD Opteron 6300 series (Fam15h, with full IOMMU support in
osboot.
libreboot.
- 6.4 GT/s per link (triple link)
### Core logic
@ -124,7 +124,7 @@ The information here is adapted, from the ASUS website.
- AMD SR5690
- AMD SP5100
### Memory compatibility (with osboot)
### Memory compatibility (with libreboot)
- *Total Slots:* 16 (4-channel per CPU, 8 DIMM per CPU), ECC
- *Capacity:* Maximum up to 256GB RDIMM (Tested max 128GB)

12
site/docs/hardware/mac_address.md
View File

@ -6,7 +6,7 @@ x-toc-enable: true
Introduction (GM45+e1000)
=========================
This section is applicable to all osboot-supported laptops with the
This section is applicable to all libreboot-supported laptops with the
mobile 4 series chipset (as shown in `$ lspci`)
that use the e1000 ethernet controller (e.g. T400, X200).
The R500 is an exception to this as it does not use the built-in e1000.
@ -14,20 +14,20 @@ The R500 is an exception to this as it does not use the built-in e1000.
On all these laptops, the
[MAC address](https://en.wikipedia.org/wiki/MAC_address)
for the built-in gigabit ethernet controller is stored inside the flash chip,
along with osboot and other configuration data. Therefore, installing
osboot will overwrite it.
along with libreboot and other configuration data. Therefore, installing
libreboot will overwrite it.
Thus, for these laptops, prebuilt osboot already contains a generic
Thus, for these laptops, prebuilt libreboot already contains a generic
MAC address in the configuration section. This address is `00:f5:f0:40:71:fe
in builds before 2018-01-16 and `00:4c:69:62:72:65` (see the ascii character
set) afterwards.
Unless you change it, your computer will boot and use it. This can lead
to network problems if you have more than one osboot computer on
to network problems if you have more than one libreboot computer on
the same layer2 network (e.g. on the same network switch). The switch
(postman) will simply not know who to deliver to as the MAC (house) addresses
will be the same.
To prevent these address clashes, you can either modify prebuilt osboot
To prevent these address clashes, you can either modify prebuilt libreboot
to use an address of your own choosing or you can change the address in your
operating system's boot scripts.

18
site/docs/hardware/macbook21.md
View File

@ -6,8 +6,8 @@ x-toc-enable: true
There is an Apple laptop called the macbook1,1 from 2006 which uses the
same i945 chipset as the ThinkPad X60/T60. A developer (Mono Moosbart) ported
the Macbook2,1 to coreboot, working alongside Vladimir Serbinenko. The ROM
images also work on the macbook1,1. osboot's support and documentation for
this is based on the osboot project, which also supports macbook2,1
images also work on the macbook1,1. libreboot's support and documentation for
this is based on the libreboot project, which also supports macbook2,1
Some macbook2,1 models are late 2006, others are early 2007.
You do not need to use external flashing equipment when flashing the MacBook2,1
@ -64,7 +64,7 @@ External flashing
macbook1,1 requires external flashing, if running the default Apple firmware.
macbook2,1 can be flased internally, regardless.
If running coreboot, osboot or osboot, you can already internally re-flash.
If running coreboot or libreboot you can already internally re-flash.
[This page shows disassembly
guides](https://www.ifixit.com/Device/MacBook_Core_2_Duo)
@ -79,9 +79,9 @@ motherboard](https://www.ifixit.com/Guide/MacBook+Core+2+Duo+PRAM+Battery+Replac
Refer to the following guide:\
[Externally rewrite 25xx NOR flash via SPI protocol](../install/spi.md)
You need to replace OS X with GNU+Linux before flashing osboot. (OSX
won't run at all in osboot), if you wish to internally flash on a macbook21.
osboot won't boot OSX either (well, maybe with Tianocore it would, but that's
You need to replace OS X with GNU+Linux before flashing libreboot. (OSX
won't run at all in libreboot), if you wish to internally flash on a macbook21.
libreboot won't boot OSX either (well, maybe with Tianocore it would, but that's
untested and OSX is inferior to GNU+Linux). In general you should think of
your Macbook like a regular laptop, for the purposes of anything coreboot.
@ -113,7 +113,7 @@ There is one mouse button only, however multiple finger tapping
works. Battery life is poor compared to X60/T60. The Apple logo on the
back is a hole, exposing the backlight, which means that it glows. You
should [cover it up](http://cweiske.de/tagebuch/tuxbook.htm).
The MacBook2,1 consumes more power with osboot than with the Apple EFI firmware, which means it overheats a lot.
The MacBook2,1 consumes more power with libreboot than with the Apple EFI firmware, which means it overheats a lot.
*The MacBook2,1 comes with a webcam which does not work with free
software. Webcams are a privacy and security risk; cover it up! Or
@ -122,11 +122,11 @@ remove it.*
Make it overheat less
---------------------
NOTE: on newer osboot revisions, this section is less relevant, because C3
NOTE: on newer libreboot revisions, this section is less relevant, because C3
states are supported now. However, this section may still be useful, so it will
be retained.
The MacBook2,1 overheats a lot with osboot, we still don't know why but a simple workaround is to install macfanctld.
The MacBook2,1 overheats a lot with libreboot, we still don't know why but a simple workaround is to install macfanctld.
Macfanctld is available on the default repos of many distributions.

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

@ -13,7 +13,7 @@ There are two possible flash chip sizes for the R400: 4MiB (32Mbit) or
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The R400 laptops come with the ME (and sometimes AMT in addition)
before flashing osboot. osboot disables and removes it by using a
before flashing libreboot. libreboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
@ -25,7 +25,7 @@ EC update {#ecupdate}
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
osboot, so we don't actually provide that, but if you still have
libreboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
@ -33,7 +33,7 @@ will update both the BIOS and EC version. See:
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running osboot is unknown. osboot
update the EC firmware while running libreboot is unknown. libreboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. bettery battery

4
site/docs/hardware/r500.md
View File

@ -11,8 +11,8 @@ The chip is 4MiB NOR flash (SPI protocol) is SOIC8 form factory.
Refer to the following guide:\
[Externally rewrite 25xx NOR flash via SPI protocol](../install/spi.md)
Unlike other GM45+ICH9M thinkpads in osboot, the R500 doesn't have an Intel
PHY (for Gigabit Ethernet). However, osboot still includes an Intel flash
Unlike other GM45+ICH9M thinkpads in libreboot, the R500 doesn't have an Intel
PHY (for Gigabit Ethernet). However, libreboot still includes an Intel flash
descriptor, but with just the descriptor and BIOS region. The `ich9gen` program
supports this fully.

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

@ -16,7 +16,7 @@ There are two possible flash chip sizes for the T400: 4MiB (32Mbit) or
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The T400 laptops come with the ME (and sometimes AMT in addition)
before flashing osboot. osboot disables and removes it by using a
before flashing libreboot. libreboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
@ -28,7 +28,7 @@ EC update {#ecupdate}
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
osboot, so we don't actually provide that, but if you still have
libreboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
@ -36,7 +36,7 @@ will update both the BIOS and EC version. See:
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running osboot is unknown. osboot
update the EC firmware while running libreboot is unknown. libreboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. bettery battery

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

@ -18,7 +18,7 @@ There are two possible flash chip sizes for the T500: 4MiB (32Mbit) or
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The T500 laptops come with the ME (and sometimes AMT in addition)
before flashing osboot. osboot disables and removes it by using a
before flashing libreboot. libreboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
@ -30,7 +30,7 @@ EC update {#ecupdate}
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
osboot, so we don't actually provide that, but if you still have
libreboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
@ -38,7 +38,7 @@ will update both the BIOS and EC version. See:
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running osboot is unknown. osboot
update the EC firmware while running libreboot is unknown. libreboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. bettery battery

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

@ -10,7 +10,7 @@ It is believed that all X200 laptops are compatible. X200S and X200
Tablet will also work, [depending on the configuration](#x200s).
It may be possible to put an X200 motherboard in an X201 chassis, though this
is currently untested by the osboot project. The same may also apply between
is currently untested by the libreboot project. The same may also apply between
X200S and X201S; again, this is untested. *It's most likely true.*
There are two possible flash chip sizes for the X200: 4MiB (32Mbit) or
@ -18,7 +18,7 @@ There are two possible flash chip sizes for the X200: 4MiB (32Mbit) or
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The X200 laptops come with the ME (and sometimes AMT in addition)
before flashing osboot. osboot disables and removes it by using a
before flashing libreboot. libreboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
@ -30,7 +30,7 @@ EC update {#ecupdate}
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
osboot, so we don't actually provide that, but if you still have
libreboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
@ -40,7 +40,7 @@ will update both the BIOS and EC version. See:
- [X200t BIOS Update](http://pcsupport.lenovo.com/au/en/products/laptops-and-netbooks/thinkpad-x-series-tablet-laptops/thinkpad-x200-tablet/downloads/ds018814)
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running osboot is unknown. osboot
update the EC firmware while running libreboot is unknown. libreboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. better battery

16
site/docs/index.md
View File

@ -2,28 +2,28 @@
title: Documentation
...
Always check [osboot.org](https://osboot.org/) for the latest updates to
osboot. News, including release announcements, can be found in
Always check [libreboot.org](https://libreboot.org/) for the latest updates to
libreboot. News, including release announcements, can be found in
the [main news section](../news/).
[Answers to Frequently Asked Questions about osboot](../faq.md).
[Answers to Frequently Asked Questions about libreboot](../faq.md).
Installing osboot
Installing libreboot
====================
- [What systems can I use osboot on?](hardware/)
- [How to install osboot](install/)
- [What systems can I use libreboot on?](hardware/)
- [How to install libreboot](install/)
Documentation related to operating systems
============================
- [GNU+Linux Guides](gnulinux/)
- [How to install BSD on a osboot system](bsd/)
- [How to install BSD on a libreboot system](bsd/)
Information for developers
==========================
- [How to compile the osboot source code](build/)
- [How to compile the libreboot source code](build/)
- [Build system developer documentation](maintain/)
- [GRUB payload](grub/)

2
site/docs/install/d510mo.md
View File

@ -2,7 +2,7 @@
title: D510MO flashing tutorial
...
This guide is for those who want osboot on their Intel D510MO
This guide is for those who want libreboot on their Intel D510MO
motherboard while they still have the original BIOS present.
NOTE: D410PT is another designation and it's the same board. Flash the same ROM.

2
site/docs/install/d945gclf.md
View File

@ -2,7 +2,7 @@
title: Intel D945GCLF flashing tutorial
...
This guide is for those who want osboot on their Intel D945GCLF
This guide is for those who want libreboot on their Intel D945GCLF
motherboard while they still have the original BIOS present.
D945GCLF2D also reported working by a user.

8
site/docs/install/ga-g41m-es2l.md
View File

@ -2,7 +2,7 @@
title: GA-G41M-ES2L flashing tutorial
...
This guide is for those who want osboot on their Intel GA-G41M-ES2L
This guide is for those who want libreboot on their Intel GA-G41M-ES2L
motherboard while they still have the original BIOS present.
Flash chip size {#flashchips}
@ -40,15 +40,15 @@ GNU+Linux. There are 2 flash chips (one is backup).
Flash the first chip:
./flashrom -p internal:dualbiosindex=0 -w osboot.rom
./flashrom -p internal:dualbiosindex=0 -w libreboot.rom
Flash the second chip:
./flashrom -p internal:dualbiosindex=1 -w osboot.rom
./flashrom -p internal:dualbiosindex=1 -w libreboot.rom
NOTE: you can still boot the system with just the main flash chip
connected, after desoldering the backup chip. This has been tested while
osboot was already installed onto the main chip.
libreboot was already installed onto the main chip.
NOTE: If you don't flash both chips, the recovery program from the default
factory BIOS will kick in and your board will be soft bricked. Make sure that

58
site/docs/install/ich9utils.md
View File

@ -13,15 +13,15 @@ into the start of a ROM, where everything after that is the BIOS region. These
are special descriptors with the Intel ME region disabled, and Intel ME itself
fully disabled.
ich9utils is handled by the `osbmk` (osboot-make) build system, but the code
ich9utils is handled by the `lbmk` (libreboot-make) build system, but the code
itself is hosted in a separate repository. You can check the Git repositories
linked on [../../git.md](../../git.md) if you wish to download and use it.
It is very *uncommon*, on GM45/ICH9M systems, to have an Intel Flash Descriptor
and GbE but *without* an Intel ME. On *most* of these systems (without osboot,
and GbE but *without* an Intel ME. On *most* of these systems (without libreboot,
Libreboot or coreboot), there is either descriptor+GbE+ME+BIOS or just BIOS,
where on systems with just the BIOS region an Intel GbE NIC is not present.
In osboot (and Libreboot), we provide descriptor+GbE images with Intel ME
In libreboot (and Libreboot), we provide descriptor+GbE images with Intel ME
disabled and not present in the ROM; this enables the Intel GbE NIC to be used,
while not having an Intel ME present. A consequence of this is that the
malicious features of ME (such as AMT) are not present, however the Intel ME
@ -55,17 +55,17 @@ ich9utils
=========
You can find `ich9utils` on the [Git page](../../git.md) or you can download
`osbmk` from the same page and run the following command in there:
`lbmk` from the same page and run the following command in there:
./build module ich9utils
You may also find it in the source code tar archives, on releases.
In `osbmk`, you can use the following command to generate descriptors:
In `lbmk`, you can use the following command to generate descriptors:
./build descriptors ich9m
The osboot build system will use the descriptors under `descriptors/ich9m`
The libreboot build system will use the descriptors under `descriptors/ich9m`
when building ROM images for these machines.
Alternatively, you can just clone `ich9utils` directly and run `make` in the
@ -104,7 +104,7 @@ These files contain the descriptor+GbE region and are suitable for systems
that have an Intel GbE NIC present. The flash regions (as defined by the
Intel Flash Descriptor) are set *read-write* which means that you can also
re-flash using `flashrom -p internal` in your operating system running on
that machine. This is the default setup used when osboot's build system
that machine. This is the default setup used when libreboot's build system
compiles ROM images.
Alternative versions of these files are also created, which have `ro` in the
@ -117,27 +117,27 @@ The region setup created by these descriptors is as follows:
* First 4KiB of flash is: Intel Flash Descriptor
* Next 8KiB after Descriptor: Intel GbE region
* Rest of the flash, after GbE: BIOS region (BIOS region will have osboot)
* Rest of the flash, after GbE: BIOS region (BIOS region will have libreboot)
The GbE region contains configuration data for your Intel GbE NIC. You can
find information about this in Intel datasheets, and it is very well described
in the `ich9utils` source code.
Assuming that your osboot image is named **osboot.rom**, copy the
file to where **osboot.rom** is located and then insert the
Assuming that your libreboot image is named **libreboot.rom**, copy the
file to where **libreboot.rom** is located and then insert the
descriptor+gbe file into the ROM image.
For 16MiB flash chips:
dd if=ich9fdgbe_16m.bin of=osboot.rom bs=12k count=1 conv=notrunc
dd if=ich9fdgbe_16m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
For 8MiB flash chips:
dd if=ich9fdgbe_8m.bin of=osboot.rom bs=12k count=1 conv=notrunc
dd if=ich9fdgbe_8m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
For 4MiB flash chips:
dd if=ich9fdgbe_4m.bin of=osboot.rom bs=12k count=1 conv=notrunc
dd if=ich9fdgbe_4m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
If you wish to have read-only flash (write protected flash), substitute the
above examples with descriptor+GbE images that have `ro` in the filename. RO
@ -154,13 +154,13 @@ will just supply a descriptor-less setup. Those GbE-less descriptor images
created by `ich9gen` are only 4KiB in size, and should *never be used* except
for fun, like, basically shits and/or giggles.
For shits and giggles, R500 ROM images in osboot use these no-GbE descriptor
For shits and giggles, R500 ROM images in libreboot use these no-GbE descriptor
images generated by ich9gen. However, a descriptorless setup would also work
just fine. ThinkPad R500 doesn't have an Intel PHY in it, and it instead uses
a Broadcom NIC for ethernet. In descriptorless mode, ICH9M works very similarly
to older ICH7 chipsets.
Your osboot.rom image is now ready to be flashed on the system. Refer
Your libreboot.rom image is now ready to be flashed on the system. Refer
back to [../install/\#flashrom](../install/#flashrom) for how to flash
it.
@ -176,7 +176,7 @@ Read on for more information. Use the `ro` files mentioned below, and your
flash will be read-only in software (you can still externally re-flash and read
the contents of flash).
For ease of use, osboot provides ROMs that are read-write by default. In
For ease of use, libreboot provides ROMs that are read-write by default. In
practise, you can boot a Linux kernel with access to lower memory disabled
which will make software re-flashing impossible (unless you reboot with such
memory protections disabled, e.g. `iomem=relaxed` kernel parameter).
@ -223,16 +223,16 @@ appear, if no GbE region was detected inside the ROM image. This is
usually the case, when a discrete NIC is used (eg Broadcom) instead of
Intel. Only the Intel NICs need a GbE region in the flash chip.
Assuming that your osboot image is named **osboot.rom**, copy the
**deblobbed\_descriptor.bin** file to where **osboot.rom** is located
Assuming that your libreboot image is named **libreboot.rom**, copy the
**deblobbed\_descriptor.bin** file to where **libreboot.rom** is located
and then run:
dd if=deblobbed_descriptor.bin of=osboot.rom bs=12k count=1 conv=notrunc
dd if=deblobbed_descriptor.bin of=libreboot.rom bs=12k count=1 conv=notrunc
Alternatively, if you got a the **deblobbed\_4kdescriptor.bin** file (no
GbE defined), do this:
dd if=deblobbed_4kdescriptor.bin of=osboot.rom bs=4k count=1 conv=notrunc
dd if=deblobbed_4kdescriptor.bin of=libreboot.rom bs=4k count=1 conv=notrunc
(it's very unlikely that you would ever see this. Descriptor without GbE is
very rare, probably non-existant, but theoretically possible and this functionality
@ -255,7 +255,7 @@ build `ich9gen` executable will be able to re-create the very same 12KiB
file from scratch, based on the C structs, this time **without** the
need for a` factory.rom` dump!
You should now have a **osboot.rom** image containing the correct 4K
You should now have a **libreboot.rom** image containing the correct 4K
descriptor and 8K gbe regions, which will then be safe to flash. Refer
back to [index.md/\#gm45](index.md/#gm45) for how to flash
it.
@ -285,7 +285,7 @@ Keep the original factory.rom stored safely somewhere):
Use-case: a factory.rom image modified in this way would theoretically
have no flash protections whatsoever, making it easy to quickly switch
between factory/osboot in software, without ever having to
between factory/libreboot in software, without ever having to
disassemble and re-flash externally unless you brick the device.
The sections below are adapted from (mostly) IRC logs related to early
@ -429,7 +429,7 @@ way through the 8K area, and the rest is all 0xFF. This is all
documented in the datasheet.
The GBe region starts at 0x20A000 bytes from the \*end\* of a factory
image and is 0x2000 bytes long. In osboot (deblobbed) the descriptor
image and is 0x2000 bytes long. In libreboot (deblobbed) the descriptor
is set to put gbe directly after the initial 4K flash descriptor. So the
first 4K of the ROM is the descriptor, and then the next 8K is the gbe
region.
@ -450,7 +450,7 @@ not making this stuff up...
regions on the X200 factory.rom dumps. The checksums of the backup
regions match BABA, however. We think `0xBABA` is the only correct checksum,
because those other, similar checksums were only ever found in the "backup"
GbE regions on factory ROM dumps. In osboot, we simply use `0xBABA` and
GbE regions on factory ROM dumps. In libreboot, we simply use `0xBABA` and
ensure that both 4KiB regions in GbE NVM have that checksum.
By default, the X200 (as shipped by Lenovo) actually has an invalid main
@ -471,7 +471,7 @@ Flash descriptor region {#flash_descriptor_region}
<http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-9-datasheet.pdf>
from page 850 onwards. This explains everything that is in the flash
descriptor, which can be used to understand what osboot is doing
descriptor, which can be used to understand what libreboot is doing
about modifying it.
How to deblob:
@ -495,7 +495,7 @@ There's an interesting parameter called 'ME Alternate disable', which
allows the ME to only handle hardware errata in the southbridge, but
disables any other functionality. This is similar to the 'ignition' in
the 5 series and higher but using the standard firmware instead of a
small 128K version. Useless for osboot, though.
small 128K version. Useless for libreboot, though.
To deblob GM45, you chop out the platform and ME regions and correct the
addresses in flReg1-4. Then you set meDisable to 1 in ICHSTRAP0 and
@ -514,7 +514,7 @@ How to patch the descriptor from the factory.rom dump
- Then it can be dd'd into the first 12K part of a coreboot image.
- the GBe region always starts 0x20A000 bytes from the end of the ROM
This means that osboot's descriptor region will simply define the
This means that libreboot's descriptor region will simply define the
following regions:
- descriptor (4K)
@ -532,8 +532,8 @@ If it's in descriptor mode, then the first 4 bytes will be 5A A5 F0 0F.
platform data partition in boot flash (factory.rom / lenovo bios) {#platform_data_region}
-----------------------------------------------------------------
Basically useless for osboot, since it appears to be a blob. Removing
it didn't cause any issues in osboot. We think it's just random data that
Basically useless for libreboot, since it appears to be a blob. Removing
it didn't cause any issues in libreboot. We think it's just random data that
the manufacturer can put there, to use in their firmware. Intel datasheets seem
to suggest that the platform region serves no specific function except to
provide a region in flash for the hardware manufacturer to use, for whatever

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

@ -3,18 +3,18 @@ title: Installation instructions
x-toc-enable: true
...
This section relates to installing osboot on supported targets.
This section relates to installing libreboot on supported targets.
NOTE: if running `flashrom -p internal` for software based flashing, and you
get an error related to `/dev/mem` access, you should reboot with
`iomem=relaxed` kernel parameter before running flashrom, or use a kernel that
has `CONFIG_STRICT_DEVMEM` not enabled.
osboot flashing can be risky business. Please ensure that you have external
libreboot flashing can be risky business. Please ensure that you have external
flashing equipment, in case anything goes wrong. The general rule of thumb with
firmware is this: if it's non-free, replace it, but if you're already running
free firmware and it works nicely for you, you do not need to update it.
However, you might want to tweak it or try out newer releases of osboot if
However, you might want to tweak it or try out newer releases of libreboot if
they have bug fixes for your board, and/or new security fixes.
If you're already running libre firmware on your board, you should decide for
@ -28,7 +28,7 @@ Init types and display mode
---------------------------
NOTE: regardless of init type, on desktops, an external/add-on GPU can always
be used. On laptop hardware in osboot, libgfxinit will always be used. On
be used. On laptop hardware in libreboot, libgfxinit will always be used. On
desktop/server hardware, if available, libgfxinit will also always be used by
default (but in that setup, SeaBIOS can be used if you want to use an add-on
graphics card, e.g. on KCMA-D8, KGPE-D16, GA-G41M-ES2L)
@ -60,11 +60,11 @@ int10h text mode is used on startup.
### vgarom
NOTE: no configs in osboot are currently available that use this method.
NOTE: no configs in libreboot are currently available that use this method.
With this method, coreboot is finding, loading and executing a VGA option ROM
for your graphics hardware. This would not be done on laptops, because that
implies supplying non-free binary blobs in osboot, so this setup would only
implies supplying non-free binary blobs in libreboot, so this setup would only
ever be provided on desktop hardware where no GPU exists or where it is
desirable for you to use an external/add-on graphics card
@ -84,7 +84,7 @@ In this setup, coreboot is neither implementing libgfxinit / native graphics
initialization nor is it finding/loading/executing VGA option ROMs. In this
setup, SeaBIOS would most likely be used for that.
The `normal` setup is supported in the osboot build system, but not
The `normal` setup is supported in the libreboot build system, but not
currently used. It is there for desktop hardware that will be added in the
future, where those desktop boards do not have an onboard GPU and therefore an
add-on GPU is always used..
@ -132,9 +132,9 @@ following article:
[ich9utils documentation](ich9utils.md)
osboot puts a default MAC address in the available ROM images, but this is
libreboot puts a default MAC address in the available ROM images, but this is
a generic MAC address and it's identical on every ROM image. Technically, you
can use it but if you encounter other osboot users on the same ethernet
can use it but if you encounter other libreboot users on the same ethernet
switch, using the same physical network as you, you will encounter a MAC
address conflict.
@ -142,7 +142,7 @@ NOTE: R500 thinkpads do not have an Intel gigabit ethernet NIC, so on that
laptop you can just flash the default ROM and you do not have to worry.
There are also some Intel X4X platforms that use an ICH10 southbridge,
supported in osboot, but these are flashed in a *descriptorless* setup,
supported in libreboot, but these are flashed in a *descriptorless* setup,
which means that the MAC address is irrelevant (either there will be an Intel
PHY module that is now unusable, and you use an add-on card, or it doesn't use
an Intel PHY module and the onboard NIC is usable).
@ -170,7 +170,7 @@ carefully.
Run flashrom on host CPU
------------------------
You can simply take any ROM image from the osboot project, and flash it.
You can simply take any ROM image from the libreboot project, and flash it.
Boot a GNU+Linux distribution on the target device, and install flashrom.
In some cases, this is not possible or there are other considerations. Please
@ -195,7 +195,7 @@ ensure that you get the same checksums. Check each dump using `sha1sum`
How to erase and rewrite the chip contents:
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w osboot.rom
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w libreboot.rom
If you are re-flashing a GM45+ICH9M laptop (e.g. ThinkPad X200/X200S/X200T,
T400, T500, R400, W500 etc - but not R500), you should run the ich9gen utility
@ -244,7 +244,7 @@ Intel NIC.
[You must flash it externally](spi.md)
D410PT is more or less the same board as D510MO, but we would like more info
about this board. If you have a D410PT mainboard, please contact the osboot
about this board. If you have a D410PT mainboard, please contact the libreboot
project via IRC and ping `leah` before you flash it. When you do so, please
reference this paragraph on this web page.
@ -257,7 +257,7 @@ and you must flash both chips. Refer to the guide:\
#### Macbook1,1 running non-free Apple EFI firmware
This laptop requires external flashing. Remove the mainboard and refer to
the [external flashing guide](spi.md); if osboot is already running, you
the [external flashing guide](spi.md); if libreboot is already running, you
can flash internally.
MacBook2,1 can be flashed internally.
@ -287,7 +287,7 @@ example of the push pin as a proof of concept:
#### ThinkPad X60/X60S/X60T/T60 with Lenovo BIOS {#flashrom_lenovobios}
You can just get bucts from the osboot project, same thing for the patched
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
has statically compiled executables. They still work just fine on modern
systems, and they can be used for this purpose.
@ -307,7 +307,7 @@ Download and build flashrom, 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 osboot, using flashrom running on the host
You can replace Lenovo BIOS with libreboot, using flashrom running on the host
CPU. However, there are some considerations.
Firstly, make sure that the yellow CMOS battery is installed, and functioning
@ -330,10 +330,10 @@ can set the machine to boot using that lower 64KiB bootblock, which is
read-write. You do this by setting the BUC.TS register to 1, using the `bucts`
program referenced below.
The osboot ROM images already have the upper 64KiB bootblock copied to the lower
The libreboot ROM images already have the upper 64KiB bootblock copied to the lower
one, so you don't have to worry about copying it yourself.
If you build flashrom using the osboot build system, there will be three
If you build flashrom using the libreboot build system, there will be three
binaries:
* `flashrom`
@ -408,7 +408,7 @@ Assuming that everything went well:
Flash the ROM for a second time. For this second flashing attempt, the upper
64KiB bootblock is now read-write. Use the *unpatched* flashrom binary:
sudo ./flashrom -p internal -w osboot.rom
sudo ./flashrom -p internal -w libreboot.rom
To reset bucts, do this:
@ -419,10 +419,10 @@ flashed. It is flashed if flashrom said VERIFIED when running the above
command.
If it said VERIFIED, shut down. If it didn't say VERIFIED, make sure bucts is
still set to 1, and consult the osboot project on IRC for advice, and avoid
still set to 1, and consult the libreboot project on IRC for advice, and avoid
shutting down your system until you get help.
If all went well, osboot should now be booting and you should be able to
If all went well, libreboot should now be booting and you should be able to
boot into your operating system.
If you messed up, there are external flashing instructions. See main navigation
@ -463,7 +463,7 @@ TARGET: Apple Macbook2,1, Macbook1,1 and iMac5,2 (i945 platform)
----------------------------------------------------------------
iMac5,2 is essentially the same board as Macbook2,1, and it is compatible with
osboot.
libreboot.
Refer to the following article:\
[Macbook2,1 and MacBook1,1 installation guide](../hardware/macbook21.md)

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

@ -16,7 +16,7 @@ Do not worry too much about which flash chip your programmer is connected to.
Flashrom will fail if you try to flash the wrong sized image for the chip you are connected
to.
The osboot roms released or built for haswell or ivybridge boards come as 12/16MiB roms.
The libreboot roms released or built for haswell or ivybridge boards come as 12/16MiB roms.
The size of the rom in question refers to the total size of *both* chips.
In order to flash a full rom externally, you need to split the rom into two sections to fit the size of the two chips you wish to flash.
This guide will show examples for the Thinkpad X230, but all of the information will apply to other boards.
@ -33,7 +33,7 @@ Obtaining Binary Blobs
If you have built your rom from source then all of the blobs are generally downloaded automatically.
Some boards however, do not have sources for all blobs and require manual blob extraction.
If you try to build a rom from source and osbmk fails to locate the blobs, you can extract them from an existing rom backup.
If you try to build a rom from source and lbmk fails to locate the blobs, you can extract them from an existing rom backup.
To do this, start by obtaining a full backup rom from your machine.
Once you have connected your programmer and read from both flash chips, you will have to combine the two images to a single rom.
@ -42,13 +42,13 @@ To create a readable rom file, simply concatenate the two files.
cat bottom.rom top.rom > full_backup.bin
Once you have a backup of your vendor rom, you can use osbmk to automatically extract the necessary blobs.
Once you have a backup of your vendor rom, you can use lbmk to automatically extract the necessary blobs.
The blob extraction script takes a board name as the first argument and a path to a rom as the second argument.
For example, here is how you would extract the blobs from an x230 rom backup.
./blobutil extract x230_12mb full_backup.bin
Note that the above command must be run from the root of the osbmk directory.
Note that the above command must be run from the root of the lbmk directory.
See [building instructions](/docs/build/index.html) for more details.
Injecting Blobs into an Existing Rom
@ -61,15 +61,15 @@ You must patch the release rom with the necessary blobs *and then* flash it to y
Osbmk includes a script that will automatically inject the necessary blobs into a rom file.
The script can determine the board automatically if you have not changed the name, but you can also manually set the board name with the `-b` flag.
In order to inject the necessary blobs into a rom image, run the script from the root of osbmk and point to the rom image.
In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image.
For example:
./blobutil inject -r x230_osboot.rom -b x230_12mb
./blobutil inject -r x230_libreboot.rom -b x230_12mb
Optionally, you can use this script to modify the mac address of the rom with the `-m` flag.
For example:
./blobutil inject -r x230_osboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd
./blobutil inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd
Splitting The Rom
-----------------
@ -78,8 +78,8 @@ You can use `dd` to easily split your rom into the two separate portions for
external flashing.
For example, here is how you would split a 12mb rom for installation:
dd if=osboot.rom of=top.rom bs=1M skip=8
dd if=osboot.rom of=bottom.rom bs=1M count=8
dd if=libreboot.rom of=top.rom bs=1M skip=8
dd if=libreboot.rom of=bottom.rom bs=1M count=8
You would then flash the 4MiB chip with `top.rom` and the 8MiB chip with `bottom.rom`.
For a larger rom image, the same logic would apply.

4
site/docs/install/kgpe-d16.md
View File

@ -5,7 +5,7 @@ x-toc-enable: true
Initial flashing instructions for KGPE-D16.
This guide is for those who want osboot on their ASUS KGPE-D16
This guide is for those who want libreboot on their ASUS KGPE-D16
motherboard, while they still have the proprietary ASUS BIOS present.
This guide can also be followed (adapted) if you brick you board, to
know how to recover.
@ -24,6 +24,6 @@ External programmer
Refer to [spi.md](spi.md) for a guide on how to re-flash externally.
The flash chip is in a PDIP 8 socket (SPI flash chip) on the
motherboard, which you take out and then re-flash with osboot, using
motherboard, which you take out and then re-flash with libreboot, using
the programmer. *DO NOT* remove the chip with your hands. Use a chip
extractor tool.

12
site/docs/install/r400_external.md
View File

@ -5,13 +5,13 @@ x-toc-enable: true
Initial flashing instructions for R400.
This guide is for those who want osboot on their ThinkPad R400 while
This guide is for those who want libreboot on their ThinkPad R400 while
they still have the original Lenovo BIOS present. This guide can also be
followed (adapted) if you brick your R400, to know how to recover.
Before following this section, please make sure to setup your osboot
Before following this section, please make sure to setup your libreboot
ROM properly first. Although ROM images are provided pre-built in
osboot, there are some modifications that you need to make to the one
libreboot, there are some modifications that you need to make to the one
you chose before flashing. (instructions referenced later in this guide)
Serial port {#serial_port}
@ -26,7 +26,7 @@ A note about CPUs
[ThinkWiki](http://www.thinkwiki.org/wiki/Category:R400) has a list of
CPUs for this system. The Core 2 Duo P8400 and P8600 are believed to
work in osboot. The Core 2 Duo T9600 was confirmed to work, so the
work in libreboot. The Core 2 Duo T9600 was confirmed to work, so the
T9400 probably also works. *The Core 2 Duo T5870/5670 and Celeron M
575/585 are untested!*
@ -44,7 +44,7 @@ Intel GPU; this is referred to as "Dual Graphics" (previously
you can specify that the system will use one or the other (but not
both).
osboot is known to work on systems with only the Intel GPU, using
libreboot is known to work on systems with only the Intel GPU, using
native graphics initialization. On systems with switchable graphics, the
Intel GPU is used and the ATI GPU is disabled, so native graphics
initialization works all the same.
@ -152,7 +152,7 @@ Remove the motherboard from the cage, and the SPI flash chip will be
next to the memory slots:\
![](https://av.libreboot.org/r400/0051.jpg) ![](https://av.libreboot.org/r400/0052.jpg)
Now, you should be ready to install osboot.
Now, you should be ready to install libreboot.
Read [this article](spi.md) to learn how you may flash the chip, which is near
to the RAM.

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

@ -6,7 +6,7 @@ x-toc-enable: true
This guide will teach you how to use various tools for externally reprogramming
a 25xx NOR flash via SPI protocol. This is the most common type of flash IC for
computers that coreboot runs on. Almost every system currently supported by
osboot uses this type of boot flash; the only exception is ASUS KFSN4-DRE,
libreboot uses this type of boot flash; the only exception is ASUS KFSN4-DRE,
which uses LPC flash in a PLCC32 socket, which you can simply hot-swap after
booting the vendor firmware, and then flash internally. Simple!
@ -14,7 +14,7 @@ We will be using
the [flashrom](https://flashrom.org/Flashrom) software which is written to
dump, erase and rewrite these flash chips.
osboot currently documents how to use these SPI programmers:
libreboot currently documents how to use these SPI programmers:
* Raspberry Pi (RPi)
* BeagleBone Black (BBB)
@ -22,10 +22,10 @@ osboot currently documents how to use these SPI programmers:
Many other SPI programmers exist. More of them will be documented on this page,
at a date in the future.
Most systems in osboot have to be re-flashed externally, using instructions
Most systems in libreboot have to be re-flashed externally, using instructions
on this and similar guides, the first time you flash. However, on all currently
supported systems, it's possible that you can re-flash *internally* when
osboot is running.
libreboot is running.
*Internal* flashing means that the host CPU on your system can re-program the
SPI flash, using an on-board SPI programmer (which all boards have). You do this
@ -37,7 +37,7 @@ is called *external* because it's not the *internal* one on your mainboard.
Do not use CH341A!
==================
NOR flashes on osboot systems run on 3.3V DC, and this includes data lines.
NOR flashes on libreboot systems run on 3.3V DC, and this includes data lines.
CH341A has 5V logic levels on data lines, which will damage your SPI flash and
also the southbridge that it's connected to, plus anything else that it's
connected to.
@ -222,11 +222,11 @@ If you're using a BBB or RPi, you will do this while SSH'd into those.
Flashrom is the software that you will use, for dumping, erasing and rewriting
the contents of your NOR flash.
In the osboot build system, from the Git repository, you can download and
In the libreboot build system, from the Git repository, you can download and
install flashrom. Do this after downloading the
[osbmk Git repository](https://notabug.org/osboot/osbmk):
[lbmk Git repository](https://notabug.org/libreboot/osbmk):
cd osbmk
cd lbmk
sudo ./build dependencies ubuntu2004
NOTE: debian, arch or void can be written instead of ubuntu2004. the debian
@ -258,7 +258,7 @@ binary is also available that you can simply run. Pass the `--workaround-mx`
argument in flashrom. This mitigates stability issues.
If you downloaded the flashrom source code directly, you can go into the
directory and simply type `make`. In the osboot build system, build
directory and simply type `make`. In the libreboot build system, build
dependencies are documented in script located
at `resources/scripts/build/dependencies/` which you can install
using the `apt-get` software.
@ -334,11 +334,11 @@ Writing
Next, run this command (RPi):
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -w /path/to/osboot.rom
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -w /path/to/libreboot.rom
If using BBB:
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w /path/to/osboot.rom
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w /path/to/libreboot.rom
If using BBB, you may have to use a lower speed than 512. You may also have to
re-flash several times before it works fully.
@ -359,8 +359,8 @@ If the board you are writing to has two chips you'll need to split the rom into
two sections.
For example, to split a rom for the x230, t430, t530, or t440p run:
dd if=osboot_12mb.rom bs=1M of=bottom.rom count=8
dd if=osboot_12mb.rom bs=1M of=top.rom skip=8
dd if=libreboot_12mb.rom bs=1M of=bottom.rom count=8
dd if=libreboot_12mb.rom bs=1M of=top.rom skip=8
Flash the resulting roms to each of their respective chips according to the above instructions.
@ -381,7 +381,7 @@ Do not *disconnect* your chip from the flasher until you've disconnected or
turned off the 3.3V DC power source.
BE CAREFUL that you are indeed supplying 3.3V DC to the chip. All SPI flashes
on all currently supported osboot hardware run on 3.3V DC and logic at that
on all currently supported libreboot hardware run on 3.3V DC and logic at that
level too.
It is important to CHECK that you are running on the correct voltage, when you
@ -405,7 +405,7 @@ ISP programming and VCC diode
-----------------------------
ISP means in-system programming. It's when you flash a chip that is already
mounted to the mainboard of your computer that you wish to install osboot
mounted to the mainboard of your computer that you wish to install libreboot
on.
It may be beneficial to modify the mainboard so that the SPI flash is powered
@ -437,8 +437,8 @@ the SOIC8/WSON8 if it uses that, and replace with an IC socket (for SOIC8,
WSON8 or DIP8, whatever you want), because then you could easily just insert
the flash into a breadboard when flashing.
TODO: Make a page on osboot.org, showing how to do this on all mainboards
supported by osboot.
TODO: Make a page on libreboot.org, showing how to do this on all mainboards
supported by libreboot.
GPIO pins on BeagleBone Black (BBB)
-----------------------------------
@ -457,7 +457,7 @@ This diagram shows the pinout for most modern Pi's and Pi derivatives.
The diagram shows the pins of an RPi on the left and the two SOIC clips
on the left.
![](https://av.osboot.org/rpi/wiring.webp)
![](https://av.libreboot.org/rpi/wiring.webp)
GPIO pins on Raspberry Pi (RPi) 26 Pin
-------------------------------
@ -592,7 +592,7 @@ SOIC8/WSON8/DIP8/SOIC16 not mounted to a mainboard
If your system has lower capacity SPI flash, you can upgrade. On *most* systems,
SPI flash is memory mapped and the maximum (in practise) that you can use is a
16MiB chip. For example, KGPE-D16 and KCMA-D8 mainboards in osboot have
16MiB chip. For example, KGPE-D16 and KCMA-D8 mainboards in libreboot have
2MiB flash by default, but you can easily upgrade these. Another example is the
ThinkPad X200S, X200 Tablet and T400S, all of which have WSON8 where the best
course of action is to replace it with a SOIC8 flash chip.
@ -697,7 +697,7 @@ for flashing. You might want to de-solder the chip, using a solder vacuum
(extractor) tool, and then you can install a socket in its place. You can then
insert the DIP8 IC into the socket.
In the osboot project, we have never heard of a board where the DIP8 is
In the libreboot project, we have never heard of a board where the DIP8 is
directly soldered. It is almost always mounted in a socket.
Your DIP8 IC has the same pinout as a SOIC8 IC.
@ -713,7 +713,7 @@ can easily damage the pads that way.
WSON8 has the same pinout as SOIC8, but it's a ball mounted QFN (quad flat
pack, no leads). There are no clips for it. Sometimes referred to as QFN8
On all currently supported osboot hardware, boards that have WSON8 can also
On all currently supported libreboot hardware, boards that have WSON8 can also
have a SOIC8 because the pads are long enough to accomodate either type of
chip.
@ -825,14 +825,14 @@ This page and the photos on it are available under
Check the Git repository for history of who owns what part of the document.
Some of these resources originate from the *old* Libreboot git repository,
before Libreboot split into separate repositories that include its `osbmk`
before Libreboot split into separate repositories that include its `lbmk`
repository.
Photos showing a BeagleBone Black are under the normal GNU Free Documentation
license like other pages and images on this website, or you can use them under
the CC-BY-SA 4.0 license if you wish (I, Leah Rowe, own all BBB photos shown
on this page, except for the one on the beaglebone website, and that one is
merely linked here, instead of being hosted on the av.osboot.org server).
merely linked here, instead of being hosted on the av.libreboot.org server).
This version of the page is hosted in the `osbwww` git repository, with images
for it hosted in the `lbwww-img` repository (from libreboot).

8
site/docs/install/t400_external.md
View File

@ -5,7 +5,7 @@ x-toc-enable: true
Initial flashing instructions for T400.
This guide is for those who want osboot on their ThinkPad T400 while
This guide is for those who want libreboot on their ThinkPad T400 while
they still have the original Lenovo BIOS present. This guide can also be
followed (adapted) if you brick your T400, to know how to recover.
@ -29,7 +29,7 @@ A note about CPUs
[ThinkWiki](http://www.thinkwiki.org/wiki/Category:T400) has a list of
CPUs for this system. The Core 2 Duo P8400, P8600 and P8700 are believed
to work in osboot.
to work in libreboot.
T9600, T9500, T9550 and T9900 are all compatible, as reported by users.
@ -51,7 +51,7 @@ Intel GPU; this is referred to as "switchable graphics". In the *BIOS
setup* program for lenovobios, you can specify that the system will use
one or the other (but not both).
osboot is known to work on systems with only the Intel GPU, using
libreboot is known to work on systems with only the Intel GPU, using
native graphics initialization. On systems with switchable graphics, the
Intel GPU is used and the ATI GPU is disabled, so native graphics
initialization works all the same.
@ -171,7 +171,7 @@ also fine:\
Of course, make sure to turn on your PSU:\
![](https://av.libreboot.org/x200/disassembly/0013.jpg)
Now, you should be ready to install osboot.
Now, you should be ready to install libreboot.
Refer to the external flashing instructions [here](spi.md), and when you're
done, re-assemble your laptop.

24
site/docs/install/t440p_external.md
View File

@ -4,11 +4,11 @@ x-toc-enable: true
...
Read the [Ivybridge/Haswell common guide](/docs/install/ivy_has_common.html) if you want more information.
All of the following instructions assume that you've cloned osbmk and are operating from the
All of the following instructions assume that you've cloned lbmk and are operating from the
root of that project. To do so, run
git clone https://notabug.org/osboot/osbmk
cd osbmk
git clone https://notabug.org/libreboot/lbmk
cd lbmk
You can now follow the rest of the instructions.
@ -20,15 +20,15 @@ You must patch the release rom with the necessary blobs *and then* flash it to y
Osbmk includes a script that will automatically inject the necessary blobs into a rom file.
The script can determine the board automatically if you have not changed the name, but you can also manually set the board name with the `-b` flag.
In order to inject the necessary blobs into a rom image, run the script from the root of osbmk and point to the rom image.
In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image.
For example:
./blobutil inject -r t440p_osboot.rom -b t440p_12mb
./blobutil inject -r t440p_libreboot.rom -b t440p_12mb
Optionally, you can use this script to modify the mac address of the rom with the `-m` flag.
For example:
./blobutil inject -r t440p_osboot.rom -b t440p_12mb -m 00:f6:f0:40:71:fd
./blobutil inject -r t440p_libreboot.rom -b t440p_12mb -m 00:f6:f0:40:71:fd
Splitting The Rom
-----------------
@ -36,8 +36,8 @@ Splitting The Rom
You can use `dd` to easily split your rom into the two separate portions for
external flashing.
dd if=osboot.rom of=top.rom bs=1M skip=8
dd if=osboot.rom of=bottom.rom bs=1M count=8
dd if=libreboot.rom of=top.rom bs=1M skip=8
dd if=libreboot.rom of=bottom.rom bs=1M count=8
Flash the top chip with top.rom, and tho bottom chip with bottom.rom.
Don't worry about knowing which chip is which on a standard setup; flashrom will let you know if the
@ -48,7 +48,7 @@ Disassembly
-----------
Start by removing the back cover screws and the main battery.\
<img tabindex=1 src="https://av.osboot.org/board/t440p/t440p_back.jpg" /><span class="f"><img src="https://av.osboot.org/board/t440p/t440p_back_orig.jpg" /></span>
<img tabindex=1 src="https://av.libreboot.org/board/t440p/t440p_back.jpg" /><span class="f"><img src="https://av.libreboot.org/board/t440p/t440p_back_orig.jpg" /></span>
You can then remove the back cover by sliding it off.
Next you need to:
@ -59,14 +59,14 @@ Next you need to:
+ Remove all visible screws
*Note: the ultrabay screw will loosen, but not come out of the assembly*\
<img tabindex=1 src="https://av.osboot.org/board/t440p/t440p_nocover.jpg" /><span class="f"><img src="https://av.osboot.org/board/t440p/t440p_nocover_orig.jpg" /></span>
<img tabindex=1 src="https://av.libreboot.org/board/t440p/t440p_nocover.jpg" /><span class="f"><img src="https://av.libreboot.org/board/t440p/t440p_nocover_orig.jpg" /></span>
Now you can pull up around the sides of the bottom assembly to release it.
Pull it upwards and lift it open to the front of the machine like a clamshell.
Make sure not to break the wires connecting the assembly to the rest of the machine.\
<img tabindex=1 src="https://av.osboot.org/board/t440p/t440p_open.jpg" /><span class="f"><img src="https://av.osboot.org/board/t440p/t440p_open_orig.jpg" /></span>
<img tabindex=1 src="https://av.libreboot.org/board/t440p/t440p_open.jpg" /><span class="f"><img src="https://av.libreboot.org/board/t440p/t440p_open_orig.jpg" /></span>
You should now be able to see the two flash chips near the RAM.\
<img tabindex=1 src="https://av.osboot.org/board/t440p/t440p_chipLocation.jpg" /><span class="f"><img src="https://av.osboot.org/board/t440p/t440p_chipLocation_orig.jpg" /></span>
<img tabindex=1 src="https://av.libreboot.org/board/t440p/t440p_chipLocation.jpg" /><span class="f"><img src="https://av.libreboot.org/board/t440p/t440p_chipLocation_orig.jpg" /></span>
You can now proceed to [flashing](/docs/install/spi.html) this machine.

18
site/docs/install/t500_external.md
View File

@ -5,7 +5,7 @@ x-toc-enable: true
Initial flashing instructions for T500.
This guide is for those who want osboot on their ThinkPad T500 while
This guide is for those who want libreboot on their ThinkPad T500 while
they still have the original Lenovo BIOS present. This guide can also be
followed (adapted) if you brick your T500, to know how to recover.
@ -23,7 +23,7 @@ A note about CPUs
[ThinkWiki](http://www.thinkwiki.org/wiki/Category:T500) has a list of
CPUs for this system. The Core 2 Duo P8400, P8600 and P8700 are believed
to work in osboot. The T9600 was also tested on the T400 and
to work in libreboot. The T9600 was also tested on the T400 and
confirmed working.
T9550 and T9900 was tested by a user, and is compatible as reported in the IRC channel.
@ -53,7 +53,7 @@ Intel GPU; this is referred to as "switchable graphics". In the *BIOS
setup* program for lenovobios, you can specify that the system will use
one or the other (but not both).
osboot is known to work on systems with only the Intel GPU, using
libreboot is known to work on systems with only the Intel GPU, using
native graphics initialization. On systems with switchable graphics, the
Intel GPU is used and the ATI GPU is disabled, so native graphics
initialization works all the same.
@ -217,7 +217,7 @@ also fine:\
Of course, make sure to turn on your PSU:\
![](https://av.libreboot.org/x200/disassembly/0013.jpg)
Now, you should be ready to install osboot.
Now, you should be ready to install libreboot.
Log in as root on your BBB, using the instructions in
[bbb\_setup.html\#bbb\_access](bbb_setup.html#bbb_access).
@ -246,7 +246,7 @@ chip):
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom
Note: the `-c` option is not required in osboot's patched
Note: the `-c` option is not required in libreboot's patched
flashrom, because the redundant flash chip definitions in *flashchips.c*
have been removed.\
Now compare the 3 images:
@ -257,7 +257,7 @@ If the hashes match, then just copy one of them (the factory.rom) to a
safe place (on a drive connected to another system, not the BBB). This
is useful for reverse engineering work, if there is a desirable
behaviour in the original firmware that could be replicated in coreboot
and osboot.
and libreboot.
While there is a default MAC address inside the gbe region of flash image,
it is not one you want to use. Make sure to change the MAC address to the one
@ -265,11 +265,11 @@ that is correct for your system, for **later internal flash**,
but always remember to **flash unmodfied txtmode image first** as it is known
to work and only this variant provides memtest. You can follow instructions
at [ich9utils.md#ich9gen](ich9utils.md#ich9gen)
to change the MAC address inside the osboot image.
to change the MAC address inside the libreboot image.
Now flash it:
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/osboot/rom/image.rom -V
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V
![](https://av.libreboot.org/x200/disassembly/0015.jpg)
@ -321,7 +321,7 @@ Some T500 laptops might come with an Atheros chipset, but this is
802.11g only.
It is recommended that you install a new wifi chipset. This can only be
done after installing osboot, because the original firmware has a
done after installing libreboot, because the original firmware has a
whitelist of approved chips, and it will refuse to boot if you use an
'unauthorized' wifi card.

12
site/docs/install/t60_unbrick.md
View File

@ -9,7 +9,7 @@ your ThinkPad T60 from booting.
This section documents how to recover from a bad flash that prevents
your ThinkPad X60 from booting.
ROM images for this machine are well-tested in osboot, so bricks are rare.
ROM images for this machine are well-tested in libreboot, so bricks are rare.
The most common cause of a brick is operator error, when flashing a ROM image.
In *most* cases, the cause will be that there is no bootblock, or an invalid
one.
@ -17,9 +17,9 @@ one.
Brick type 1: bucts not reset. {#bucts_brick}
==============================
You still have Lenovo BIOS, or you had osboot running and you flashed
You still have Lenovo BIOS, or you had libreboot running and you flashed
another ROM; and you had bucts 1 set and the ROM wasn't dd'd.\* or if
Lenovo BIOS was present and osboot wasn't flashed.
Lenovo BIOS was present and libreboot wasn't flashed.
There are *2* 64KiB bootblocks possible, in the upper part of the ROM image.
By default (bucts set to 0), the top one is used. If bucts is set to 1, the
@ -44,7 +44,7 @@ two:\
![](https://av.libreboot.org/t60_dev/0006.JPG)
\*Those dd commands should be applied to all newly compiled T60 ROM
images (the ROM images in osboot binary archives already have this
images (the ROM images in libreboot binary archives already have this
applied!):
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
@ -72,7 +72,7 @@ will not boot at all.
"Unbricking" means flashing a known-good (working) ROM. The problem:
you can't boot the system, making this difficult. In this situation,
external hardware (see hardware requirements above) is needed which can
flash the SPI chip (where osboot resides).
flash the SPI chip (where libreboot resides).
Remove those screws and remove the HDD:\
![](https://av.libreboot.org/t60_dev/0001.JPG) ![](https://av.libreboot.org/t60_dev/0002.JPG)
@ -160,7 +160,7 @@ which all draw a lot of current, more than your flasher can provide.
Example command:
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w osboot.rom -V
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
If flashrom complains about multiple flash chips detected, just pass the `-c`
option as it suggests, and pick any of the chips it lists. `spispeed=4096` or

10
site/docs/install/x200_external.md
View File

@ -3,7 +3,7 @@ title: First-time ThinkPad X200 flashing
x-toc-enable: true
...
This guide is for those who want osboot on their ThinkPad X200 while
This guide is for those who want libreboot on their ThinkPad X200 while
they still have the original Lenovo BIOS present. This guide can also be
followed (adapted) if you brick your X200, to know how to recover.
@ -13,7 +13,7 @@ underneath the palm rest. You will then connect an external SPI programmer, to
re-flash the chip externally while it is powered off with the battery removed.
NOTE: This guide only applies to the regular X200. For X200S and X200 Tablet
flashing, please read other guides available on osboot.org.
flashing, please read other guides available on libreboot.org.
Flash chip size
===============
@ -55,7 +55,7 @@ Lift back the tape that covers a part of the flash chip, and then
connect the clip:\
![](https://av.libreboot.org/x200/disassembly/0008.jpg)
Now, you should be ready to install osboot.
Now, you should be ready to install libreboot.
Refer to the [SPI programming instructions](spi.md).
@ -138,13 +138,13 @@ could discover how this works, by debugging the Lenovo BIOS update utility (in
Windows), and then replicate what it is doing, with some tool for GNU+Linux,
then load a flashrom binary into memory and the ROM to flash (for the BIOS
region). You would do this with GPIO33 grounded, and the payload program would
actually flash the entire chip, with just a normal osboot image.
actually flash the entire chip, with just a normal libreboot image.
It's possible. The above is likely the only way that the Lenovo BIOS updater
program works. So if we discover precisely how to do that, then you could
just connect some pogo pins to ground GPIO33, then boot up, run some software
(which would have to be written) that does the above.
On a related note, osboot has a utility that could help with
On a related note, libreboot has a utility that could help with
investigating this:
[ich9utils.md#demefactory](ich9utils.md#demefactory)

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

@ -4,11 +4,11 @@ x-toc-enable: true
...
Read the [Ivybridge/Haswell common guide](/docs/install/ivy_has_common.html) if you want more information.
All of the following instructions assume that you've cloned osbmk and are operating from the
All of the following instructions assume that you've cloned lbmk and are operating from the
root of that project. To do so, run
git clone https://notabug.org/osboot/osbmk
cd osbmk
git clone https://notabug.org/libreboot/lbmk
cd lbmk
You can now follow the rest of the instructions.
@ -20,15 +20,15 @@ You must patch the release rom with the necessary blobs *and then* flash it to y
Osbmk includes a script that will automatically inject the necessary blobs into a rom file.
The script can determine the board automatically if you have not changed the name, but you can also manually set the board name with the `-b` flag.
In order to inject the necessary blobs into a rom image, run the script from the root of osbmk and point to the rom image.
In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image.
For example:
./blobutil inject -r x230_osboot.rom -b x230_12mb
./blobutil inject -r x230_libreboot.rom -b x230_12mb
Optionally, you can use this script to modify the mac address of the rom with the `-m` flag.
For example:
./blobutil inject -r x230_osboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd
./blobutil inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd
Splitting The Rom
-----------------
@ -36,8 +36,8 @@ Splitting The Rom
You can use `dd` to easily split your rom into the two separate portions for
external flashing.
dd if=osboot.rom of=top.rom bs=1M skip=8
dd if=osboot.rom of=bottom.rom bs=1M count=8
dd if=libreboot.rom of=top.rom bs=1M skip=8
dd if=libreboot.rom of=bottom.rom bs=1M count=8
Flash the top chip with top.rom, and tho bottom chip with bottom.rom.
Don't worry about knowing which chip is which on a standard setup; flashrom will let you know if the
@ -52,10 +52,10 @@ Start by removing the battery.
Remove every screw from the bottom of the machine marked with a keyboard/touchpad indicator.
Pry up the keyboard and separate it from the palmrest.
![](https://av.osboot.org/board/x230/palmrest.jpg)
![](https://av.libreboot.org/board/x230/palmrest.jpg)
Unplug the ribbon cable from the palmrest and pry it off as well.
![](https://av.osboot.org/board/x230/palmrest_cable.jpg)
![](https://av.libreboot.org/board/x230/palmrest_cable.jpg)
Pull up the protective cover to reveal the two soic chips for flashing.
![](https://av.osboot.org/board/x230/chipLocation.jpg)
![](https://av.libreboot.org/board/x230/chipLocation.jpg)

12
site/docs/install/x60_unbrick.md
View File

@ -6,7 +6,7 @@ x-toc-enable: true
This section documents how to recover from a bad flash that prevents
your ThinkPad X60 from booting.
ROM images for this machine are well-tested in osboot, so bricks are rare.
ROM images for this machine are well-tested in libreboot, so bricks are rare.
The most common cause of a brick is operator error, when flashing a ROM image.
In *most* cases, the cause will be that there is no bootblock, or an invalid
one.
@ -14,9 +14,9 @@ one.
Brick type 1: bucts not reset. {#bucts_brick}
==============================
You still have Lenovo BIOS, or you had osboot running and you flashed
You still have Lenovo BIOS, or you had libreboot running and you flashed
another ROM; and you had bucts 1 set and the ROM wasn't dd'd.\* or if
Lenovo BIOS was present and osboot wasn't flashed.
Lenovo BIOS was present and libreboot wasn't flashed.
There are *2* 64KiB bootblocks possible, in the upper part of the ROM image.
By default (bucts set to 0), the top one is used. If bucts is set to 1, the
@ -41,7 +41,7 @@ two:\
![](https://av.libreboot.org/x60_unbrick/0004.jpg)\
\*Those dd commands should be applied to all newly compiled X60 ROM
images (the ROM images in osboot binary archives already have this
images (the ROM images in libreboot binary archives already have this
applied!):
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
@ -68,7 +68,7 @@ will not boot at all.
"Unbricking" means flashing a known-good (working) ROM. The problem:
you can't boot the system, making this difficult. In this situation,
external hardware (see hardware requirements above) is needed which can
flash the SPI chip (where osboot resides).
flash the SPI chip (where libreboot resides).
Remove those screws:\
![](https://av.libreboot.org/x60_unbrick/0000.jpg)
@ -141,7 +141,7 @@ which all draw a lot of current, more than your programmer can provide.
Example RPi command:
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w osboot.rom -V
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
If flashrom complains about multiple flash chips detected, just pass the `-c`
option as it suggests, and pick any of the chips it lists. `spispeed=4096` or

12
site/docs/install/x60tablet_unbrick.md
View File

@ -6,7 +6,7 @@ x-toc-enable: true
This section documents how to recover from a bad flash that prevents
your ThinkPad X60 Tablet from booting.
ROM images for this machine are well-tested in osboot, so bricks are rare.
ROM images for this machine are well-tested in libreboot, so bricks are rare.
The most common cause of a brick is operator error, when flashing a ROM image.
In *most* cases, the cause will be that there is no bootblock, or an invalid
one.
@ -14,9 +14,9 @@ one.
Brick type 1: bucts not reset. {#bucts_brick}
==============================
You still have Lenovo BIOS, or you had osboot running and you flashed
You still have Lenovo BIOS, or you had libreboot running and you flashed
another ROM; and you had bucts 1 set and the ROM wasn't dd'd.\* or if
Lenovo BIOS was present and osboot wasn't flashed.
Lenovo BIOS was present and libreboot wasn't flashed.
There are *2* 64KiB bootblocks possible, in the upper part of the ROM image.
By default (bucts set to 0), the top one is used. If bucts is set to 1, the
@ -41,7 +41,7 @@ two:\
![](https://av.libreboot.org/x60t_unbrick/0008.JPG)\
\*Those dd commands should be applied to all newly compiled X60 ROM
images (the ROM images in osboot binary archives already have this
images (the ROM images in libreboot binary archives already have this
applied!):
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
@ -68,7 +68,7 @@ will not boot at all.
"Unbricking" means flashing a known-good (working) ROM. The problem:
you can't boot the system, making this difficult. In this situation,
external hardware (see hardware requirements above) is needed which can
flash the SPI chip (where osboot resides).
flash the SPI chip (where libreboot resides).
![](https://av.libreboot.org/x60t_unbrick/0000.JPG)
@ -121,7 +121,7 @@ which all draw a lot of current, more than most flashers can provide.
Example command:
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w osboot.rom -V
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
If flashrom complains about multiple flash chips detected, just pass the `-c`
option as it suggests, and pick any of the chips it lists. `spispeed=4096` or

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

@ -1,33 +1,33 @@
---
title: osbmk maintenance manual
title: lbmk maintenance manual
x-toc-enable: true
...
Automated pragmatism
====================
This manual describes the nature of `osbmk` (OSBoot MaKe), the automated
build system used to produce osboot releases. It is intended as a reference
for *osboot development*.
This manual describes the nature of `lbmk` (OSBoot MaKe), the automated
build system used to produce libreboot releases. It is intended as a reference
for *libreboot development*.
If you simply wish to compile osboot from source, you should instead refer
If you simply wish to compile libreboot from source, you should instead refer
to the [build instructions](../build/)
Generally speaking, *testing* releases of osboot will not come with
Generally speaking, *testing* releases of libreboot will not come with
documentation; if you're later using *old* testing releases, it is prudent to
check the `osbwww.git` repository on a revision from around the same time as
those releases. Future stable releases of osboot will come with a snapshot of
those releases. Future stable releases of libreboot will come with a snapshot of
the `osbwww.git` repository, for documentation pertaining to such releases. One
way to do this, all testing releases of osboot, will be to simply run `git log`
way to do this, all testing releases of libreboot, will be to simply run `git log`
on the `news/` section of `osbwww.git` and find the revision that added
the *announcement* for a given release (when available), and then you can
just reset to that revision.
As such, you should always refer to the *live* version of this page, on
osboot.org, when working on the `osbmk.git` repository; the live version is
libreboot.org, when working on the `lbmk.git` repository; the live version is
intended for development on the Git repository!
osboot blob reduction policy
libreboot blob reduction policy
============================
The coreboot software is nominally free, but it requires additional binary
@ -35,9 +35,9 @@ blobs on many supported systems. These *blobs* lack source code, and the
coreboot project does not control them, but they can be used to perform
specific initialization tasks.
The osboot project *allows* binary blobs from coreboot, but there is *still* a
The libreboot project *allows* binary blobs from coreboot, but there is *still* a
lot of nuance to precisely what is allowed. It is important that you understand
these nuances, when working on *osboot*.
these nuances, when working on *libreboot*.
[Please read the blob reduction guidelines](../../news/policy.md)
@ -45,30 +45,30 @@ lbmk
====
Libreboot *bans* binary blobs outright, in its build system. This is in stark
contrast to osboot's more pragmatic policies.
contrast to libreboot's more pragmatic policies.
Libreboot's own build system is named `lbmk`. The `osbmk` build system is a
Libreboot's own build system is named `lbmk`. The `lbmk` build system is a
direct fork of `lbmk`. For your reference:
* [Libreboot's lbmk maintenance manual](https://libreboot.org/docs/maintain/)
* [Libreboot's blob deletion policy](https://libreboot.org/news/policy.html)
These should have no bearing on osboot development, but you may wish to
educate yourself about the differences. Any changes that you submit to osboot
These should have no bearing on libreboot development, but you may wish to
educate yourself about the differences. Any changes that you submit to libreboot
may in fact be used in Libreboot aswell, and vice versa, if those changes are
either not board-specific (such as build system changes), or they are changes
made to hardware supported by both osboot and libreboot.
made to hardware supported by both libreboot and libreboot.
The reason is simple: Libreboot and osboot both have the same fundamental
The reason is simple: Libreboot and libreboot both have the same fundamental
design in their build system. They differ in only very minor aspects, but the
core logic is identical. Documentation is also shared between both projects,
lead by Leah Rowe who founded *both* projects.
What is osbmk?
What is lbmk?
==============
In the same way that Trisquel and Debian are GNU+Linux distributions, OSboot
is a **coreboot distribution**. The `osbmk` build system *is* that distro,
is a **coreboot distribution**. The `lbmk` build system *is* that distro,
providing the glue necessary to integrate coreboot plus anything else that's
needed, unifying everything in a completely automated and pre-configured
fashion, so as to provide a distribution that is ease to install and use by
@ -76,18 +76,18 @@ non-technical users.
In the past, installation of coreboot **required** extensive amounts of
configuration by the user, because there was no automation available. It was a
problem, and one that `osbmk` has *solved*; it is a problem, because most users
simply want to *install* coreboot without giving it much thought. The `osbmk`
problem, and one that `lbmk` has *solved*; it is a problem, because most users
simply want to *install* coreboot without giving it much thought. The `lbmk`
build system is written for *those* people, while also providing some
flexibility for those who do want to tinker and get their hands dirty.
The `osbmk` build system is designed to be simple. Each part of it is its own
The `lbmk` build system is designed to be simple. Each part of it is its own
separate program, which is to run independently. *Write one program that does
one thing well*.
Technically, `osbmk` isn't necessarily a build system, but rather, a handful of
Technically, `lbmk` isn't necessarily a build system, but rather, a handful of
small scripts that run other scripts, or even C programs if you wish. What
makes `osbmk` *be* `osbmk` is what each individual script does, and how scripts
makes `lbmk` *be* `osbmk` is what each individual script does, and how scripts
interact with or call each other to produce working ROM images. It takes
a *light touch* approach, providing only the most minimal glue necessary to
build working ROM images that the user can install, with sane defaults, while
@ -96,60 +96,60 @@ describing how to do just that. User-friendly documentation is provided, with
simple installation steps, automating as much of it as possible.
*This* document is different. The document you're reading right now is written
for *technical* users who want to know how osboot is put together.
for *technical* users who want to know how libreboot is put together.
The osbmk design also helps to ease copyright licensing and compliance, because
each part of osbmk is literally its own separate program. With this design, it
The lbmk design also helps to ease copyright licensing and compliance, because
each part of lbmk is literally its own separate program. With this design, it
means that most scripts do not directly link/embed/include each other. Because
of this, it's much easier to have different licenses in use for different
files. Generally speaking, osbmk is GNU GPLv3+, but it's perfectly OK, for
files. Generally speaking, lbmk is GNU GPLv3+, but it's perfectly OK, for
example, to add files that are GPLv2 or other licenses. By comparison, if you
were to have a C program under GPLv3, you could not \#include C libraries that
are GPLv2, at least not directly, or there would be many pitfalls to avoid at
the very least. With osbmk's design, you can think of it as like when you have
the very least. With lbmk's design, you can think of it as like when you have
many programs running in your operating system, and not all of those programs
are under the same license, and most of those different licenses are not
compatible with each other; this is perfectly OK there, and it's OK here too.
The purpose of this document is to (hopefully) cause you to understand the
entire build system in osboot, so that you can contribute patches or
entire build system in libreboot, so that you can contribute patches or
otherwise make whatever changes you like. As such, this is a reference guide
for osboot development.
for libreboot development.
OSboot is a *coreboot distro*, focusing on integration. As such, direct
development on software such as coreboot, GNU GRUB, SeaBIOS etc should ideally
be done upstream, or if it's a project hosted by osboot (such as ich9utils)
be done upstream, or if it's a project hosted by libreboot (such as ich9utils)
developed in the corresponding separate repository.
This document is written for developers and power users alike, or otherwise for
anyone who is curious enough to learn more about what *makes* osboot!
anyone who is curious enough to learn more about what *makes* libreboot!
A major planned addition to osbmk in the future is: use it to implement a small
A major planned addition to lbmk in the future is: use it to implement a small
busybox+linux distribution, with musl libc, plus u-root, and implement a
linux-based bootloader setup similar to Heads, but do it *osbmk-style*. The
osbmk build system is designed for absolute simplicity and modularity, making
linux-based bootloader setup similar to Heads, but do it *lbmk-style*. The
lbmk build system is designed for absolute simplicity and modularity, making
it easy to understand and maintain. It intentionally avoids use of rather
complicated programs such as GNU Autoconf; the Makefile in osbmk is just bolted
on but it not required. The `osbmk` build system is a *non-design*; it evolved
complicated programs such as GNU Autoconf; the Makefile in lbmk is just bolted
on but it not required. The `lbmk` build system is a *non-design*; it evolved
over time, into what it is today. Its modularity and simplicity of non-design
allows you to easily rewrite large parts of it, whenever you want to do so.
osbmk is largely written in GNU BASH, and this is unlikely to change in the
future. However, osbmk integrates several projects such as coreboot, GNU GRUB
or SeaBIOS, and these all have *their* own build systems aswell. The `osbmk`
lbmk is largely written in GNU BASH, and this is unlikely to change in the
future. However, lbmk integrates several projects such as coreboot, GNU GRUB
or SeaBIOS, and these all have *their* own build systems aswell. The `lbmk`
build system is the glue that puts all of these together to produce ROM images
for users, in a completely automated fashion. The purpose of `osbmk` is to
for users, in a completely automated fashion. The purpose of `lbmk` is to
provide an *unattended* build process, with as little user interaction as
possible. Thus, `osbmk` is an *automated build system*. It says on the osboot
home page that osboot is a *coreboot distribution* in much the same way that
Trisquel is a *GNU+Linux distribution*, and `osbmk` is what implements that!
possible. Thus, `lbmk` is an *automated build system*. It says on the libreboot
home page that libreboot is a *coreboot distribution* in much the same way that
Trisquel is a *GNU+Linux distribution*, and `lbmk` is what implements that!
Continue reading, and you will learn of each file contained in `osbmk`. This
document largely pertains to the version of `osbmk` as hosted in `osbmk.git`,
Continue reading, and you will learn of each file contained in `lbmk`. This
document largely pertains to the version of `lbmk` as hosted in `osbmk.git`,
but this manual also covers source code archives containing the full downloaded
set of modules such as coreboot and GRUB.
In general, it is advisable to open *every* file in osbmk, after you downloaded
In general, it is advisable to open *every* file in lbmk, after you downloaded
it (from the Git repository), and study the logic in great detail. This manual
attempts to explain all of it, and provide a general idea, but nothing beats
simply *studying* the logic directly.
@ -157,15 +157,15 @@ simply *studying* the logic directly.
AUTOMATED automation
====================
Every part of osbmk checks if the prerequisite steps are done, and does them
Every part of lbmk checks if the prerequisite steps are done, and does them
automatically if not. The `roms_helper` script is no different; for example, it
automatically downloads coreboot if not present, aswell as GRUB and everything
else. You can run each and every part of osbmk without having to worry about
else. You can run each and every part of lbmk without having to worry about
running something before it, because it is handled automatically; if that is
ever not the case, it's a bug that should be fixed immediately (in Libreboot
20160907, such fine tuned automation did not exist and you did have to run
specific parts of the build system manually, in a precise order, but this is
no longer the case in modern `lbmk` or `osbmk`).
no longer the case in modern `lbmk` or `lbmk`).
Another example: if you run `./build payload grub` but `./build module grub` is
not completed, it will automatically run that first, to produce
@ -175,40 +175,40 @@ Another example: if you run `./build boot roms` and crossgcc isn't yet built
for the revision used on each given board, it will automatically compile that
version of it, using *that* coreboot tree's own build system to do it.
This level of automation means that modern `lbmk` and `osbmk` are both much
This level of automation means that modern `lbmk` and `lbmk` are both much
easier to use, compared to the build system present in Libreboot 20160907.
Massive improvements to that build system were made, during most of 2021, when
implementing both the `osbmk` *and* `lbmk` build systems.
implementing both the `lbmk` *and* `lbmk` build systems.
All sections below pertain to actual files in osbmk:
All sections below pertain to actual files in lbmk:
COPYING
=======
This file contains a copy of the GNU General Public License, version 3.0. It is
the license that most parts of `osbmk` are released under.
the license that most parts of `lbmk` are released under.
Makefile
========
For use with GNU Make, this is a frontend to `osbmk`, which can be used to run
various commands in `osbmk`.
For use with GNU Make, this is a frontend to `lbmk`, which can be used to run
various commands in `lbmk`.
Use of this file is purely optional, and largely beneficial if you simply want
to build all of `osbmk` (just run `make` when the current work directory is the
root directory of `osbmk`).
to build all of `lbmk` (just run `make` when the current work directory is the
root directory of `lbmk`).
README.md
=========
This file contains a brief description of osboot, along with information
This file contains a brief description of libreboot, along with information
about the project
build
=====
This is the main BASH script, part of `osbmk`, used for running most `osbmk`
commands. You could say that this file *is* `osbmk`. Run `./build help` for
This is the main BASH script, part of `lbmk`, used for running most `osbmk`
commands. You could say that this file *is* `lbmk`. Run `./build help` for
usage instructions.
It calls scripts in `resources/scripts/build/`. For example, the
@ -246,7 +246,7 @@ You may also refer to the [build instructions](../build)
download
========
This is the main BASH script for downloading various components used by `osbmk`.
This is the main BASH script for downloading various components used by `lbmk`.
For example, this script downloads coreboot. Scripts called by `download` may
also apply patches and such, to the corresponding project; for example, it will
apply custom patches to GNU GRUB.
@ -294,18 +294,18 @@ This would run:
projectname
===========
This file contains a single line of text, with the string "osboot".
This file contains a single line of text, with the string "libreboot".
If you were to fork osboot, you could very easily just modify this file, so
as to rename your fork in a largely automated way. Many parts of osbmk use this
If you were to fork libreboot, you could very easily just modify this file, so
as to rename your fork in a largely automated way. Many parts of lbmk use this
file.
resources/coreboot/
===================
This directory contains configuration, patches and so on, for each mainboard
supported in the `osbmk` build system. These directories contain such
configuration, so that `osbmk` can build working ROM images.
supported in the `lbmk` build system. These directories contain such
configuration, so that `lbmk` can build working ROM images.
The scripts in `resources/scripts/build/boot/` make heavy use of this
directory.
@ -348,9 +348,9 @@ be `coreboot/bar/`. ALSO:
FUN FACT: such references are infinitely checked until resolved. For
example, `foo` can refer to `bar` and `bar` can refer to `baz` but if there is
an infinite loop, this is detected and handled by `osbmk`. For example,
an infinite loop, this is detected and handled by `lbmk`. For example,
if `bar` refers to `foo` which refers back to `bar`, this is not permitted
and will throw an error in `osbmk`.
and will throw an error in `lbmk`.
The `romtype` entry largely defines what `./build boot roms` does once the ROM
is built; for example, `romtype="4MiB ICH9 IFD NOR flash"` would specify that
@ -358,13 +358,13 @@ an Intel Flash Descriptor for ICH9M, generated by `ich9gen`, would have to be
inserted.
The `cbrevision` entry defines which coreboot revision to use, from the
coreboot Git repository. *At present, osbmk only supports use of the official
coreboot Git repository. *At present, lbmk only supports use of the official
repository from the upstream coreboot project*.
The `arch` entry specifies which CPU architecture is to be used: currently
recognized entries are `x86_32`, `x86_64` and `ARMv7`. *At present, setting it
to ARMv7 only means that crossgcc-arm will be compiled, but no support for
actually building ROMs exists in osbmk exists yet, except for 32-bit and 64-bit
actually building ROMs exists in lbmk exists yet, except for 32-bit and 64-bit
x86 machines.*
The `payload_grub` entry specifies whether or not GNU GRUB is to be included in
@ -408,7 +408,7 @@ Configuration file names can be as follows:
Information pertaining to this can be found on
the [installation manual](../install/)
In `osbmk`, a board-specific directory under `resources/coreboot/` should never
In `lbmk`, a board-specific directory under `resources/coreboot/` should never
specify a coreboot revision. Rather, a directory *without* coreboot configs
should be created, specifying a coreboot revision. For example, the
directory `resources/coreboot/default/` specifies a coreboot revision. In the
@ -417,7 +417,7 @@ specify `cbtree="default"` but without specifying a coreboot revision (this
is specified by `resources/coreboot/default/board.cfg`).
When you create a coreboot configuration, you should set the payload to *none*
because `osbmk` itself will assume that is the case, and insert payloads itself.
because `lbmk` itself will assume that is the case, and insert payloads itself.
Configurations with `libgfxinit` will use coreboot's native graphics init code
if available on that board. If the file name has `txtmode` in it, coreboot
@ -438,7 +438,7 @@ the VGA ROM (on an add-on graphics card, as opposed to onboard chipset), you
should have a *separate* directory just for that, under `resources/coreboot/`;
another directory for that board will have configs with `libgfxinit`. HOWEVER:
It *is* supported in osbmk to have SeaBIOS used, on either setup. In the
It *is* supported in lbmk to have SeaBIOS used, on either setup. In the
directory `resources/seabios/` there are SeaBIOS configs for both; the vgarom
one sets VGA hardware type to *none* while the libgfxinit one sets it
to *coreboot linear framebuffer*. However, if you use SeaBIOS on a setup with
@ -448,7 +448,7 @@ SeaBIOS, but the board has libgfxinit, it is recommended that you do it from
a `libgfxinit` ROM.
HOWEVER: there's no hard and fast rule. For example, you could make a vgarom
configuration, on a board in osbmk, but in its coreboot configuration, don't
configuration, on a board in lbmk, but in its coreboot configuration, don't
enable native init *or* oproms, and do SeaBIOS-only on that board.
On `vgarom` setups, coreboot can be configured to start with a high resolution
@ -481,7 +481,7 @@ This and other documents from coreboot shall help you to understand *coreboot*.
You create a config, for `resources/coreboot/BOARDNAME/configs`, by running
the `make menuconfig` command in the *coreboot* build system. You should do
this after running `./download coreboot` in osbmk.
this after running `./download coreboot` in lbmk.
You can simply clone coreboot upstream, add whatever patches you want, and
then you can make your config. It will appear afterwards in a file
@ -495,15 +495,15 @@ The *base* revision, upon which any custom patches you wrote are applied,
shall be the `cbrevision` entry.
REMINDER: Do not enable a payload in coreboot's build system. Set it
to *none*, and enable whatever payload you want in osbmk.
to *none*, and enable whatever payload you want in lbmk.
If a payload is not supported in osbmk, patches are very much welcome! It is
the policy of osboot, to only ever use the *coreboot* build system inside
If a payload is not supported in lbmk, patches are very much welcome! It is
the policy of libreboot, to only ever use the *coreboot* build system inside
coreboot, but not use any of *coreboot's* own integration for payloads. It is
far more flexible and *robust* to handle payloads externally, relative to the
coreboot build system.
Scripts exist in `osbmk` for automating the modification/updating of *existing*
Scripts exist in `lbmk` for automating the modification/updating of *existing*
configs, but not for adding them. Adding them is to be done manually, based on
the above guidance.
@ -524,8 +524,8 @@ the command `./download coreboot`, those patches will be applied chronologically
in alphanumerical order as per patch file names.
The patch files should be named with `.patch` file extensions. All other files
will be ignored. By having `osbmk` do it this way, you could add a `README` file
for instance, and `osbmk` will not erroneously try to apply `README` as though
will be ignored. By having `lbmk` do it this way, you could add a `README` file
for instance, and `lbmk` will not erroneously try to apply `README` as though
it were a patch file. This might be useful if you have a *lot* of patches, and
you want to provide some explanations about specific files.
@ -556,7 +556,7 @@ resources/grub/keymap/
======================
This directory contains keymaps for GRUB. They allow for different keyboard
layouts to be used. The `osbmk` build system uses these to produce ROM images
layouts to be used. The `lbmk` build system uses these to produce ROM images
with various keyboard layouts used by default, when the GRUB payload is to be
used.
@ -627,7 +627,7 @@ for `romtype`:
* `4MiB IFD BIOS region` will cause only the upper 4MB section of the ROM
to be included in a release. This option is largely deprecated, a hangover
from osboot, which also no longer uses this option on any boards, and it is
from libreboot, which also no longer uses this option on any boards, and it is
thus subject for removal.
* `d8d16sas` will cause *fake* (empty) files named `pci1000,0072.rom`
and `pci1000,3050.rom` to be inserted in CBFS. This prevents SeaBIOS from
@ -654,7 +654,7 @@ for `romtype`:
part). In all cases, the default *ME* (Intel Management Engine) region is
disabled, as is the ME itself, based on bits set to disable it in the Intel
Flash Descriptor. The descriptor is used in such a setup, because on all
such boards in osboot, GbE NVM is needed to get gigabit ethernet working
such boards in libreboot, GbE NVM is needed to get gigabit ethernet working
correctly; it is the sole reason `ich9gen` was written, because it is
otherwise possible to boot these machines in a *descriptorless* setup, where
ICH9M behaves similarly to ICH7: all one region of flash, for the boot
@ -690,14 +690,14 @@ used, in which case the option is set to *0* (disabled) because coreboot is
then expected to handle option ROMs, and SeaBIOS should not do it.
Essentially, the `roms_helper` script makes use of each and every part of
osbmk. It is the heart of osboot.
lbmk. It is the heart of libreboot.
When the ROM is finished compiling, it will appear under a directory in `bin/`
resources/scripts/build/clean/cbutils
=====================================
This simply runs `make clean` on various utilities from coreboot, which osbmk
This simply runs `make clean` on various utilities from coreboot, which lbmk
makes use of.
Command: `./build clean cbutils`
@ -706,7 +706,7 @@ resources/scripts/build/clean/crossgcc
======================================
This runs `make crossgcc-clean` on all of the coreboot revisions present in
osbmk.
lbmk.
Command: `./build clean crossgcc`
@ -882,7 +882,7 @@ in `resources/coreboot/`.
Command: `./download coreboot`
NOTE: Unlike `lbmk`, the version of this in `osbmk` does not delete blobs at
NOTE: Unlike `lbmk`, the version of this in `lbmk` does not delete blobs at
all. It also does not delete Git history. Everything is fully preserved.
NOTE: This version of the script also performs the full git checkout in each
@ -895,7 +895,7 @@ The `lbmk` version only does this:
git submodule update --init
The coreboot project sets up its Git repository, in such a way where most blobs
are skipped if you omit `--checkout`. Since osbmk's policy is to *include*
are skipped if you omit `--checkout`. Since lbmk's policy is to *include*
these in its distribution, it makes sense to use `--checkout`.
resources/scripts/download/flashrom
@ -980,7 +980,7 @@ resources/scripts/update/seabios/configs
========================================
This runs `make oldconfig` on SeaBIOS configs. It is most useful when updating
the version of SeaBIOS used by osbmk.
the version of SeaBIOS used by lbmk.
Command: `./update seabios configs`

26
site/docs/maintain/porting.md
View File

@ -4,7 +4,7 @@ title: Porting Guide
This guide is intended for those with very little knowledge of firmware
in general and coreboot in particular.
Most boards in coreboot can be quite easily ported to osboot.
Most boards in coreboot can be quite easily ported to libreboot.
You don't need any knowledge of a particular programming language or
technology in general to port a board.
If you want to make more major contributions to the build system,
@ -21,29 +21,29 @@ or it's name (ex: thinkpad t420).
Because we're targeting chips on the PCB, we refer to all of the above terms
synonymously as `board.`
The rest of this article will refer to the board you wish to port to
osboot as `board.`
libreboot as `board.`
If `board` is not supported in coreboot then you need to start there first.
Osboot developers will generally not port new boards to coreboot on request.
If you're not sure whether your board is in coreboot check the [coreboot table of hardware.](https://coreboot.org/status/board-status.html)
If you have determined that `board` is supported by coreboot, but is not
supported by osboot, then follow the rest of this guide to try to port it yourself.
supported by libreboot, then follow the rest of this guide to try to port it yourself.
If you're still unable to port the board, or anything in this guide is
unclear, then contact osboot developers.
The best way to get in touch is via [osboot irc.](/contact.html#irc-chatroom)
unclear, then contact libreboot developers.
The best way to get in touch is via [libreboot irc.](/contact.html#irc-chatroom)
Cloning Osbmk
=============
Before you try to get any work done, you'll need to clone the osbmk (osboot make)
Before you try to get any work done, you'll need to clone the lbmk (libreboot make)
project.
To do so, you'll need to have git installed on your machine. You can then clone
the project.
git clone https://notabug.org/osboot/osbmk
git clone https://notabug.org/libreboot/lbmk
If you want more information on building osbmk see [the build instructions.](/docs/build/index.html)
If you want more information on building lbmk see [the build instructions.](/docs/build/index.html)
Coreboot Config
===============
@ -59,7 +59,7 @@ starting point.
cp -r resources/coreboot/t420_12mb/ resources/coreboot/t420s_12mb
You can then easily modify the existing coreboot configs for you board via osbmk.
You can then easily modify the existing coreboot configs for you board via lbmk.
./modify coreboot configs t420s_12mb
@ -113,7 +113,7 @@ binary blobs from a backup of your vendor rom.
You'll need a unified rom for dual chip setups; see [the ivybridge haswell guide](/docs/install/ivy_has_common.html)
for instructions on creating a unified rom image.
Extracting the blobs from a vendor rom image is automated in osbmk.
Extracting the blobs from a vendor rom image is automated in lbmk.
Simply run `./blobutil extract [board] [/path/to/backup.bin]`
For example:
@ -127,13 +127,13 @@ Getting Help
Once you have tried everything above, you might find that the board still doesn't
work.
If that is the case, then you should contact osboot developers for more help.
If that is the case, then you should contact libreboot developers for more help.
You can ping `shmalebx9` and/or `leah` on irc or submit an issue on git.
In either case, make sure to include a detailed description of everything you
tried, and what exactly happened when you tried to flash the rom.
If your board is not supported in osboot, then you can assume that osboot
If your board is not supported in libreboot, then you can assume that our
developers don't have it.
You'll therefore be expected to test roms created by osboot developers on
You'll therefore be expected to test roms created by libreboot developers on
your own machine.
In the meantime, you can always externally flash a backup of your vendor rom

2
site/docs/misc/codenames.md
View File

@ -10,7 +10,7 @@ Introduction
This document lists product codenames for some hardware.
Please note that just because a certain device is listed here does NOT mean
that it is supported in osboot. For supported devices refer to the
that it is supported in libreboot. For supported devices refer to the
installation documentation.
### A note on GPUs

30
site/docs/misc/index.md
View File

@ -10,7 +10,7 @@ High Pitched Whining Noise on Idle in Debian or Devuan
Start powertop automatically at boot time.
Included with osboot is a script called 'powertop.debian'. Run this
Included with libreboot is a script called 'powertop.debian'. Run this
as root and it will setup powertop to run with --auto-tune at boot
time. Load the file in your text editor to see how it does that.
@ -34,7 +34,7 @@ is a step towards that. Also, in some instances you will need to run
'sudo powertop --auto-tune' again. This needs to be implemented
properly in coreboot itself!
On the X60 with coreboot or osboot, there is a high pitched sound
On the X60 with coreboot or libreboot, there is a high pitched sound
when idle. So far we have use processor.max\_cstate=2 or idle=halt in
GRUB. These consume power. Stop using them!
@ -84,7 +84,7 @@ X60 Tablet it is called X6 Tablet UltraBase). For the ThinkPad T60, you
can use the "Advanced Mini Dock".
If you are using one of the ROM images with 'serial' in the name, then
you have serial port enabled in osboot and you have memtest86+
you have serial port enabled in libreboot and you have memtest86+
included inside the ROM. Connect your null modem cable to the serial
port on the dock and connect the other end to a 2nd system using your
USB Serial adapter.
@ -99,7 +99,7 @@ Y.
There are also others like Minicom but I like GNU Screen
By doing this before booting the X60/T60, you will see console output
from osboot. You will also see GRUB displaying on the serial output,
from libreboot. You will also see GRUB displaying on the serial output,
and you will be able to see MemTest86+ on the serial output aswell. You
can also configure your distro so that a terminal (TTY) is accessible
from the serial console.
@ -117,7 +117,7 @@ change the `linux` line to add instructions for enabling getty. See
Finetune backlight control on intel gpu's
=========================================
Sometimes the backlight control value (BLC\_PWM\_CTL) set by osboot
Sometimes the backlight control value (BLC\_PWM\_CTL) set by libreboot
is not ideal. The result is either flicker, which could cause nausea or
epilepsy or an uneven backlight and/or coil whine coming from the
display. To fix this a different value for the gpu reg BLC\_PWM\_CTL
@ -209,34 +209,34 @@ Power Management Beeps on Thinkpads
When disconnecting or connecting the charger, a beep occurs. When the
battery goes to a critically low charge level, a beep occurs. Nvramtool
is included in osboot, and can be used to enable or disable this
is included in libreboot, and can be used to enable or disable this
behaviour.
You need to write changes in a osboot rom image, and flash it, in order
You need to write changes in a libreboot rom image, and flash it, in order
to apply them. You can either use a pre-compiled rom image, or create an image
from the current one in your computer. See here
<https://osboot.org/docs/gnulinux/grub_cbfs.html#get-the-rom-image> for
<https://libreboot.org/docs/gnulinux/grub_cbfs.html#get-the-rom-image> for
more information on how to do that.
Once you have a osboot rom image, say 'osboot.rom', you can write
Once you have a libreboot rom image, say 'libreboot.rom', you can write
changes on the image with the following commands.
Disable or enable beeps when removing/adding the charger:
sudo ./nvramtool -C osboot.rom -w power_management_beeps=Enable
sudo ./nvramtool -C osboot.rom -w power_management_beeps=Disable
sudo ./nvramtool -C libreboot.rom -w power_management_beeps=Enable
sudo ./nvramtool -C libreboot.rom -w power_management_beeps=Disable
Disable or enable beeps when battery is low:
sudo ./nvramtool -C osboot.rom -w low_battery_beep=Enable
sudo ./nvramtool -C osboot.rom -w low_battery_beep=Disable
sudo ./nvramtool -C libreboot.rom -w low_battery_beep=Enable
sudo ./nvramtool -C libreboot.rom -w low_battery_beep=Disable
You can check that the parameters are set in the image with :
sudo ./nvramtool -C osboot.rom -a
sudo ./nvramtool -C libreboot.rom -a
Finally, you need to flash the rom with this new image. See here
<https://osboot.org/docs/gnulinux/grub_cbfs.html#with-re-flashing-the-rom>
<https://libreboot.org/docs/gnulinux/grub_cbfs.html#with-re-flashing-the-rom>
for a detailed explanation.
Get EDID: Find out the name (model) of your LCD panel

8
site/download.md
View File

@ -7,7 +7,7 @@ Future releases will be announced in the [main news section](news/).
Git repository
--------------
There are no binary releases for `osboot` yet, so you must download from the
There are no binary releases for `libreboot` yet, so you must download from the
available Git repository and compile it yourself.
Please ensure that you have the [Git](https://git-scm.com/) software installed.
@ -15,7 +15,7 @@ It is available in *most* distributions, via *package management*.
Please refer to the following resources:
* [How to download osboot from Git](git.md)
* [How to compile osboot from source](docs/build/)
* [osbmk maintenance manual](docs/maintain/)
* [How to download libreboot from Git](git.md)
* [How to compile libreboot from source](docs/build/)
* [lbmk maintenance manual](docs/maintain/)

88
site/faq.md
View File

@ -8,15 +8,15 @@ AKA Frequently Questioned Answers
Important issues
================
How to compile osboot from source
How to compile libreboot from source
------------------------------------
Refer to the [osbmk build instructions](docs/build/).
Refer to the [lbmk build instructions](docs/build/).
How does the build system work?
-------------------------------
Refer to the [osbmk maintenance manual](docs/maintain/).
Refer to the [lbmk maintenance manual](docs/maintain/).
Do not use CH341A!
------------------
@ -62,7 +62,7 @@ The ethernet doesn't work on my X200/T400/X60/T60 when I plug in it
-------------------------------------------------------------------
This was observed on some systems using network-manager. This happens
both on the original BIOS and in osboot. It's a quirk in the
both on the original BIOS and in libreboot. It's a quirk in the
hardware. On debian systems, a workaround is to restart the networking
service when you connect the ethernet cable:
@ -87,7 +87,7 @@ module without loading the option ROM.
Refer to the [linuxboot website](https://www.linuxboot.org/). This is a special
busybox+linux system, which goes in the boot flash as a coreboot payload. You
can insert it into your osboot ROM image using cbfstool, if it's big enough.
can insert it into your libreboot ROM image using cbfstool, if it's big enough.
On KCMA-D8/KGPE-D16 it's trivial to upgrade the boot flash to 16MiB, which is
more than enough to fit Linuxboot. See:\
[External flashing guide](docs/install/spi.md)
@ -97,14 +97,14 @@ which can boot other Linux kernels using kexec. It can parse GNU GRUB configs,
and it can also provide some basic UEFI features. Because it's using the Linux
kernel, this means that LinuxBoot can make use of the PIKE2008 module.
TODO: Integrate this in osboot, as a payload option, but also:
TODO: Integrate this in libreboot, as a payload option, but also:
TODO: Fork LinuxBoot, and make a version of it that uses linux-libre. Ensure
that it is a fully free distribution, so that the FSF can endorse it.
LinuxBoot is *perfect*, especially if you're setting up one of these systems to
be used as a server. LinuxBoot is *much* more flexible and configurable than
GNU GRUB, which right now is the payload that osboot prefers.
GNU GRUB, which right now is the payload that libreboot prefers.
How to save kernel panic logs on thinkpad laptops?
--------------------------------------------------
@ -174,11 +174,11 @@ the target (`target$`):
Hardware compatibility
======================
What systems are compatible with osboot?
What systems are compatible with libreboot?
-----------------------------------------------------------------------------------
Any system can easily be added, so *compatibility* merely refers to whatever
boards are integrated in the `osbmk` build system, which osboot uses.
boards are integrated in the `lbmk` build system, which libreboot uses.
Please read the [hardware compatibility list](docs/hardware/).
@ -271,7 +271,7 @@ application introduced in Q2 2013 with ME firmware version 9.0 on 4th
Generation Intel Core i3/i5/i7 (Haswell) CPUs. It allows a PC OEM to
generate an asymmetric cryptographic keypair, install the public key in
the CPU, and prevent the CPU from executing boot firmware that isn't
signed with their private key. This means that ***coreboot and osboot
signed with their private key. This means that ***coreboot and libreboot
are impossible to port*** to such PCs, without the OEM's private
signing key. Note that systems assembled from separately purchased
mainboard and CPU parts are unaffected, since the vendor of the
@ -309,7 +309,7 @@ privacy that can't be ignored.
Before version 6.0 (that is, on systems from 2008/2009 and earlier), the
ME can be disabled by setting a couple of values in the SPI flash
memory. The ME firmware can then be removed entirely from the flash
memory space. The osboot project [does this](docs/install/ich9utils.md) on
memory space. The libreboot project [does this](docs/install/ich9utils.md) on
the Intel 4 Series systems that it supports, such as the [ThinkPad
X200](../docs/install/x200_external.md) and [ThinkPad
T400](../docs/install/t400_external.md). ME firmware versions 6.0 and
@ -331,7 +331,7 @@ hopelessly proprietary and "tivoized".
**In summary, the Intel Management Engine and its applications are a
backdoor with total access to and control over the rest of the PC. The
ME is a threat to freedom, security, and privacy, and the osboot
ME is a threat to freedom, security, and privacy, and the libreboot
project strongly recommends avoiding it entirely. Since recent versions
of it can't be removed, this means avoiding all recent generations of
Intel hardware.**
@ -405,7 +405,7 @@ most cases (they will just integrate the blobs that Intel provides).
Newer Intel graphics chipsets also [require firmware
blobs](https://01.org/linuxgraphics/intel-linux-graphics-firmwares?langredirect=1).
The `osboot` project *does* provide some support for newer Intel platforms, but
The `libreboot` project *does* provide some support for newer Intel platforms, but
you should be aware of these issues if you choose to run those machines.
Freedom pitfalls to consider on AMD hardware {#amd}
@ -452,7 +452,7 @@ machine completely outside of the user's knowledge.
Much like with the Intel Boot Guard (an application of the Intel
Management Engine), AMD's PSP can also act as a tyrant by checking
signatures on any boot firmware that you flash, making replacement boot
firmware (e.g. osboot, coreboot) impossible on some boards. Early
firmware (e.g. libreboot, coreboot) impossible on some boards. Early
anecdotal reports indicate that AMD's boot guard counterpart will be
used on most OEM hardware, disabled only on so-called "enthusiast"
CPUs.
@ -500,7 +500,7 @@ practically the same, though it was found with much later hardware in
AMD that you could run without microcode updates. It's unknown whether
the updates are needed on all AMD boards (depends on CPU).
The osboot project does not consider microcode updates a problem, and it
The libreboot project does not consider microcode updates a problem, and it
enables them by default on all supported hardware, even libreboot-compatible
hardware.
@ -537,7 +537,7 @@ Hi, I have &lt;insert random system here&gt;, is it supported?
If it's supported by coreboot, you can add it immediately.
Read the [porting guide](/docs/maintain/porting.html) for how to port for a new board.
If you are able to generate a working rom for your system, please read
[osbmk maintenance manual](docs/maintain/) for how to add it to osboot.
[lbmk maintenance manual](docs/maintain/) for how to add it to libreboot.
If coreboot lacks support for your hardware, you must add support for it.
Please consult the coreboot project for guidance.
@ -545,7 +545,7 @@ Please consult the coreboot project for guidance.
General questions
=================
How do I install osboot?
How do I install libreboot?
-------------------------------------------------------
See [installation guide](docs/install/)
@ -562,7 +562,7 @@ align the pins properly. The connection is generally more sturdy.
How do I write-protect the flash chip?
----------------------------------------------------------------------------
By default, there is no write-protection on a osboot system. This is
By default, there is no write-protection on a libreboot system. This is
for usability reasons, because most people do not have easy access to an
external programmer for re-flashing their firmware, or they find it
inconvenient to use an external programmer.
@ -573,7 +573,7 @@ possible, using dedicated hardware). For example, on current GM45
laptops (e.g. ThinkPad X200, T400), you can write-protect (see
[ICH9 gen utility](docs/install/ich9utils.md#ich9gen)).
It's possible to write-protect on all osboot systems, but the instructions
It's possible to write-protect on all libreboot systems, but the instructions
need to be written. The documentation is in the main git repository, so you are
welcome to submit patches adding these instructions.
@ -583,17 +583,17 @@ other methods on AMD systems.
How do I change the BIOS settings?
------------------------------------------------------------------------
Most osboot setups actually use the [GRUB
Most libreboot setups actually use the [GRUB
payload](http://www.coreboot.org/GRUB2). More information about payloads
can be found at
[coreboot.org/Payloads](http://www.coreboot.org/Payloads). SeaBIOS is also
available. The *CMOS* config is hardcoded in osboot.
available. The *CMOS* config is hardcoded in libreboot.
The osboot project inherits the modular payload concept from coreboot, which
The libreboot project inherits the modular payload concept from coreboot, which
means that pre-OS bare-metal *BIOS setup* programs are not very
practical. Coreboot (and osboot) does include a utility called
practical. Coreboot (and libreboot) does include a utility called
*nvramtool*, which can be used to change some settings. You can find
nvramtool under *coreboot/util/nvramtool/*, in the osboot source
nvramtool under *coreboot/util/nvramtool/*, in the libreboot source
archives.
The *-a* option in nvramtool will list the available options, and *-w*
@ -603,7 +603,7 @@ coreboot wiki for more information.
In practise, you don't need to change any of those settings, in most
cases.
Default osboot setups lock the CMOS table, to ensure consistent functionality
Default libreboot setups lock the CMOS table, to ensure consistent functionality
for all users. You can use:
nvramtool -C yourrom.rom -w somesetting=somevalue
@ -620,10 +620,10 @@ How do I pad a ROM before flashing?
It is advisable to simply use a larger ROM image. This section was written
mostly for ASUS KCMA-D8 and KGPE-D16 mainboards, where previously we only
provided 2MiB ROM images in osboot, but we now provide 16MiB ROM images.
provided 2MiB ROM images in libreboot, but we now provide 16MiB ROM images.
Other sizes are not provided because in practise, someone upgrading one of
these chips will just use a 16MiB one. Larger sizes are available, but 16MiB
is the maximum that you can use on all currently supported osboot systems
is the maximum that you can use on all currently supported libreboot systems
that use SPI flash.
Required for ROMs where the ROM image is smaller than the flash chip
@ -658,17 +658,17 @@ With padding removed cbfstool will be able to operate on the image as usual.
Do I need to install a bootloader when installing a distribution?
---------------------------------------------------------------------------------------------------
Most osboot setups integrate the GRUB bootloader already, as a
Most libreboot setups integrate the GRUB bootloader already, as a
*[payload](http://www.coreboot.org/Payloads)*. This means that the GRUB
bootloader is actually *flashed*, as part of the boot firmware
(osboot). This means that you do not have to install a boot loader on
(libreboot). This means that you do not have to install a boot loader on
the HDD or SSD, when installing a new distribution. You'll be able to
boot just fine, using the bootloader (GRUB) that is in the flash chip.
This also means that even if you remove the HDD or SSD, you'll still
have a functioning bootloader installed which could be used to boot a
live distribution installer from a USB flash drive. See
[How to install GNU+Linux on a osboot system](../docs/gnulinux/grub_boot_installer.md)
[How to install GNU+Linux on a libreboot system](../docs/gnulinux/grub_boot_installer.md)
Nowadays, other payloads are also provided. If you're using the SeaBIOS payload,
then the normal MBR bootsector is used on your HDD or SSD, like you would
@ -677,12 +677,12 @@ expect. So the above paragraphs only apply to the GNU GRUB payload.
Do I need to re-flash when I re-install a distribution?
-------------------------------------------------------------------------------------------
Not anymore. Recent versions of osboot (using the GRUB payload) will
Not anymore. Recent versions of libreboot (using the GRUB payload) will
automatically switch to a GRUB configuration on the HDD or SSD, if it
exists. You can also load a different GRUB configuration, from any kind
of device that is supported in GRUB (such as a USB flash drive). For
more information, see
[Modifying the GRUB Configuration in osboot Systems](../docs/gnulinux/grub_cbfs.md)
[Modifying the GRUB Configuration in libreboot Systems](../docs/gnulinux/grub_cbfs.md)
If you're using the SeaBIOS payload, it's even easier. It works just like you
would expect. SeaBIOS implements a normal x86 BIOS interface.
@ -693,10 +693,10 @@ What does a flash chip look like?
You can find photos of various chip types on the following page:\
[External 25xx NOR flashing guide](docs/install/spi.md)
What other firmware exists outside of osboot?
What other firmware exists outside of libreboot?
==================================================
You can also read information about these in the [osboot binary blob
You can also read information about these in the [libreboot binary blob
reduction policy](docs/policy.md), where it goes into more detail about some
of them.
@ -711,7 +711,7 @@ in a coreboot ROM image and have coreboot executes it, if you use a
different payload, such as GRUB).
The *coreboot project* provides free initialization code, on many boards, and
osboot will use this code when it is available, depending on the configuration.
libreboot will use this code when it is available, depending on the configuration.
In configurations where SeaBIOS and native GPU init are used together,
a special shim VBIOS is added that uses coreboot linear framebuffer.
@ -832,7 +832,7 @@ Other links:
It is recommended that you use full disk encryption, on HDDs connected
via USB. There are several adapters available online, that allow you to
connect SATA HDDs via USB. The osboot documentation says how to install
connect SATA HDDs via USB. The libreboot documentation says how to install
several distributions with full disk encryption. You can adapt these for
use with USB drives:
@ -863,7 +863,7 @@ Microcode configures logic gate arrays in a microprocessor, to implement the
instruction set architecture. Special *decoders* in the microprocessor will
configure the circuitry, based on that microcode.
The [osboot blob reduction policy](news/policy.md) goes into great detail
The [libreboot blob reduction policy](news/policy.md) goes into great detail
about microcode.
### Sound card
@ -877,7 +877,7 @@ workaround.
Webcams have firmware integrated into them that process the image input
into the camera; adjusting focus, white balancing and so on. Can use USB
webcam hardware, to work around potential DMA issues; integrated webcams
(on laptops, for instance) are discouraged by the osboot project, for
(on laptops, for instance) are discouraged by the libreboot project, for
security reasons.
### USB host controller
@ -902,7 +902,7 @@ by the GSM network, by triangulating the signal).
On some laptops, these cards use USB (internally), so won't have DMA,
but it's still a massive freedom and privacy issue. If you have an
internal WWAN chip/card, the osboot project recommends that you
internal WWAN chip/card, the libreboot project recommends that you
disable and (ideally, if possible) physically remove the hardware. If
you absolutely must use this technology, an external USB dongle is much
better because it can be easily removed when you don't need it, thereby
@ -917,7 +917,7 @@ Operating Systems
Can I use GNU+Linux?
--------------------------------------------------
Absolutely! It is well-tested in osboot, and highly recommended. See
Absolutely! It is well-tested in libreboot, and highly recommended. See
[installing GNU+Linux](../docs/gnulinux/grub_boot_installer.md) and
[booting GNU+Linux](../docs/gnulinux/grub_cbfs.md).
@ -934,7 +934,7 @@ Refer to [the GNU+Linux page](docs/gnulinux/).
Can I use BSD?
----------------------------------
Absolutely! The osboot firmware has native support for NetBSD, OpenBSD and
Absolutely! The libreboot firmware has native support for NetBSD, OpenBSD and
LibertyBSD. Other distros are untested.
See:
@ -945,15 +945,15 @@ Are other operating systems compatible?
Unknown. Probably not.
What level of software freedom does osboot give me?
What level of software freedom does libreboot give me?
===================================================
TODO: Re-write this section. It has been adapted, poorly, from the Libreboot
FAQ section.
Please read the [osboot binary blob minimization policy](docs/policy.md).
Please read the [libreboot binary blob minimization policy](docs/policy.md).
The osboot firmware provides host hardware init firmware images,
The libreboot firmware provides host hardware init firmware images,
that can be written 25XX SPI NOR Flash. But on many systems there are
a lot more computers running blob firmware.
Some of them are not practicable to replace due to being located on Mask ROM.

82
site/git.md
View File

@ -3,19 +3,19 @@ title: Code review
x-toc-enable: true
...
osboot repositories
libreboot repositories
===================
Information about who works on osboot and who runs the project can be
Information about who works on libreboot and who runs the project can be
found on [who.md](who.md)
The `osboot` project has 3 main Git repositories:
The `libreboot` project has 3 main Git repositories:
* Build system: <https://notabug.org/osboot/osbmk>
* Website (+docs): <https://notabug.org/osboot/osbwww>
* Images (for website): <https://notabug.org/osboot/osbwww-img>
* Build system: <https://notabug.org/libreboot/lbmk>
* Website (+docs): <https://notabug.org/libreboot/osbwww>
* Images (for website): <https://notabug.org/libreboot/osbwww-img>
There is also these programs, hosted by the Libreboot project, and osboot
There is also these programs, hosted by the Libreboot project, and libreboot
either recommends them or makes use of them:
* Bucts (utility): <https://notabug.org/libreboot/bucts>
@ -24,78 +24,78 @@ either recommends them or makes use of them:
You can download any of these repositories, make whatever changes you like, and
then submit your changes using the instructions below.
It is recommended that you build osboot (all parts of it) in a GNU+Linux
distribution. For example, the build system (osbmk) is untested on BSD systems.
It is recommended that you build libreboot (all parts of it) in a GNU+Linux
distribution. For example, the build system (lbmk) is untested on BSD systems.
Install `git` in your GNU+Linux system, and download one of the repositories.
Development of osboot is done using the Git version control system.
Development of libreboot is done using the Git version control system.
Refer to the [official Git documentation](https://git-scm.com/doc) if you don't
know how to use Git.
The `bucts` repository is hosted by the osboot project, because the original
The `bucts` repository is hosted by the libreboot project, because the original
repository on `stuge.se` is no longer available, last time we checked. The
`bucts` program was written by Peter Stuge. You need `bucts` if you're flashing
internally an osboot ROM onto a ThinkPad X60 or T60 that is currently running
internally an libreboot ROM onto a ThinkPad X60 or T60 that is currently running
the non-free Lenovo BIOS. Instructions for that are available here:\
[osboot installation guides](docs/install/)
[libreboot installation guides](docs/install/)
The `ich9utils` repository is used heavily, by the `osbmk` build system. However,
The `ich9utils` repository is used heavily, by the `lbmk` build system. However,
you can also download `ich9utils` on its own and use it. It generates ICH9M
descriptor+GbE images for GM45 ThinkPads that use the ICH9M southbridge. It may
also work for other systems using the same platform/chipset.
Documentation for `ich9utils` is available here:\
[ich9utils documentation](docs/install/ich9utils.md)
osbmk (osboot-make)
lbmk (libreboot-make)
---------------------
This is the core build system in osboot. You could say that `osbmk` *is*
osboot! Download the Git repository:
This is the core build system in libreboot. You could say that `lbmk` *is*
libreboot! Download the Git repository:
git clone https://notabug.org/osboot/osbmk
git clone https://notabug.org/libreboot/lbmk
The `git` command, seen above, will download the osboot build system `osbmk`.
The `git` command, seen above, will download the libreboot build system `lbmk`.
You can then go into it like so:
cd osbmk
cd lbmk
Make whatever changes you like, or simply build it. For instructions on how to
build `osbmk`, refer to the [build instructions](docs/build/).
build `lbmk`, refer to the [build instructions](docs/build/).
Information about the build system itself, and how it works, is available in
the [osbmk maintenance guide](docs/maintain/).
the [lbmk maintenance guide](docs/maintain/).
osbwww and osbwww-img
-------------------
The *entire* osboot website and documentation is hosted in a Git repository.
The *entire* libreboot website and documentation is hosted in a Git repository.
Download it like so:
git clone https://notabug.org/osboot/osbwww
git clone https://notabug.org/libreboot/osbwww
Images are hosted on <https://av.osboot.org/> and available in a separate
Images are hosted on <https://av.libreboot.org/> and available in a separate
repository:
git clone https://notabug.org/osboot/osbwww-img
git clone https://notabug.org/libreboot/osbwww-img
Make whatever changes you like. See notes below about how to send patches.
The entire website is written in Markdown, specifically the Pandoc version of
it. The static HTML pages are generated with [Untitled](https://untitled.vimuser.org/).
Leah Rowe, the founder of osboot, is also the founder of the Untitled static
Leah Rowe, the founder of libreboot, is also the founder of the Untitled static
site generator project.
If you like, you can set up a local HTTP server and build your own local
version of the website. Please note that images will still link to the ones
hosted on <https://av.osboot.org/>, so any images that you add to `osbwww-img`
hosted on <https://av.libreboot.org/>, so any images that you add to `osbwww-img`
will not show up on your local `lbwww` site if you make the image links (for
images that you add) link to `av.osboot.org`. However, it is required that such
images be hosted on av.osboot.org.
images that you add) link to `av.libreboot.org`. However, it is required that such
images be hosted on av.libreboot.org.
Therefore, if you wish to add images to the website, please also submit to the
`lbwww-img` repository, with the links to them being
<https://av.osboot.org/path/to/your/new/image/in/osbwww-img> for each one.
When it is merged on the osboot website, your images will appear live.
<https://av.libreboot.org/path/to/your/new/image/in/osbwww-img> for each one.
When it is merged on the libreboot website, your images will appear live.
For development purposes, you might make your images local links first, and
then adjust the URLs when you submit your documentation/website patches.
@ -115,8 +115,8 @@ everyone can access. This includes the name and email address of the
contributor.
In Git, for author name and email address, you do not have to use identifying
data. You can use `osboot Contributor` and your email address could be
specified as contributor@osboot.org. You are permitted to do this, if
data. You can use `libreboot Contributor` and your email address could be
specified as contributor@libreboot.org. You are permitted to do this, if
you wish to maintain privacy. We believe in privacy. If you choose to remain
anonymous, we will honour this.
@ -146,29 +146,29 @@ We require all patches to be submitted under a free license:
the default, restrictive copyright laws apply, which would make your work
non-free.
GNU+Linux is generally recommended as the OS of choice, for osboot
development. However, BSD operating systems also boot on osboot machines.
GNU+Linux is generally recommended as the OS of choice, for libreboot
development. However, BSD operating systems also boot on libreboot machines.
Send patches
------------
Make an account on <https://notabug.org/> and navigate (while logged in) to the
repository that you wish to work on. Click *Fork* and in your account,
you will have your own repository of osboot. Clone your repository, make
you will have your own repository of libreboot. Clone your repository, make
whatever changes you like to it and then push to your repository, in your
account on NotABug. You can also do this on a new branch, if you wish.
In your Notabug account, you can then navigate to the official osboot
In your Notabug account, you can then navigate to the official libreboot
repository and submit a Pull Request. The way it works is similar to other
popular web-based Git platforms that people use these days.
You can submit your patches there. Alternative, you can log onto the osboot
You can submit your patches there. Alternative, you can log onto the libreboot
IRC channel and notify the channel of which patches you want reviewed, if you
have your own Git repository with the patches.
Once you have issued a Pull Request, the osboot maintainers will be notified
Once you have issued a Pull Request, the libreboot maintainers will be notified
via email. If you do not receive a fast enough response from the project, then
you could also notify the project via the `#osboot` channel on Libera Chat.
you could also notify the project via the `#libreboot` channel on Libera Chat.
Another way to submit patches is to email Leah Rowe directly:
[leah@libreboot.org](mailto:leah@libreboot.org) is Leah's project email address.

54
site/index.md
View File

@ -1,19 +1,19 @@
---
title: osboot project
title: libreboot project
x-toc-enable: true
...
The `osboot` project provides
The `libreboot` project provides
[freedom-respecting](https://www.gnu.org/philosophy/free-sw.html) *boot
firmware* that initializes the hardware (e.g. memory controller, CPU,
peripherals) on [specific Intel/AMD x86 computers](docs/hardware/) and starts
a bootloader for your operating system. [GNU+Linux](docs/gnulinux/)
and [BSD](docs/bsd/) are well-supported. It replaces proprietary BIOS/UEFI
firmware. Help is available
via [\#osboot](https://web.libera.chat/#osboot)
via [\#libreboot](https://web.libera.chat/#libreboot)
on [Libera](https://libera.chat/) IRC.
Why should you use *osboot*?
Why should you use *libreboot*?
----------------------------
You have rights. The right to privacy, freedom of thought, freedom of speech
@ -24,78 +24,78 @@ Your freedom matters.
Many people use [proprietary](https://www.gnu.org/proprietary/proprietary.html)
boot firmware, even if they use [GNU+Linux](https://www.gnu.org/distros/).
Non-free firmware often [contains](faq.html#intel) [backdoors](faq.html#amd),
and can be buggy. The osboot project was founded in in December 2020, with the
and can be buggy. The libreboot project was founded in in December 2020, with the
express purpose of making Free Software accessible for non-technical users at
the firmware level. It's true that `osboot` can be called Open Source, [but you
the firmware level. It's true that `libreboot` can be called Open Source, [but you
should call it Free
Software](https://www.gnu.org/philosophy/open-source-misses-the-point.en.html).
The `osboot` project uses [coreboot](https://www.coreboot.org/) for [hardware
The `libreboot` project uses [coreboot](https://www.coreboot.org/) for [hardware
initialization](https://doc.coreboot.org/getting_started/architecture.html).
Coreboot is notoriously difficult to install for most non-technical users; it
handles only basic initialization and jumps to a separate
[payload](https://doc.coreboot.org/payloads.html) program (e.g.
[GRUB](https://www.gnu.org/software/grub/),
[Tianocore](https://www.tianocore.org/)), which must also be configured.
*The osboot software solves this problem*; it is a *coreboot distribution* with
*The libreboot software solves this problem*; it is a *coreboot distribution* with
an [automated build system](docs/build/) that builds complete *ROM images*, for
more robust installation. Documentation is provided.
How does osboot differ from regular coreboot?
How does libreboot differ from regular coreboot?
---------------------------------------------
In the same way that *Debian* is a GNU+Linux distribution, `osboot` is
In the same way that *Debian* is a GNU+Linux distribution, `libreboot` is
a *coreboot distribution*. If you want to build a ROM image from scratch, you
otherwise have to perform expert-level configuration of coreboot, GRUB and
whatever other software you need, to prepare the ROM image. With *osboot*,
whatever other software you need, to prepare the ROM image. With *libreboot*,
you can literally download from Git or a source archive, and run `make`, and it
will build entire ROM images. An automated build system, named `osbmk`
will build entire ROM images. An automated build system, named `lbmk`
(OSBoot MaKe), builds these ROM images automatically, without any user input
or intervention required. Configuration has already been performed in advance.
If you were to build regular coreboot, without using osboot's automated
If you were to build regular coreboot, without using libreboot's automated
build system, it would require a lot more intervention and decent technical
knowledge to produce a working configuration.
Reguar binary releases of `osboot` provide these
Reguar binary releases of `libreboot` provide these
ROM images pre-compiled, and you can simply install them, with no special
knowledge or skill except the ability to
follow [simplified instructions, written for non-technical
users](docs/install/).
How does osboot differ from *Libreboot*?
How does libreboot differ from *Libreboot*?
----------------------------------------
Libreboot and osboot are both developed in parallel. Both projects were founded
Libreboot and libreboot are both developed in parallel. Both projects were founded
by Leah Rowe, who leads both projects.
**The osboot project is a fork of Libreboot, but it has scrapped the [Libreboot
**The libreboot project is a fork of Libreboot, but it has scrapped the [Libreboot
zero-blob policy](news/policy.md). It comes with CPU microcode updates turned
on by default, even on libreboot-compatible hardware (on libreboot-compatible
hardware, that is the only difference). The osboot build system automatically
hardware, that is the only difference). The libreboot build system automatically
downloads the entire set of `3rdparty` submodules from coreboot. The coreboot
software is nominally free, but does require some binary blobs on certain
machines, and those are included in the `3rdparty` submodules.**
[CPU microcode updates do not hurt your freedom, because your CPU already has
older, buggier microcode in mask ROM anyway. You should choose osboot, not
older, buggier microcode in mask ROM anyway. You should choose libreboot, not
Libreboot, even on Libreboot-compatible hardware, because the microcode updates
improve system stability and reliability.](news/policy.md) Out of principle,
`osboot` will always enable microcode updates. Libreboot is inferior to osboot,
`libreboot` will always enable microcode updates. Libreboot is inferior to libreboot,
in every way, but it will continue to be developed and polished, alongside
osboot development.
libreboot development.
The purpose of `osboot` is to provide as
The purpose of `libreboot` is to provide as
much freedom as possible, to those who wish to move away from their otherwise
fully proprietary firmware. The `osboot` build system does not delete binary
fully proprietary firmware. The `libreboot` build system does not delete binary
blobs like Libreboot's one does, because it *wants* to provide help for all
those who wish to have some freedoms over their hardware, even if that hardware
isn't supported by Libreboot yet. Libreboot compatibility is still very much
desirable, on all hardware, and work to this end is highly encouraged!
You can learn more by reading osboot's enlightened [binary blobs
You can learn more by reading libreboot's enlightened [binary blobs
policy](news/policy.md) which is in stark contrast to Libreboot's policy.
The osboot project removes all restrictions in its fork of the Libreboot
The libreboot project removes all restrictions in its fork of the Libreboot
build system, allowing any board from coreboot to be supported (the goal
is literally to support all of them).
@ -103,12 +103,12 @@ How to help
-----------
You can check bugs listed on
the [bug tracker](https://notabug.org/osboot/osbmk/issues).
the [bug tracker](https://notabug.org/libreboot/lbmk/issues).
If you spot a bug and have a fix, [here are instructions for how to send
patches](git.md), and you can also report it. Also, this entire website is
written in Markdown and hosted in a [separate
repository](https://notabug.org/osboot/osbwww) where you can send patches.
repository](https://notabug.org/libreboot/osbwww) where you can send patches.
Any and all development discussion and user support are all done on the IRC
channel. More information is on the [contact page](contact.md).

54
site/index.uk.md
View File

@ -1,19 +1,19 @@
---
title: проект osboot
title: проект libreboot
x-toc-enable: true
...
Проект `osboot` надає
Проект `libreboot` надає
[поважаючу свободу](https://www.gnu.org/philosophy/free-sw.html) *прошивку*,
яка виконує ініціалізацію апаратного забезпечення (такого як - контролер пам'яті, ЦП,
периферія) на [деяких комп'ютерах Intel/AMD x86](docs/hardware/) та розпочинає
завантажувач для вашої операційної системи. [GNU+Linux](docs/gnulinux/)
та [BSD](docs/bsd/) добре підтримуються. Це заміняє невільну BIOS/UEFI
прошивку. Допомога доступна
через [\#osboot](https://web.libera.chat/#osboot)
через [\#libreboot](https://web.libera.chat/#libreboot)
на IRC [Libera](https://libera.chat/).
Чому вам варто використовувати *osboot*?
Чому вам варто використовувати *libreboot*?
----------------------------
У вас є права. Право на конфіденційність, свобода думки, свобода мови,
@ -24,77 +24,77 @@ x-toc-enable: true
Багато людей використовує [невільну](https://www.gnu.org/proprietary/proprietary.html)
прошивку, навіть якщо вони використовують [GNU+Linux](https://www.gnu.org/distros/).
Невільна прошивка часто [містить](faq.html#intel) [лазівки](faq.html#amd),
та може бути забагованою. Проект osboot був заснований в грудні 2020 року, з
та може бути забагованою. Проект libreboot був заснований в грудні 2020 року, з
чіткою метою зробити вільне програмне забезпечення доступним для нетехнічних користувачів на
рівні прошивки. Це правда, що `osboot` можна назвати з відкритим джерельним кодом, [але вам
рівні прошивки. Це правда, що `libreboot` можна назвати з відкритим джерельним кодом, [але вам
варто називати його вільне
програмне забезпечення](https://www.gnu.org/philosophy/open-source-misses-the-point.uk.html).
Проект `osboot` використовує [coreboot](https://www.coreboot.org/) для [апаратної
Проект `libreboot` використовує [coreboot](https://www.coreboot.org/) для [апаратної
ініціалізації](https://doc.coreboot.org/getting_started/architecture.html).
Coreboot неординарно складно встановити для більшості нетехнічних користувачів; він
виконує лише базову ініціалізацію та перестрибує до окремої програми
[корисного навантаження](https://doc.coreboot.org/payloads.html) (такої як -
[GRUB](https://www.gnu.org/software/grub/),
[Tianocore](https://www.tianocore.org/)), які також потрібно налаштувати.
*Програмне забезпечення osboot вирішує цю проблему*; це *дистрибутив coreboot* з
*Програмне забезпечення libreboot вирішує цю проблему*; це *дистрибутив coreboot* з
[автоматизованою системою побудови](docs/build/), який створює *ROM образи*, для
більш міцної установки. Документація надається.
Чим відрізняється osboot від звичайного coreboot?
Чим відрізняється libreboot від звичайного coreboot?
---------------------------------------------
Таким же самим чином, як *Debian* є дистрибутивом GNU+Linux, `osboot` є
Таким же самим чином, як *Debian* є дистрибутивом GNU+Linux, `libreboot` є
*дистрибутивом coreboot*. Якщо ви хочете створити образ ROM з нуля, вам в
інакшому випадку доведеться виконати експертну конфігурацію coreboot, GRUB та
будь-якого іншого програмного забезпечення, яке вам потрібно, щоб підготувати образ ROM. З *osboot*,
будь-якого іншого програмного забезпечення, яке вам потрібно, щоб підготувати образ ROM. З *libreboot*,
ви можете завантажити з Git або архіву вихідного коду, та запустити `make`, і таким чином
будуть побудовані всі образи ROM. Автоматизована система побудови osboot, названа `osbmk`
будуть побудовані всі образи ROM. Автоматизована система побудови libreboot, названа `lbmk`
(OSBoot MaKe), будує ці ROM образи автоматично, без будь-якого введення
або втручання користувача. Конфігурація вже була виконана заздалегідь.
Якщо складати звичайний coreboot, без використання автоматизованої
системи побудови osboot, це потребувало би набагато більше інтервенцій та пристойних технічних
системи побудови libreboot, це потребувало би набагато більше інтервенцій та пристойних технічних
знань для створення працюючої конфігурації.
Регулярні двійкові випуски `osboot` надають ці
Регулярні двійкові випуски `libreboot` надають ці
образи ROM попередньо зібраними, і ви можете просто встановити їх, не маючи спеціальних
знань або навичок, крім можливості
дотримуватися [спрощених інструкцій, написаних для нетехнічних користувачів](docs/install/).
Чим osboot відрізняється від *Libreboot*?
Чим libreboot відрізняється від *Libreboot*?
----------------------------------------
Libreboot та osboot обидва розроблюються паралельно. Обидва проекта були засновані
Libreboot та libreboot обидва розроблюються паралельно. Обидва проекта були засновані
Лією Роу, яка керує обома проектами.
**Проект osboot є відгалудженням від Libreboot, але він позбавився від [Політики відсутності
**Проект libreboot є відгалудженням від Libreboot, але він позбавився від [Політики відсутності
двійкових компонентів Libreboot](news/policy.md). Він іде з оновленням мікрокоду ЦП, увімкненим за
замовченням, навіть на libreboot-сумісному обладнанні (на libreboot-сумісному
обладнанні, це є єдиною різницею). Система побудови osboot автоматично
обладнанні, це є єдиною різницею). Система побудови libreboot автоматично
завантажує повний набір `3rdparty` підмодулей з coreboot. Програмне забезпечення coreboot
номінально вільне, але потребує деяких двійкових компонентів на окремих
машинах, які додаються в підмодулях `3rdparty`.**
[Оновлення мікрокодів ЦП не завдає шкоди вашій свободі, тому що ЦП вже має
старіший, з більшою кількістю помилок мікрокод у вбудованій ROM. Вам варто вибирати osboot, не
старіший, з більшою кількістю помилок мікрокод у вбудованій ROM. Вам варто вибирати libreboot, не
Libreboot, навіть на Libreboot-сумісному обладнанні, тому що оновлення мікрокоду
підвищує стабільність та надійність системи.](news/policy.md) Випливає з цього принципу те, що
`osboot` буде завжди включати оновлення мікрокоду. Libreboot нижчьої якості за osboot,
`libreboot` буде завжди включати оновлення мікрокоду. Libreboot нижчьої якості за libreboot,
з будь-якого погляду, але його будуть продовжувати розробляти та полірувати, пліч-о-пліч з
розробкою osboot.
розробкою libreboot.
Метою `osboot` є надати настільки
Метою `libreboot` є надати настільки
багато свободи, скільки можливо, для тих, хто бажає кинути свою в іншому разі
повністю невільну прошивку. Система побудови `osboot` не видаляє двійкові
повністю невільну прошивку. Система побудови `libreboot` не видаляє двійкові
компоненти, як робить Libreboot, тому що вона *хоче* надати допомогу всім
тим, хто бажає мати деякі свободи зі своїм обладнанням, навіть якщо це обладнання
не підтримується Libreboot наразі. Підтримка Libreboot є досі дуже сильно
бажаною, на всьому обладнанні, і працювати до цієї мети дуже заохочується!
Ви можете дізнатись більше, прочитавши надихнувшу osboot [політику двійкових
Ви можете дізнатись більше, прочитавши надихнувшу libreboot [політику двійкових
компонентів](news/policy.md), що різко контрастує з політикою Libreboot.
Проект osboot видаляє усі обмеження в своєму відгалудженні системи побудови Libreboot,
Проект libreboot видаляє усі обмеження в своєму відгалудженні системи побудови Libreboot,
дозволяючи підтримувати будь-яку плату з coreboot (метою є
буквально підтримка їх всіх).
@ -102,12 +102,12 @@ Libreboot, навіть на Libreboot-сумісному обладнанні,
-----------
Ви можете перевірити баги, перелічені
на [баг трекері](https://notabug.org/osboot/osbmk/issues).
на [баг трекері](https://notabug.org/libreboot/lbmk/issues).
Якщо ви виявите помилку та маєте вирішення, [ось інструкції, як відправити
виправлення](git.md), і ви можете також повідомити про це. Також, увесь цей веб-сайт
написано Markdown та розміщено в [окремому
репозиторії](https://notabug.org/osboot/osbwww), де можна надсилати виправлення.
репозиторії](https://notabug.org/libreboot/osbwww), де можна надсилати виправлення.
Будь-яке та усе обговорення розробки та підтримка користувачів виконується на каналі IRC.
Більше інформації на [сторінці зворотнього зв'язку](contact.md).

10
site/license.md
View File

@ -4,21 +4,21 @@ x-toc-enable: true
...
Unless otherwise stated, every page and image (e.g. JPG/PNG files) on
osboot.org or in the repository that it is built on, is released under the
libreboot.org or in the repository that it is built on, is released under the
terms of the GNU Free Documentation License, either version 1.3 or (at your
option) any newer version as published by the [Free Software
Foundation](https://www.fsf.org/), with no Invariant Sections, no Front Cover
Texts and no Back Cover
Texts.
The *logo* for osboot is Copyright (C) 2022 Ioan Moldovan, released under an
The *logo* for libreboot is Copyright (C) 2022 Ioan Moldovan, released under an
Expat license which you can find here:
<https://av.osboot.org/logo/COPYING>
<https://av.libreboot.org/logo/COPYING>
The original logo files are here: <https://av.osboot.org/logo/>
The original logo files are here: <https://av.libreboot.org/logo/>
You can download the logo files from `osbwww-img.git`. See:
<https://osboot.org/git.html>
<https://libreboot.org/git.html>
These pages are static HTML, generated from Markdown files, which you can find
a link to at the bottom of each HTML page, for the corresponding Markdown file.

111
site/news/policy.md
View File

@ -5,49 +5,33 @@
Introduction
============
The `osboot` project is a *fork* of the Libreboot project.
Libreboot is designed to comply with the Free Software Foundation's
[Respects Your Freedom criteria](https://ryf.fsf.org/about/criteria) and
the [GNU Free System Distribution Guidelines (GNU FSDG)](https://www.gnu.org/distros/free-system-distribution-guidelines.en.html),
ensuring that it is entirely [Free Software](https://www.gnu.org/philosophy/free-sw.html).
In the beginning Libreboot intentionally *de-blobbed* coreboot, which is to say that it did not
include binary blobs. Coreboot, on the other hand, requires binary blobs on
most systems that it has support for. Libreboot's
entirely *"free"* version of coreboot consequently supported fewer mainboards.
It was decided that a formal policy should be written, because there is quite
a bit of nuance that would otherwise not be covered. The policies of `osboot`
are fundamentally different than those of Libreboot.
Libreboot intentionally *de-blobs* coreboot, which is to say that it does not
include binary blobs. The coreboot software otherwise requires binary blobs on
most systems that it has support for. Libreboot's version of coreboot is
entirely *free*, on its consequently reduced set of supported mainboards.
The `osboot` project is *fundamentally* different:
Libreboot's [zero blobs policy](https://libreboot.org/news/policy.html) has
been scrapped, entirely. The goal of *osboot* is simply to support every single
Libreboot's zero blobs policy has
been scrapped, entirely. The goal of *libreboot* is simply to support every single
system from coreboot, to provide pre-configured, automated compiling of ROM
images for *all* of them. This is quite a lot more ambitious in terms of sheer
workload, and maintenance. It is expected that the project will *grow* in the
future, to accomodate *board maintainers*, just like you have *package
maintainers* in Debian; the analogy is highly appropriate, given the nature
of the osboot build system, which you can learn more about on the [osbmk
maintenance manual](../docs/maintain/).
of the libreboot build system, which you can learn more about on the [lbmk maintenance manual](../docs/maintain/).
**Freedom is very much preferable and a world where everyone can use Free
Software, exclusively, is to be welcomed. However, we do not yet live in that
world. The osboot project wishes to see more hardware become suitable for
entry into Libreboot, in the future. Both osboot and Libreboot are lead by
Leah Rowe, who is also the founder of both projects.**
world.**
The osboot position is more like an opinion, as opposed to an actual policy.
The libreboot position is more like an opinion, as opposed to an actual policy.
That opinion is this: *some* freedom is better than *zero* freedom. There are
plenty of people with coreboot-compatible hardware, who wish to move away from
otherwise fully proprietary boot firmware (usually supplied by the manufacturer
of the hardware). The *osboot* project is here to help! It provides a fully
of the hardware). The *libreboot* project is here to help! It provides a fully
automated build system, making coreboot much easier to use, and it provides
user-friendly [installation guides](../docs/install/) to help you get started.
The position of the osboot project is basically the same as that of Libreboot,
except that it takes a far more *pragmatic* approach, as opposed to Libreboot's
*dogmatic* approach. Supporting more hardware, even if the hardware is less
Supporting more hardware, even if the hardware is less
friendly to software freedom, will provide a path towards coreboot for more
people, and it may lead to more coreboot development in the future.
@ -59,9 +43,9 @@ a level of computing freedom that they would otherwise not have.
Current project scope
=====================
The osboot project is concerned with what goes in the main boot flash IC, but
The libreboot project is concerned with what goes in the main boot flash IC, but
there are other pieces of firmware to take into consideration, as covered
in the [osboot FAQ](../faq.md#what-other-firmware-exists-outside-of-osboot).
in the [libreboot FAQ](../faq.md#what-other-firmware-exists-outside-of-osboot).
Most critical of these are:
@ -70,7 +54,7 @@ Most critical of these are:
* Intel Management Engine / AMD PSP firmware
Specific binary blobs are also problematic, on most coreboot systems, but they
differ per machine. The *osboot* project has a *blob minimalization* policy
differ per machine. The *libreboot* project has a *blob minimalization* policy
(as opposed to Libreboot's *blob deletion policy*), which you can read about
in the following section.
@ -82,41 +66,38 @@ Blob *minimalization* policy
Default configurations
----------------------
*Libreboot* has a blob *deletion* policy; it contains no binary blobs, not even
CPU microcode updates.
The *osboot* project has the following policy, by contrast:
The *libreboot* project has the following policy:
* If a blob *can* be avoided, it should be avoided. For example, if VGA ROM
initialization otherwise does a better job but coreboot has *free* init code
for a given graphics device, that code should be used in osboot, when
for a given graphics device, that code should be used in libreboot, when
building a ROM image. Similarly, if *memory controller initialization* is
possible with a binary blob *or* free code in coreboot, the *free* code
should be used in ROMs built by `osbmk`, and the *blob* for raminit should
should be used in ROMs built by `lbmk`, and the *blob* for raminit should
not be used; however, if no free init code is available for said raminit,
it is permitted and osbmk will use the *blob*.
it is permitted and lbmk will use the *blob*.
* Some nuance is to be observed: on some laptop or desktop configurations, it's
common that there will be *two* graphics devices (for example, an nvidia and
an intel chip, using nvidia optimus technology, on a laptop). It may be that
one of them has free init code in coreboot, but the other one does not. It's
perfectly acceptable, and desirable, for osboot to support both devices,
perfectly acceptable, and desirable, for libreboot to support both devices,
and accomodate the required binary blob on the one that lacks native
initialization.
* An exception is made for CPU microcode updates: they are permitted, and in
fact *required* as per osboot policy. These updates fix CPU bugs, including
fact *required* as per libreboot policy. These updates fix CPU bugs, including
security bugs, and since the CPU already has non-free microcode burned into
ROM anyway, the only choice is either *x86* or *broken x86*. Thus, osboot
ROM anyway, the only choice is either *x86* or *broken x86*. Thus, libreboot
will only allow coreboot mainboard configurations where microcode updates
are *enabled*, if available for the CPU on that mainboard.
* Intel Management Engine: in the osboot documentation, words *must* be written
* Intel Management Engine: in the libreboot documentation, words *must* be written
to tell people how to *neuter* the ME, if possible on a given board.
The `me_cleaner` program is very useful, and provides a much more secure ME
configuration.
* Binary blobs should *never* be deleted, even if they are unused. In the
coreboot project, a set of `3rdparty` submodules are available, with binary
blobs for init tasks on many boards. These must *all* be included in osboot
releases, even if unused. That way, even if `osbmk` does not yet integrate
support for a given board, someone who downloads osboot can still make
blobs for init tasks on many boards. These must *all* be included in libreboot
releases, even if unused. That way, even if `lbmk` does not yet integrate
support for a given board, someone who downloads libreboot can still make
changes to their local version of the build system, if they wish, to provide
a configuration for their hardware.
@ -124,28 +105,28 @@ Generally speaking, common sense is applied. For example, an exception to the
minimalization might be if *blob* raminit and *free* raminit are available, but
the *free* one is so broken so as to be unusable. In that situation, the blob
one should be used instead, because otherwise the user might switch back to an
otherwise fully proprietary system, instead of using coreboot (via osboot).
otherwise fully proprietary system, instead of using coreboot (via libreboot).
Configuration
-------------
The principles above should apply to *default* configurations. However, osboot
The principles above should apply to *default* configurations. However, libreboot
is to be *configurable*, allowing the user to do whatever they like.
It's natural that the user may want to create a setup that is *less* free than
the default one in osboot. This is perfectly acceptable; freedom is superior,
the default one in libreboot. This is perfectly acceptable; freedom is superior,
and should be encouraged, but the user's freedom to choose should also be
respected, and accomodated.
In other words, do not lecture the user. Just try to help them with their
problem! The goal of the osboot project is simply to make coreboot more
problem! The goal of the libreboot project is simply to make coreboot more
accessible for otherwise non-technical users.
FREEDOM CATALOG
===============
A *blob status* page should also be made available, educating people about the
status of binary blobs on each machine supported by `osbmk`.
status of binary blobs on each machine supported by `lbmk`.
It is desirable to see a world where all hardware and software is free.
Hardware!?
@ -174,7 +155,7 @@ The FSF RYF guidelines state the following:
*"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 is a violation of every principle the FSF stands for, *and it should be
rejected on ideological grounds*. The rest of osboot's policy and overall
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 *free*. Instead of making such
@ -213,13 +194,13 @@ 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
actively encourage people to free it, on every laptop!
Other firmware currently outside the reach of the *osboot* project are covered
in the osboot FAQ page. For example, HDD/SSD firmware is covered in the FAQ.
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 *osboot* project will not hide or overlook these issues, because they are
indeed critical, but again, currently outside the scope of what osbmk does.
At the moment, osbmk concerns itself just with coreboot, but this ought to
The *libreboot* project will not hide or overlook these issues, because they are
indeed critical, but again, currently outside the scope of what lbmk does.
At the moment, lbmk concerns itself just with coreboot, but this ought to
change in the future.
Examples of FSF *sweeping blobs under the rug*
@ -250,7 +231,7 @@ provide incentive for levels of software freedom, such as:
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> - osboot also has this
<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
@ -324,7 +305,7 @@ To be clear: it is preferable that microcode be free. The microcode on Intel
and AMD systems *are* non-free. Facts and feelings rarely coincide; the
purpose of this section is to spread *facts*.
The *osboot* build system enables microcode updates *by default*, even on
The *libreboot* build system enables microcode updates *by default*, even on
boards that Libreboot supports. Libreboot *excludes* microcode updates.
Not including CPU microcode updates is an absolute disaster for system
@ -393,19 +374,19 @@ Pick your poison. Not adding the updates is *irresponsible*, and ultimately
futile, because you still end up with non-free microcode anyway, just you get
an older, buggier version instead!
The *osboot* build system does not apply the two patches linked above! Instead,
The *libreboot* build system does not apply the two patches linked above! Instead,
CPU microcode updates are enabled by default, on the affected boards. The
result is superior IA32 feature control and added PECI support.
The *osboot* project rejects the FSF's narrow, dogmatic view entirely.
The *libreboot* project rejects the FSF's narrow, dogmatic view entirely.
The osboot firmware is far superior to Libreboot, in terms of reliability, due
The libreboot firmware is far superior to Libreboot, in terms of reliability, due
to the presence of microcode updates in the firmware, and with zero practical
change to your freedom, on libreboot-compatible hardware.
However:
**I will continue to develop Libreboot and osboot, in parallel.**
**I will continue to develop Libreboot and libreboot, in parallel.**
There are some people who still want Libreboot, who believe in FSF principles
on this subject, and I believe it would ultimately be damaging if I were to
@ -422,8 +403,8 @@ people, *because I want everyone to have freedom*. I also believe in freedom of
choice, and Libreboot is an excellent choice for those who wish to use something
that complies with FSF criteria.
Thus, I continue developing Libreboot in parallel with osboot, even though
Libreboot is technically *inferior* to osboot. The *osboot* project is where
Thus, I continue developing Libreboot in parallel with libreboot, even though
Libreboot is technically *inferior* to libreboot. The *osboot* project is where
my heart truly lies. I'm completely in it, whereas Libreboot is something I
also maintain on the side. I try to do my best, when working on both projects.
I really don't mind maintaining both of them, because they are actually very
@ -466,7 +447,7 @@ 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. As of 2 January 2022, Libreboot still complies strictly with
RYF, and will continue to do so, at least for the time being. The *osboot*
RYF, and will continue to do so, at least for the time being. The *libreboot*
project rejects those policies in their entirety, and instead takes a pragmatic
approach.
@ -480,7 +461,7 @@ 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. The *osboot* project, again,
based on assumptions that are no longer true. The *libreboot* project, again,
takes a pragmatic approach, rejecting Libreboot's dogmatic approach entirely.
Sad truth: RYF actively encourages *less* freedom, by not being bold enough.

14
site/news/translations.md
View File

@ -2,11 +2,11 @@
% Leah Rowe
% 4 January 2022
The osboot website is currently only available in English.
The libreboot website is currently only available in English.
I've recently added support for translations to
the [Untitled Static Site Generator](https://untitled.vimuser.org/), which the
osboot website uses. Pages on osboot.org are written in Markdown, and
libreboot website uses. Pages on libreboot.org are written in Markdown, and
this software generates HTML pages.
This very page that you are reading was created this way!
@ -14,11 +14,11 @@ This very page that you are reading was created this way!
Getting started
===============
The osboot website is available, in Markdown, from a Git repository:\
<https://notabug.org/osboot/osbwww>
The libreboot website is available, in Markdown, from a Git repository:\
<https://notabug.org/libreboot/osbwww>
Instructions for how to send patches are available here:\
<https://osboot.org/git.html>
<https://libreboot.org/git.html>
If you're working on a translation, make note of the commit ID from `osbwww.git`
and keep track of further changes (to the English website) in that repository.
@ -26,12 +26,12 @@ and keep track of further changes (to the English website) in that repository.
When you send the translation, please specify what commit ID in `osbwww.git` it
is up to date with. From then on, I will keep track of changes to the English
website, which is what I work on. My native language is English. When the first
translation is made available on osboot.org, I will create a new page (in
translation is made available on libreboot.org, I will create a new page (in
English only), and add notes to it whenever I make site changes, and show
where these changes need to then be performed in translated versions of each
page that I change.
How to translate osboot.org
How to translate libreboot.org
==============================
The documentation on <https://untitled.vimuser.org/> tells you how to handle

2
site/template-license.md
View File

@ -16,7 +16,7 @@ The file `template.include` is the modified version (modified by Leah Rowe).
The original version can be found here: [/template.original](/template.original)
Other modified templates may be used, on specific pages. Check for this on the
Git repository for the osboot website.
Git repository for the libreboot website.
The original template file named `template.original` by John MacFarlane was
released under these conditions:

16
site/who.md
View File

@ -1,32 +1,32 @@
---
title: Who develops osboot?
title: Who develops libreboot?
x-toc-enable: true
...
The purpose of this page is to clearly define who works on osboot, who runs
The purpose of this page is to clearly define who works on libreboot, who runs
the project, how decisions are made, and in general how the project functions.
You can find information about major contributions made to osboot, on this
You can find information about major contributions made to libreboot, on this
page which lists such people: [List of contributors](contrib.md)
Leah Rowe (founder, lead developer)
===================================
Leah Rowe is the founder of the osboot project. Leah oversees all development of osboot, reviewing
Leah Rowe is the founder of the libreboot project. Leah oversees all development of libreboot, reviewing
outside contributions, and has the final say over all decisions. Leah owns and
operates the osboot.org servers from her lab in the UK.
operates the libreboot.org servers from her lab in the UK.
You can learn more about Leah's involvement with osboot, by reading her
You can learn more about Leah's involvement with libreboot, by reading her
entry on the [page listing all contributors, past and present](contrib.md)
Caleb La Grange
===============
Caleb goes by the screen name `shmalebx9`.
Caleb mainly deals with improvements to the osbmk build system, board porting,
Caleb mainly deals with improvements to the lbmk build system, board porting,
and documentation.
You can learn more about Caleb's involvement with osboot, by reading his
You can learn more about Caleb's involvement with libreboot, by reading his
entry on the [page listing all contributors, past and present](contrib.md)
Developers wanted!