diff options
Diffstat (limited to 'docs/hcl')
| -rw-r--r-- | docs/hcl/x200.html | 196 | ||||
| -rw-r--r-- | docs/hcl/x200_remove_me.html | 324 |
2 files changed, 252 insertions, 268 deletions
diff --git a/docs/hcl/x200.html b/docs/hcl/x200.html index e7dbc290..18a1cf81 100644 --- a/docs/hcl/x200.html +++ b/docs/hcl/x200.html @@ -15,20 +15,16 @@ <h1 id="pagetop">ThinkPad X200</h1> <p> - This sections relates to known hardware compatibility in libreboot. - </p> - <p> Or <a href="index.html">back to main index</a>. </p> <p> - It is believed that all X200 laptops are compatible. X200s and X200t may also work, - but require soldering (for the initial installation/flashing of a ROM image, or - dumping the current firmware). <b>Only the X200 is tested so far.</b> + It is believed that all X200 laptops are compatible. X200S and X200 Tablet will + also work, <a href="#x200s">depending on the configuration</a>. </p> <p> 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. + by the libreboot project. The same may also apply between X200S and X201S; again, this is untested. <b>It's most likely true.</b> </p> @@ -39,17 +35,135 @@ </p> <p> - <b>The X200 laptops come with ME (and sometimes AMT) before flashing libreboot. Libreboot disables and removes it + <b>The X200 laptops come with the ME (and sometimes AMT in addition) before flashing libreboot. Libreboot disables and removes it by using a modified descriptor: see <a href="x200_remove_me.html">x200_remove_me.html</a></b> (contains notes, plus instructions) </p> - + <p> Flashing instructions can be found at <a href="../install/index.html#flashrom_x200">../install/index.html#flashrom_x200</a> </p> <hr/> + <div class="section"> + + <h2 id="compatibility_noblobs">Compatibility (without blobs)</h2> + + <p> + Usual limitations apply for native graphics initialization + (no VBT and/or INT10H and only GRUB works so no BIOS, so no DOS/Windows support + - who cares? There is no system but GNU, and Linux is one of it's kernels). + </p> + + <p> + When connecting the AC adapter while system is powered off, system will then power on. + This probably happens in coreboot aswell (with or without blobs). + It's a minor annoyance, but it should be fixed (if it's not already fixed by now). + </p> + + <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 + non-descriptor mode would wipe it out, not to mention require hardware modifications that most users will be unwilling to make). + </p> + + <h3 id="hwvirt">Hardware virtualization (vt-x)</h3> + <p> + 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). + </p> + <p> + The following errata datasheet from Intel might help with investigation: + <a href="http://download.intel.com/design/mobile/specupdt/320121.pdf">http://download.intel.com/design/mobile/specupdt/320121.pdf</a> + </p> + + </div> + +<hr/> + + <div class="section"> + + <h2 id="x200s">X200S and X200 Tablet.</h2> + + <p> + X200S and X200 Tablet have raminit issues at the time of writing + (GS45 chipset. X200 uses GM45). + </p> + + <p> + X200S is known to work, but only with certain CPU+RAM configurations. + The current stumbling block is RCOMP and SFF, mentioned in + <a href="https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf">https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf</a>. + </p> + <p> + The X200 Tablet should also work, but it is not guaranteed. + </p> + <p> + The issues mostly relate to raminit (memory initialization). With an + unpatched coreboot, you get the following: <a href="text/x200s/cblog00.txt">text/x200s/cblog00.txt</a>. + No SODIMM combination that was tested would work. At first glance, it looks + like GS45 (chipset that X200S uses. X200 uses GM45) is unsupported, but + there is a workaround that can be used to make certain models of the X200S + work, depending on the RAM. + </p> + <p> + The datasheet for GS45 describes two modes: low-performance and + high-performance. Low performance uses the SU range of ultra-low + voltage procesors (SU9400, for example), and high-performance uses the + SL range of processors (SL9400, for example). According to datasheets, + GS45 behaves very similarly to GM45 when operating in high-performance + mode. + </p> + <p> + The theory then was that you could simply remove + the checks in coreboot and make it pass GS45 off as GM45; the idea is + that, with a high-performance mode CPU (SL9400, for example) it would + just boot up and work. + </p> + <p> + This suspicion was confirmed with the following log: + <a href="text/x200s/cblog01.txt">text/x200s/cblog01.txt</a>. + The memory modules in this case are 2x4GB. <b>However, not all + configurations work: <a href="text/x200s/cblog02.txt">text/x200s/cblog02.txt</a> (2x2GB) + and <a href="text/x200s/cblog03.txt">text/x200s/cblog03.txt</a> (1x2GB) + show a failed bootup.</b> + </p> + <p> + This was then pushed as a patch for coreboot, which can be found at + <a href="http://review.coreboot.org/#/c/7786/">http://review.coreboot.org/#/c/7786/</a> + (libreboot merges this patch in coreboot-libre now. Check the 'getcb' script in + src or git). + </p> + + <h3 id="x200s_raminit">Proper GS45 raminit</h3> + <p> + A new northbridge gs45 should be added to coreboot, based on gm45, + and a new port x200st (X200S and X200T) should be added based on + the x200 port. + </p> + <p> + This port would have proper raminit. Alternatively, gs45 (if + raminit is taken to be the only issue with it) can be part of + gm45 northbridge support (and X200S/Tablet being part of the X200 + port) with conditional checks in the raminit that make raminit + work differently (as required) for GS45. nico_h and pgeorgi/patrickg + in the coreboot IRC channel should know more about raminit on gm45 + and likely gs45. + </p> + <p> + pgeorgi recommends to run SerialICE on the factory BIOS (for X200S), + comparing it with X200 (factory BIOS) and X200 (gm45 raminit code + in coreboot), to see what the differences are. Then tweak raminit + code based on that. + </p> + + </div> + +<hr/> + <h1 id="lcd_supported_list">LCD compatibility list</h1> <p> Unless otherwise noted (italic styling, underlined), these are CCFL 1280x800 screens with TN panels inside. @@ -68,21 +182,21 @@ Tested LCD panels (confirmed working): </p> <ul> - <li>X200/X200s: LG-Philips LP121WX3-TLC1 (sgsit on IRC has this panel) (LED backlight)</li> - <li>X200/X200s: Samsung LTN121AT03 (phcoder on IRC has this panel)</li> - <li>X200/X200s: AUO B121EW03 V.6 (fchmmr on IRC has this panel)</li> + <li>X200/X200S: LG-Philips LP121WX3-TLC1 (sgsit on IRC has this panel) (LED backlight)</li> + <li>X200/X200S: Samsung LTN121AT03 (phcoder on IRC has this panel)</li> + <li>X200/X200S: AUO B121EW03 V.6 (fchmmr on IRC has this panel)</li> + <li>X200S: TMD-Toshiba LTD121EQ3B (1440x900 resolution) (LED backlight) (sgsit on IRC has this panel)</li> </ul> <p> Untested LCD panels (status unknown): </p> <ul> <li>X200 Tablet: TMD-Toshiba LTD121KX6B (LED backlight)</li> - <li>X200/X200s: TMD-Toshiba LTD121EWVB</li> - <li>X200/X200s: AOU B121EW09 V.2 (LED backlight)</li> - <li>X200/X200s: FRU 42T0715 (no manufacturer/model given) (LED backlight)</li> - <li>X200/X200s: LG-Philips LP121WX3-TLA1 (LED backlight)</li> - <li>X200/X200s: 42T0713 FRU (no model/manufacturer given) (LED backlight)</li> - <li>X200s (not X200): TMD-Toshiba LTD121EQ3B (1440x900 resolution) (LED backlight)</li> + <li>X200/X200S: TMD-Toshiba LTD121EWVB</li> + <li>X200/X200S: AOU B121EW09 V.2 (LED backlight)</li> + <li>X200/X200S: FRU 42T0715 (no manufacturer/model given) (LED backlight)</li> + <li>X200/X200S: LG-Philips LP121WX3-TLA1 (LED backlight)</li> + <li>X200/X200S: 42T0713 FRU (no model/manufacturer given) (LED backlight)</li> </ul> <p> <a href="#pagetop">Back to top of page.</a> @@ -128,10 +242,10 @@ <li><a href="http://thinkwiki.de/X200_Displayumbau">ThinkWiki.de - X200 Displayumbau</a> (achtung: du musst lesen und/oder spreche deutsch; oder ein freund fur hilfe)</li> </ul> - <h3>X200s</h3> + <h3>X200S</h3> <p> <a href="http://forum.thinkpads.com/viewtopic.php?p=618928#p618928">http://forum.thinkpads.com/viewtopic.php?p=618928#p618928</a> - explains that the X200s screens/assemblies are thinner. You need to replace the whole lid with one from a normal X200/X201. + explains that the X200S screens/assemblies are thinner. You need to replace the whole lid with one from a normal X200/X201. </p> <p> @@ -159,6 +273,48 @@ <hr/> + <div class="section"> + + <h2 id="new_targets">New targets</h2> + + <p> + ThinkPad R400/R500/T400/T400S/T500/W500. These all use either the GM45 or GS45 + chipset, and should be easy-ish to port to coreboot (based on the X200 port and + the GM45 code), then adapted for use in libreboot. + </p> + + <p> + There may be issues (most likely to do with raminit) on some of them, and + some of them might sometimse come with ATI graphics (to be avoided) instead + of Intel. + </p> + + <p> + For example, the R400 currently has issues with raminit (not yet ported to coreboot) + where it's DDR3 memory reported as DDR2, as shown in + <a href="text/r400/r400_dmidecode.txt">text/r400/r400_dmidecode.txt</a> + </p> + + </div> + +<hr/> + + <div class="section"> + + <h2 id="unsorted">Unsorted notes</h2> + +<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> 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> + + </div> + +<hr/> + <p> Copyright © 2014 Francis Rowe <info@gluglug.org.uk><br/> This document is released under the Creative Commons Attribution-ShareAlike 4.0 International Public License and all future versions. diff --git a/docs/hcl/x200_remove_me.html b/docs/hcl/x200_remove_me.html index 97937375..463fd06c 100644 --- a/docs/hcl/x200_remove_me.html +++ b/docs/hcl/x200_remove_me.html @@ -108,8 +108,10 @@ </div> +<hr/> + <div class="section"> - + <h2 id="flashchips">Flash chips</h2> <ul> @@ -133,37 +135,13 @@ </div> - <div class="section"> - - <h2 id="compatibility">Compatibility (without blobs)</h2> - - <p>sgsit said this: There are problems with the DMAR table and I get a kernel panic with KVM but day to day it's fine with no ME or microcode.</p> - - <p>Usual limitations apply for native graphics initialization (no VBT and/or INT10H and only GRUB works so no BIOS, so no DOS/Windows support - - who cares? There is no system but GNU, and Linux is one of it's kernels).</p> - - <p>When connecting the AC adapter while system is powered off, system will then power on. This probably happens in coreboot aswell. - It's a minor annoyance, but it should be fixed (if it's not already fixed by now).</p> - - <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 - non-descriptor mode would wipe it out, not to mention require hardware modifications that most users will be unwilling to make).</p> - - </div> +<hr/> <div class="section"> <h2 id="early_development_notes">Early development notes</h2> - - <p> - There is a tool called FITC which contains all the descriptor manipulation tools. This is what sgsit used initially; - it's proprietary software, for Windows, but it was useful for liberating the X200 and making it a real target in - libreboot. End justified means, and the software is no longer needed. - </p> <pre> -<sgsit> here's some output: -<b>Was a paste link. putting it here instead:</b> <i> Start (hex) End (hex) Length (hex) Area Name ----------- --------- ------------ --------- @@ -192,11 +170,7 @@ Start (hex) End (hex) Length (hex) Area Name 001F6000 001F7FFF 00002000 GbE Region 001F8000 001FFFFF 00008000 PDR Region 00200000 003FFFFF 00200000 BIOS Region -</i> -<sgsit> this is the one that's running on my machine at the moment: -<b>Was a paste link. Putting here instead:</b> -<i> Start (hex) End (hex) Length (hex) Area Name ----------- --------- ------------ --------- 00000000 003FFFFF 00400000 Flash Image @@ -228,35 +202,39 @@ Build Settings Flash Erase Size = 0x1000 </i> +</pre> -Tool used: -<sgsit> it's called 'Flash Image Tool' from the 4.x package -<sgsit> you drag a complete image into it and the the tool decomposes the various components -<sgsit> and allows you to set the soft straps - -This tool is proprietary, for Windows only, but was used to deblob the X200. End justified by means, and -the utility is no longer needed (sgsit's ich9deblob utility documented at the top of the page is now -used to create deblobbed descriptors). + <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> -</pre> - </div> - + +<hr/> + <div class="section"> - <h2 class="gbe_region"> + <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> -<sgsit> this is the only content: -<b>Was a paste link. putting it here instead:</b> <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 @@ -270,35 +248,39 @@ FF FF FF FF FF FF FF FF FF FF FF FF FF FF D9 F0 DD CC 18 00 11 20 17 00 DD DD 18 00 12 20 17 00 00 80 1D 00 00 00 1F </i> -<sgsit> the first part is the MAC address which I've set to all 0x1F -<sgsit> it's repeated half way through the 8k area. the rest is 0xFF -<sgsit> <b>it's not a blob - i've just found the intel docs with the full spec of the data there</b> -<sgsit> <b>thanks to mtjm: <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></b> -<sgsit> so we have a mostly functional libre x200 -<sgsit> just need to sort some ACPI issues </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 it directly after the initial 4K flash descriptor. + 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> - -<pre> -<sgsit> interesting fact about the gbe checksum: it's supposed to add up to 0xBABA (in honour of Baba O'Reilly apparently) but it is actually 0x3ABA -<sgsit> either the checksum doesn't matter or the MSB of the checksum isn't checked. strange though -<sgsit> <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> -<sgsit> "One of those engineers loves classic rock music, so he selected 0xBABA" -<sgsit> 0xBABA and 0x3ABA only differ by the most significant bit. -<sgsit> the checksum in the GBe region of my X200S is 0x34BA -<sgsit> when it should be 0xBABA -34BA is BABA in L33T speak. 3=B and 4=A. Thus, 34BA=BABA -Apparently these intel people have a sense of humour. -</pre> + <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 0x3ABA. + Either the checksum doesn't matter or the most significant bit of the checksum isn't checked. + <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 he selected 0xBABA"</i> + </p> + <p> + 0xBABA and 0x3ABA only differ by the most significant bit. The checksum of the GBe region from an X200S + was found to be 0x34BA; again, it should be 0xBABA. 34BA is actually BABA in L33T speak (look it up). + </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> </div> +<hr/> + <div class="section"> <h2 id="flash_descriptor_region">Flash descriptor region</h2> @@ -347,201 +329,47 @@ Apparently these intel people have a sense of humour. <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> - -<pre> -<sgsit> the data in the descriptor is little endian -<sgsit> and it represents bits 24:12 of the address (bits 12-24. written as 24:12 since bit 24 is more nearer to left than bit 12) -<sgsit> so x << 12 = address --- -<sgsit> if it is in descriptor mode, the first 4 bytes will be 5A A5 F0 0F --- -<fchmmr> so there are just 3 regions in libreboot (X200) rom then: -<fchmmr> * descriptor (4K) -<fchmmr> * gbe (8K) -<fchmmr> * bios (rest of flash chip. CBFS also set to occupy this whole size) -</pre> - - </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. Removing it didn't cause any issues. + This means that libreboot's descriptor region will simply define the following regions: </p> - -<pre> -<mtjm> sgsit: thanks; have you checked what platform data partition has? my notes state that it has only a 448 byte fragment different from 0x00 or 0xff -<sgsit> mtjm: the contents of mine from the stock rom are here: -<b>Was a paste link. Moving it here:</b> -<i> -53 FC 75 06 91 CA FA 62 91 27 D9 BF 59 93 A6 03 -38 FA 2E 96 02 8C BD 1D F5 5F A6 6A 87 30 47 45 -25 70 9A 60 B9 62 FD 9D 64 E1 88 37 FB 59 17 C2 -91 B0 A5 25 26 9B 36 44 85 09 E4 02 CC 91 28 8F -01 FF 22 D9 7B AA 61 97 5B E6 EE 7D CD F2 7F B1 -83 74 36 88 6B 4C 4F D5 DF 11 1E DF C0 D9 87 48 -CA DC 57 B7 F9 65 E4 E5 78 BA 90 78 D7 1E CB 3B -C3 8E 34 27 B9 B7 29 3D AA 53 96 0B 7D F7 47 82 -C6 E2 08 CD 94 49 10 C4 6D BD B2 2F BD 84 1B 20 -EC 8C 7E 33 6A B0 20 8D A4 7C 10 61 AD 11 66 BA -8F B1 07 B1 52 C2 F0 B7 88 BB 3A 6F 27 8F C1 EA -F7 BF 82 11 92 39 44 51 AB 19 25 2B 8A 7A D1 66 -2B 82 FF CE C7 EC 78 E2 9F 47 BE C2 37 F7 5A 2E -A6 57 B6 B3 66 2B 2D 33 20 C6 4D F7 26 41 57 70 -DC 04 42 39 BD B8 96 71 3E B1 9C 13 76 BF E2 AC -DD 65 E1 82 D6 46 F3 39 EA B5 FE F6 56 3F B9 67 -DE 5E 08 8B 00 77 D9 94 D0 16 F0 97 BF A6 44 3A -C1 27 22 E1 7C DD 2F 15 A1 D5 53 61 2A 37 F8 E1 -94 8E 1F 3D 8F 79 08 37 09 45 AC 1B 33 75 FB 3D -1D 6E 67 22 3D C3 90 B4 F8 9E 31 09 6F 70 1F BC -9E 48 29 A0 1F 29 5E 1B B5 D3 C3 D7 6C 14 AE 63 -FE F3 3A 23 98 78 4C C9 7E 9E F0 A4 72 9F FF 25 -CC 6F 2B D1 41 27 00 A5 79 4A 37 D3 83 63 32 89 -FB 03 2C AE 6B 33 31 1A 5A A2 A8 C5 5E 1F A5 BD -40 A7 76 7D A9 AC AC 18 21 6D F6 74 7D 18 19 C4 -DE 6D D1 55 A0 C9 2C FD 6A 56 BB 1B 08 C1 B6 60 -16 B7 EB D3 8B D8 BC 41 5F D6 86 A5 45 F8 A7 99 -68 6E EA 4D EA B6 39 6E 9B 5D 0E 58 9B D8 00 00 -</i> -<sgsit> i've removed it - doesn't seem to have had any ill effect -<sgsit> the region is 32k but like yours the rest of it is 0x00 or 0xFF -<mtjm> mine is different; maybe it's just something that the BIOS used -<sgsit> i think that's the case -</pre> - - </div> - - <div class="section"> - - <h2 id="new_targets">New targets</h2> - -<pre> -R400, R500 -T400, T400s, T500 -W500 -X200, X200s, X200 Tablet, X301 -^ these are other gm45 targets for coreboot (not yet ported at the time of writing) that could be in libreboot one day -^ some of them have ATI or Intel graphics. Avoid ATI (proprietary video bios rom needed) - -<sgsit> from the mailing list where somebody was enquiring abouy an R400 port: -<sgsit> Your dmidecode.log shows that you have DDR2 memory. -<sgsit> Sadly, our current GM45 chipset code does only support DDR3 (which is used in the Roda RK9). -<sgsit> If this isn't a fault in your DMI tables and you really have DDR2 memory, porting coreboot will be especially hard (some more month of extra) -<sgsit> re DDR3 on the R400, that's really weird -<sgsit> mtjm will be able to confirm but maybe there's something messed up in the HW of the R400 because it reports DDR2 -<a href="text/r400/r400_dmidecode.txt">text/r400/r400_dmidecode.txt</a> is dmidecode output from factory bios on R400. + <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> -Some of them use DDR2 memory, or DDR3 memory that is detected as DDR2, or they are GS45 chipset. Basically, some of -them involve the hell of getting raminit right. but these are all fine targets that could be ported to coreboot -based on the X200 port. -</pre> - + <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="unsorted">Unsorted notes</h2> - -<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> 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> - - <p> - sgsit couldn't use vt-x without microcode updates. setting vm to have 1 core made vm kernel panic. - setting vm to use 2 cores made host kernel panic. Might be possible to workaround this in qemu. - according to sgsit (if not, just use software-only virtualization, no acceleration) - <a href="http://download.intel.com/design/mobile/specupdt/320121.pdf">http://download.intel.com/design/mobile/specupdt/320121.pdf</a> - </p> - - </div> +<hr/> <div class="section"> - <h2 class="x200s">X200S and X200T</h2> + <h2 id="platform_data_region">platform data partition in boot flash (factory.rom / lenovo bios)</h2> <p> - Only X200 is known to work so far. X200S and X200 Tablet have raminit issues at the time of writing - (GS45 chipset. X200 is GM45). + 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> -<pre> -X200S issues (X200T probably also affected): -<sgsit> fchmmr: some light reading - <a href="https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf">https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf</a> -<sgsit> mentions RCOMP which is the current stumbling block -<sgsit> oh god - SFF platform unsupported in write i/o initialization. -<sgsit> i think the X200S is doomed -<sgsit> hi. i've just flashed the X200 image to an X200S and i'm getting the error "SFF platform unsupported in RCOMP initialization." after "Setting IGD memory frequencies for VCO #1.". can anyone point me in the right direction to resolve this? -<sgsit> full log here: <a href="text/x200s/cblog00.txt">text/x200s/cblog00.txt</a> -<sgsit> i've tried many different SODIMM combinations -<PaulePanter> sgsit: src/northbridge/intel/gm45/raminit.c: die("SFF platform unsupported in RCOMP initialization.\n"); -<PaulePanter> sgsit: Check the source why it gets there. Found with `git grep "SFF platform"`. -<sgsit> PaulePanter: thanks, i'll investigate -<sgsit> PaulePanter: damn, looks like GS45 is unsupported -<sgsit> pgeorgi: do you know if adding RCOMP and write i/o init support to GS45 is going to be a nightmare? or is it a matter of studying datasheets? did you write the GM45 raminit code? -<pgeorgi> sgsit: I helped write some parts, but nico was the principal author -<pgeorgi> sgsit: I think the ddr3 side is pretty complete -<fchmmr> nico_h ? -<sgsit> pgeorgi: is it possible that GM45 is marked as unsupported because it wasn't able to be tested? -<sgsit> *GS45 -<pgeorgi> sgsit: we wrote that specifically for gm45. gs45 is unsupported because nobody ever cared for it -<sgsit> i know that GS45 only supports 1066/1333 and GM45 supports 800 too. i wonder if that points to big differences in the ram init code -<pgeorgi> fchmmr: nico_h, yes -<sgsit> sorry i meant 667/800/1066 -<pgeorgi> sgsit: everything is possible. my approach on this (absent reasonable datasheet access) would be to trace the vendor bios with serialice, then compare against the gm45 code, since it's probably somewhat similar -<sgsit> pgeorgi: thanks for the advice. you've given me hope -<pgeorgi> of course, after testing that the current gm45 code isn't just blocked by something trivial (eg. a pci id test) -<sgsit> yes, i was going to try removing the die command first.. the laptop i'm working on has a WSON-8 flash chip so i'm going to have to get the soldering iron out again. boo -<kmalkki> sgsit: some lenovo boards have WSON-8 and SOIC-8 layout on the PCB in parallel -<kmalkki> sgsit: does the silk screen have SPI1 and SPI2 ? -<sgsit> kmalkki: on the X200S the land array can take a SOIC-8 too. i don't (yet) have a hot air rework tool though -<sgsit> only thing is the supported SOIC-8 chips on that board are all 4MiB -<kmalkki> sgsit: you can switch from WSON-8 to SOIC-8 if you have matching IDs on the SPI flash part -<kmalkki> vendor bios might care, but for coreboot and flashrom you can switch to different SPI part entirely -<sgsit> but i was looking forward to having loads of free space to do interesting things with -<kmalkki> several options for 8MiB in SOIC-8 -<sgsit> kmalkki: sorry, i hadn't realised the significance of what you were saying. i actually have some new MX25L6445EM2I-10G here which i could probably swap over then. would flashing internally, using the ICH be a problem? -<kmalkki> sgsit: change of SPI flash part may confuse vendor BIOS and may require (simple) coreboot and flashrom development work -<kmalkki> sgsit: internal flashing is only issue once your system boots to OS -<sgsit> fchmmr: i have renewed hope for the X200S. after digging through the datasheet, i've discovered that the GS45 operates in 2 modes. -<sgsit> low and high performance -<sgsit> low performance uses the SU range of ultra-low voltage chips eg SU9400 -<sgsit> my X200S has an SL9400 which is in the high-performance category -<sgsit> from the docs, the GS45 behaves just like the GM45 when it's in high performance mode. -<sgsit> i expect / hope that the coreboot devs were wary of the other mode. with any luck, if i remove the checks (or hardcode the sff param to 0) the board may just boot up. i may have time to try this later -<sgsit> <fchmmr> I take it that the low-performance ones still wouldn't work, so for now you'd have to be careful to get one that has a particular cpu in it. -<sgsit> that's my assumption -<sgsit> orly_owl: no, i don't think so. the ulv cpus run at a different voltage. this is good news though, unless you buy an SUxxxx model -<sgsit> fchmmr: my hand crafted and untested patch for raminit.c: -<sgsit> --- -<sgsit> 113 -<sgsit> +++ sysinfo->gs45_low_power_mode = 1; -<sgsit> 113 sysinfo->gs45_low_power_mode = 0; -<sgsit> --- -<sgsit> 1696 const int sff = sysinfo->gfx_type == GMCH_GS45; -<sgsit> +++ -<sgsit> 1696 const int sff = sysinfo->gfx_type == GMCH_GS45 && sysinfo->gs45_low_power_mode = 1; -<sgsit> * 1696 const int sff = sysinfo->gfx_type == GMCH_GS45 && sysinfo->gs45_low_power_mode == 1; -<sgsit> i'll try it later -<sgsit> it assumes that GS45 is in high performance mode rather than low power which is no good for the masses -<sgsit> fchmmr: progress ;) -<sgsit> <a href="text/x200s/cblog01.txt">text/x200s/cblog01.txt</a> -<sgsit> doesn't like my 2GB dimms but it at least boots with 2x4GB -<sgsit> haven't put it back together yet so no idea if it's stable -<sgsit> note line 12 - GMCH: GS45, using high performance mode by default -<sgsit> with the patch i wrote blind earlier -<sgsit> needs testing -<sgsit> may be barely functional -<sgsit> and has problems with some SODIMMS -<sgsit> <a href="text/x200s/cblog02.txt">text/x200s/cblog02.txt</a> (2x2GB) -<sgsit> <a href="text/x200s/cblog03.txt">text/x200s/cblog03.txt</a> (1x2GB) -<sgsit> the GS45 in high performance mode is just a shrunken GM45 afaict -</pre> + <p> + It has only a 448 byte fragment different from 0x00 or 0xFF. + </p> </div> |