aboutsummaryrefslogtreecommitdiff
path: root/docs/tasks.html
blob: c7f884ef1b48876463ff1c3a21c34b2583e1c78b (plain) (blame)
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
<!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>Libreboot task list</title>
</head>
<body>
	<div class="section">
		<h1 id="pagetop">Libreboot task list</h1>
			<p>
				Back to <a href="index.html">index.html</a>.
			</p>
	</div>

	<div class="section">

		<div class="subsection">

			<h2 id="tasks">
				Important tasks for the libreboot project
			</h2>
				<h3 id="board_ports">Board ports</h3>
					<ul>
						<li>
							Current candidates (new boards) for libreboot:
							<ul>
								<li>
									Libreboot has so far been biased towards Intel. This needs to end (the sooner, the better). A nice start:
									<ul>
										<li>
											<b><i><u>HIGH^2 PRIORITY!</u></i></b> Lenovo G505S (works without CPU microcode updates). Video BIOS is an issue (unfinished replacement: openatom), as
											is the SMU firmware (ruik will know more). Other non-essential blobs may also still be present (but possible
											to remove). <a href="http://projects.mtjm.eu/work_packages/44">http://projects.mtjm.eu/work_packages/44</a>
											- It's AMD, so no ME either!
											<ul>
												<li>funfunctor (afaik) in the coreboot IRC channel is the person who ported this laptop,
												he might be able to help</li>
												<li>mrnuke in the coreboot IRC channel is the person responsible for openatom</li>
												<li><b>Add this board to the <i>LTS Candidates</i> page on the coreboot wiki</b></li>
											</ul>
										</li>
										<li>
											<b><i><u>HIGH PRIORITY!</u></i></b> ASUS KFSN4-DRE - fam10h, already in coreboot, seems to have native graphics initialization already,
											CPUs probably work without microcode updates, looks like this can already run blob-free.
											NOTE: PLCC flash chip (see vultureprog. BBB might be possible, it has GPIO pins etc) - 
											external flashing not required. Flashing internally from stock firmware works.
											Recommendation: boot with proprietary firmware, dump it, hot-swap the chip and copy the dump to the new chip.
											Do this a few times. Now you have a backup. Then flash coreboot/libreboot. No external programmer needed
											(not even for brick recovery, since you backed it up onto spare flash chips).
										</li>
										<li>
											<b><u><i>HIGH PRIORITY!</i></u></b> ASUS KGPE-D16 - ported by <a href="http://raptorengineeringinc.com/content/base/main.htm">Raptor Engineering Inc.</a> (USA). 
											They use it internally, but have not yet released the code.
											According to tpearson in #coreboot this will run completely blob-free with full functionality. They are
											asking for $50,000* (USD) to pay for the work to upstream it (get it into coreboot master repository).
											<b>Crowd funding will be necessary!</b>
											See <a href="http://www.coreboot.org/pipermail/coreboot/2015-April/079773.html">this thread</a>
											on the coreboot mailing list.
											- note: external flashing required for initial install (internal flashing works with coreboot/libreboot running).
											It uses a DIP-8 (socket) SPI flash chip, so it's easy to flash.
											* was 35K. the extra is for adding S3 support and full text-mode graphics initialization (bugs eliminated, etc).
											A lot of work went into this port!
										</li>
										<li>
											<b><i><u>HIGH PRIORITY!</u></i></b> F2A85-M and E350M1 (libreboot_*_headless.rom). Test openatom (video BIOS replacement). SMU firmware is a problem. XHCI firmware is a problem.
										</li>
										<li>
											<b>TODO: Add ARM candidates here (the above systems are all AMD).</b>
										</li>
										<li><b>This list needs to expand!</b></li>
									</ul>
								</li>
								<li>
									That doesn't mean Intel is off the table just yet:
									<ul>
										<li>
											<b><u><i>HIGH PRIORITY!</i></u></b> ThinkPad R500: <a href="http://projects.mtjm.eu/work_packages/43">http://projects.mtjm.eu/work_packages/43</a>
										</li>
										<li>
											<b><u><i>HIGH PRIORITY!</i></u></b> ThinkPad W500: they all use switchable graphics (ATI+Intel), the native init code in coreboot (for Intel)
											needs to disable the ATI chip and use Intel (already done in libreboot on GM45 laptops with the same setup)
											- NOTE: it's uncertain whether PM45 is compatible with GM45
										</li>
										<li>
											Non-lenovo GM45 laptops:
											<ul>
												<li><b><u><i>HIGH PRIORITY!</i></u></b> Dell Latitude E6400 - quite a few of these online. This is a good laptop to target in coreboot and libreboot.
												NOTE: EC support. ALSO: DDR2 memory (coreboot raminit for GM45 currently only supports DDR3)</li>
											</ul>
										</li>
									</ul>
								</li>
							</ul>
						</li>
					</ul>
					
				<h3>Platform-specific bugs</h3>
					<ul>
						<li>
							<b><u><i>HIGH PRIORITY!</i></u></b> Fix these issues on GM45/GS45 targets:
							<ul>
								<li>
									X200: text-mode is broken. only framebuffer graphics work.
									Commit bde6d309dfafe58732ec46314a2d4c08974b62d4 in coreboot is what
									broke it. Investigate. 
									<ul>
										<li>It might not be that commit; it's only an educated guess, based on
										running <i>git log</i> on src/northbridge/intel/gm45/gma.c - an actual
										git bisect has not yet been done.</li>
									</ul>
								</li>
								<li>
									X200 and X60: problem observed on both laptops: battery will drain even when the system
									is powered down, which means that it's not fully powered down and something is still using
									power. This could alternatively just be dead/dying batteries, but it should be investigated
									whether something can be done in coreboot.
								</li>
								<li>
									Sound (internal speaker) worked on the T500, but stopped after all subsequent boots.
									(might just be this system). investigate. (external speaker works)
									- probably because it uses a different hda_verb
								</li>
								<li>
									tty0_ in #libreboot got tablet functions on X200T to work. Wait for it to land in gerrit
									(and master)? also test it first. For now, here is a paste:
									<a href="https://paste.debian.net/plainh/65cd0a55">https://paste.debian.net/plainh/65cd0a55</a>
									- tty0_ wants to know whether it breaks the X200 (non-tablet version) or not. (It's probably fine)
								</li>
							</ul>
						</li>
						<li>
							<b>Finish all work listed in <a href="future/index.html">future/index.html</a></b>
						</li>
						<li>
							Fix these issues on i945 targets (X60/T60/macbook21)
							<ul>
								<li>
									<b><u><i>HIGH PRIORITY!</i></u></b> Fix remaining incompatible LCD panels in native graphics on T500. 
									See <a href="hcl/t500.html">hcl/t500.html</a>.
								</li>
								<li>
									i945: fix VRAM size (currently 8MB. should be 64MB). 
									See <a href="future/index.html#i945_vram_size">future/index.html#i945_vram_size</a>.
								</li>
								<li>
									Fix remaining incompatible LCD panels in native graphics on T60. 
									See <a href="future/index.html#lcd_i945_incompatibility">future/index.html#lcd_i945_incompatibility</a>.
								</li>
								<li>
									i945: the intel video driver used to initialize the display without native graphics initialization
									and without the extracted video BIOS. It no longer does, so investigate why it does not, and fix
									the regression (fix has to be done in the kernel, Linux).
									See <a href="http://www.coreboot.org/pipermail/coreboot/2014-June/078104.html">http://www.coreboot.org/pipermail/coreboot/2014-June/078104.html</a> and
									<a href="http://www.coreboot.org/pipermail/coreboot/2014-June/078105.html">http://www.coreboot.org/pipermail/coreboot/2014-June/078105.html</a>
								</li>
								<li>
									Add fake_vbt tables on i945 systems (also GM45).
								</li>
								<li>
									Commit 26ca08caf81ad2dcc9c8246a743d82ffb464c767 in coreboot, see the while (1) loop that
									waits for the panel to power up on i945. This is an infinite loop if the panel doesn't power up.
									Fix it. Also, are there panels that don't power up? Test this, and fix it.
								</li>
							</ul>
						</li>
					</ul>
					
				<h3>
					Flashing from lenovobios to libreboot (and vice versa)
				</h3>
					<ul>
						<li>
							Implement everything outlined in
							<a href="hcl/gm45_remove_me.html#demefactory">hcl/gm45_remove_me.html#demefactory</a>
							and test it.
						</li>
					</ul>
					
				<h3>Payloads</h3>
					<ul>
						<li>
							Add ProteanOS payload to systems with big enough flash chips. (eg X200/R400).
							This page (outdated, but still useful according to the maintainer) has some info:
							<a href="http://www.proteanos.com/doc/plat/porting/">http://www.proteanos.com/doc/plat/porting/</a>.
							pehjota says that once the port is done, prokit can be modified to generate the entire
							distribution as a vmlinuz and initrd.img file.
						</li>
					</ul>

				<h3>Build system</h3>
					<ul>
						<li>
							<b><u><i>HIGH PRIORITY!</i></u></b> All parts of libreboot that download 
							non-intergrated parts (coreboot/grub/memtest/bucts/flashrom) rely on only a single
							repository link, which means single-point-of-failure. Make them fall back on alternative
							(backup) repositories if the main ones are down.
							<ul>
								<li>The coreboot one also cherry picks patches from review.coreboot.org (gerrit), but coreboot.org
								is sometimes down. When that happens, libreboot cannot be built from git. 
								The solution is to directly include those patches that are used, as patch/diff files
								under <i>resources/libreboot/patch/, instead of cherry picking from gerrit
								(but still include a commented-out link to the gerrit patch that the diff file came from)</i></li>
							</ul>
						</li>
						<li>
							<b><u><i>HIGH PRIORITY!</i></u></b> 
							When downloading coreboot/grub/memtest/etc using the download scripts, it currently does
							not check the integrity of these sources at all. Libreboot releases are signed, but
							what can be done to improve it is to check the sha512sums of all files downloaded
							by these scripts (which are in the git repository, but not the release archives,
							because the release archives already include these sources). Do this for all
							non-integrated modules used in libreboot.
						</li>
						<li><b><u><i>HIGH PRIORITY!</i></u></b> <b>Make memtest86+ build using coreboot's own crossgcc toolchain. Currently,
						memtest86+ doesn't even work at all when cross-compiled using the toolchain in x86-64 trisquel7</b></li>
						<li>
							Make libreboot (all of it!) build reproducibly. This is very important.
							See <a href="http://projects.mtjm.eu/work_packages/16">http://projects.mtjm.eu/work_packages/16</a>.
						</li>
						<li>
							build/release/archives currently fails on Parabola (it only works well in Trisquel).
							That script is buggy, and full of ugly hacks anyway, 
							so re-write it and make it modular/portable this time.
						</li>
					</ul>
					
				<h3>Improvements to the utilities</h3>
					<ul>
						<li>
							Stop deleting flash chip definitions in flashrom. Instead, modify flashrom to ignore
							a list of chip definitions. This is a much cleaner solution. (add an option to override
							the ignore).
						</li>
						<li>
							Make ich9gen/ich9deblob portable. They both rely extensively on bitfields, and they assume
							little-endian; for instance, mapping a little endian file directly to a struct, instead
							of serializing/deserializing. Re-factor both utilities and make them fully portable.
							See <a href="http://projects.mtjm.eu/work_packages/18">http://projects.mtjm.eu/work_packages/18</a>
						</li>
						<li>
							Adapt linux-libre deblob scripts for use with coreboot. Libreboot is already deblobbed
							using its own script, but updating it is still a bit too manual. linux-libre's deblob
							scripts do an excellent job and (adapted) will make it much easier to maintain coreboot-libre.
						</li>
						<li>
							Add a whitelist entry to board_enable.c in flashrom, for the ThinkPad R400 and T400
						</li>
					</ul>
					
				<h3>
					BeagleBone Black
				</h3>
					<ul>
						<li>Get libre distros ported to it. Eg proteanos, trisquel, parabola, librecmc and so on.</li>
						<li>See <a href="https://coreboot.org/BBB_screwdriver">BBB screwdriver</a> - from the coreboot
						project, this is an openwrt-based image for the BBB that comes with EHCI enabled out of the box.
						Look into re-basing that on librecmc (librecmc is a deblobbed version of openwrt).</li>
					</ul>
				
				<h3>Documentation improvements</h3>
					<ul>
						<li>
							<b><u><i>HIGH PRIORITY!</i></u></b> <b>Add information from hw registers on all boards. See
							<a href="http://projects.mtjm.eu/work_packages/15">http://projects.mtjm.eu/work_packages/15</a></b>
							<ul>
								<li>We currently have them for X200 (4MiB flash chip), T400 but not complete</li>
								<li>
									Get them for more boards:
									<ul>
										<li>X60</li>
										<li>T60</li>
										<li>macbook21</li>
										<li>X200 (make sure to have it for both flash chip sizes)</li>
										<li>R400 (make sure to have it for both flash chip sizes)</li>
										<li>T400 (make sure to have it for both flash chip sizes)</li>
										<li>T500 (make sure to have it for both flash chip sizes)</li>
									</ul>
								</li>
							</ul>
						</li>
						<li>
							Apparently, leaving HOLD and WP pins floating (unconnected) isn't a good idea.
							Information online says that this needs to be connected along with 3.3V - look into this.
							(it is specific to each flash chip, so read the datasheets).
							<ul>
								<li>
									eg http://flashrom.org/FT2232SPI_Programmer - 
									&quot; The WP# and HOLD# pins should be tied to VCC! If you leave them unconnected you'll likely experience strange issues.&quot;
								</li>
								<li>
									&lt;pehjota&gt; stefanct: We've never had any &quot;strange issues&quot; with leaving WP# and HOLD# 
									unconnected on the Macronix and Atmel SOIC-8 and SOIC-16 flash chips on the X200.  
									IIRC, the datasheets don't say how those pins are wired internally or whether they can 
									be left unconnected.  But I tested their voltages while flashing, and they float high 
									on their own, so they seem to support it fine.
								</li>
								<li>
									&lt;pehjota&gt; fchmmr: You would connect the WP# and HOLD# pins to 3.3 V (on an ATX PSU you'd 
									hook up more cables to the other orange pins, with your PSU I guess you'd wrap more wires 
									around the 3.3-V screw), just like you do VCC.  But as I said above, it doesn't seem to 
									be necessary (WP# and HOLD# seem to be held high already).<br/>
									&lt;pehjota&gt; I got a solid ~3.3 V (i.e. pulled high, not floating between high and low) 
									from WP# and HOLD# with just VCC, GND, MOSI, MISO, CS#, and SCLK connected.  Plus, we haven't 
									had any write protection issues as I'd expect from floating WP# and HOLD#, AFAIK.<br/>
									&lt;pehjota&gt; fchmmr: These pins do nothing if they're held high.  The "#" (not) means they cause different behavior when held low.
								</li>
								<li>
									&lt;stefanct&gt; fchmmr: pehjota: it may not be a problem if the chip is soldered to the x200, but it surely is when it isnt.
								</li>
								<li>
									&lt;stefanct&gt; yes...
									&lt;stefanct&gt; a small note noting that would be appreciated because there are enough people out there already that ignore those pins and get stuck
									&gt;pehjota&gt; stefanct: You mean a note in the libreboot documentation explaining why we don't have to connect HOLD# and WP# to anything and how they would have to be tied to VCC on a chip not soldered to a board?
									&lt;Kamilion&gt; How about a more useful note that explains the whole discussion you two had succinctly?
									&lt;Kamilion&gt; Not everyone is going to be an EE to know about the # indicating the pin should be pulled low to be active.
									&lt;Kamilion&gt; reminds me, I need to pull out my pomona and try to fix some intel NIC roms
									&lt;stefanct&gt; pehjota: yes
								</li>
							</ul>
						</li>
						<li>
							Adapt the notes at <a href="install/bbb_setup.html#stability">install/bbb_setup.html#stability</a>
							into a full guide.
						</li>
						<li>
							There are no instructions for how to use the GRUB terminal to find
							a grub.cfg manually, or how to boot an installed GNU/Linux manually, 
							so some users get stuck after the initial installation of libreboot
							not knowing how to boot the GNU/Linux system that they had before installing.
							Fix that. (also, promote the FSF-endorsed distros while you do it)
						</li>
						<li>
							Add guides for GM45 laptops in docs/security/
						</li>
						<li>
							Add guides for GM45 laptops in docs/hardware/
						</li>
						<li>
							Convert documentation to Sphinx/ReST
							See <a href="http://projects.mtjm.eu/work_packages/5">http://projects.mtjm.eu/work_packages/5</a>
							and <a href="http://projects.mtjm.eu/work_packages/12">http://projects.mtjm.eu/work_packages/12</a>
						</li>
						<li>
							<b>
								Maintainence manual. How to contribute to libreboot.
								See <a href="http://projects.mtjm.eu/work_packages/11">http://projects.mtjm.eu/work_packages/11</a>
								<ul>
									<li>Work has begun. <a href="maintain/index.html">maintain/index.html</a></li>
								</ul>
							</b>
						</li>
						<li>
							LUKS key in initramfs: Add Trisquel documentation for docs/gnulinux/encrypted_trisquel.html.
							See <a href="http://projects.mtjm.eu/work_packages/39">http://projects.mtjm.eu/work_packages/39</a>
						</li>
						<li>
							PLCC flashing guide is needed:
							<a href="http://blogs.coreboot.org/files/2013/07/vultureprog_shuttle_sbs.jpg">image</a>,
							<a href="http://blogs.coreboot.org/files/2013/08/vultureprog_probing.jpg">image</a>,
							<a href="http://blogs.coreboot.org/files/2013/06/superboosted2.jpg">image</a> - 
							work with mrnuke on getting info about vultureprog PLCC flashing into libreboot. Libreboot needs
							server boards. <a href="https://github.com/mrnuke/vultureprog">https://github.com/mrnuke/vultureprog</a>,
							<a href="https://github.com/mrnuke/qiprog">https://github.com/mrnuke/qiprog</a>,
							<a href="https://github.com/mrnuke/vultureprog-hardware">https://github.com/mrnuke/vultureprog-hardware</a>.
							He also uses the sigrok logic analyzer (free/libre):
							<a href="http://www.dx.com/p/logic-analyzer-w-dupont-lines-and-usb-cable-for-scm-black-148945">http://www.dx.com/p/logic-analyzer-w-dupont-lines-and-usb-cable-for-scm-black-148945</a>
						</li>
					</ul>
					
				<h3>Project (institutional) improvements</h3>
					<ul>
						<li>
							<b><u><i>HIGH PRIORITY!</i></u></b> Add proper guidelines for contributions,
							like <i>Development Guidelines</i> on the coreboot wiki. For instance, require
							<i>Sign-off-by</i> in all commits for libreboot. Consulting with the FSF about this
							(licensing@fsf.org).
						</li>
						<li>
							<b><u><i>HIGH PRIORITY!</i></u></b> <b>Libreboot needs to be factory firmware, not the replacement. It needs to be *the* firmware.
							Consult with the openlunchbox project (and maybe others) on getting hardware manufactured
							with libreboot support (out of the box, from the factory).</b>
						</li>
						<li>
							PROPOSAL (only a proposal, for now):
							Look into the possibility of expanding libreboot to support non-coreboot systems. (u-boot, for instance). 
							Currently, libreboot presents itself as a deblobbed coreboot distribution. There are other systems out there
							that use other firmware, such as u-boot, which libreboot could theoretically support. This would mean that
							the build scripts know how to build things other than just coreboot/grub.
							<ul>
								<li>Allwinner A10 (ARM) SoCs</li>
								<li>PMON?</li>
								<li>barebox (u-boot derivative)</li>
								<li>etc</li>
								<li>
									<a href="http://zedboard.org/product/zedboard">http://zedboard.org/product/zedboard</a>
									might be a candidate, according to the main developer of openlunchbox.
								</li>
							</ul>
						</li>
						<li>
							Set up a routine (project-wise) for testing each system with the latest kernel version.
							See <a href="http://projects.mtjm.eu/work_packages/22">http://projects.mtjm.eu/work_packages/22</a>
							and <a href="http://projects.mtjm.eu/work_packages/21">http://projects.mtjm.eu/work_packages/21</a>
						</li>
					</ul>
					
				<h3>EC firmware</h3>
					<p>
						<a href="http://www.coreboot.org/Embedded_controller">http://www.coreboot.org/Embedded_controller</a>
						Replace this on all libreboot targets. Some laptops use an extra SPI flash chip for the EC, some
						have EC in the main chip, some don't use SPI flash at all but have the firmware inside the EC chip itself.
						If the EC has integrated flash then you need to be able to get to the pins on the chip or be able to program them over LPC or SPI (if they have that feature).
						The lenovo laptops currently supported in libreboot all use H8 EC chips (contains flash inside the chip).
						Read the datasheets on how to externally programme the EC. Chromebooks seem to have free EC
						(<a href="https://chromium.googlesource.com/chromiumos/platform/ec/+/master/chip/">https://chromium.googlesource.com/chromiumos/platform/ec/+/master/chip/</a>).
					</p>
					
		</div>

		<p><a href="#pagetop">Back to top of page.</a></p>
		
	</div>

	<div class="section">

		<p>
			Copyright &copy; 2014, 2015 Francis Rowe &lt;info@gluglug.org.uk&gt;<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>
		
	</div>

</body>
</html>