diff --git a/site/contact.md b/site/contact.md index fce7f4b..4b60779 100644 --- a/site/contact.md +++ b/site/contact.md @@ -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: - + Libera is one of the largest IRC networks, used for Free Software projects. Find more about them here: @@ -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: +News announcements: 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: - + diff --git a/site/contrib.md b/site/contrib.md index ed3346b..e1a3831 100644 --- a/site/contrib.md +++ b/site/contrib.md @@ -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: ) -* 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: ) +* 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: + (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: + + + +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: + +The following is an archive of autoboot.org, from when it was online back in +2016: (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): + + +(archive link: ) + + +(archive link: ) + +Fun fact: Patrick is also the lead developer of ProteanOS, an FSF-endorsed +embedded OS project: (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 and 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). diff --git a/site/docs/bsd/index.md b/site/docs/bsd/index.md index c5040ad..89ec429 100644 --- a/site/docs/bsd/index.md +++ b/site/docs/bsd/index.md @@ -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 diff --git a/site/docs/build/index.md b/site/docs/build/index.md index ea8dbee..b7edc48 100644 --- a/site/docs/build/index.md +++ b/site/docs/build/index.md @@ -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 diff --git a/site/docs/gnulinux/encrypted_debian.md b/site/docs/gnulinux/encrypted_debian.md index 453c1a6..eaf513a 100644 --- a/site/docs/gnulinux/encrypted_debian.md +++ b/site/docs/gnulinux/encrypted_debian.md @@ -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: diff --git a/site/docs/gnulinux/grub_boot_installer.md b/site/docs/gnulinux/grub_boot_installer.md index 6c77812..2c05ae5 100644 --- a/site/docs/gnulinux/grub_boot_installer.md +++ b/site/docs/gnulinux/grub_boot_installer.md @@ -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 . -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 diff --git a/site/docs/gnulinux/grub_cbfs.md b/site/docs/gnulinux/grub_cbfs.md index 8e3de64..1354ffc 100644 --- a/site/docs/gnulinux/grub_cbfs.md +++ b/site/docs/gnulinux/grub_cbfs.md @@ -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 diff --git a/site/docs/gnulinux/grub_hardening.md b/site/docs/gnulinux/grub_hardening.md index c91152a..9eaf954 100644 --- a/site/docs/gnulinux/grub_hardening.md +++ b/site/docs/gnulinux/grub_hardening.md @@ -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: -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 diff --git a/site/docs/gnulinux/guix.md b/site/docs/gnulinux/guix.md index 56023d8..831a65b 100644 --- a/site/docs/gnulinux/guix.md +++ b/site/docs/gnulinux/guix.md @@ -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 diff --git a/site/docs/gnulinux/index.md b/site/docs/gnulinux/index.md index 5c17c52..883a904 100644 --- a/site/docs/gnulinux/index.md +++ b/site/docs/gnulinux/index.md @@ -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 -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: diff --git a/site/docs/grub/index.md b/site/docs/grub/index.md index 979b48e..d3d43a1 100644 --- a/site/docs/grub/index.md +++ b/site/docs/grub/index.md @@ -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) diff --git a/site/docs/hardware/d510mo.md b/site/docs/hardware/d510mo.md index e38aadc..3a72509 100644 --- a/site/docs/hardware/d510mo.md +++ b/site/docs/hardware/d510mo.md @@ -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. diff --git a/site/docs/hardware/d945gclf.md b/site/docs/hardware/d945gclf.md index 5e85d1c..a8d0d76 100644 --- a/site/docs/hardware/d945gclf.md +++ b/site/docs/hardware/d945gclf.md @@ -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:\ diff --git a/site/docs/hardware/ga-g41m-es2l.md b/site/docs/hardware/ga-g41m-es2l.md index 508eddc..c252da1 100644 --- a/site/docs/hardware/ga-g41m-es2l.md +++ b/site/docs/hardware/ga-g41m-es2l.md @@ -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/) diff --git a/site/docs/hardware/imac52.md b/site/docs/hardware/imac52.md index 50fced1..5d1ad87 100644 --- a/site/docs/hardware/imac52.md +++ b/site/docs/hardware/imac52.md @@ -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/) diff --git a/site/docs/hardware/index.md b/site/docs/hardware/index.md index 3c9949d..d8eb138 100644 --- a/site/docs/hardware/index.md +++ b/site/docs/hardware/index.md @@ -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: - 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 diff --git a/site/docs/hardware/kcma-d8.md b/site/docs/hardware/kcma-d8.md index 8e9f09c..63ea8b5 100644 --- a/site/docs/hardware/kcma-d8.md +++ b/site/docs/hardware/kcma-d8.md @@ -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 diff --git a/site/docs/hardware/kfsn4-dre.md b/site/docs/hardware/kfsn4-dre.md index 19615a2..6d5371b 100644 --- a/site/docs/hardware/kfsn4-dre.md +++ b/site/docs/hardware/kfsn4-dre.md @@ -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). diff --git a/site/docs/hardware/kgpe-d16.md b/site/docs/hardware/kgpe-d16.md index 310e76b..61566d4 100644 --- a/site/docs/hardware/kgpe-d16.md +++ b/site/docs/hardware/kgpe-d16.md @@ -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: ) - 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) diff --git a/site/docs/hardware/mac_address.md b/site/docs/hardware/mac_address.md index 38f8a59..ccaf5d3 100644 --- a/site/docs/hardware/mac_address.md +++ b/site/docs/hardware/mac_address.md @@ -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. diff --git a/site/docs/hardware/macbook21.md b/site/docs/hardware/macbook21.md index 130cb4a..a772c15 100644 --- a/site/docs/hardware/macbook21.md +++ b/site/docs/hardware/macbook21.md @@ -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. diff --git a/site/docs/hardware/r400.md b/site/docs/hardware/r400.md index b017acc..0ef781a 100644 --- a/site/docs/hardware/r400.md +++ b/site/docs/hardware/r400.md @@ -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: - 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 diff --git a/site/docs/hardware/r500.md b/site/docs/hardware/r500.md index e3f6732..2235327 100644 --- a/site/docs/hardware/r500.md +++ b/site/docs/hardware/r500.md @@ -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. diff --git a/site/docs/hardware/t400.md b/site/docs/hardware/t400.md index 6800b17..8a828fa 100644 --- a/site/docs/hardware/t400.md +++ b/site/docs/hardware/t400.md @@ -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: - 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 diff --git a/site/docs/hardware/t500.md b/site/docs/hardware/t500.md index 5faa61b..deed8a0 100644 --- a/site/docs/hardware/t500.md +++ b/site/docs/hardware/t500.md @@ -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: - 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 diff --git a/site/docs/hardware/x200.md b/site/docs/hardware/x200.md index d7d8fe4..ae44917 100644 --- a/site/docs/hardware/x200.md +++ b/site/docs/hardware/x200.md @@ -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 diff --git a/site/docs/index.md b/site/docs/index.md index 3a5daaa..e87abc3 100644 --- a/site/docs/index.md +++ b/site/docs/index.md @@ -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/) diff --git a/site/docs/install/d510mo.md b/site/docs/install/d510mo.md index 876af29..a0cb9f2 100644 --- a/site/docs/install/d510mo.md +++ b/site/docs/install/d510mo.md @@ -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. diff --git a/site/docs/install/d945gclf.md b/site/docs/install/d945gclf.md index b2954f2..a9ab282 100644 --- a/site/docs/install/d945gclf.md +++ b/site/docs/install/d945gclf.md @@ -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. diff --git a/site/docs/install/ga-g41m-es2l.md b/site/docs/install/ga-g41m-es2l.md index 2000a95..0324065 100644 --- a/site/docs/install/ga-g41m-es2l.md +++ b/site/docs/install/ga-g41m-es2l.md @@ -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 diff --git a/site/docs/install/ich9utils.md b/site/docs/install/ich9utils.md index c1f54b1..9d0733f 100644 --- a/site/docs/install/ich9utils.md +++ b/site/docs/install/ich9utils.md @@ -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} 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 diff --git a/site/docs/install/index.md b/site/docs/install/index.md index ab1b8b0..ae38119 100644 --- a/site/docs/install/index.md +++ b/site/docs/install/index.md @@ -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) diff --git a/site/docs/install/ivy_has_common.md b/site/docs/install/ivy_has_common.md index ed66f91..7280af7 100644 --- a/site/docs/install/ivy_has_common.md +++ b/site/docs/install/ivy_has_common.md @@ -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. diff --git a/site/docs/install/kgpe-d16.md b/site/docs/install/kgpe-d16.md index 16a41bf..1b8bfaa 100644 --- a/site/docs/install/kgpe-d16.md +++ b/site/docs/install/kgpe-d16.md @@ -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. diff --git a/site/docs/install/r400_external.md b/site/docs/install/r400_external.md index fe13613..c15f7fb 100644 --- a/site/docs/install/r400_external.md +++ b/site/docs/install/r400_external.md @@ -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. diff --git a/site/docs/install/spi.md b/site/docs/install/spi.md index 57dc1e7..9836972 100644 --- a/site/docs/install/spi.md +++ b/site/docs/install/spi.md @@ -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). diff --git a/site/docs/install/t400_external.md b/site/docs/install/t400_external.md index ef01fae..d7f786c 100644 --- a/site/docs/install/t400_external.md +++ b/site/docs/install/t400_external.md @@ -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. diff --git a/site/docs/install/t440p_external.md b/site/docs/install/t440p_external.md index ec6cf94..2790738 100644 --- a/site/docs/install/t440p_external.md +++ b/site/docs/install/t440p_external.md @@ -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.\ - + 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*\ - + 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.\ - + You should now be able to see the two flash chips near the RAM.\ - + You can now proceed to [flashing](/docs/install/spi.html) this machine. diff --git a/site/docs/install/t500_external.md b/site/docs/install/t500_external.md index 61b816b..5f09190 100644 --- a/site/docs/install/t500_external.md +++ b/site/docs/install/t500_external.md @@ -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. diff --git a/site/docs/install/t60_unbrick.md b/site/docs/install/t60_unbrick.md index 42e191f..b54115d 100644 --- a/site/docs/install/t60_unbrick.md +++ b/site/docs/install/t60_unbrick.md @@ -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 diff --git a/site/docs/install/x200_external.md b/site/docs/install/x200_external.md index 32423bf..483898f 100644 --- a/site/docs/install/x200_external.md +++ b/site/docs/install/x200_external.md @@ -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) diff --git a/site/docs/install/x230_external.md b/site/docs/install/x230_external.md index 54076bb..32947e0 100644 --- a/site/docs/install/x230_external.md +++ b/site/docs/install/x230_external.md @@ -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) diff --git a/site/docs/install/x60_unbrick.md b/site/docs/install/x60_unbrick.md index 1b5ccce..5903b0b 100644 --- a/site/docs/install/x60_unbrick.md +++ b/site/docs/install/x60_unbrick.md @@ -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 diff --git a/site/docs/install/x60tablet_unbrick.md b/site/docs/install/x60tablet_unbrick.md index bb04d95..1650c47 100644 --- a/site/docs/install/x60tablet_unbrick.md +++ b/site/docs/install/x60tablet_unbrick.md @@ -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 diff --git a/site/docs/maintain/index.md b/site/docs/maintain/index.md index 4863523..290a925 100644 --- a/site/docs/maintain/index.md +++ b/site/docs/maintain/index.md @@ -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` diff --git a/site/docs/maintain/porting.md b/site/docs/maintain/porting.md index 1578a45..fd1523d 100644 --- a/site/docs/maintain/porting.md +++ b/site/docs/maintain/porting.md @@ -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 diff --git a/site/docs/misc/codenames.md b/site/docs/misc/codenames.md index f68ac2f..0986e91 100644 --- a/site/docs/misc/codenames.md +++ b/site/docs/misc/codenames.md @@ -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 diff --git a/site/docs/misc/index.md b/site/docs/misc/index.md index 5d90e4e..4b52583 100644 --- a/site/docs/misc/index.md +++ b/site/docs/misc/index.md @@ -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 - for + 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 - + for a detailed explanation. Get EDID: Find out the name (model) of your LCD panel diff --git a/site/download.md b/site/download.md index 4623ad4..8e876dd 100644 --- a/site/download.md +++ b/site/download.md @@ -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/) diff --git a/site/faq.md b/site/faq.md index 81f7cad..50b3b90 100644 --- a/site/faq.md +++ b/site/faq.md @@ -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 <insert random system here>, 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. diff --git a/site/git.md b/site/git.md index cda69e8..b043a3b 100644 --- a/site/git.md +++ b/site/git.md @@ -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: -* Website (+docs): -* Images (for website): +* Build system: +* Website (+docs): +* Images (for website): -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): @@ -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 and available in a separate +Images are hosted on 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 , so any images that you add to `osbwww-img` +hosted on , 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 - for each one. -When it is merged on the osboot website, your images will appear live. + 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 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. diff --git a/site/index.md b/site/index.md index 59d27ab..7579775 100644 --- a/site/index.md +++ b/site/index.md @@ -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). diff --git a/site/index.uk.md b/site/index.uk.md index 05f9025..b901b06 100644 --- a/site/index.uk.md +++ b/site/index.uk.md @@ -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). diff --git a/site/license.md b/site/license.md index 4d3f1ea..e7eeaf2 100644 --- a/site/license.md +++ b/site/license.md @@ -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: - + -The original logo files are here: +The original logo files are here: You can download the logo files from `osbwww-img.git`. See: - + 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. diff --git a/site/news/policy.md b/site/news/policy.md index aa099ac..8827d5c 100644 --- a/site/news/policy.md +++ b/site/news/policy.md @@ -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: - - osboot also has this + - 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. diff --git a/site/news/translations.md b/site/news/translations.md index e7db6ca..e138b0a 100644 --- a/site/news/translations.md +++ b/site/news/translations.md @@ -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:\ - +The libreboot website is available, in Markdown, from a Git repository:\ + Instructions for how to send patches are available here:\ - + 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 tells you how to handle diff --git a/site/template-license.md b/site/template-license.md index 7235509..b197464 100644 --- a/site/template-license.md +++ b/site/template-license.md @@ -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: diff --git a/site/who.md b/site/who.md index 3544bd3..19a726a 100644 --- a/site/who.md +++ b/site/who.md @@ -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!