diff options
Diffstat (limited to 'docs/hcl')
| -rw-r--r-- | docs/hcl/c201.md | 26 | ||||
| -rw-r--r-- | docs/hcl/gm45_remove_me.md | 46 | ||||
| -rw-r--r-- | docs/hcl/index.md | 118 | ||||
| -rw-r--r-- | docs/hcl/kcma-d8.md | 12 | ||||
| -rw-r--r-- | docs/hcl/kfsn4-dre.md | 4 | ||||
| -rw-r--r-- | docs/hcl/kgpe-d16.md | 14 | ||||
| -rw-r--r-- | docs/hcl/r400.md | 4 | ||||
| -rw-r--r-- | docs/hcl/t400.md | 4 | ||||
| -rw-r--r-- | docs/hcl/t500.md | 6 | ||||
| -rw-r--r-- | docs/hcl/x200.md | 36 |
10 files changed, 135 insertions, 135 deletions
diff --git a/docs/hcl/c201.md b/docs/hcl/c201.md index c8262d1f..ada724d1 100644 --- a/docs/hcl/c201.md +++ b/docs/hcl/c201.md @@ -20,7 +20,7 @@ Flashing instructions can be found at -- [Google\'s intent with CrOS devices](#googlesintent) +- [Google's intent with CrOS devices](#googlesintent) - [Considerations about ChromeOS and free operating systems](#os) - [Caution: Video acceleration requires a non-free blob, software rendering can be used instead.](#videoblobs) @@ -33,7 +33,7 @@ Flashing instructions can be found at -Google\'s intent with CrOS devices {#googlesintent} +Google's intent with CrOS devices {#googlesintent} ================================== CrOS (Chromium OS/Chrome OS) devices, such as Chromebooks, were not @@ -47,14 +47,14 @@ generally friendly to the free software movement and try to be good members of the free software community, by contributing code back. CrOS devices are designed (from the factory) to actually coax the user -into using proprietary web services (SaaSS) that invade the user\'s +into using proprietary web services (SaaSS) that invade the user's privacy (ChromeOS is literally just the Google Chrome browser when you boot up, itself proprietary and comes with proprietary add-ons like -flash. It\'s only intended for SaaSS, not actual, real computing). +flash. It's only intended for SaaSS, not actual, real computing). Google is even a member of the *PRISM* program, as outlined by Edward Snowden. See notes about ChromeOS below. The libreboot project recommends that the user replace the default *ChromeOS* with a -distribution that can be used in freedom, without invading the user\'s +distribution that can be used in freedom, without invading the user's privacy. We also use a similar argument for the MacBook and the ThinkPads that @@ -70,8 +70,8 @@ Considerations about ChromeOS and free operating systems {#os} ======================================================== This laptop comes preinstalled (from the factory) with Google ChromeOS. -This is a GNU+Linux distribution, but it\'s not general purpose and it -comes with proprietary software. It\'s designed for SaaSS. Libreboot +This is a GNU+Linux distribution, but it's not general purpose and it +comes with proprietary software. It's designed for SaaSS. Libreboot recommends that users of this laptop replace it with another distribution. @@ -101,7 +101,7 @@ tasks can still be performed without video acceleration, without any noticeable performance penalty. In practise, this means that certain things like games, blender and -GNOME shell (or other fancy desktops) won\'t work well. The libreboot +GNOME shell (or other fancy desktops) won't work well. The libreboot project recommends a lightweight desktop which does not need video acceleration, such as *XFCE* or *LXDE*. @@ -143,7 +143,7 @@ too. EC firmware is free software! {#ec} ============================= -It\'s free software. Google provides the source. Build scripts will be +It's free software. Google provides the source. Build scripts will be added later, with EC sources provided in libreboot, and builds of the EC firmware. @@ -163,7 +163,7 @@ No microcode! {#microcode} Unlike x86 (e.g. Intel/AMD) CPUs, ARM CPUs do not use microcode, not even built in. On the Intel/AMD based libreboot systems, there is still microcode in the CPU (not considered problematic by the FSF, provided -that it is reasonably trusted to not be malicious, since it\'s part of +that it is reasonably trusted to not be malicious, since it's part of the hardware and read-only), but we exclude microcode updates (volatile updates which are uploaded at boot time by the boot firmware, if present), which are proprietary software. @@ -187,8 +187,8 @@ software, maintained by Google. Flash chip write protection: the screw {#thescrew} ====================================== -It\'s next to the flash chip. Unscrew it, and the flash chip is -read-write. Screw it back in, and the flash chip is read-only. It\'s +It's next to the flash chip. Unscrew it, and the flash chip is +read-write. Screw it back in, and the flash chip is read-only. It's called the screw. *The screw* is accessible by removing other screws and gently prying off @@ -203,7 +203,7 @@ of how to set up an SPI programmer. Write protection is useful, because it prevents the firmware from being re-flashed by any malicious software that might become executed on your GNU+Linux system, as root. In other words, it can prevent a -firmware-level *evil maid* attack. It\'s possible to write protect on +firmware-level *evil maid* attack. It's possible to write protect on all current libreboot systems, but CrOS devices make it easy. The screw is such a stupidly simple idea, which all designs should implement. diff --git a/docs/hcl/gm45_remove_me.md b/docs/hcl/gm45_remove_me.md index 0fd8c024..3a57af31 100644 --- a/docs/hcl/gm45_remove_me.md +++ b/docs/hcl/gm45_remove_me.md @@ -48,7 +48,7 @@ Run:\ \$ **./ich9gen** Running ich9gen this way (without any arguments) generates a default -descriptor+gbe image with a generic MAC address. You probably don\'t +descriptor+gbe image with a generic MAC address. You probably don't want to use the generic one; the ROM images in libreboot contain a descriptor+gbe image by default (already inserted) just to prevent or mitigate the risk of bricking your laptop, but with the generic MAC @@ -61,10 +61,10 @@ correct MAC address in your ROM), dump it (flashrom -r) and read the first 6 bytes from position 0x1000 (or 0x2000) in a hex editor (or, rename it to factory.rom and run it in ich9deblob: in the newly created mkgbe.c will be the individual bytes of your MAC address). If you are -currently running the stock firmware and haven\'t installed libreboot +currently running the stock firmware and haven't installed libreboot yet, you can also run that through ich9deblob to get the mac address. -An even simpler way to get the MAC address would be to read what\'s on +An even simpler way to get the MAC address would be to read what's on the little sticker on the bottom/base of the laptop. On GM45 laptops that use flash descriptors, the MAC address or the @@ -140,7 +140,7 @@ protection or to flash yet another ROM image with write protection set in the descriptor). Flashrom will tell you that you can still forcefully re-flash, using *-p -internal:ich\_spi\_force=yes* but this won\'t actually work; it\'ll just +internal:ich\_spi\_force=yes* but this won't actually work; it'll just brick your laptop. For external flashing guides, refer to [../install/](../install/). @@ -246,7 +246,7 @@ TODO: test this.\ TODO: lenovobios (GM45 thinkpads) still write-protects parts of the flash. Modify the assembly code inside. Note: the factory.rom (BIOS region) from lenovobios is in a compressed format, which you have to -extract. bios\_extract upstream won\'t work, but the following was said +extract. bios\_extract upstream won't work, but the following was said in \#coreboot on freenode IRC: <roxfan> vimuser: try bios_extract with ffv patch http://patchwork.coreboot.org/patch/3444/ @@ -268,7 +268,7 @@ demefactory is part of the ich9deblob src, found at The sections below are adapted from (mostly) IRC logs related to early development getting the ME removed on GM45. They are useful for -background information. This could not have been done without sgsit\'s +background information. This could not have been done without sgsit's help. @@ -281,15 +281,15 @@ Early notes {#early_notes} - ~~**See reference to HDA\_SDO (disable descriptor security)**~~ strap connected GPIO33 pin is it on ICH9-M (X200). HDA\_SDO applies to later chipsets (series 6 or higher). Disabling descriptor - security also disables the ethernet according to sgsit. sgsit\'s - method involves use of \'soft straps\' (see IRC logs below) instead + security also disables the ethernet according to sgsit. sgsit's + method involves use of 'soft straps' (see IRC logs below) instead of disabling the descriptor. - **and the location of GPIO33 on the x200s: (was an external link. Putting it here instead)** [images/x200/gpio33\_location.jpg](images/x200/gpio33_location.jpg) - - it\'s above the number 7 on TP37 (which is above the big intel chip + it's above the number 7 on TP37 (which is above the big intel chip at the bottom) -- The ME datasheet may not be for the mobile chipsets but it doesn\'t +- The ME datasheet may not be for the mobile chipsets but it doesn't vary that much. This one gives some detail and covers QM67 which is what the X201 uses: <http://www.intel.co.uk/content/dam/www/public/us/en/documents/datasheets/6-chipset-c200-chipset-datasheet.pdf> @@ -386,7 +386,7 @@ Early development notes {#early_development_notes} -------------- Flash Erase Size = 0x1000 -It\'s a utility called \'Flash Image Tool\' for ME 4.x that was used for +It's a utility called 'Flash Image Tool' for ME 4.x that was used for this. You drag a complete image into in and the utility decomposes the various components, allowing you to set soft straps. @@ -419,7 +419,7 @@ The only actual content found was: DD CC 18 00 11 20 17 00 DD DD 18 00 12 20 17 00 00 80 1D 00 00 00 1F -The first part is the MAC address set to all 0x1F. It\'s repeated haly +The first part is the MAC address set to all 0x1F. It's repeated haly way through the 8K area, and the rest is all 0xFF. This is all documented in the datasheet. @@ -432,14 +432,14 @@ region. ### GBE region: change MAC address {#gbe_region_changemacaddress} -According to the datasheet, it\'s supposed to add up to 0xBABA but can +According to the datasheet, it's supposed to add up to 0xBABA but can actually be others on the X200. <https://communities.intel.com/community/wired/blog/2010/10/14/how-to-basic-eeprom-checksums> -*\"One of those engineers loves classic rock music, so they selected -0xBABA\"* +*"One of those engineers loves classic rock music, so they selected +0xBABA"* -In honour of the song *Baba O\'Reilly* by *The Who* apparently. We\'re +In honour of the song *Baba O'Reilly* by *The Who* apparently. We're not making this stuff up\... 0x3ABA, 0x34BA, 0x40BA and more have been observed in the main Gbe @@ -487,9 +487,9 @@ How to deblob: length to 0 - and you change the number of regions from 4 (zero based) to 2 -There\'s an interesting parameter called \'ME Alternate disable\', which +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 +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 libreboot, though. @@ -507,10 +507,10 @@ How to patch the descriptor from the factory.rom dump - extract the 8k GBe region and append that to the end of the 4k descriptor - output the 12k concatenated chunk -- Then it can be dd\'d into the first 12K part of a coreboot image. +- 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 libreboot\'s descriptor region will simply define the +This means that libreboot's descriptor region will simply define the following regions: - descriptor (4K) @@ -523,7 +523,7 @@ nearer to left than bit 12 in the binary representation). So, *x << 12 = address* -If it\'s in descriptor mode, then the first 4 bytes will be 5A A5 F0 0F. +If it's in descriptor mode, then the first 4 bytes will be 5A A5 F0 0F. @@ -531,10 +531,10 @@ platform data partition in boot flash (factory.rom / lenovo bios) {#platform_dat ----------------------------------------------------------------- Basically useless for libreboot, since it appears to be a blob. Removing -it didn\'t cause any issues in libreboot. +it didn't cause any issues in libreboot. This is a 32K region from the factory image. It could be data -(non-functional) that the original Lenovo BIOS used, but we don\'t know. +(non-functional) that the original Lenovo BIOS used, but we don't know. It has only a 448 byte fragment different from 0x00 or 0xFF. diff --git a/docs/hcl/index.md b/docs/hcl/index.md index f348f333..dcafec2a 100644 --- a/docs/hcl/index.md +++ b/docs/hcl/index.md @@ -54,10 +54,10 @@ Libreboot supports the following systems in this release: - [Apple MacBook1,1](#macbook11) - [Apple MacBook2,1](#macbook21) -\'Supported\' means that the build scripts know how to build ROM images +'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. +'officially' supported systems. It is also possible to build ROM images (from source) for other systems (and virtual systems, e.g. QEMU). @@ -71,7 +71,7 @@ EC update on i945 (X60, T60) and GM45 (X200, T400, T500, R400) {#ecupdate} It is recommended that you update to the latest EC firmware version. The [EC firmware](https://libreboot.org/faq/#firmware-ec) is separate from -libreboot, 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: @@ -93,13 +93,13 @@ How to find what EC version you have (i945/GM45) {#ecversion} ================================================ In GNU+Linux, you can try this:\ -**grep \'at EC\' /proc/asound/cards** +**grep 'at EC' /proc/asound/cards** Sample output:\ **ThinkPad Console Audio Control at EC reg 0x30, fw 7WHT19WW-3.6** 7WHT19WW is the version in different notation, use search engine to find -out regular version - in this case it\'s a 1.06 for x200 tablet +out regular version - in this case it's a 1.06 for x200 tablet [Back to top of page](#pagetop) @@ -116,7 +116,7 @@ The following are known to work well: - Any of the chipsets listed at <https://h-node.org/wifi/catalogue/en/1/1/undef/undef/yes?> -The following was mentioned (on IRC), but it\'s unknown to the libreboot +The following was mentioned (on IRC), but it's unknown to the libreboot project if these work with linux-libre kernel (TODO: test): - ar5bhb116 ar9382 ABGN @@ -130,9 +130,9 @@ project if these work with linux-libre kernel (TODO: test): List of supported ThinkPad X60s {#supported_x60_list} ------------------------------- -Native gpu initialization (\'native graphics\') which replaces the -proprietary VGA Option ROM (\'[Video -BIOS](https://en.wikipedia.org/wiki/Video_BIOS)\' or \'VBIOS\'), all +Native gpu initialization ('native graphics') which replaces the +proprietary VGA Option ROM ('[Video +BIOS](https://en.wikipedia.org/wiki/Video_BIOS)' or 'VBIOS'), all known LCD panels are currently compatible: To find what LCD panel you have, see: @@ -144,7 +144,7 @@ To find what LCD panel you have, see: - BOE-Hydis HT121X01-101: \# You can remove an X61/X61s motherboard from the chassis and install an -X60/X60s motherboard in it\'s place (for flashing libreboot). The +X60/X60s motherboard in it's place (for flashing libreboot). The chassis is mostly identical and the motherboards are the same shape/size. @@ -162,9 +162,9 @@ is very easily replaced; just remove the card and install another one List of supported ThinkPad X60 Tablets {#supported_x60t_list} -------------------------------------- -Native gpu initialization (\'native graphics\') which replaces the -proprietary VGA Option ROM (\'[Video -BIOS](https://en.wikipedia.org/wiki/Video_BIOS)\' or \'VBIOS\'). +Native gpu initialization ('native graphics') which replaces the +proprietary VGA Option ROM ('[Video +BIOS](https://en.wikipedia.org/wiki/Video_BIOS)' or 'VBIOS'). To find what LCD panel you have, see: [../misc/\#get\_edid\_panelname](../misc/#get_edid_panelname). @@ -180,7 +180,7 @@ There are 5 known LCD panels for the X60 Tablet: - BOE-Hydis HV121P01-101 (works) Most X60Ts only have digitizer (pen), but some have finger (touch) -aswell as pen; finger/multitouch doesn\'t work, only digitizer (pen) +aswell as pen; finger/multitouch doesn't work, only digitizer (pen) does. You can remove an X61/X61s motherboard from the chassis and install an @@ -250,9 +250,9 @@ could get finger input working. They used linuxwacom at git tag Supported T60 list {#supported_t60_list} ------------------ -Native gpu initialization (\'native graphics\') which replaces the -proprietary VGA Option ROM (\'[Video -BIOS](https://en.wikipedia.org/wiki/Video_BIOS)\' or \'VBIOS\'). +Native gpu initialization ('native graphics') which replaces the +proprietary VGA Option ROM ('[Video +BIOS](https://en.wikipedia.org/wiki/Video_BIOS)' or 'VBIOS'). To find what LCD panel you have, see: [../misc/\#get\_edid\_panelname](../misc/#get_edid_panelname). @@ -263,32 +263,32 @@ this.** Tested LCD panels: **working(compatible)** -- TMD-Toshiba LTD141EN9B (14.1\" 1400x1050) (FRU P/N 41W1478 +- TMD-Toshiba LTD141EN9B (14.1" 1400x1050) (FRU P/N 41W1478 recommended for the inverter board) -- Samsung LTN141P4-L02 (14.1\" 1400x1050) (FRU P/N 41W1478 recommended +- Samsung LTN141P4-L02 (14.1" 1400x1050) (FRU P/N 41W1478 recommended for the inverter board) -- LG-Philips LP150E05-A2K1 (15.1\" 1400x1050) (P/N 42T0078 FRU 42T0079 +- LG-Philips LP150E05-A2K1 (15.1" 1400x1050) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board) -- Samsung LTN150P4-L01 (15.1\" 1400x1050) (P/N 42T0078 FRU 42T0079 or +- Samsung LTN150P4-L01 (15.1" 1400x1050) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board) (not a T60 screen afaik, but it works) -- BOE-Hydis HV150UX1-100 (15.1\" 1600x1200) (P/N 42T0078 FRU 42T0079 +- BOE-Hydis HV150UX1-100 (15.1" 1600x1200) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board) Tested LCD panels: **not working yet (incompatible; see [../future/\#lcd\_i945\_incompatibility](../future/#lcd_i945_incompatibility))** -- Samsung LTN141XA-L01 (14.1\" 1024x768) -- LG-Philips LP150X09 (15.1\" 1024x768) -- Samsung LTN150XG (15.1\" 1024x768) -- LG-Philips LP150E06-A5K4 (15.1\" 1400x1050) (also, not an official +- Samsung LTN141XA-L01 (14.1" 1024x768) +- LG-Philips LP150X09 (15.1" 1024x768) +- Samsung LTN150XG (15.1" 1024x768) +- LG-Philips LP150E06-A5K4 (15.1" 1400x1050) (also, not an official T60 screen) -- Samsung LTN154X3-L0A (15.4\" 1280x800) -- IDtech IAQX10N (15.1\" 2048x1536) (no display in GRUB, display in +- Samsung LTN154X3-L0A (15.4" 1280x800) +- IDtech IAQX10N (15.1" 2048x1536) (no display in GRUB, display in GNU+Linux is temperamental) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board) -- IDtech N150U3-L01 (15.1\" 1600x1200) (no display in GRUB, display in +- IDtech N150U3-L01 (15.1" 1600x1200) (no display in GRUB, display in GNU+Linux works) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board) @@ -297,27 +297,27 @@ Tested LCD panels: **not working yet (incompatible; see *The following LCD panels are **UNTESTED**. If you have one of these panels then please submit a report!*: -- CMO(IDtech?) N141XC (14.1\" 1024x768) -- BOE-Hydis HT14X14 (14.1\" 1024x768) -- TMD-Toshiba LTD141ECMB (14.1\" 1024x768) -- Boe-Hydis HT14P12 (14.1\" 1400x1050) (FRU P/N 41W1478 recommended +- CMO(IDtech?) N141XC (14.1" 1024x768) +- BOE-Hydis HT14X14 (14.1" 1024x768) +- TMD-Toshiba LTD141ECMB (14.1" 1024x768) +- Boe-Hydis HT14P12 (14.1" 1400x1050) (FRU P/N 41W1478 recommended for the inverter board) -- CMO (IDtech?) 13N7068 (15.1\" 1024x768) -- CMO (IDtech?) 13N7069 (15.1\" 1024x768) -- BOE-Hydis HV150P01-100 (15.1\" 1400x1050) (P/N 42T0078 FRU 42T0079 +- CMO (IDtech?) 13N7068 (15.1" 1024x768) +- CMO (IDtech?) 13N7069 (15.1" 1024x768) +- BOE-Hydis HV150P01-100 (15.1" 1400x1050) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board) -- BOE-Hydis HV150UX1-102 (15.1\" 1600x1200) (P/N 42T0078 FRU 42T0079 +- BOE-Hydis HV150UX1-102 (15.1" 1600x1200) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board) -- IDtech IAQX10S (15.1\" 2048x1536) (P/N 42T0078 FRU 42T0079 or P/N +- IDtech IAQX10S (15.1" 2048x1536) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board) -- Samsung LTN154P2-L05 (42X4641 42T0329) (15.4\" 1680x1050) -- LG-Philips LP154W02-TL10 (13N7020 42T0423) (15.4\" 1680x1050) -- LG-Philips LP154WU1-TLB1 (42T0361) (15.4\" 1920x1200) **(for T61p +- Samsung LTN154P2-L05 (42X4641 42T0329) (15.4" 1680x1050) +- LG-Philips LP154W02-TL10 (13N7020 42T0423) (15.4" 1680x1050) +- LG-Philips LP154WU1-TLB1 (42T0361) (15.4" 1920x1200) **(for T61p but it might work in T60. Unknown!)** -- Samsung LTN154U2-L05 (42T0408 42T0574) (15.4\" 1920x1200) **(for +- Samsung LTN154U2-L05 (42T0408 42T0574) (15.4" 1920x1200) **(for T61p but it might work in T60. Unknown!)** -It is unknown whether the 1680x1050 (15.4\") and 1920x1200 (15.4\") +It is unknown whether the 1680x1050 (15.4") and 1920x1200 (15.4") panels use a different inverter board than the 1280x800 panels. The T60 typically comes with an Intel wifi chipset which does not work @@ -335,17 +335,17 @@ is very easily replaced; just remove the card and install another one ThinkPad T60 (ATI GPU) and ThinkPad T60 (Intel GPU) differences. {#t60_ati_intel} ---------------------------------------------------------------- -If your T60 is a 14.1\" or 15.1\" model with an ATI GPU, it won\'t work +If your T60 is a 14.1" or 15.1" model with an ATI GPU, it won't work with libreboot by default but you can replace the motherboard with another T60 motherboard that has an Intel GPU, and then libreboot should work. -As far as I know, 14.1\" (Intel GPU) and 15.1\" (Intel GPU) T60 -motherboards are the same, where \'spacers\' are used on the 15.1\" T60. +As far as I know, 14.1" (Intel GPU) and 15.1" (Intel GPU) T60 +motherboards are the same, where 'spacers' are used on the 15.1" T60. In any case, it makes sense to find one that is guaranteed to fit in your chassis. -There is also a 15.4\" T60 with Intel GPU. +There is also a 15.4" T60 with Intel GPU. Note: the T60**p** laptops all have ATI graphics. The T60p laptops cannot be used with libreboot under any circumstances. @@ -361,17 +361,17 @@ The reason that the ATI GPU on T60 is unsupported is due to the VBIOS has been reverse engineered, and replaced with Free Software and so will work in libreboot. -The \'Video BIOS\' is what initializes graphics. +The 'Video BIOS' is what initializes graphics. See: <https://en.wikipedia.org/wiki/Video_BIOS>.\ In fact, lack of free VBIOS in general is a big problem in coreboot, and is one reason (among others) why many ports for coreboot are unsuitable -for libreboot\'s purpose. +for libreboot's purpose. Theoretically, the ThinkPad T60 with ATI GPU can work with libreboot and have ROM images compiled for it, however in practise it would not be usable as a laptop because there would be no visual display at all. That -being said, such a configuration is acceptable for use in a \'headless\' +being said, such a configuration is acceptable for use in a 'headless' server setup (with serial and/or ssh console as the display). [Back to top of page.](#pagetop) @@ -410,7 +410,7 @@ Also of interest: [../git/\#config\_macbook21](../git/#config_macbook21). Unbricking: [this page shows disassembly -guides](https://www.ifixit.com/Device/MacBook_Core_2_Duo) and mono\'s +guides](https://www.ifixit.com/Device/MacBook_Core_2_Duo) and mono's page (see [\#macbook21](#macbook21)) shows the location of the SPI flash chip on the motherboard. [How to remove the motherboard](https://www.ifixit.com/Guide/MacBook+Core+2+Duo+PRAM+Battery+Replacement/529). @@ -445,7 +445,7 @@ http://macbook.donderklumpen.de/coreboot/**\ Use **-e robots=off** if using this trick for other sites and the site restricts using robots.txt -**Links to wget backups (and the backups themselves) of Mono\'s pages +**Links to wget backups (and the backups themselves) of Mono's pages (see above) removed temporarily. Mono has given me permission to distribute them, but I need to ask this person to tell me what license these works fall under first. Otherwise, the above URLs should be fine. @@ -455,14 +455,14 @@ NOTE TO SELF: REMOVE THIS WHEN DONE** ### Installing GNU+Linux distributions (on Apple EFI firmware) - [Parabola GNU+Linux installation on a macbook2,1 with Apple EFI - firmware](#) (this is a copy of Mono\'s page, see above) + firmware](#) (this is a copy of Mono's page, see above) How to boot an ISO: burn it to a CD (like you would normally) and hold down the Alt/Control key while booting. The bootloader will detect the -GNU+Linux CD as \'Windows\' (because Apple doesn\'t think GNU+Linux +GNU+Linux CD as 'Windows' (because Apple doesn't think GNU+Linux exists). Install it like you normally would. When you boot up again, hold Alt/Control once more. The installation (on the HDD) will once -again be seen as \'Windows\'. (it\'s not actually Windows, but Apple +again be seen as 'Windows'. (it's not actually Windows, but Apple likes to think that Apple and Microsoft are all that exist.) Now to install libreboot, follow [../install/\#flashrom\_macbook21](../install/#flashrom_macbook21). @@ -471,7 +471,7 @@ install libreboot, follow ### Information about coreboot -- [Coreboot on the macbook2,1](#) (this is a copy of Mono\'s page, see +- [Coreboot on the macbook2,1](#) (this is a copy of Mono's page, see above) @@ -506,7 +506,7 @@ Also of interest: [../git/\#config\_macbook21](../git/#config_macbook21). Unbricking: [this page shows disassembly -guides](https://www.ifixit.com/Device/MacBook_Core_2_Duo) and mono\'s +guides](https://www.ifixit.com/Device/MacBook_Core_2_Duo) and mono's page (see above) shows the location of the SPI flash chip on the motherboard. [How to remove the motherboard](https://www.ifixit.com/Guide/MacBook+Core+2+Duo+PRAM+Battery+Replacement/529). @@ -515,7 +515,7 @@ For external flashing, refer to [../install/bbb\_setup.html](../install/bbb_setup.html). You need to replace OS X with GNU+Linux before flashing libreboot. (OSX -won\'t run at all in libreboot). +won't run at all in libreboot). There are some issues with this system (compared to other computers that libreboot supports): @@ -584,7 +584,7 @@ A user reported that the above is only for linux kernel 3.15 or lower. For newer kernels, the touchpad works fine out of the box, except middle tapping. -A user submitted a utility to enable 3-finger tap on this laptop. It\'s +A user submitted a utility to enable 3-finger tap on this laptop. It's available at *resources/utilities/macbook21-three-finger-tap* in the libreboot git repository. diff --git a/docs/hcl/kcma-d8.md b/docs/hcl/kcma-d8.md index 845652d5..ae681e89 100644 --- a/docs/hcl/kcma-d8.md +++ b/docs/hcl/kcma-d8.md @@ -49,11 +49,11 @@ identical, but the position of the screws are different. IPMI iKVM module add-on {#ipmi} ======================= -Don\'t use it. It uses proprietary firmware and adds a backdoor (remote +Don't use it. It uses proprietary firmware and adds a backdoor (remote out-of-band management chip, similar to the [Intel Management Engine](http://libreboot.org/faq/#intelme). Fortunately, the firmware is unsigned (possibly to replace) and physically separate from the -mainboard since it\'s on the add-on module, which you don\'t have to +mainboard since it's on the add-on module, which you don't have to install. @@ -61,7 +61,7 @@ install. Flash chips {#flashchips} =========== -2MiB flash chips are included by default, on these boards. It\'s on a +2MiB flash chips are included by default, on these boards. It's on a P-DIP 8 slot (SPI chip). The flash chip can be upgraded to higher sizes: 4MiB, 8MiB or 16MiB. With at least 8MiB, you could feasibly fit a compressed linux+initramfs image (BusyBox+Linux system) into CBFS and @@ -94,15 +94,15 @@ Current issues {#issues} can be on a SAS drive. The linux kernel can use those SAS drives (via PIKE module) without an option ROM). - IPMI iKVM module (optional add-on card) uses proprietary firmware. - Since it\'s for remote out-of-band management, it\'s theoretically a + 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 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 - practise, out-of-band management isn\'t very useful anyway (or at - the very least, it\'s not a major inconvenience to not have it). + practise, out-of-band management isn't very useful anyway (or at + the very least, it's not a major inconvenience to not have it). - Graphics: only text-mode works. See [\#graphics](#graphics) diff --git a/docs/hcl/kfsn4-dre.md b/docs/hcl/kfsn4-dre.md index 18fb57d6..bd0b5ae8 100644 --- a/docs/hcl/kfsn4-dre.md +++ b/docs/hcl/kfsn4-dre.md @@ -67,11 +67,11 @@ Current issues {#issues} - There seems to be a 30 second bootblock delay (observed by tpearson); the system otherwise boots and works as expected. See [text/kfsn4-dre/bootlog.txt](text/kfsn4-dre/bootlog.txt) - this uses - the \'simple\' bootblock, while tpearson uses the \'normal\' + the 'simple' bootblock, while tpearson uses the 'normal' bootblock, which tpearson suspects may be a possible cause. This person says that they will look into it. [This config](http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=asus/kfsn4-dre/4.0-10101-g039edeb/2015-06-27T03:59:16Z/config.txt;h=4742905c185a93fbda8eb14322dd82c70641aef0;hb=055f5df4e000a97453dfad6c91c2d06ea22b8545) - doesn\'t have the issue. + doesn't have the issue. - Text-mode is a bit jittery (but still usable). (the jitter disappears if using KMS, once the kernel starts. The jitter will remain, if booting the kernel in text-mode). diff --git a/docs/hcl/kgpe-d16.md b/docs/hcl/kgpe-d16.md index 9cad59c6..0d00bf6d 100644 --- a/docs/hcl/kgpe-d16.md +++ b/docs/hcl/kgpe-d16.md @@ -50,11 +50,11 @@ identical, but the position of the screws are different. IPMI iKVM module add-on {#ipmi} ======================= -Don\'t use it. It uses proprietary firmware and adds a backdoor (remote +Don't use it. It uses proprietary firmware and adds a backdoor (remote out-of-band management chip, similar to the [Intel Management Engine](http://libreboot.org/faq/#intelme). Fortunately, the firmware is unsigned (possibly to replace) and physically separate from the -mainboard since it\'s on the add-on module, which you don\'t have to +mainboard since it's on the add-on module, which you don't have to install. @@ -62,7 +62,7 @@ install. Flash chips {#flashchips} =========== -2MiB flash chips are included by default, on these boards. It\'s on a +2MiB flash chips are included by default, on these boards. It's on a P-DIP 8 slot (SPI chip). The flash chip can be upgraded to higher sizes: 4MiB, 8MiB or 16MiB. With at least 8MiB, you could feasibly fit a compressed linux+initramfs image (BusyBox+Linux system) into CBFS and @@ -95,15 +95,15 @@ Current issues {#issues} can be on a SAS drive. The linux kernel can use those SAS drives (via PIKE module) without an option ROM). - IPMI iKVM module (optional add-on card) uses proprietary firmware. - Since it\'s for remote out-of-band management, it\'s theoretically a + 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 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 - practise, out-of-band management isn\'t very useful anyway (or at - the very least, it\'s not a major inconvenience to not have it). + practise, out-of-band management isn't very useful anyway (or at + the very least, it's not a major inconvenience to not have it). - Graphics: only text-mode works. See [\#graphics](#graphics) @@ -166,7 +166,7 @@ The information here is adapted, from the ASUS website. ### Form factor {#form-factor} -- SSI EEB 3.61 (12\"x13\") +- SSI EEB 3.61 (12"x13") ### ASUS features diff --git a/docs/hcl/r400.md b/docs/hcl/r400.md index 784dfe0c..c7760cd6 100644 --- a/docs/hcl/r400.md +++ b/docs/hcl/r400.md @@ -28,7 +28,7 @@ EC update {#ecupdate} It is recommended that you update to the latest EC firmware version. The [EC firmware](https://libreboot.org/faq/#firmware-ec) is separate from -libreboot, 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: @@ -54,7 +54,7 @@ The R400, when run without CPU microcode updates in coreboot, currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest. With a single core enabled for the guest, the guest panics (but the host is fine). Working around this in QEMU might be possible; if -not, software virtualization should work fine (it\'s just slower). +not, software virtualization should work fine (it's just slower). On GM45 hardware (with libreboot), make sure that the *kvm* and *kvm\_intel* kernel modules are not loaded, when using QEMU. diff --git a/docs/hcl/t400.md b/docs/hcl/t400.md index 4f0f3f5b..ce60cc76 100644 --- a/docs/hcl/t400.md +++ b/docs/hcl/t400.md @@ -28,7 +28,7 @@ EC update {#ecupdate} It is recommended that you update to the latest EC firmware version. The [EC firmware](https://libreboot.org/faq/#firmware-ec) is separate from -libreboot, 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: @@ -54,7 +54,7 @@ The T400, when run without CPU microcode updates in coreboot, currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest. With a single core enabled for the guest, the guest panics (but the host is fine). Working around this in QEMU might be possible; if -not, software virtualization should work fine (it\'s just slower). +not, software virtualization should work fine (it's just slower). On GM45 hardware (with libreboot), make sure that the *kvm* and *kvm\_intel* kernel modules are not loaded, when using QEMU. diff --git a/docs/hcl/t500.md b/docs/hcl/t500.md index a978c66f..54764879 100644 --- a/docs/hcl/t500.md +++ b/docs/hcl/t500.md @@ -28,7 +28,7 @@ EC update {#ecupdate} It is recommended that you update to the latest EC firmware version. The [EC firmware](https://libreboot.org/faq/#firmware-ec) is separate from -libreboot, 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: @@ -54,7 +54,7 @@ The T500, when run without CPU microcode updates in coreboot, currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest. With a single core enabled for the guest, the guest panics (but the host is fine). Working around this in QEMU might be possible; if -not, software virtualization should work fine (it\'s just slower). +not, software virtualization should work fine (it's just slower). On GM45 hardware (with libreboot), make sure that the *kvm* and *kvm\_intel* kernel modules are not loaded, when using QEMU. @@ -86,7 +86,7 @@ were something like:\ \$ **diff -u t500descriptor x200descriptor** ME VSCC table is in a different place and a different size on the T500. -Libreboot disables and removes the ME anyway, so it doesn\'t matter. +Libreboot disables and removes the ME anyway, so it doesn't matter. The very same descriptor/gbe used on the X200 (generated by [ich9gen](gm45_remove_me.html#ich9gen)) was re-used on the T500, and it diff --git a/docs/hcl/x200.md b/docs/hcl/x200.md index e27088a6..01bfd23e 100644 --- a/docs/hcl/x200.md +++ b/docs/hcl/x200.md @@ -7,7 +7,7 @@ Tablet will also work, [depending on the configuration](#x200s). It \*might\* be possible to put an X200 motherboard in an X201 chassis, though this is currently untested by the libreboot project. The same may -also apply between X200S and X201S; again, this is untested. **It\'s +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 @@ -31,7 +31,7 @@ EC update {#ecupdate} It is recommended that you update to the latest EC firmware version. The [EC firmware](https://libreboot.org/faq/#firmware-ec) is separate from -libreboot, 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: @@ -57,7 +57,7 @@ The X200, when run without CPU microcode updates in coreboot, currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest. With a single core enabled for the guest, the guest panics (but the host is fine). Working around this in QEMU might be possible; if -not, software virtualization should work fine (it\'s just slower). +not, software virtualization should work fine (it's just slower). On GM45 hardware (with libreboot), make sure that the *kvm* and *kvm\_intel* kernel modules are not loaded, when using QEMU. @@ -108,11 +108,11 @@ this case are 2x4GB. ~~**However, not all configurations work: [text/x200s/cblog03.txt](text/x200s/cblog03.txt) (1x2GB) show a failed bootup.**~~ *False alarm. The modules were mixed (non-matching). X200S with high-performance mode CPU will work so long as you use matching -memory modules (doesn\'t matter what size).* +memory modules (doesn't matter what size).* This was then pushed as a patch for coreboot, which can be found at <http://review.coreboot.org/#/c/7786/> (libreboot merges this patch in -coreboot-libre now. Check the \'getcb\' script in src or git). +coreboot-libre now. Check the 'getcb' script in src or git). ### Proper GS45 raminit {#x200s_raminit} @@ -136,7 +136,7 @@ based on that. -Trouble undocking (button doesn\'t work) +Trouble undocking (button doesn't work) ---------------------------------------- This person seems to have a workaround: @@ -220,9 +220,9 @@ CCFL inverter is high-voltage and will destroy an LED backlit panel). CCFLs contain mercury. An X200 with a CCFL backlight will (****unless it has been changed to an LED, with the correct inverter. Check with your -supplier!) the following: *\"This product contains Lithium Ion Battery, +supplier!) the following: *"This product contains Lithium Ion Battery, Lithium Battery and a lamp which contains mercury; dispose according to -local, state or federal laws\"* (one with an LED backlit panel will say +local, state or federal laws"* (one with an LED backlit panel will say something different). [Back to top of page.](#pagetop) @@ -246,7 +246,7 @@ RAM, S3 and microcode updates {#ram_s3_microcode} ============================= Not all memory modules work. Most of the default ones do, but you have -to be careful when upgrading to 8GiB; some modules work, some don\'t. +to be careful when upgrading to 8GiB; some modules work, some don't. Someone on reddit also did their own research on RAM compatibility: [on this @@ -258,17 +258,17 @@ different, so this page might be BS) pehjota started collecting some steppings for different CPUs on several X200 laptops. You can get the CPUID by running:\ -\$ **dmesg | sed -n \'s/\^.\* microcode: CPU0 -sig=0x\\(\[\^,\]\*\\),.\*\$/\\1/p\'** +\$ **dmesg | sed -n 's/\^.\* microcode: CPU0 +sig=0x\\(\[\^,\]\*\\),.\*\$/\\1/p'** What pehjota wrote: The laptops that have issues resuming from suspend, -as well as a laptop that (as I mentioned earlier in \#libreboot) won\'t +as well as a laptop that (as I mentioned earlier in \#libreboot) won't boot with any Samsung DIMMs, all have CPUID 0x10676 (stepping M0). What pehjota wrote: Laptops with CPUID 0x167A (stepping R0) resume -properly every time and work with Samsung DIMMs. I\'ll need to do more +properly every time and work with Samsung DIMMs. I'll need to do more testing on more units to better confirm these trends, but it looks like -the M0 microcode is very buggy. That would also explain why I didn\'t +the M0 microcode is very buggy. That would also explain why I didn't have issues with Samsung DIMMs with the Lenovo BIOS (which would have microcode updates). I wonder if VT-x works on R0. @@ -278,9 +278,9 @@ factory microcode. (1067 is the family and model, and 6 or A is the stepping ID.) **TODO: check the CPUIDs and test S3 resume and/or KVM on any C2D -systems (including non-P8xxx ones, which I don\'t have here) you have -available. I\'d be curious if you could confirm these results.** It -might not be coreboot that\'s buggy with raminit/S3; it might just be +systems (including non-P8xxx ones, which I don't have here) you have +available. I'd be curious if you could confirm these results.** It +might not be coreboot that's buggy with raminit/S3; it might just be down to the microcode updates. @@ -297,7 +297,7 @@ Unsorted notes {#unsorted} Copyright © 2014, 2015 Leah Rowe <info@minifree.org>\ -Copyright © 2015 Patrick \"P. J.\" McDermott <pj@pehjota.net>\ +Copyright © 2015 Patrick "P. J." McDermott <pj@pehjota.net>\ Permission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 4.0 International license or any later version published by Creative |