1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
|
<!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>ThinkPad X200: remove the ME (manageability engine)</title>
</head>
<body>
<h1 id="pagetop">ThinkPad X200: 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 the ThinkPad X200.
</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 the X200, it is possible to remove it without any ill effects. All
other parts of coreboot on the X200 can be blob-free, so removing the ME was the last obstacle to
get X200 support in libreboot (the machine can also work without the microcode blobs).
</p>
<p>
Or <a href="x200.html">back to main X200 compatibility page (x200.html)</a>.
</p>
<hr/>
<h1 id="ich9deblob">ICH9 deblob utility</h1>
<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 ./builddeps or ./builddeps-ich9deblob from the main directory (./),
otherwise you can build it like so:<br/>
$ <b>./builddeps-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_bin 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 X200
(can be obtained using the guide at <a href="../install/x200_external.html">../install/x200_external.html</a>) in
the directory where you have your ich9deblob executable, then run the tool:<br/>
$ <b>./ich9deblob</b>
</p>
<p>
A 12kiB file named <b>deblobbed_descriptor.bin</b> will now appear. <b>Keep this and the factory.rom stored in a safe location!</b>
The first 4KiB contains the descriptor data region for your machine, and the next 8KiB contains the gbe region (config data for your
gigabit NIC). These 2 regions could actually be separate files, but they are joined into 1 file in this case.
</p>
<p>
Assuming that your X200 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>
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/index.html#flashrom_x200">../install/index.html#flashrom_x200</a>
for how to flash it.
</p>
<hr/>
<p>
The sections below are adapted from (mostly) IRC logs related to early development getting the ME removed on the X200.
They are useful for background information. This could not have been done without sgsit's help.
</p>
<div class="section">
<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 class="section">
<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 X200's 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 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>
<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
----------- --------- ------------ ---------
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
</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
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>
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).
</pre>
</div>
<div class="section">
<h2 class="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>
<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
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>
<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 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.
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>
</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 the x200, 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>
<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.
</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.
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>
</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>
<div class="section">
<h2 class="x200s">X200S and X200T</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).
</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>
</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.
A copy of the license can be found at <a href="../license.txt">../license.txt</a>.
</p>
<p>
This document is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See <a href="../license.txt">../../license.txt</a> for more information.
</p>
</body>
</html>
|
