aboutsummaryrefslogtreecommitdiff
path: root/docs/tasks.html
blob: 0659f359bdd5014d7d3754ffe632e3cd722d4b68 (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
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
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
<!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" id="pagetop">
		<h1>Libreboot task list</h1>
			<p>
				Back to <a href="index.html">index.html</a>.
			</p>
	</div>

	<div class="section">
		<h1 id="tasks">
			Important tasks for the libreboot project
		</h1>
			<p>
				This page is part of the git repository, so feel free to submit patches
				adding to or removing from this list. (adapting the HTML should be simple enough)
			</p>
	</div>

	<div class="section">

		<h1 id="specialnews">Special news that affects libreboot</h1>
			<ul>
				<li>
					Coreboot (upstream) is adopting a new release model. See 
					<a href="http://www.coreboot.org/pipermail/coreboot/2015-July/080120.html">http://www.coreboot.org/pipermail/coreboot/2015-July/080120.html</a>
					- TODO: think about how this affects libreboot, and see what can be done to make effective use of this policy change.
				</li>
			</ul>

		<h1 id="board_ports">Board ports</h1>
			<ul>
				<li>
					Someone linked to
					<a href="https://www.phoronix.com/scan.php?page=news_item&px=XGI-Coreboot-FB-Port">this news post</a>
					about a PCI-E graphics card for which a free VBIOS replacement exists. This card uses the same
					chipset as the onboard GPU in the ASUS KFSN4-DRE mainboard, which is already supported in libreboot.
					This graphics card will allow certain desktop motherboards to be viable in libreboot.
				</li>
				<li>
					<a href="https://lkml.org/lkml/2014/9/4/172">patch for linux (kernel) to add coreboot framebuffer support</a>
				</li>
				<li>
					Libreboot has so far been biased towards Intel. This needs to end (the sooner, the better). A nice start:
					<ul>
						<li>
							<b>ASUS KGPE-D16</b>: this is a very modern board. It has support for both Fam10h and Fam15h AMD CPUs. The board is still
							new, and still in production. See
							these coreboot mailing list posts:<br/>
							<a href="http://www.coreboot.org/pipermail/coreboot/2015-April/079773.html">post 1</a> and
							<a href="http://www.coreboot.org/pipermail/coreboot/2015-April/079773.html">post 2</a><br/><br/>
							
							The board is fully functional (blobs not required), and will be an instant addition to libreboot.
							See <a href="https://raptorengineeringinc.com/coreboot/kgpe-d16-status.php">https://raptorengineeringinc.com/coreboot/kgpe-d16-status.php</a><br/><br/>
							
							<a href="http://raptorengineeringinc.com/content/base/main.htm">Raptor Engineering Inc</a> (USA) has ported
							this board to coreboot, and is using the port internally on their computing cluster, for
							the research that they do. This is the same company that ported 
							the <a href="hcl/kfsn4-dre.html">ASUS KFSN4-DRE</a> which is supported in libreboot.
							The owner (and the
							person who ported the board to coreboot), Timothy Pearson (tpearson on freenode IRC) has reached out to the community,
							in request for funding. This funding will pay for the many months of work (at least 4-5 months, for over 10000 
							lines of code any many patches that will need to be split up) to get the code
							upstreamed into coreboot. This is not as simple as just releasing the code; coreboot has a very strict code
							review process (in place to ensure quality control). The patches will have to be split up, with people's
							concerns and comments addressed over a long period, with patches constantly rebased to keep up with the
							latest coreboot master branch. In order to get this done in a decent enough time frame, Raptor Engineering will need
							to work on a more-or-less full-time basis.:
						</li>
						<li>
							Francis Rowe (lead developer of libreboot) is paying for this privately, and will have it
							ready in libreboot as soon as possible.
						</li>
						<li>
							Although Raptor will be working for many months to get this upstreamed (merged in coreboot's master branch
							in the git repository), libreboot will merge it more or less instantly, probably in the same week that the
							code is released for review. Raptor would also of course be rebasing the patches on a regular basis, as part
							of the review process, so even if it takes longer for the patches to be merged in coreboot, libreboot would have
							support for this board.<br/><br/>
							
							This is a <b>very</b> high-end board, making for a powerful server or workstation (desktop) system
							that should easily be more than powerful enough for almost everyone. Timothy has replaced the AGESA
							source in coreboot with native initialization code for AMD. The work that he has done can easily be
							extended to support more hardware, so getting this code out and upstreamed is very important.<br/><br/>
							<ul>
								<li>
									TYAN S8230 is very similar, and could probably be ported based on the KGPE-D16. Same GPU too.
									<a href="http://tyan.com/product_SKU_spec.aspx?ProductType=MB&pid=665&SKU=600000194">http://tyan.com/product_SKU_spec.aspx?ProductType=MB&amp;pid=665&amp;SKU=600000194</a>
									<ul>
										<li>
											W83627 (SuperIO) might have a public datasheet.
											Board-specific wiring (PCI interrupts, DIMM voltage selection). etc.
											Board seems to use socketed SOIC-8 SPI flash according to tpearson, based on photos available online - looks like a ZIF socket or something else, a clip retaining the chip.
										</li>
										<li>
											tpearson says: Tyan seems to have done the same thing as Asus did and built a whole lot of custom power control circuitry out of FETs.
											According to him, this will take much effort to reverse engineer.
										</li>
										<li>
											IPMI firmware is non-free but optional (for iKVM feature, remote management like Intel ME).  Not sure if add-on module or baked in.
											In either case, it might be removed or otherwise excluded because it's a HUGE backdoor. Unlike Intel ME, this isn't signed so can be
											removed, and also replaced theoretically. Is the protocol standard public? If so, might be easy/feasible to replace with free code.
											<a href="https://github.com/facebook/openbmc">https://github.com/facebook/openbmc</a> - also linked from
											<a href="https://raptorengineeringinc.com/coreboot/kgpe-d16-status.php">https://raptorengineeringinc.com/coreboot/kgpe-d16-status.php</a>
											- might be possible adapt this.
											- You
											 might need to use the vendor tools running from under the proprietary BIOS to wipe the Flash chip holding the IPMI firmware,
											 if it's baked in. (on KGPE-D16, it's an <a href="http://www.servethehome.com/wp-content/uploads/2013/03/ASUS-ASMB6-iKVM-Module.png">add-on card</a> so just don't add the add-on card - also SOIC-16 according to tpearson. but not sure what form factor used on S8230 - it better not be bl***y WSON).
										</li>
										<li>
											SAS controller requires firmware, but optional. (same thing on KGPE-D16). Board also has SATA, so it's fine.
											NOTE: SAS firmware is already flashed onto the SAS controller, to a dedicated chip. Not uploaded/handled by coreboot or linux kernel.
										</li>
										<li>
											tpearson says: power control circuits are a potential issue, not a definite one. it all depends on how Tyan decided to wire things up
											if they engineered things properly, it should actually be transparent.
											ASUS did not, and required work to get it going (see the notes document)
										</li>
									</ul>
								</li>
							</ul>
						</li>
						<li>
							Lenovo G505S (works without CPU microcode updates).
							Videos BIOS is not yet fully replaced (openatom doesn't have a working framebuffer, yet, but
							it can draw a bitmap in user space, using a special utility) - 
							<a href="https://github.com/alterapraxisptyltd/openatom">openatom in github</a>.
							SMU needs replacing (ruik/funfuctor/patrickg/mrnuke might be able to help).
						</li>
						<li>
							F2A85-M and E350M1 (libreboot_*_headless.rom). Test openatom (video BIOS replacement). SMU firmware is a problem. XHCI firmware is a problem.
						</li>
						<li>
							<ul>
								<li>Look into the <i>rockchip</i> (rk3288. note: mali gpu. one or two blobs might need replacing.
								see <a href="http://blogs.coreboot.org/blog/2015/05/26/report-on-chrome-os-upstreaming/">this page</a>
								for example) and <i>IBM 'POWER8' platforms</i> - NOTE: ARM systems use the <i>depthcharge</i> payload
								which afaik is free-sw. For GRUB, see <a href="https://wiki.linaro.org/LEG/Engineering/Grub2">https://wiki.linaro.org/LEG/Engineering/Grub2</a></li>
								<li>
									asus chromebook c201. paulk is working on it. See libreboot mailing list post
									<a href="https://lists.nongnu.org/archive/html/libreboot/2015-08/msg00009.html">https://lists.nongnu.org/archive/html/libreboot/2015-08/msg00009.html</a> for
									details<br/>
									<a href="http://review.coreboot.org/#/c/11112/">http://review.coreboot.org/#/c/11112/</a>(merged)<br/>
									<a href="http://review.coreboot.org/#/c/11113/">http://review.coreboot.org/#/c/11113/</a><br/>
									<a href="http://review.coreboot.org/#/c/11114/">http://review.coreboot.org/#/c/11114/</a><br/>
									<a href="http://review.coreboot.org/#/c/11116/">http://review.coreboot.org/#/c/11116/</a><br/>
									<a href="http://review.coreboot.org/#/c/11115/">http://review.coreboot.org/#/c/11115/</a>(merged)<br/>
									<a href="http://review.coreboot.org/#/c/11117/">http://review.coreboot.org/#/c/11117/</a><br/>
									<a href="http://review.coreboot.org/#/c/11119/">http://review.coreboot.org/#/c/11119/</a><br/>
									<a href="http://review.coreboot.org/#/c/11118/">http://review.coreboot.org/#/c/11118/</a>(merged)<br/>
									<a href="http://git.code.paulk.fr/gitweb/?p=depthcharge.git;a=shortlog;h=refs/heads/next">http://git.code.paulk.fr/gitweb/?p=depthcharge.git;a=shortlog;h=refs/heads/next</a><br/>
									<a href="http://git.code.paulk.fr/gitweb/?p=depthcharge.git;a=commit;h=5ca76d1cb8fda74c93a6c65dab8a776d72e1f61a">http://git.code.paulk.fr/gitweb/?p=depthcharge.git;a=commit;h=5ca76d1cb8fda74c93a6c65dab8a776d72e1f61a</a><br/>
									<a href="http://git.code.paulk.fr/gitweb/?p=depthcharge.git;a=commit;h=01c61f3c0ca96d49c2d33e0bf93e1d4779664011">http://git.code.paulk.fr/gitweb/?p=depthcharge.git;a=commit;h=01c61f3c0ca96d49c2d33e0bf93e1d4779664011</a><br/>
									<a href="http://git.paulk.fr/gitweb/?p=embedded-freedom-scripts.git;a=summary">http://git.paulk.fr/gitweb/?p=embedded-freedom-scripts.git;a=summary</a>
									<a href="http://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery">http://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery</a><br/>
									<a href="http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot">http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot</a><br/>
									<a href="http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-crypto">http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-crypto</a>
								</li>
								<li>There may be others</li>
							</ul>
						</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>
							Intel D510MO motherboard (desktop), pineview chipset. damo22 got raminit working, and is working on finishing the port for coreboot.
							southbridge NM10 (basically rebranded ich7).
							not sure about video init (does it have native graphics initialization?). TODO: review it for libreboot once damo22 pushes
							the code to coreboot for review. damo22 says it should work with several CPUs (Atom D510 D525 N5x etc - but he's unsure). 
							TODO: find other boards similar that could be ported. damo22's one has an Intel Atom D510 CPU.
						</li>
						<li>
							ThinkPad W500: they all use switchable graphics (ATI+Intel). Unknown if PM45 is compatible with GM45.
						</li>
						<li>
							ThinkPad X61: ICH8, i965
							lubko in #coreboot. <a href="https://github.com/lkundrak/coreboot/tree/x61">https://github.com/lkundrak/coreboot/tree/x61</a>
							- raminit still isn't done, there might be other parts that need to be finished (probably EC).
							This system comes with a ME, but it's optional like in GM45, and can be removed.
							<ul>
								<li>T61: <a href="http://review.coreboot.org/#/c/8482/">http://review.coreboot.org/#/c/8482/</a></li>
							</ul>
						</li>
						<li>
							ThinkPad R60, Z61 - probably very similar to X60/T60, with few modifications required
							(probably only the changes based on logs acquired by following
							<a href="http://www.coreboot.org/Motherboard_Porting_Guide">http://www.coreboot.org/Motherboard_Porting_Guide</a>)
						</li>
						<li>
							Non-lenovo GM45 laptops:
							<ul>
								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>
						<li>
							<b>Desktop</b> system: Dell Optiplex 755. There are <b>lots</b> of these available online.
							ICH9. DDR2 RAM (needs work in coreboot). No EC (it's a desktop). It will require
							quite a bit of work in coreboot, but this is a very good candidate.
							The ME can probably be removed and disabled, using ich9gen without any modifications
							(or with few modifications). Where are the datasheets? Schematics?
						</li>
					</ul>
				</li>
			</ul>
			<p><a href="#pagetop">Back to top of page.</a></p>
	</div>
	
	<div class="section">
		<h1>Platform-specific bugs</h1>
			<ul>
				<li>
					Several serious bugs exist on the ThinkPad R500, which makes
					the system virtually unusable. See <a href="hcl/r500/index.html#issues">hcl/r500/index.html#issues</a>.
				</li>
				<li>
					GM45: investigate S3/raminit on all models (CPU stepping/cpuid).
					See <a href="hcl/x200.html#ram_s3_microcode">hcl/x200.html#ram_s3_microcode</a>

				</li>
				<li>
					all thinkpads: When the system is running, plugging in an ethernet cable
					doesn't always work (no network), you have to try several times. Booting with
					an ethernet cable attached is reliable. Debug this and fix it.
				</li>
				<li>
					KFSN4-DRE: investigate the 30 second bootblock delay.
					<a href="hcl/kfsn4-dre.html#issues">More info</a>
				</li>
				<li>
					KFSN4-DRE: jittery text-mode graphics.
					<a href="hcl/kfsn4-dre.html#issues">More info</a>
				</li>
				<li>
					Fix these issues on GM45/GS45 targets:
					<ul>
						<li>
							X200: text-mode is broken. only framebuffer graphics work.
							880101121e0cef5df3afda075809e2fbacf68ffe is the commit in coreboot that added native graphics initialization
							for GM45. The commit message says that text mode should work. tpearson tested with this revision, and it didn't
							work in text mode, so it looks like text mode never worked at all. It could be that it did work before phcoder
							submitted it, but then he made more changes that broke text mode, and didn't realize this. This means that a bisect
							is not possible.
						</li>
						<li>
							X60: on the latest coreboot-libre update lately (during June 2015), keyboard works intermittently.
							Bisect and fix.
						</li>
						<li>
							X200/X60: battery drained even while system is "off" on some systems. investigate.
							Could just be the Ethernet controller waiting for a Wake-on-LAN frame.
							'ethtool -s net0 wol d' disables wake on lan until the next boot. There are a lot of ways to make it permanent: netctl. systemd, udev, cron
							- wake on lan was tested, and isn't the issue. It is probably how coreboot handles power off state
							(see the code that handles power_on_after_fail)
						</li>
						<li>
							Sound (internal speaker) broken on T500 (works in lenovobios). external speaker/headphones work.
							- probably a different hda_verb
							- <b>different HDA verbs are now used, test this again</b>
							- worked while system was disassambled, but booted (loose), stopped working when re-assembling. Not sure what's going on here.
						</li>
						<li>
							Fix remaining incompatible LCD panels in native graphics on T500 and T400. 
							See <a href="hcl/gm45_lcd.html">hcl/gm45_lcd.html</a>.
							- EDID related, or difference in how VGA ROM does init. Investigate.
						</li>
						<li>
							T400/T500/R400 (tested on T400): UART (serial port) doesn't work. Investigate.
							(already tried enabling early h8 dock option. some RE with superiotool is needed).
							- kmalkki has an R400. He says he can be contracted for it. (try to DIY first)
						</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>
							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>.
							- EDID related, or difference in how VGA ROM does init. Investigate.
						</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>
				<li>
					Look into the notes an <a href="http://www.thinkwiki.org/wiki/Problem_with_high_pitch_noises">http://www.thinkwiki.org/wiki/Problem_with_high_pitch_noises</a>
				</li>
			</ul>
			<p><a href="#pagetop">Back to top of page.</a></p>
	</div>
	
	<div class="section">
		<h1>
			Flashing from lenovobios to libreboot (and vice versa)
		</h1>
			<ul>
				<li>
					mtjm says: francis7: please add this issue to your current tasks list (inspired by what GNUtoo-irssi wrote): have the script for flashing from Lenovo BIOS verify that the image is swapped (i.e. last 64 KiB is just 0xff bytes, second to last 64 KiB isn't) and fail before writing to flash if it isn't
				</li>
				<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>
			<p><a href="#pagetop">Back to top of page.</a></p>
	</div>

	<div class="section">
		<h1>Payloads</h1>
			<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>
			<p><a href="#pagetop">Back to top of page.</a></p>
	</div>

	<div class="section">
		<h1>Build system</h1>
			<ul>
				<li>Patch the coreboot build system, so that version information is still reliably generated
				(e.g. in the logs), which is currently lacking because libreboot deletes the .git directory
				(because the git history contains the deleted blobs, so libreboot has to delete it). It could
				just be a small patch that hardcodes the coreboot version information, for that coreboot version,
				each time libreboot rebases on a new version of coreboot.<br/><br/>
				patrickg says: francis7: we have you covered: have your libreboot script add a file ".coreboot-version" to the top-level directory, containing the appropriate version number information. that will be used if git describe doesn't work (eg. because .git is missing)
				</li>
				<li>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</li>
				<li>
					Make libreboot (all of it!) build reproducibly. This is very important.
					<ul>
						<li>Talk to h01ger in coreboot about the coreboot part (he did reproducible.debian.net/coreboot/coreboot.html</li>
						<li>
							h01ger says ------ fchmmr: please keep the reproducible-builds@lists.alioth.debian.org mailing list posted - i'm aware of http://projects.mtjm.eu/work_packages/16 :-)
						</li>
						<li><a href="https://reproducible.debian.net/coreboot/coreboot.html">https://reproducible.debian.net/coreboot/coreboot.html</a></li>
						<li>
							check coreboot mailing list, eg:
							<a href="http://www.coreboot.org/pipermail/coreboot/2015-June/079994.html">http://www.coreboot.org/pipermail/coreboot/2015-June/079994.html</a>
						</li>
						<li>
							Check GRUB in Debian (or GRUB upstream) for how to make that reproducible
							if Debian has done this already (they are working on reproducible builds)
							- <b>h01ger says reproducible.debian.net/grub2</b>
						</li>
						<li>
							<a href="https://wiki.debian.org/ReproducibleBuilds">https://wiki.debian.org/ReproducibleBuilds</a>
						</li>
						<li>
							Join #debian-reproducible on OFTC IRC.
						</li>
						<li>
							merged in master (coreboot) - pay attention to these, especially
							the fact that the reproducibility relies on git (libreboot uses coreboot without git,
							and the reason makes this unavoidable):
							<a href="http://review.coreboot.org/#/c/8616/">http://review.coreboot.org/#/c/8616/</a>
							<a href="http://review.coreboot.org/#/c/8617/">http://review.coreboot.org/#/c/8617/</a>
							<a href="http://review.coreboot.org/#/c/8618/">http://review.coreboot.org/#/c/8618/</a>
							<a href="http://review.coreboot.org/#/c/8619/">http://review.coreboot.org/#/c/8619/</a>
						</li>
						<li>
							not yet merged in master (coreboot:
							<a href="http://review.coreboot.org/#/c/10515/">http://review.coreboot.org/#/c/10515/</a> -- 
							not really relevant yet, but will be in the future. (libreboot currently ignores SeaBIOS)
						</li>
					</ul>
				</li>
			</ul>
			<p><a href="#pagetop">Back to top of page.</a></p>
	</div>

	<div class="section">
		<h1>Improvements to the utilities</h1>
			<ul>
				<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.
				</li>
				<li>
					Make ich9gen/ich9deblob/demefactory show GPL license info via <i>--version</i> argument.
				</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>
			</ul>
			<p><a href="#pagetop">Back to top of page.</a></p>
	</div>

	<div class="section">
		<h1>
			BeagleBone Black
		</h1>
			<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>
			<p><a href="#pagetop">Back to top of page.</a></p>
	</div>

	<div class="section">
		<h1>Documentation improvements</h1>
			<ul>
				<li>
					Next release after 20150518, relating to the ASUS KFSN4-DRE:
					<ul>
						<li>Remove the notes in docs/release.html that say <i>NOTE: not in libreboot 20150518. Only in git, for now.</i></li>
						<li>Remove the note in docs/hcl/kfsn4-dre.html that says <i> NOTE: This board is unsupported in libreboot 20150518. To use it in libreboot, for now, you must build for it from source using the libreboot git repository. </i></li>
						<li>Remove the note in docs/hcl/r500.html that says <i> NOTE: This board is unsupported in libreboot 20150518. To use it in libreboot, for now, you must build for it from source using the libreboot git repository. </i></li>
					</ul>
				</li>
				<li>
					Next release after 20150518: note, mention that ACPI brightness methods for X60/T60 work again.
				</li>
				<li>
					Get /proc/ioports for all hw logs. (this was added to Motherboard Porting Guide recently)
					- other instructions were also added there. basically, get whatever extra logs are
					desirable, for all systems.
				</li>
				<li>
					Add info about FTDI 	FT232H usbdebug (BBB could be used for this):
					<a href="http://review.coreboot.org/#/c/10063">http://review.coreboot.org/#/c/10063</a>
				</li>
				<li>
					Add information from hw registers on all boards.
					Get them for the following remaining boards: X60, T60, macbook21, R400
				</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 use Latex (or whatever the GNU project requires) as source.
				</li>
				<li>
					LPC (eg PLCC socket) 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>
			<p><a href="#pagetop">Back to top of page.</a></p>
	</div>

	<div class="section">
		<h1>Project (institutional) improvements</h1>
			<ul>
				<li>
					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>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>
					- rhombus tech might be interesting to contact (also projects like novena, and so on).
					eg <a href="http://rhombus-tech.net/community_ideas/laptop_15in/news/">http://rhombus-tech.net/community_ideas/laptop_15in/news/</a>
					- also see <a href="http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68">http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68</a>
				</li>
				<li>
					Set up a routine (project-wise) for testing each system with the latest kernel version.
				</li>
				<li>
					Define properly how to maintain libreboot (things to look out for, things to do on a release). It's somewhat
					documented now, but it's not perfect. Delegate tasks (to people that are reliable).
				</li>
			</ul>
			<p><a href="#pagetop">Back to top of page.</a></p>
	</div>

	<div class="section">
		<h1>EC firmware</h1>
			<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 flash 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>).
				- see
				<a href="http://blogs.coreboot.org/blog/2015/05/28/progress-gsoc-week-1/">http://blogs.coreboot.org/blog/2015/05/28/progress-gsoc-week-1/</a> (H8S EC, applies to thinkpads)
			</p>
			<p>
				<a href="https://github.com/lynxis/h8s-ec">https://github.com/lynxis/h8s-ec</a>
				<a href="https://events.ccc.de/congress/2010/Fahrplan/events/4174.en.html">https://events.ccc.de/congress/2010/Fahrplan/events/4174.en.html</a>
			</p>
			<p>
				<a href="https://archive.org/details/27c3-4174-en-the_hidden_nemesis">https://archive.org/details/27c3-4174-en-the_hidden_nemesis</a>
			</p>
			
			<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/>
			Permission is granted to copy, distribute and/or modify this document
			under the terms of the GNU Free Documentation License, Version 1.3
			or any later version published by the Free Software Foundation;
			with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
			A copy of the license can be found at <a href="gfdl-1.3.txt">gfdl-1.3.txt</a>
		</p>

		<p>
			Updated versions of the license (when available) can be found at
			<a href="https://www.gnu.org/licenses/licenses.html">https://www.gnu.org/licenses/licenses.html</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>