diff options
| author | Francis Rowe <info@gluglug.org.uk> | 2015-06-27 21:20:19 (EDT) |
|---|---|---|
| committer | Francis Rowe <info@gluglug.org.uk> | 2015-06-27 21:20:19 (EDT) |
| commit | 0e3520f74d25bc43572a1afeaa4439bfedcc0d78 (patch) | |
| tree | 0a94f3f6574017e7bd0a8a03f6bd86dae5912db2 | |
| parent | d56f1258cc63b9981d29f37530fafd72b5acf904 (diff) | |
| download | libreboot-0e3520f74d25bc43572a1afeaa4439bfedcc0d78.zip libreboot-0e3520f74d25bc43572a1afeaa4439bfedcc0d78.tar.gz libreboot-0e3520f74d25bc43572a1afeaa4439bfedcc0d78.tar.bz2 | |
s/machine/system
It was annoying me.
27 files changed, 120 insertions, 120 deletions
diff --git a/docs/archive_old.html b/docs/archive_old.html index 386feca..0d59019 100644 --- a/docs/archive_old.html +++ b/docs/archive_old.html @@ -561,7 +561,7 @@ This was put there before for users upgrading from libreboot r5 to r6, but also allows the user to flash the wrong image. For example, the user could flash a T60 image on an X60, thus - bricking the machine. It's almost certain that most people + bricking the system. It's almost certain that most people have upgraded by now, so remove this potentially dangerous option. </li> @@ -676,7 +676,7 @@ </ul> </li> </ul> - <h2>New machines supported in this release:</h2> + <h2>New systems supported in this release:</h2> <ul> <li> <b>Lenovo ThinkPad X60 Tablet</b> (1024x768 and 1400x1050) with digitizer support @@ -708,7 +708,7 @@ </ul> <h2>Machines no longer supported (compared to previous release):</h2> <ul> - <li><b>All previous machines still supported!</b></li> + <li><b>All previous systems still supported!</b></li> </ul> <h2> @@ -725,7 +725,7 @@ <li>Regression fix: Re-add CD-ROM (ata0) in GRUB</li> <li>Documentation: add notes about performance penalty when using ecryptfs.</li> <li>Documentation: Fixed spelling and grammatical errors.</li> - <li>Documentation: macbook21: add new machine as tested</li> + <li>Documentation: macbook21: add new system as tested</li> <li>Documentation: macbook21: add info about improving touchpad sensitivity</li> <li>Documentation: X60 Tablet: add more information about finger input</li> <li>Documentation: release.html: Add information about recently merged commit in coreboot</li> @@ -786,7 +786,7 @@ </ul> </li> <li>Updated GRUB to new version from August 14th, 2014.</li> - <li>Unified all grub configurations for all machines to a single grub.cfg under resources/grub/config/</li> + <li>Unified all grub configurations for all systems to a single grub.cfg under resources/grub/config/</li> <li>Updated flashrom to new version from August 20th, 2014</li> <li> Added getseabios and builddeps-seabios (builddeps and getall were also updated) @@ -815,7 +815,7 @@ <li>Commented out lines in resources/grub/config/grub.cfg for loading font/background (not useful anymore, now that GRUB is in text-mode).</li> <li>Commented out lines in buildrom-withgrub that included backgrounds/fonts (not useful anymore, now that GRUB is in text-mode).</li> <li> - Added resources/utilities/i945-pwm/ (from git://git.mtjm.eu/i945-pwm), for debugging acpi brightness on i945 machines. + Added resources/utilities/i945-pwm/ (from git://git.mtjm.eu/i945-pwm), for debugging acpi brightness on i945 systems. <ul> <li>Added instructions for it in builddeps, builddeps-i945pwm, builddeb and cleandeps</li> </ul> @@ -849,7 +849,7 @@ <li>Moved resources/grub/keymap to resources/utilities/grub-assemble/keymap, and updated that utility to use it</li> <li>Documentation: removed useless links to pictures of keyboard layouts and unmodified layouts.</li> <li>Removed all unused fonts from dejavu-fonts-ttf-2.34/ directory</li> - <li>'buildrom-withgrub' script: updated it to create 2 sets of ROMs for each machine: one with text-mode, one with coreboot framebuffer.</li> + <li>'buildrom-withgrub' script: updated it to create 2 sets of ROMs for each system: one with text-mode, one with coreboot framebuffer.</li> <li>Documentation: updated index.html#rom to reflect the above</li> <li>Deleted unused README and COPYING file from main directory</li> <li>Removed some rm -Rf .git* instructions from the get* scripts and moved them to build-release script</li> diff --git a/docs/future/index.html b/docs/future/index.html index d39f8a9..df67797 100644 --- a/docs/future/index.html +++ b/docs/future/index.html @@ -141,7 +141,7 @@ </p> <p> - Run that tool (resources/utilities/i945gpu/intel-regs.py) as root on machines with the offending panels in: + Run that tool (resources/utilities/i945gpu/intel-regs.py) as root on systems with the offending panels in: </p> <ul> <li>Coreboot (or libreboot, whatever) with VBIOS (disable native graphics also)</li> @@ -286,8 +286,8 @@ f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ Before each test run, boot a live USB and delete the old logs in /var/log (kernel log, xorg log, dmesg and so on). </p> <p> - Load (from the ROM) the runningvga.bin for each LCD panel on each machine; do not execute it, only load it! (coreboot will have to be modified). - Rename the ROM appropriately, based on the machine name and the panel name. coreboot_nativegfx_5868_plusrunningvga_t60_14_LTD141ECMB.rom, + Load (from the ROM) the runningvga.bin for each LCD panel on each system; do not execute it, only load it! (coreboot will have to be modified). + Rename the ROM appropriately, based on the system name and the panel name. coreboot_nativegfx_5868_plusrunningvga_t60_14_LTD141ECMB.rom, for instance. Keep a copy for later use. </p> @@ -299,7 +299,7 @@ f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <p> With each boot, make notes about what you see and get logs using the <a href="#standard_test">standard test</a>. - You will need the files from <a href="#intelvbttool_results">#intelvbttool_results</a> for each machine. + You will need the files from <a href="#intelvbttool_results">#intelvbttool_results</a> for each system. </p> Results (# means untested): @@ -418,7 +418,7 @@ f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ </p> <p> - Backup both files (runningvga.bin and intelvbttool_out), renaming them to match the machine and LCD panel used. + Backup both files (runningvga.bin and intelvbttool_out), renaming them to match the system and LCD panel used. <a href="../misc/index.html#get_edid_panelname">../misc/index.html#get_edid_panelname</a> will show you how to get the name (model) of the LCD panel used. </p> diff --git a/docs/future/old.html b/docs/future/old.html index 950e2c4..42db718 100644 --- a/docs/future/old.html +++ b/docs/future/old.html @@ -80,7 +80,7 @@ Reading <b>0xe4361254</b> (address) in Lenovo BIOS always yields FFFFFFFF, even when writing to it (and writing to it doesn't affect brightness controls). 'mtjm' on IRC found that the buttons (Fn keys) control /sys/class/backlight/acpi_video0 which has no affect on 61254 (BLC_PWM_CTL). He says intel_backlight has different values and uses the register. devmem2 works, needs checking <b>lspci -vv</b> for where the memory is mapped, - which is different than on coreboot; mtjm found that it was 0xec061254 on his machine (X60 Tablet), and the register value is different too. + which is different than on coreboot; mtjm found that it was 0xec061254 on his system (X60 Tablet), and the register value is different too. <b>This is relevant, because we still don't know how backlight controls are actually handled. We got it working by accident. We need to know more.</b>. </p> <p> @@ -225,7 +225,7 @@ <p> <b> The replay code is obsolete (see 5320 changeset on review.coreboot.org for better version - which supports more machines/screens, and then 5345 for T60). Information here for reference since that is where the fix was first applied. + which supports more systems/screens, and then 5345 for T60). Information here for reference since that is where the fix was first applied. </b> </p> diff --git a/docs/git/index.html b/docs/git/index.html index e21bf72..e220760 100644 --- a/docs/git/index.html +++ b/docs/git/index.html @@ -152,11 +152,11 @@ external flashing will be safe regardless. Each ROM contains identical data inside the two final 64K region in the file*. This corresponds to the final two 64K regions in the flash chip. Lenovo BIOS will prevent you from writing the - final one, so running "<b>bucts 1</b>" will set the machine to boot from the other block instead (which + final one, so running "<b>bucts 1</b>" will set the system to boot from the other block instead (which is writeable along with everything beneath it when using a patched flashrom. see <a href="#build_flashrom">#build_flashrom</a>). After shutting down and booting up after the first flash of libreboot, the final 64K block is writeable so you flash the ROM again with an unpatched flashrom and run "<b>bucts 0</b>" to - make the machine boot from the normal (highest) block again. + make the system boot from the normal (highest) block again. </p> <p> @@ -289,7 +289,7 @@ <p> Configurations are then saved as files called <b>".config"</b>. Copies of each configuration used - for each machine type by the libreboot build scripts are stored in resources/libreboot/config/ + for each system type by the libreboot build scripts are stored in resources/libreboot/config/ </p> <div class="subsection"> @@ -334,7 +334,7 @@ Display / Keep VESA framebuffer = <i>disable</i> (disable for text-mode graphics, enable for coreboot vesa framebuffer) <ul> <li>Libreboot provides this with text-mode enabled by default, but it automatically patches a copy of the config at build time - to enable coreboot framebuffer for a separate set of ROM images, in each machine.</li> + to enable coreboot framebuffer for a separate set of ROM images, in each system.</li> </ul> </li> <li>Generic Drivers / USB 2.0 EHCI debug dongle support = <i>Enable</i></li> @@ -355,7 +355,7 @@ </ul> <p> The resulting .config file was saved as resources/libreboot/config/<b>kfsn4-dre/config</b> and is used by the build - scripts for this machine. + scripts for this system. </p> </div> @@ -376,7 +376,7 @@ Display / Keep VESA framebuffer = <i>disable</i> (disable for text-mode graphics, enable for coreboot vesa framebuffer) <ul> <li>Libreboot provides this with text-mode enabled by default, but it automatically patches a copy of the config at build time - to enable coreboot framebuffer for a separate set of ROM images, in each machine.</li> + to enable coreboot framebuffer for a separate set of ROM images, in each system.</li> </ul> </li> <li>Generic Drivers / USB 2.0 EHCI debug dongle support = <i>Enable</i></li> @@ -397,7 +397,7 @@ </ul> <p> The resulting .config file was saved as resources/libreboot/config/<b>x60/config</b> and is used by the build - scripts for this machine. + scripts for this system. </p> <p> This configuration is used on all variants: X60, X60S and X60 Tablet. @@ -426,7 +426,7 @@ Display / Keep VESA framebuffer = <i>disable</i> (disable for text-mode graphics, enable for coreboot vesa framebuffer) <ul> <li>Libreboot provides this with text-mode enabled by default, but it automatically patches a copy of the config at build time - to enable coreboot framebuffer for a separate set of ROM images, in each machine.</li> + to enable coreboot framebuffer for a separate set of ROM images, in each system.</li> </ul> </li> <li>Generic Drivers / USB 2.0 EHCI debug dongle support = <i>Enable</i></li> @@ -446,7 +446,7 @@ </ul> <p> The resulting .config file was saved as resources/libreboot/config/<b>t60/config</b> and is used by the build - scripts for this machine. + scripts for this system. </p> <p> It is believed that the motherboards on 14.1" and 15.1" T60s are the same, so the same configuration is used @@ -475,7 +475,7 @@ Display / Keep VESA framebuffer = <i>disable</i> (disable for text-mode graphics, enable for coreboot vesa framebuffer) <ul> <li>Libreboot provides this with text-mode enabled by default, but it automatically patches a copy of the config at build time - to enable coreboot framebuffer for a separate set of ROM images, in each machine.</li> + to enable coreboot framebuffer for a separate set of ROM images, in each system.</li> </ul> </li> <li>Generic Drivers / USB 2.0 EHCI debug dongle support = <i>Enable</i></li> @@ -497,7 +497,7 @@ <p> The resulting .config file was saved as resources/libreboot/config/<b>x200_8mb/config</b> and resources/libreboot/config/<b>x200_4mb/config</b> and is used by the build - scripts for this machine. + scripts for this system. </p> </div> @@ -522,7 +522,7 @@ Display / Keep VESA framebuffer = <i>disable</i> (disable for text-mode graphics, enable for coreboot vesa framebuffer) <ul> <li>Libreboot provides this with text-mode enabled by default, but it automatically patches a copy of the config at build time - to enable coreboot framebuffer for a separate set of ROM images, in each machine.</li> + to enable coreboot framebuffer for a separate set of ROM images, in each system.</li> </ul> </li> <li>Generic Drivers / USB 2.0 EHCI debug dongle support = <i>Enable</i></li> @@ -543,7 +543,7 @@ <p> The resulting .config file was saved as resources/libreboot/config/<b>r400_8mb/config</b> and resources/libreboot/config/<b>r400_4mb/config</b> and is used by the build - scripts for this machine. + scripts for this system. </p> </div> @@ -568,7 +568,7 @@ Display / Keep VESA framebuffer = <i>disable</i> (disable for text-mode graphics, enable for coreboot vesa framebuffer) <ul> <li>Libreboot provides this with text-mode enabled by default, but it automatically patches a copy of the config at build time - to enable coreboot framebuffer for a separate set of ROM images, in each machine.</li> + to enable coreboot framebuffer for a separate set of ROM images, in each system.</li> </ul> </li> <li>Generic Drivers / USB 2.0 EHCI debug dongle support = <i>Enable</i></li> @@ -589,7 +589,7 @@ <p> The resulting .config file was saved as resources/libreboot/config/<b>t400_8mb/config</b> and resources/libreboot/config/<b>t400_4mb/config</b> and is used by the build - scripts for this machine. + scripts for this system. </p> </div> @@ -614,7 +614,7 @@ Display / Keep VESA framebuffer = <i>disable</i> (disable for text-mode graphics, enable for coreboot vesa framebuffer) <ul> <li>Libreboot provides this with text-mode enabled by default, but it automatically patches a copy of the config at build time - to enable coreboot framebuffer for a separate set of ROM images, in each machine.</li> + to enable coreboot framebuffer for a separate set of ROM images, in each system.</li> </ul> </li> <li>Generic Drivers / USB 2.0 EHCI debug dongle support = <i>Enable</i></li> @@ -635,7 +635,7 @@ <p> The resulting .config file was saved as resources/libreboot/config/<b>t500_8mb/config</b> and resources/libreboot/config/<b>t500_4mb/config</b> and is used by the build - scripts for this machine. + scripts for this system. </p> </div> @@ -661,7 +661,7 @@ Display / Keep VESA framebuffer = <i>disable</i> (disable for text-mode graphics, enable for coreboot vesa framebuffer) <ul> <li>Libreboot provides this with text-mode enabled by default, but it automatically patches a copy of the config at build time - to enable coreboot framebuffer for a separate set of ROM images, in each machine.</li> + to enable coreboot framebuffer for a separate set of ROM images, in each system.</li> </ul> </li> <li>Generic Drivers / USB 2.0 EHCI debug dongle support = <i>Enable</i></li> @@ -681,7 +681,7 @@ </ul> <p> The resulting .config file was saved as resources/libreboot/config/<b>macbook21/config</b> and is used by the build - scripts for this machine. <b>This config is also used for the MacBook1,1</b>. + scripts for this system. <b>This config is also used for the MacBook1,1</b>. </p> </div> @@ -699,7 +699,7 @@ Display / Keep VESA framebuffer = <i>enable</i> (disable for text-mode graphics, enable for coreboot vesa framebuffer) <ul> <li>Libreboot provides this with framebuffer enabled by default, but it automatically patches a copy of the config at build time - to enable coreboot text-mode for a separate set of ROM images, in each machine.</li> + to enable coreboot text-mode for a separate set of ROM images, in each system.</li> </ul> </li> @@ -715,7 +715,7 @@ </ul> <p> The resulting .config file was saved as resources/libreboot/config/<b>qemu_i440fx_piix4/config</b> and is used by the build - scripts for this machine. + scripts for this system. </p> </div> @@ -733,7 +733,7 @@ Display / Keep VESA framebuffer = <i>enable</i> (disable for text-mode graphics, enable for coreboot vesa framebuffer) <ul> <li>Libreboot provides this with framebuffer enabled by default, but it automatically patches a copy of the config at build time - to enable coreboot text-mode for a separate set of ROM images, in each machine.</li> + to enable coreboot text-mode for a separate set of ROM images, in each system.</li> </ul> </li> @@ -749,7 +749,7 @@ </ul> <p> The resulting .config file was saved as resources/libreboot/config/<b>qemu_q35_ich9/config</b> and is used by the build - scripts for this machine. + scripts for this system. </p> </div> @@ -874,7 +874,7 @@ </p> <p> <b>To include statically linked i686 and x86_64 binaries for bucts and flashrom, - you will need to build them on a chroot, a virtual machine or a real + you will need to build them on a chroot, a virtual system or a real system where the host uses each given architecture. These packages are difficult to cross-compile, and the libreboot project is still figuring out how to deal with them.</b> @@ -917,7 +917,7 @@ </p> <p> - The ROM images will be stored in separate archives for each machine, under <b>release/rom/</b>. + The ROM images will be stored in separate archives for each system, under <b>release/rom/</b>. </p> </div> diff --git a/docs/gnulinux/configuring_parabola.html b/docs/gnulinux/configuring_parabola.html index 6d2ebe2..df87618 100644 --- a/docs/gnulinux/configuring_parabola.html +++ b/docs/gnulinux/configuring_parabola.html @@ -77,7 +77,7 @@ <p> While not strictly related to the libreboot project, this guide is intended to be useful for those interested in installing - Parabola on their libreboot machine. + Parabola on their libreboot system. </p> <p> @@ -107,7 +107,7 @@ <p> Paradoxically, as you get more advanced Parabola can actually become <i>easier to use</i> - when you want to set up your machine in a special way compared to what most distributions provide. + when you want to set up your system in a special way compared to what most distributions provide. You will find over time that other distributions tend to <i>get in your way</i>. </p> @@ -142,7 +142,7 @@ <p> Some of these steps require internet access. I'll go into networking later but for now, I just connected - my machine to a switch and did:<br/> + my system to a switch and did:<br/> # <b>systemctl start dhcpcd.service</b><br/> You can stop it later by running:<br/> # <b>systemctl stop dhcpcd.service</b><br/> @@ -674,7 +674,7 @@ <p> Enable LXDM (the default display manager, providing a graphical login):<br/> # <b>systemctl enable lxdm.service</b><br/> - It will start when you boot up the machine. To start it now, do:<br/> + It will start when you boot up the system. To start it now, do:<br/> # <b>systemctl start lxdm.service</b> </p> <p> @@ -758,7 +758,7 @@ <div class="subsection"> <h3 id="lxde_suspend">LXDE - disable suspend</h3> <p> - When closing the laptop lid, the machine suspends. This is annoying at least to me. + When closing the laptop lid, the system suspends. This is annoying at least to me. NOTE TO SELF: disable it, then document the steps here. </p> <p> diff --git a/docs/gnulinux/encrypted_parabola.html b/docs/gnulinux/encrypted_parabola.html index 0b7c0eb..7a74f93 100644 --- a/docs/gnulinux/encrypted_parabola.html +++ b/docs/gnulinux/encrypted_parabola.html @@ -28,7 +28,7 @@ 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 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 machine. + access to the system. </p> <p> <a href="index.html">Back to previous index</a> diff --git a/docs/gnulinux/encrypted_trisquel.html b/docs/gnulinux/encrypted_trisquel.html index 32eeaff..367dbbf 100644 --- a/docs/gnulinux/encrypted_trisquel.html +++ b/docs/gnulinux/encrypted_trisquel.html @@ -28,7 +28,7 @@ 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 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 machine. + access to the system. </p> <p> This works in Trisquel 7, and probably Trisquel 6. Boot the 'net installer' (Install Trisquel in Text Mode). diff --git a/docs/gnulinux/grub_cbfs.html b/docs/gnulinux/grub_cbfs.html index 82cbc4b..6de1e54 100644 --- a/docs/gnulinux/grub_cbfs.html +++ b/docs/gnulinux/grub_cbfs.html @@ -89,10 +89,10 @@ <p> There are several advantages to modifying the GRUB configuration stored in CBFS, but - this also means that you have to flash a new libreboot ROM image on your machine (some users + this also means that you have to flash a new libreboot ROM image on your system (some users feel intimidated by this, to say the least). Doing so can be risky if not handled correctly, because it can result in a bricked - machine (recovery is easy if you have the <a href="../install/bbb_setup.html">equipment</a> + system (recovery is easy if you have the <a href="../install/bbb_setup.html">equipment</a> for it, but most people don't). If you aren't up to that then don't worry; it is possible to use a custom GRUB menu without flashing a new image, by loading a GRUB configuration from a partition on the main storage instead. @@ -270,7 +270,7 @@ The libreboot.rom file contains your <i>grub.cfg</i> and <i>grubtest.cfg</i> files. grub.cfg will load first, but it has a menu entry for switching to the copy (grubtest.cfg). Thus, you should extract, modify and re-insert the grubtest.cfg first. - This reduces your chance of making a mistake that could make your machine unbootable (or very hard to boot). + This reduces your chance of making a mistake that could make your system unbootable (or very hard to boot). </p> <p> diff --git a/docs/hcl/gm45_remove_me.html b/docs/hcl/gm45_remove_me.html index a70838d..52edf9c 100644 --- a/docs/hcl/gm45_remove_me.html +++ b/docs/hcl/gm45_remove_me.html @@ -19,14 +19,14 @@ <p> This sections relates to disabling and removing the ME (Intel <b>M</b>anagement <b>E</b>ngine) on GM45. This was originally done on the ThinkPad X200, and later adapted for the ThinkPad R400/T400/T500. It can - in principle be done on any GM45 or GS45 machine. + in principle be done on any GM45 or GS45 system. </p> <p> The ME is a blob that typically must be left inside the flash chip (in the ME region, as outlined by the default descriptor). On GM45, it is possible to remove it without any ill effects. All - other parts of coreboot on GM45 machines (provided GMA MHD4500 / Intel graphics) can be blob-free, + other parts of coreboot on GM45 systems (provided GMA MHD4500 / Intel graphics) can be blob-free, so removing the ME was the last obstacle to - make GM45 a feasible target in libreboot (the machines can also work without the microcode blobs). + make GM45 a feasible target in libreboot (the systems can also work without the microcode blobs). </p> <p> The ME is removed and disabled in libreboot by modifying the descriptor. More info about @@ -121,7 +121,7 @@ </p> <p> - Your libreboot.rom image is now ready to be flashed on the machine. Refer back to + Your libreboot.rom image is now ready to be flashed on the system. Refer back to <a href="../install/index.html#flashrom">../install/index.html#flashrom</a> for how to flash it. </p> @@ -161,12 +161,12 @@ <h1 id="ich9deblob">ICH9 deblob utility</h1> <p> - <b>This is no longer strictly necessary. Libreboot ROM images for GM45 machines now + <b>This is no longer strictly necessary. Libreboot ROM images for GM45 systems now contain the 12KiB descriptor+gbe generated from ich9gen, by default.</b> </p> <p> - This was the tool originally used to disable the ME on X200 (later adapted for other machines that use the + This was the tool originally used to disable the ME on X200 (later adapted for other systems that use the GM45 chipset). <a href="#ich9gen">ich9gen</a> now supersedes it; ich9gen is better because it does not rely on dumping the factory.rom image (whereas, ich9deblob does). </p> @@ -187,14 +187,14 @@ </p> <p> - Place the factory.rom from your machine + Place the factory.rom from your system (can be obtained using the external flashing guides for GM45 targets linked <a href="../install/index.html">../install/index.html</a>) in the directory where you have your ich9deblob executable, then run the tool:<br/> $ <b>./ich9deblob</b> </p> <p> A 12kiB file named <b>deblobbed_descriptor.bin</b> will now appear. <b>Keep this and the factory.rom stored in a safe location!</b> - The first 4KiB contains the descriptor data region for your machine, and the next 8KiB contains the gbe region (config data for your + The first 4KiB contains the descriptor data region for your system, and the next 8KiB contains the gbe region (config data for your gigabit NIC). These 2 regions could actually be separate files, but they are joined into 1 file in this case. </p> @@ -493,7 +493,7 @@ DD CC 18 00 11 20 17 00 DD DD 18 00 12 20 17 00 <p> By default, the X200 (as shipped by Lenovo) actually has an invalid main gbe checksum. The backup gbe region is correct, - and is what these machines default to. Basically, you should do what you need on the *backup* gbe region, and + and is what these systems default to. Basically, you should do what you need on the *backup* gbe region, and then correct the main one by copying from the backup. </p> diff --git a/docs/hcl/index.html b/docs/hcl/index.html index de3c4da..11350cd 100644 --- a/docs/hcl/index.html +++ b/docs/hcl/index.html @@ -32,7 +32,7 @@ <h2 id="supported_list">List of supported hardware</h2> <p> - Libreboot supports the following machines in this release: + Libreboot supports the following systems in this release: </p> <ul> <li><a href="kfsn4-dre.html">ASUS KFSN4-DRE server/workstation board</a></li> @@ -48,13 +48,13 @@ </ul> <p> - 'Supported' means that the build scripts know how to build ROM images for these machines, - and that the machines have been tested (confirmed working). There may be exceptions; - in other words, this is a list of 'officially' supported machines. + 'Supported' means that the build scripts know how to build ROM images for these systems, + and that the systems have been tested (confirmed working). There may be exceptions; + in other words, this is a list of 'officially' supported systems. </p> <p> - It is also possible to build ROM images (from source) for other machines (and virtual machines, e.g. QEMU). + It is also possible to build ROM images (from source) for other systems (and virtual systems, e.g. QEMU). </p> <p><a href="#pagetop">Back to top of page</a></p> @@ -107,7 +107,7 @@ <p> The X60 typically comes with an Intel wifi chipset which does not work at all without proprietary firmware, and while Lenovo BIOS is running - the machine will refuse to boot if you replace the card. Fortunately it is very easily replaced; + the system will refuse to boot if you replace the card. Fortunately it is very easily replaced; just remove the card and install another one <b>after</b> libreboot is installed. See <a href="#recommended_wifi">#recommended_wifi</a> for replacements. </p> @@ -160,7 +160,7 @@ <p> The X60 Tablet typically comes with an Intel wifi chipset which does not work at all without proprietary firmware, and while Lenovo BIOS is running - the machine will refuse to boot if you replace the card. Fortunately it is very easily replaced; + the system will refuse to boot if you replace the card. Fortunately it is very easily replaced; just remove the card and install another one <b>after</b> libreboot is installed. See <a href="#recommended_wifi">#recommended_wifi</a> for replacements. </p> @@ -299,7 +299,7 @@ EndSection <p> The T60 typically comes with an Intel wifi chipset which does not work at all without proprietary firmware, and while Lenovo BIOS is running - the machine will refuse to boot if you replace the card. Fortunately it is very easily replaced; + the system will refuse to boot if you replace the card. Fortunately it is very easily replaced; just remove the card and install another one <b>after</b> libreboot is installed. See <a href="#recommended_wifi">#recommended_wifi</a> for replacements. </p> @@ -409,7 +409,7 @@ EndSection </p> <p> - No method is yet known for flashing in GNU/Linux while the Apple firmware is running. You will need to disassemble the machine and flash externally. + No method is yet known for flashing in GNU/Linux while the Apple firmware is running. You will need to disassemble the system and flash externally. Reading from flash seems to work. For external flashing, refer to <a href="../install/bbb_setup.html">../install/bbb_setup.html</a>. </p> @@ -517,7 +517,7 @@ EndSection </p> <p> - There are some issues with this machine (compared to other computers that libreboot supports): + There are some issues with this system (compared to other computers that libreboot supports): </p> <p> @@ -527,7 +527,7 @@ EndSection </p> <p> - The machine does get a bit hotter compared to when running the original firmware. It is certainly hotter + The system does get a bit hotter compared to when running the original firmware. It is certainly hotter than an X60/T60. The heat issues have been partially fixed by the following patch (now merged in libreboot): <a href="http://review.coreboot.org/#/c/7923/">http://review.coreboot.org/#/c/7923/</a>. </p> diff --git a/docs/hcl/x200.html b/docs/hcl/x200.html index f741eb4..b79c5d1 100644 --- a/docs/hcl/x200.html +++ b/docs/hcl/x200.html @@ -65,7 +65,7 @@ <p> This method of disabling the ME leaves the flash descriptor and gbe in place (non-functional data, fully documented) - and disables the ME using soft straps. This means that the gigabit ethernet will still work (putting the machine in + and disables the ME using soft straps. This means that the gigabit ethernet will still work (putting the system in non-descriptor mode would wipe it out). </p> @@ -351,8 +351,8 @@ <pre> <sgsit> do you know if it's possible to flash thinkpads over the LPC debug connector at the front edge? -<sgsit> that would make life much easier for machines like this -<sgsit> all the Wistron manufactured machines have this thing called a "golden finger", normally at the front edge of the board +<sgsit> that would make life much easier for systems like this +<sgsit> all the Wistron manufactured systems have this thing called a "golden finger", normally at the front edge of the board <sgsit> you can plug a board in which gives diagnostic codes but i'm wondering whether it is capable of more <sgsit> <a href="http://www.endeer.cz/bios.tools/bios.html">http://www.endeer.cz/bios.tools/bios.html</a> </pre> diff --git a/docs/install/index.html b/docs/install/index.html index fa73a37..5d5757a 100644 --- a/docs/install/index.html +++ b/docs/install/index.html @@ -310,7 +310,7 @@ <p> <b> Warning: this guide will not instruct the user how to backup the original Lenovo BIOS firmware. These backups - are tied to each machine, and will not work on any other. + are tied to each system, and will not work on any other. For that, please refer to <a href="http://www.coreboot.org/Board:lenovo/x60/Installation">http://www.coreboot.org/Board:lenovo/x60/Installation</a>. </b> </p> diff --git a/docs/install/r400_external.html b/docs/install/r400_external.html index cec56b4..060b283 100644 --- a/docs/install/r400_external.html +++ b/docs/install/r400_external.html @@ -387,7 +387,7 @@ Please specify which chip definition to use with the -c <chipname> option. the redundant flash chip definitions in <i>flashchips.c</i> have been removed.<br/> Now compare the 3 images:<br/> # <b>sha512sum factory*.rom</b><br/> - If the hashes match, then just copy one of them (the factory.rom) to a safe place (on a drive connected to another machine, not + 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 libreboot. </p> @@ -443,7 +443,7 @@ Verifying flash... VERIFIED. <p> When re-installing the heatsink, you must first clean off all old paste with the alcohol/cloth. - Then apply new paste. AS5 is also much better than the default paste used on these machines. + Then apply new paste. AS5 is also much better than the default paste used on these systems. </p> <p> diff --git a/docs/install/t400_external.html b/docs/install/t400_external.html index 045d502..73eb3cc 100644 --- a/docs/install/t400_external.html +++ b/docs/install/t400_external.html @@ -364,7 +364,7 @@ Please specify which chip definition to use with the -c <chipname> option. the redundant flash chip definitions in <i>flashchips.c</i> have been removed.<br/> Now compare the 3 images:<br/> # <b>sha512sum factory*.rom</b><br/> - If the hashes match, then just copy one of them (the factory.rom) to a safe place (on a drive connected to another machine, not + 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 libreboot. </p> @@ -419,7 +419,7 @@ Verifying flash... VERIFIED. <p> When re-installing the heatsink, you must first clean off all old paste with the alcohol/cloth. - Then apply new paste. AS5 is also much better than the default paste used on these machines. + Then apply new paste. AS5 is also much better than the default paste used on these systems. </p> <p> diff --git a/docs/install/t500_external.html b/docs/install/t500_external.html index 048980a..54e6718 100644 --- a/docs/install/t500_external.html +++ b/docs/install/t500_external.html @@ -246,7 +246,7 @@ POMONA 5250 (correlate with the BBB guide) <p> When you re-assemble, you will be replacing the wifi chip with another. These two screws don't hold anything together, - but they are included in your machine because the screw + but they are included in your system because the screw holes for half-height cards are a different size, so use these if you will be installing a half-height card:<br/> <img src="images/t500/0027.jpg" alt="" /> @@ -324,7 +324,7 @@ POMONA 5250 (correlate with the BBB guide) </p> <p> The flash chip is next to the memory slots. On this - machine, it was a SOIC-8 (4MiB or 32Mb) flash chip:<br/> + system, it was a SOIC-8 (4MiB or 32Mb) flash chip:<br/> <img src="images/t500/0060.jpg" alt="" /> </p> <p> @@ -381,7 +381,7 @@ Please specify which chip definition to use with the -c <chipname> option. the redundant flash chip definitions in <i>flashchips.c</i> have been removed.<br/> Now compare the 3 images:<br/> # <b>sha512sum factory*.rom</b><br/> - If the hashes match, then just copy one of them (the factory.rom) to a safe place (on a drive connected to another machine, not + 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 libreboot. </p> @@ -436,7 +436,7 @@ Verifying flash... VERIFIED. <p> When re-installing the heatsink, you must first clean off all old paste with the alcohol/cloth. - Then apply new paste. AS5 is also much better than the default paste used on these machines. + Then apply new paste. AS5 is also much better than the default paste used on these systems. </p> <p> diff --git a/docs/install/t60_unbrick.html b/docs/install/t60_unbrick.html index d05078c..e92298b 100644 --- a/docs/install/t60_unbrick.html +++ b/docs/install/t60_unbrick.html @@ -26,7 +26,7 @@ Types of brick: <ul> <li><a href="#bucts_brick">Brick type 1: bucts not reset</a></li> - <li><a href="#recovery">Brick type 2: bad rom (or user error), machine won't boot</a></li> + <li><a href="#recovery">Brick type 2: bad rom (or user error), system won't boot</a></li> </ul> </li> </ul> @@ -45,7 +45,7 @@ dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k<br/> dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump<br/> dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc<br/> - (doing this makes the ROM suitable for use when flashing a machine that still has Lenovo BIOS running, + (doing this makes the ROM suitable for use when flashing a system that still has Lenovo BIOS running, using those instructions: <a href="http://www.coreboot.org/Board:lenovo/x60/Installation">http://www.coreboot.org/Board:lenovo/x60/Installation</a>. (it says x60, but instructions for t60 are identical) </p> @@ -53,14 +53,14 @@ <div class="section"> - <h1 id="recovery">bad rom (or user error), machine won't boot</h1> + <h1 id="recovery">bad rom (or user error), system won't boot</h1> <p> - In this scenario, you compiled a ROM that had an incorrect configuration, or there is an actual bug preventing your machine from - booting. Or, maybe, you set BUC.TS to 0 and shut down after first flash while Lenovo BIOS was running. In any case, your machine is bricked and will not boot at all. + In this scenario, you compiled a ROM that had an incorrect configuration, or there is an actual bug preventing your system from + booting. Or, maybe, you set BUC.TS to 0 and shut down after first flash while Lenovo BIOS was running. In any case, your system is bricked and will not boot at all. </p> <p> - "Unbricking" means flashing a known-good (working) ROM. The problem: you can't boot the machine, making this difficult. In this situation, external hardware (see hardware requirements above) is needed which can flash the SPI chip (where libreboot resides). + "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 libreboot resides). </p> <p> @@ -156,7 +156,7 @@ <p> Remove the shielding containing the motherboard, then flip it over. Remove these screws, placing them on a steady surface in the same layout as they were in before you removed them. Also, you should mark each screw hole after removing the - screw (a permanent marker pen will do), this is so that you have a point of reference when re-assembling the machine:<br/> + screw (a permanent marker pen will do), this is so that you have a point of reference when re-assembling the system:<br/> <img src="../images/t60_dev/0027.JPG" alt="" /> <img src="../images/t60_dev/0028.JPG" alt="" /> <img src="../images/t60_dev/0029.JPG" alt="" /> <img src="../images/t60_dev/0031.JPG" alt="" /> <img src="../images/t60_dev/0032.JPG" alt="" /> <img src="../images/t60_dev/0033.JPG" alt="" /> </p> diff --git a/docs/install/x200_external.html b/docs/install/x200_external.html index dc93582..8a24761 100644 --- a/docs/install/x200_external.html +++ b/docs/install/x200_external.html @@ -156,7 +156,7 @@ chip on those pins? </h2> <p> This section is for the X200. This does not apply to the X200S or X200 Tablet - (for those machines, you have to remove the motherboard completely, since + (for those systems, you have to remove the motherboard completely, since the flash chip is on the other side of the board). </p> <p> @@ -240,7 +240,7 @@ Please specify which chip definition to use with the -c <chipname> option. the redundant flash chip definitions in <i>flashchips.c</i> have been removed.<br/> Now compare the 3 images:<br/> # <b>sha512sum factory*.rom</b><br/> - If the hashes match, then just copy one of them (the factory.rom) to a safe place (on a drive connected to another machine, not + 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 libreboot. </p> diff --git a/docs/install/x60_unbrick.html b/docs/install/x60_unbrick.html index 0822a71..d420cb6 100644 --- a/docs/install/x60_unbrick.html +++ b/docs/install/x60_unbrick.html @@ -26,7 +26,7 @@ Types of brick: <ul> <li><a href="#bucts_brick">Brick type 1: bucts not reset</a></li> - <li><a href="#recovery">Brick type 2: bad rom (or user error), machine won't boot</a></li> + <li><a href="#recovery">Brick type 2: bad rom (or user error), system won't boot</a></li> </ul> </li> </ul> @@ -45,20 +45,20 @@ dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k<br/> dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump<br/> dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc<br/> - (doing this makes the ROM suitable for use when flashing a machine that still has Lenovo BIOS running, + (doing this makes the ROM suitable for use when flashing a system that still has Lenovo BIOS running, using those instructions: <a href="http://www.coreboot.org/Board:lenovo/x60/Installation">http://www.coreboot.org/Board:lenovo/x60/Installation</a>. </p> </div> <div class="section"> - <h1 id="recovery">bad rom (or user error), machine won't boot</h1> + <h1 id="recovery">bad rom (or user error), system won't boot</h1> <p> - In this scenario, you compiled a ROM that had an incorrect configuration, or there is an actual bug preventing your machine from - booting. Or, maybe, you set BUC.TS to 0 and shut down after first flash while Lenovo BIOS was running. In any case, your machine is bricked and will not boot at all. + In this scenario, you compiled a ROM that had an incorrect configuration, or there is an actual bug preventing your system from + booting. Or, maybe, you set BUC.TS to 0 and shut down after first flash while Lenovo BIOS was running. In any case, your system is bricked and will not boot at all. </p> <p> - "Unbricking" means flashing a known-good (working) ROM. The problem: you can't boot the machine, making this difficult. In this situation, external hardware (see hardware requirements above) is needed which can flash the SPI chip (where libreboot resides). + "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 libreboot resides). </p> <p> Remove those screws:<br/> @@ -223,7 +223,7 @@ POMONA 5250: <img src="../images/x60_unbrick/0039.jpg" alt="" /> </p> <p> - Connect the wifi antenna cables. At the start of the tutorial, this machine had an Intel wifi chip. Here you see I've replaced it with an + Connect the wifi antenna cables. At the start of the tutorial, this system had an Intel wifi chip. Here you see I've replaced it with an Atheros AR5B95 (supports 802.11n and can be used without blobs):<br/> <img src="../images/x60_unbrick/0040.jpg" alt="" /> </p> diff --git a/docs/install/x60tablet_unbrick.html b/docs/install/x60tablet_unbrick.html index 8d93f82..c64f90c 100644 --- a/docs/install/x60tablet_unbrick.html +++ b/docs/install/x60tablet_unbrick.html @@ -26,7 +26,7 @@ Types of brick: <ul> <li><a href="#bucts_brick">Brick type 1: bucts not reset</a></li> - <li><a href="#recovery">Brick type 2: bad rom (or user error), machine won't boot</a></li> + <li><a href="#recovery">Brick type 2: bad rom (or user error), system won't boot</a></li> </ul> </li> </ul> @@ -45,20 +45,20 @@ dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k<br/> dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump<br/> dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc<br/> - (doing this makes the ROM suitable for use when flashing a machine that still has Lenovo BIOS running, + (doing this makes the ROM suitable for use when flashing a system that still has Lenovo BIOS running, using those instructions: <a href="http://www.coreboot.org/Board:lenovo/x60/Installation">http://www.coreboot.org/Board:lenovo/x60/Installation</a>. </p> </div> <div class="section"> - <h1 id="recovery">bad rom (or user error), machine won't boot</h1> + <h1 id="recovery">bad rom (or user error), system won't boot</h1> <p> - In this scenario, you compiled a ROM that had an incorrect configuration, or there is an actual bug preventing your machine from - booting. Or, maybe, you set BUC.TS to 0 and shut down after first flash while Lenovo BIOS was running. In any case, your machine is bricked and will not boot at all. + In this scenario, you compiled a ROM that had an incorrect configuration, or there is an actual bug preventing your system from + booting. Or, maybe, you set BUC.TS to 0 and shut down after first flash while Lenovo BIOS was running. In any case, your system is bricked and will not boot at all. </p> <p> - "Unbricking" means flashing a known-good (working) ROM. The problem: you can't boot the machine, making this difficult. In this situation, external hardware (see hardware requirements above) is needed which can flash the SPI chip (where libreboot resides). + "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 libreboot resides). </p> <p> @@ -158,7 +158,7 @@ POMONA 5250: </p> <p> - Reverse the steps to re-assemble your machine. + Reverse the steps to re-assemble your system. </p> </div> diff --git a/docs/misc/index.html b/docs/misc/index.html index 5ed2655..5bfa82f 100644 --- a/docs/misc/index.html +++ b/docs/misc/index.html @@ -88,7 +88,7 @@ WantedBy=multi-user.target <b># systemctl enable powertop</b><br/> <b># systemctl start powertop</b></p> - <p>The next time you boot the machine, the buzz will be gone.</p> + <p>The next time you boot the system, the buzz will be gone.</p> <p><a href="#pagetop">Back to top of page</a></p> @@ -105,10 +105,10 @@ WantedBy=multi-user.target <p> If you are using one of the ROM images with 'serial' in the name, then 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 machine using your USB Serial adapter. + and connect the other end to a 2nd system using your USB Serial adapter. </p> <p> - On the 2nd machine, you can try this (using GNU Screen):<br/> + On the 2nd system, you can try this (using GNU Screen):<br/> <b>$ sudo screen /dev/ttyUSB0 115200</b> </p> <p> diff --git a/docs/security/t60_security.html b/docs/security/t60_security.html index 03bb2a0..bb2f9bb 100644 --- a/docs/security/t60_security.html +++ b/docs/security/t60_security.html @@ -50,7 +50,7 @@ <p> This tutorial deals with reducing the number of devices that have direct memory access that could communicate with inputs/outputs that could be used to remotely - command the machine (or leak data). All of this is purely theoretical for the time being. + command the system (or leak data). All of this is purely theoretical for the time being. </p> </div> @@ -157,7 +157,7 @@ <p> Remove the shielding containing the motherboard, then flip it over. Remove these screws, placing them on a steady surface in the same layout as they were in before you removed them. Also, you should mark each screw hole after removing the - screw (a permanent marker pen will do), this is so that you have a point of reference when re-assembling the machine:<br/> + screw (a permanent marker pen will do), this is so that you have a point of reference when re-assembling the system:<br/> <img src="../images/t60_dev/0027.JPG" alt="" /> <img src="../images/t60_dev/0028.JPG" alt="" /> <img src="../images/t60_dev/0029.JPG" alt="" /> <img src="../images/t60_dev/0031.JPG" alt="" /> <img src="../images/t60_dev/0032.JPG" alt="" /> <img src="../images/t60_dev/0033.JPG" alt="" /> </p> @@ -170,7 +170,7 @@ record what you say, and use it to receive data from nearby devices if they're compromised too. Also, we do not know what the built-in microcode (in the CPU) is doing; it could theoretically be programmed to accept remote commands from some speaker somewhere (remote security hole). <b>In other words, - the machine could already be compromised from the factory.</b> + the system could already be compromised from the factory.</b> </p> <p> diff --git a/docs/security/x60_security.html b/docs/security/x60_security.html index bc2f36c..8e84ccb 100644 --- a/docs/security/x60_security.html +++ b/docs/security/x60_security.html @@ -56,7 +56,7 @@ <p> This tutorial deals with reducing the number of devices that have direct memory access that could communicate with inputs/outputs that could be used to remotely - command the machine (or leak data). All of this is purely theoretical for the time being. + command the system (or leak data). All of this is purely theoretical for the time being. </p> <h1 id="procedure">Disassembly</h1> @@ -104,7 +104,7 @@ </p> <p> - The following is a summary of what you will remove (already done to this machine):<br/> + The following is a summary of what you will remove (already done to this system):<br/> <img src="../images/x60_security/0001_overview.jpg" alt="" /><br/> Note: the blue lines represent antenna cables and modem cables. You don't need to remove these, but you can if you want (to make it tidier after removing other parts). I removed the antenna wires, the modem jack, the modem cable and @@ -119,7 +119,7 @@ record what you say, and use it to receive data from nearby devices if they're compromised too. Also, we do not know what the built-in microcode (in the CPU) is doing; it could theoretically be programmed to accept remote commands from some speaker somewhere (remote security hole). <b>In other words, - the machine could already be compromised from the factory.</b> + the system could already be compromised from the factory.</b> </p> <p> @@ -104,7 +104,7 @@ if [ "${mode}" = "i945lenovo_firstflash" ] || [ "${mode}" = "i945lenovo_secondfl # anti-bricking precaution if [ ! -f "${bucts}" ]; then - printf "bucts binary not present. ABORTING so as to protect against bricking the machine.\n" + printf "bucts binary not present. ABORTING so as to protect against bricking the system.\n" exit 1 fi diff --git a/resources/scripts/helpers/build/release/tobuild b/resources/scripts/helpers/build/release/tobuild index c3e8ddc..7360fb1 100755 --- a/resources/scripts/helpers/build/release/tobuild +++ b/resources/scripts/helpers/build/release/tobuild @@ -2,7 +2,7 @@ # helper: prepare a small source archive for those utils # that don't easily cross-compile. Then the tarball can be extracted -# on those machines with the target architecture, and compiled. +# on those systems with the target architecture, and compiled. # # Copyright (C) 2014, 2015 Francis Rowe <info@gluglug.org.uk> # diff --git a/resources/scripts/helpers/download/flashrom b/resources/scripts/helpers/download/flashrom index fd71af5..a44dd45 100755 --- a/resources/scripts/helpers/download/flashrom +++ b/resources/scripts/helpers/download/flashrom @@ -50,8 +50,8 @@ printf "Enabling whitelist for Libiquity Taurinus X200\n" patch "board_enable.c" < "../resources/flashrom/patch/0001-Add-board-enable-for-Libiquity-Taurinus-X200.patch" # Remove redundant definitions for the flash chips that -# supported libreboot machines use. This removes the need -# for the user to run with the "-c" argument on these machines +# supported libreboot systems use. This removes the need +# for the user to run with the "-c" argument on these systems printf "Patching flashchips.c to remove the redundant entries\n" patch "flashchips.c" < "../resources/flashrom/patch/purged_chips.diff" diff --git a/resources/utilities/ich9deblob/src/descriptor/descriptor.h b/resources/utilities/ich9deblob/src/descriptor/descriptor.h index 263d542..47a619c 100644 --- a/resources/utilities/ich9deblob/src/descriptor/descriptor.h +++ b/resources/utilities/ich9deblob/src/descriptor/descriptor.h @@ -66,7 +66,7 @@ struct FLVALSIG /* * 4 bytes. * descriptor mode = 0FF0A55A (hex, big endian). Note: stored in ROM in little endian order. - * Anything else is considered invalid and will put the machine in non-descriptor mode. + * Anything else is considered invalid and will put the system in non-descriptor mode. */ uint32_t signature; /* Put 0x0FF0A55A here. confirmed in deblobbed_descriptor.bin */ }; diff --git a/resources/utilities/ich9deblob/src/ich9deblob.c b/resources/utilities/ich9deblob/src/ich9deblob.c index 18b5c81..72ade04 100644 --- a/resources/utilities/ich9deblob/src/ich9deblob.c +++ b/resources/utilities/ich9deblob/src/ich9deblob.c @@ -2,7 +2,7 @@ * ich9deblob.c * This file is part of the ich9deblob utility from the libreboot project * - * Purpose: disable and remove the ME from ich9m/gm45 machines in coreboot. + * Purpose: disable and remove the ME from ich9m/gm45 systems in coreboot. * * Copyright (C) 2014 Steve Shenton <sgsit@libreboot.org> * Francis Rowe <info@gluglug.org.uk> @@ -25,7 +25,7 @@ /* Original utility can be found at https://gitorious.org/ich9descriptortool */ /* - * Read a factory.rom dump (ich9m/gm45 machines) and + * Read a factory.rom dump (ich9m/gm45 systems) and * modify the flash descriptor to remove all regions except descriptor, * Gbe and BIOS. Set BIOS region to full size of the ROM image (after * the flash descriptor and gbe). Basically, deblob the descriptor. |