diff options
| author | Alyssa Rosenzweig <alyssa@rosenzweig.io> | 2017-03-17 22:24:25 -0700 |
|---|---|---|
| committer | Alyssa Rosenzweig <alyssa@rosenzweig.io> | 2017-03-17 22:24:25 -0700 |
| commit | dbc480fb28a694ad5a587be025eabfded7c7784b (patch) | |
| tree | 16b4251dcbdede274781f7bb8b1f23570853f3bb /docs/hcl/gm45_remove_me.html | |
| parent | 85ec6862e8af0747420ca15fef7100edb5885302 (diff) | |
| download | librebootfr-dbc480fb28a694ad5a587be025eabfded7c7784b.tar.gz librebootfr-dbc480fb28a694ad5a587be025eabfded7c7784b.zip | |
Convert documentation to markdown
Diffstat (limited to 'docs/hcl/gm45_remove_me.html')
| -rw-r--r-- | docs/hcl/gm45_remove_me.html | 693 |
1 files changed, 0 insertions, 693 deletions
diff --git a/docs/hcl/gm45_remove_me.html b/docs/hcl/gm45_remove_me.html deleted file mode 100644 index 8e66ef7d..00000000 --- a/docs/hcl/gm45_remove_me.html +++ /dev/null @@ -1,693 +0,0 @@ -<!DOCTYPE html> -<html> -<head> - <meta charset="utf-8"> - <meta name="viewport" content="width=device-width, initial-scale=1"> - - <style type="text/css"> - @import url('../css/main.css'); - </style> - - <title>GM45 chipsets: remove the ME (manageability engine)</title> -</head> - -<body> - - <div class="section"> - - <h1 id="pagetop">GM45 chipsets: remove the ME (manageability engine)</h1> - <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 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 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 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 - this can be found in the ich9deblob/ich9gen source code in resources/utilities/ich9deblob/ - in libreboot, or more generally on this page. - </p> - <p> - More information about the ME can be found at - <a href="http://www.coreboot.org/Intel_Management_Engine">http://www.coreboot.org/Intel_Management_Engine</a> - and <a href="http://me.bios.io/Main_Page">http://me.bios.io/Main_Page</a>. - </p> - <p> - Another project recently found: - <a href="http://io.smashthestack.org/me/">http://io.smashthestack.org/me/</a> - </p> - <p> - <a href="./">Back to previous index</a>. - </p> - - </div> - - <div class="section"> - - <h1 id="ich9gen">ICH9 gen utility</h1> - - <p> - It is no longer necessary to use <a href="#ich9deblob">ich9deblob</a> to generate - a deblobbed descriptor+gbe image for GM45 targets. ich9gen is a small utility within - ich9deblob that can generate them from scratch, without a factory.bin dump. - </p> - - <p> - ich9gen executables can be found under ./ich9deblob/ statically compiled in - libreboot_util. If you are using src or git, build ich9gen from source with:<br/> - $ <b>./oldbuild module ich9deblob</b><br/> - The executable will appear under resources/utilities/ich9deblob/ - </p> - - <p> - Run:<br/> - $ <b>./ich9gen</b> - </p> - - <p> - Running ich9gen this way (without any arguments) generates - a default 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 address (the libreboot - project does not know what your real MAC address is). - </p> - - <p> - You can find out your MAC address from <b>ip addr</b> or <b>ifconfig</b> in GNU+Linux. - Alternatively, if you are running libreboot already (with the 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 yet, you can also run that through ich9deblob to get the mac address. - </p> - - <p> - 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. - </p> - - <p> - On GM45 laptops that use flash descriptors, the MAC address - or the onboard ethernet chipset is flashed (inside the ROM image). - You should generate a descriptor+gbe image with your own MAC address - inside (with the Gbe checksum updated to match). Run:<br/> - $ <b>./ich9gen --macaddress XX:XX:XX:XX:XX:XX</b><br/> - (replace the XX chars with the hexadecimal chars in the MAC address that you want) - </p> - - <p> - Two new files will be created: - </p> - <ul> - <li><b>ich9fdgbe_4m.bin</b>: this is for GM45 laptops with the 4MB flash chip.</li> - <li><b>ich9fdgbe_8m.bin</b>: this is for GM45 laptops with the 8MB flash chip.</li> - <li><b>ich9fdgbe_16m.bin</b>: this is for GM45 laptops with the 16MB flash chip.</li> - </ul> - - <p> - Assuming that your libreboot image is named <b>libreboot.rom</b>, copy - the file to where <b>libreboot.rom</b> is located - and then insert the descriptor+gbe file into the ROM image.<br/> - For 16MiB flash chips:<br/> - $ <b>dd if=ich9fdgbe_16m.bin of=libreboot.rom bs=1 count=12k conv=notrunc</b><br/> - For 8MiB flash chips:<br/> - $ <b>dd if=ich9fdgbe_8m.bin of=libreboot.rom bs=1 count=12k conv=notrunc</b><br/> - For 4MiB flash chips:<br/> - $ <b>dd if=ich9fdgbe_4m.bin of=libreboot.rom bs=1 count=12k conv=notrunc</b><br/> - </p> - - <p> - Your libreboot.rom image is now ready to be flashed on the system. Refer back to - <a href="../install/#flashrom">../install/#flashrom</a> - for how to flash it. - </p> - - <h2> - Write-protecting the flash chip - </h2> - <p> - Look in <i>resources/utilities/ich9deblob/src/descriptor/descriptor.c</i> - for the following lines in the <i>descriptorHostRegionsUnlocked</i> function: - </p> -<pre> - descriptorStruct.masterAccessSection.flMstr1.fdRegionWriteAccess = 0x1; - descriptorStruct.masterAccessSection.flMstr1.biosRegionWriteAccess = 0x1; - descriptorStruct.masterAccessSection.flMstr1.meRegionWriteAccess = 0x1; - descriptorStruct.masterAccessSection.flMstr1.gbeRegionWriteAccess = 0x1; - descriptorStruct.masterAccessSection.flMstr1.pdRegionWriteAccess = 0x1; -</pre> - <p> - Also look in <i>resources/utilities/ich9deblob/src/ich9gen/mkdescriptor.c</i> - for the following lines: - </p> -<pre> - descriptorStruct.masterAccessSection.flMstr1.fdRegionWriteAccess = 0x1; /* see ../descriptor/descriptor.c */ - descriptorStruct.masterAccessSection.flMstr1.biosRegionWriteAccess = 0x1; /* see ../descriptor/descriptor.c */ - descriptorStruct.masterAccessSection.flMstr1.meRegionWriteAccess = 0x1; /* see ../descriptor/descriptor.c */ - descriptorStruct.masterAccessSection.flMstr1.gbeRegionWriteAccess = 0x1; /* see ../descriptor/descriptor.c */ - descriptorStruct.masterAccessSection.flMstr1.pdRegionWriteAccess = 0x1; /* see ../descriptor/descriptor.c */ -</pre> - - <p style="font-size:2em;"> - NOTE: When you write-protect the flash chip, re-flashing is no longer possible unless you - use dedicated external equipment, which also means disassembling the laptop. The same equipment - can also be used to remove the write-protection later on, if you choose to do so. *Only* write-protect - the chip if you have the right equipment for external flashing later on; for example, see - <a href="../install/bbb_setup.html">../install/bbb_setup.html</a>. - </p> - - <p> - Change them all to 0x0, then re-compile ich9gen. After you have done that, - follow the notes in <a href="#ich9gen">#ich9gen</a> to generate a new - descriptor+gbe image and insert that into your ROM image, then flash it. - The next time you boot, the flash chip will be read-only in software - (hardware re-flashing will still work, which you will need for re-flashing - the chip after write-protecting it, to clear the write protection or - to flash yet another ROM image with write protection set in the descriptor). - </p> - <p> - Flashrom will tell you that you can still forcefully re-flash, using <i>-p internal:ich_spi_force=yes</i> but - this won't actually work; it'll just brick your laptop. - </p> - <p> - For external flashing guides, refer to <a href="../install/">../install/</a>. - </p> - - </div> - - <div class="section"> - - <h1 id="ich9deblob">ICH9 deblob utility</h1> - - <p> - <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 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> - - <p> - This is what you will use to generate the deblobbed descriptor+gbe regions for your libreboot ROM image. - </p> - <p> - If you are working with libreboot_src (or git), you can find the source under resources/utilities/ich9deblob/ - and will already be compiled if you ran <b>./oldbuild module all</b> or <b>./oldbuild module ich9deblob</b> from the main directory (./), - otherwise you can build it like so:<br/> - $ <b>./oldbuild module ich9deblob</b><br/> - An executable file named <b>ich9deblob</b> will now appear under resources/utilities/ich9deblob/ - </p> - <p> - If you are working with libreboot_util release archive, you can find the utility included, statically compiled - (for i686 and x86_64 on GNU+Linux) under ./ich9deblob/. - </p> - - <p> - Place the factory.rom from your system - (can be obtained using the external flashing guides for GM45 targets linked <a href="../install/">../install/</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 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> - <p> - A 4KiB file named <b>deblobbed_4kdescriptor.bin</b> will alternatively appear, if no GbE region was detected inside the ROM image. - This is usually the case, when a discrete NIC is used (eg Broadcom) instead of Intel. Only the Intel NICs need a GbE region in - the flash chip. - </p> - - <p> - Assuming that your libreboot image is named <b>libreboot.rom</b>, copy - the <b>deblobbed_descriptor.bin</b> file to where <b>libreboot.rom</b> is located - and then run:<br/> - $ <b>dd if=deblobbed_descriptor.bin of=libreboot.rom bs=1 count=12k conv=notrunc</b> - </p> - <p> - Alternatively, if you got a the <b>deblobbed_4kdescriptor.bin</b> file (no GbE defined), - do this: - $ <b>dd if=deblobbed_4kdescriptor.bin of=libreboot.rom bs=1 count=4k conv=notrunc</b> - </p> - <p> - - </p> - - <p> - The utility will also generate 4 additional files: - </p> - <ul> - <li>mkdescriptor.c</li> - <li>mkdescriptor.h</li> - <li>mkgbe.c</li> - <li>mkgbe.h</li> - </ul> - <p> - These are C source files that can re-generate the very same Gbe and Descriptor structs - (from ich9deblob/ich9gen). To use these, place them in src/ich9gen/ in ich9deblob, then re-build. - The newly built <b>ich9gen</b> executable will be able to re-create the very same 12KiB file from scratch, - based on the C structs, this time <b>without</b> the need for a factory.rom dump! - </p> - - <p> - You should now have a <b>libreboot.rom</b> image containing the correct 4K descriptor and 8K gbe regions, which - will then be safe to flash. Refer back to <a href="../install/#flashrom">../install/#flashrom</a> - for how to flash it. - </p> - - </div> - - <div class="section"> - - <h1 id="demefactory">demefactory utility</h1> - - <p> - This takes a factory.rom dump and disables the ME/TPM, but leaves the region intact. - It also sets all regions read-write. - </p> - - <p> - The ME interferes with flash read/write in flashrom, and the default descriptor - locks some regions. The idea is that doing this will remove all of those restrictions. - </p> - - <p> - Simply run (with factory.rom in the same directory):<br/> - $ <b>./demefactory</b> - </p> - - <p> - It will generate a 4KiB descriptor file (only the descriptor, no GbE). Insert that into - a factory.rom image (NOTE: do this on a copy of it. Keep the original factory.rom stored - safely somewhere):<br/> - $ <b>dd if=demefactory_4kdescriptor.bin of=factory_nome.rom bs=1 count=4k conv=notrunc</b> - </p> - - <p> - TODO: test this.<br/> - 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 in #coreboot on freenode IRC: - </p> -<pre> -<roxfan> vimuser: try bios_extract with ffv patch <a href="http://patchwork.coreboot.org/patch/3444/">http://patchwork.coreboot.org/patch/3444/</a> -<roxfan> or <a href="https://github.com/coreboot/bios_extract/blob/master/phoenix_extract.py">https://github.com/coreboot/bios_extract/blob/master/phoenix_extract.py</a> -<roxfan> what are you looking for specifically, btw? - -0x74: 0x9fff03e0 PR0: Warning: 0x003e0000-0x01ffffff is read-only. -0x84: 0x81ff81f8 PR4: Warning: 0x001f8000-0x001fffff is locked. -</pre> - - <p> - Use-case: a factory.rom image modified in this way would theoretically have no - flash protections whatsoever, making it easy to quickly switch between factory/libreboot - in software, without ever having to disassemble and re-flash externally unless you brick - the device. - </p> - - <p> - demefactory is part of the ich9deblob src, found at <i>resources/utilities/ich9deblob/</i> - </p> - - </div> - - <div class="section"> - - <p> - 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 help. - </p> - - <div class="subsection"> - - <h2 id="early_notes">Early notes</h2> - - <ul> - <li> - <a href="http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-10-family-datasheet.pdf">http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-10-family-datasheet.pdf</a> - page 230 mentions about descriptor and non-descriptor mode (which wipes out gbe and ME/AMT). - </li> - <li> - <s><b>See reference to HDA_SDO (disable descriptor security)</b></s> - 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 of disabling the descriptor. - </li> - <li> - <b>and the location of GPIO33 on the x200s: (was an external link. Putting it here instead)</b> - <a href="images/x200/gpio33_location.jpg">images/x200/gpio33_location.jpg</a> - - it's above the number 7 on TP37 (which is above the big intel chip at the bottom) - </li> - <li> - 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: - <a href="http://www.intel.co.uk/content/dam/www/public/us/en/documents/datasheets/6-chipset-c200-chipset-datasheet.pdf">http://www.intel.co.uk/content/dam/www/public/us/en/documents/datasheets/6-chipset-c200-chipset-datasheet.pdf</a> - </li> - </ul> - - </div> - - </div> - - <div class="section"> - - <div class="subsection"> - - <h2 id="flashchips">Flash chips</h2> - - <ul> - <li> - Schematics for X200 laptop: <a href="http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006075.pdf">http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006075.pdf</a> - <b><s>- Page 20 and page 9 refer to SDA_HDO or SDA_HDOUT</s></b> only on series 6 or higher chipsets. ICH9-M (X200) does it with a strap connected to GPIO33 pin (see IRC notes below)<br/> - - According to page 29, the X200 can have any of the following flash chips: - <ul> - <li>ATMEL AT26DF321-SU 72.26321.A01 - this is a 32Mb (4MiB) chip</li> - <li>MXIC (Macronix?) MX25L3205DM2I-12G 72.25325.A01 - another 32Mb (4MiB) chip</li> - <li>MXIC (Macronix?) MX25L6405DMI-12G 41R0820AA - this is a 64Mb (8MiB) chip</li> - <li>Winbond W25X64VSFIG 41R0820BA - another 64Mb (8MiB) chip</li> - </ul> - sgsit says that the X200s with the 64Mb flash chips are (probably) the ones with AMT (alongside the ME), whereas - the 32Mb chips contain only the ME. - </li> - <li> - Schematics for X200s laptop: <a href="http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006104.pdf">http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006104.pdf</a>. - </li> - </ul> - - </div> - - </div> - - <div class="section"> - - <h2 id="early_development_notes">Early development notes</h2> - -<pre> -<i> -Start (hex) End (hex) Length (hex) Area Name ------------ --------- ------------ --------- -00000000 003FFFFF 00400000 Flash Image - -00000000 00000FFF 00001000 Descriptor Region -00000004 0000000F 0000000C Descriptor Map -00000010 0000001B 0000000C Component Section -00000040 0000004F 00000010 Region Section -00000060 0000006B 0000000C Master Access Section -00000060 00000063 00000004 CPU/BIOS -00000064 00000067 00000004 Manageability Engine (ME) -00000068 0000006B 00000004 GbE LAN -00000100 00000103 00000004 ICH Strap 0 -00000104 00000107 00000004 ICH Strap 1 -00000200 00000203 00000004 MCH Strap 0 -00000EFC 00000EFF 00000004 Descriptor Map 2 -00000ED0 00000EF7 00000028 ME VSCC Table -00000ED0 00000ED7 00000008 Flash device 1 -00000ED8 00000EDF 00000008 Flash device 2 -00000EE0 00000EE7 00000008 Flash device 3 -00000EE8 00000EEF 00000008 Flash device 4 -00000EF0 00000EF7 00000008 Flash device 5 -00000F00 00000FFF 00000100 OEM Section -00001000 001F5FFF 001F5000 ME Region -001F6000 001F7FFF 00002000 GbE Region -001F8000 001FFFFF 00008000 PDR Region -00200000 003FFFFF 00200000 BIOS Region - -Start (hex) End (hex) Length (hex) Area Name ------------ --------- ------------ --------- -00000000 003FFFFF 00400000 Flash Image - -00000000 00000FFF 00001000 Descriptor Region -00000004 0000000F 0000000C Descriptor Map -00000010 0000001B 0000000C Component Section -00000040 0000004F 00000010 Region Section -00000060 0000006B 0000000C Master Access Section -00000060 00000063 00000004 CPU/BIOS -00000064 00000067 00000004 Manageability Engine (ME) -00000068 0000006B 00000004 GbE LAN -00000100 00000103 00000004 ICH Strap 0 -00000104 00000107 00000004 ICH Strap 1 -00000200 00000203 00000004 MCH Strap 0 -00000ED0 00000EF7 00000028 ME VSCC Table -00000ED0 00000ED7 00000008 Flash device 1 -00000ED8 00000EDF 00000008 Flash device 2 -00000EE0 00000EE7 00000008 Flash device 3 -00000EE8 00000EEF 00000008 Flash device 4 -00000EF0 00000EF7 00000008 Flash device 5 -00000EFC 00000EFF 00000004 Descriptor Map 2 -00000F00 00000FFF 00000100 OEM Section -00001000 00002FFF 00002000 GbE Region -00003000 00202FFF 00200000 BIOS Region - -Build Settings --------------- -Flash Erase Size = 0x1000 - -</i> -</pre> - - <p> - 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. - </p> - <p> - This tool is proprietary, for Windows only, but was used to deblob the X200. End justified means, and - the utility is no longer needed since the ich9deblob utility (documented on this page) can now be - used to create deblobbed descriptors. - </p> - - </div> - - <div class="section"> - - <h2 id="gbe_region"> - GBE (gigabit ethernet) region in SPI flash - </h2> - - <p> - Of the 8K, about 95% is 0xFF. - The data is the gbe region is fully documented in this public datasheet: - <a href="http://www.intel.co.uk/content/dam/doc/application-note/i-o-controller-hub-9m-82567lf-lm-v-nvm-map-appl-note.pdf">http://www.intel.co.uk/content/dam/doc/application-note/i-o-controller-hub-9m-82567lf-lm-v-nvm-map-appl-note.pdf</a> - </p> - - <p> - The only actual content found was: - </p> - -<pre> -<i> -00 1F 1F 1F 1F 1F 00 08 FF FF 83 10 FF FF FF FF -08 10 FF FF C3 10 EE 20 AA 17 F5 10 86 80 00 00 -01 0D 00 00 00 00 05 06 20 30 00 0A 00 00 8B 8D -02 06 40 2B 43 00 00 00 F5 10 AD BA F5 10 BF 10 -AD BA CB 10 AD BA AD BA 00 00 00 00 00 00 00 00 -00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -00 01 00 40 28 12 07 40 FF FF FF FF FF FF FF FF -FF FF FF FF FF FF FF FF FF FF FF FF FF FF D9 F0 -20 60 1F 00 02 00 13 00 00 80 1D 00 FF 00 16 00 -DD CC 18 00 11 20 17 00 DD DD 18 00 12 20 17 00 -00 80 1D 00 00 00 1F -</i> -</pre> - - <p> - 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. - </p> - - <p> - The GBe region starts at 0x20A000 bytes from the *end* of a factory image and is 0x2000 bytes long. - In libreboot (deblobbed) the descriptor is set to put gbe directly after the initial 4K flash descriptor. - So the first 4K of the ROM is the descriptor, and then the next 8K is the gbe region. - </p> - - <div class="subsection"> - - <h3 id="gbe_region_changemacaddress">GBE region: change MAC address</h3> - - <p> - According to the datasheet, it's supposed to add up to 0xBABA but can actually be others on the X200. - <a href="https://communities.intel.com/community/wired/blog/2010/10/14/how-to-basic-eeprom-checksums">https://communities.intel.com/community/wired/blog/2010/10/14/how-to-basic-eeprom-checksums</a> - </p> - <p> - <i>"One of those engineers loves classic rock music, so they selected 0xBABA"</i> - </p> - <p>In honour of the song <i>Baba O'Reilly</i> by <i>The Who</i> apparently. We're not making this stuff up...</p> - - <p> - 0x3ABA, 0x34BA, 0x40BA and more have been observed in the main Gbe regions on the X200 factory.rom dumps. - The checksums of the backup regions match BABA, however. - </p> - - <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 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> - - <p> - Look at resources/utilities/ich9deblob/ich9deblob.c. - </p> - <ul> - <li>Add the first 0x3F 16bit numbers (unsigned) of the GBe descriptor together (this includes the checksum value) - and that has to add up to 0xBABA. In other words, the checksum is 0xBABA minus the total of the first - 0x3E 16bit numbers (unsigned), ignoring any overflow.</li> - </ul> - - </div> - - </div> - - <div class="section"> - - <h2 id="flash_descriptor_region">Flash descriptor region</h2> - - <p> - <a href="http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-9-datasheet.pdf">http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-9-datasheet.pdf</a> - from page 850 onwards. This explains everything that is in the flash descriptor, which can be used to understand what libreboot - is doing about modifying it. - </p> - - <p> - How to deblob: - </p> - <ul> - <li>patch the number of regions present in the descriptor from 5 - 3</li> - <li>originally descriptor + bios + me + gbe + platform</li> - <li>modified = descriptor + bios + gbe</li> - <li>the next stage is to patch the part of the descriptor which defines the start and end point of each section</li> - <li>then cut out the gbe region and insert it just after the region</li> - <li>all this can be substantiated with public docs (ICH9 datasheet)</li> - <li>the final part is flipping 2 bits. Halting the ME via 1 MCH soft strap and 1 ICH soft strap</li> - <li>the part of the descriptor described there gives the base address and length of each region (bits 12:24 of each address)</li> - <li>to disable a region, you set the base address to 0xFFF and the length to 0</li> - <li>and you change the number of regions from 4 (zero based) to 2</li> - </ul> - - <p> - There's an interesting parameter called 'ME Alternate disable', which allows the ME to only handle hardware errata in the southbridge, - but disables any other functionality. This is similar to the 'ignition' in the 5 series and higher but using the standard firmware - instead of a small 128K version. Useless for libreboot, though. - </p> - - <p> - To deblob GM45, you chop out the platform and ME regions and correct the addresses in flReg1-4. - Then you set meDisable to 1 in ICHSTRAP0 and MCHSTRAP0. - </p> - - <p>How to patch the descriptor from the factory.rom dump</p> - <ul> - <li>map the first 4k into the struct (minus the gbe region)</li> - <li>set NR in FLMAP0 to 2 (from 4)</li> - <li>adjust BASE and LIMIT in flReg1,2,3,4 to reflect the new location of each region (or remove them in the case of Platform and ME)</li> - <li>set meDisable to 1/true in ICHSTRAP0 and MCHSTRAP0</li> - <li>extract the 8k GBe region and append that to the end of the 4k descriptor</li> - <li>output the 12k concatenated chunk</li> - <li>Then it can be dd'd into the first 12K part of a coreboot image.</li> - <li>the GBe region always starts 0x20A000 bytes from the end of the ROM</li> - </ul> - - <p> - This means that libreboot's descriptor region will simply define the following regions: - </p> - <ul> - <li>descriptor (4K)</li> - <li>gbe (8K)</li> - <li>bios (rest of flash chip. CBFS also set to occupy this whole size)</li> - </ul> - - <p> - The data in the descriptor region is little endian, and it represents bits 24:12 of the address - (bits 12-24, written this way since bit 24 is nearer to left than bit 12 in the binary representation). - </p> - <p> - So, <i>x << 12 = address</i> - </p> - <p> - If it's in descriptor mode, then the first 4 bytes will be 5A A5 F0 0F. - </p> - - </div> - - - <div class="section"> - - <h2 id="platform_data_region">platform data partition in boot flash (factory.rom / lenovo bios)</h2> - - <p> - Basically useless for libreboot, since it appears to be a blob. - Removing it didn't cause any issues in libreboot. - </p> - <p> - 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. - </p> - - <p> - It has only a 448 byte fragment different from 0x00 or 0xFF. - </p> - - </div> - - <div class="section"> - - <p> - Copyright © 2014, 2015 Leah Rowe <info@minifree.org><br/> - 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 Commons; - - A copy of the license can be found at <a href="../cc-by-sa-4.0.txt">../cc-by-sa-4.0.txt</a> - </p> - - <p> - Updated versions of the license (when available) can be found at - <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode">https://creativecommons.org/licenses/by-sa/4.0/legalcode</a> - </p> - - <p> - UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE - EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS - AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF - ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, - IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, - WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR - PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, - ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT - KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT - ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. - </p> - <p> - TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE - TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, - NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, - INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, - COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR - USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN - ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR - DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR - IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. - </p> - <p> - The disclaimer of warranties and limitation of liability provided - above shall be interpreted in a manner that, to the extent - possible, most closely approximates an absolute disclaimer and - waiver of all liability. - </p> - - </div> - -</body> -</html> |