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
|
<!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 $35,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.
</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>
HP Pavillion 1035DX (same chipset as G505S. See notes above)
</li>
<li>
BioStar AM1ML - just recently ported to coreboot. blob situation unknown.
</li>
<li>
Thinkpad E135 and Thinkpad E145 - port to coreboot. Apparently, the CPU used is based on the E350 (zacate)
CPU used is the ASrock E350M1 which is in coreboot, and already a libreboot candidate.
Blob situation is unknown, though it will probably rely on AGESA if ported and will probably need SMU firmware
or Video BIOS (which must be replaced). It is unknown what other blobs may exist when ported, and whether
or not this system will work reliably without the CPU microcode updates.
<ul>
<li>Difficulty: unknown</li>
</ul>
</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 (this isn't done yet)
- NOTE: This uses the PM45 chipset, but it might be compatible with the existing coreboot src for GM45.
<ul>
<li>Compaq Presario CQ60 - same comment</li>
</ul>
</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>
<li>
add roda rk9 support (contact nico to ask for more details about hw).
This is GM45 but these machines do not have a descriptor (no ME), should be easy
<ul>
<li>This board lacks native graphics initialization (it should be easy to add in Kconfig files,
but it has to be tested beforehand)</li>
</ul>
</li>
<li>
T400S and X301. These both seem to be GS45. X301 uses only the low-performance mode CPUs, so raminit
is the main blocker there. They both probably use WSON-8 flash chips.
</li>
<li>
Add proper GS45 raminit for enabling all X200S and X200 Tablets to work properly. (maybe other machines)
See <a href="hcl/x200.html#x200s_raminit">hcl/x200.html#x200s_raminit</a>
</li>
<li>
ThinkPad X201 - ME ignition is an issue. 30min reset watchdog for ME is an issue. Might be possible to disable watchdog in the flash descriptor
(soft straps) - sgsit in the libreboot or coreboot IRC channel is interested in this.
</li>
<li>
T410S is supported but not yet merged. This uses the same chipset as the X201.
<a href="http://review.coreboot.org/#/c/7975/">http://review.coreboot.org/#/c/7975/</a>
has the patch. This should be tested by someone and should ideally be merged in coreboot. pecg has one. help him.
</li>
<li>
This page contains a list of basically every thinkpad that would ever be a candidate for libreboot:
<a href="http://psref.lenovo.com/WithdrawnBook">http://psref.lenovo.com/WithdrawnBook</a> -
take a look at <a href="http://www.lenovo.com/psref/pdf/ltwbook_2013.pdf">this PDF</a>.
</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>
Sound (internal speaker) worked on the T500, but stopped after all subsequent boots.
(might just be this machine). investigate. (external speaker works)
</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>
<li>
On the X60, linux-libre 3.13.0-49 used from the Trisquel repositories, installed barebones (just TTY),
the backlight would be on but screen would be blank at login. Connecting a VGA cable to an external
monitor worked; also, the output on LVDS started working. Investigate. (does this happen on other
distros, or on other kernel versions?)
</li>
</ul>
</li>
<li>
X200: when undocking, the beep persists and never stops. Beep beep beep. Fix it (EC-related. fix should be done in coreboot and
added to libreboot afterwards) - might also affect T400/T500/R400/R500
<ul>
<li>On another X200, this did not occur. It might be that old versions of the EC have this bug</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>
<b><u><i>HIGH PRIORITY!</i></u></b> <b>i945: Linux 3.19 doesn't boot.
<b>UPDATE: Patch to fix it is on linux bug tracker (see below), we are waiting
for it to merge in linux upstream/mainline. For now, we are getting
this patch into the GNU/Linux distros typically used with libreboot.</b>
(also affects T60/macbook21).
<a href="https://bugzilla.kernel.org/show_bug.cgi?id=93171">Preliminary bug report (kernel, linux)</a>
pstuge said <a href="http://biosbits.org/">http://biosbits.org/</a>
patricg says https://wiki.ubuntu.com/HardwareEnablementTeam/Documentation/FirmwareTestSuiteLive</b>
<ul>
<li>It's commit aaecdf61 (drm/i915: Stop gathering error states for CS error interrupts)
in linux that introduced the regression</li>
<li>
This patch linked on the bug report page above:
<a href="https://bugzilla.kernel.org/attachment.cgi?id=172941">https://bugzilla.kernel.org/attachment.cgi?id=172941</a>
- fixes the problem, and makes the i945 laptops boot up again.
<ul>
<li>
Parabola has temporarily merged it in a kernel update
- when it's merged upstream, let Emulatorman know (#parabola on IRC freenode)
</li>
<li>
So has Guix
- when it's merged upstream, let mark_weaver know (#guix on IRC freenode)
</li>
<li>
So has freesh (for Trisquel)
- when it's merged upstream, let jxself and lxo know (#linux-libre on IRC freeode)
</li>
</ul>
</li>
<li>
Since 3.19, there are still some warning messages now, after applying the patch.
See Mono's comments on the bug report page
- <a href="https://bugzilla.kernel.org/show_bug.cgi?id=93171#c27">https://bugzilla.kernel.org/show_bug.cgi?id=93171#c27</a>
<ul>
<li>
<a href="https://bugzilla.kernel.org/show_bug.cgi?id=93171#c29">https://bugzilla.kernel.org/show_bug.cgi?id=93171#c29</a>
<a href="https://bugzilla.kernel.org/show_bug.cgi?id=93171#c30">https://bugzilla.kernel.org/show_bug.cgi?id=93171#c30</a>
- it seems that these warnings have been fixed, and will soon land in upstream.
</li>
</ul>
</li>
<li>
TODO: this fix in linux is a workaround, the real bug is in coreboot. (without the patch,
3.19/higher doesn't boot on coreboot/libreboot i945 with native graphics, but does boot
on lenovobios with 3.19/higher - it probably also boots with coreboot+vgarom, since
the bug is in the video init code.
</li>
</ul>
</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 machines (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>Payloads</h3>
<ul>
<li>
Add ProteanOS payload to machines 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>
<li>
Related to MemTest86+:
<ul>
<li>
Todo: modify memtest86+ to work with libpayload (coreboot framebuffer) and delete all the text-mode ROM images.
See <a href="http://projects.mtjm.eu/work_packages/17">http://projects.mtjm.eu/work_packages/17</a>
</li>
</ul>
</li>
</ul>
<h3>Build system</h3>
<ul>
<li>
PaulePanter reported in #coreboot that cbfstool currently fails to build on 32-bit x86 hosts.
This patch is supposed to fix it:
<a href="http://review.coreboot.org/#/c/9995/">http://review.coreboot.org/#/c/9995/</a>
</li>
<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>
<b><u><i>HIGH PRIORITY</i></u></b> GRUB does not display any text at all when using EHCI debug. Investigate.
<ul>
<li>It has to do with the dongle used. Use the default one in menuconfig, not BBB.</li>
<li>
<b><u><i>HIGH PRIORITY</i></u></b> Confirm that the EHCI debug options enabled in coreboot menuconfig are correct
for the current versions of the BBB (rev. C or higher). Search <b>EHCI debug</b> on
<a href="install/bbb_setup.html">install/bbb_setup.html</a>
</li>
</ul>
</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>
<li>
Reduce the size of libreboot releases.
See <a href="http://projects.mtjm.eu/work_packages/19">http://projects.mtjm.eu/work_packages/19</a>
<ul>
<li>
Proposal: unify ROM images (don't duplicate).
See <a href="http://projects.mtjm.eu/work_packages/20">http://projects.mtjm.eu/work_packages/20</a>.
</li>
</ul>
</li>
<li>Make GRUB build using coreboot's own crossgcc toolchain</li>
<li>
Delete all parts of coreboot that libreboot doesn't use.
For instance, delete boards that aren't used in libreboot.
This will reduce the size of the source tarballs considerably.
</li>
</ul>
<h3>Improvements to the utilities</h3>
<ul>
<li>
Stop deleting flash chip definitions in flashrom. Instead, modify flashrom to accept a list
of known flash chips, provided by a text file or naming them on the argument (eg --flashchips "chip 1" "chip 2"),
where flashrom would ignore any detected flash chips that are not on the list. Make
the flashing scripts use it, by default.
</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>
<li>
Improve the deblobbing scripts (see <a href="http://projects.mtjm.eu/work_packages/40">http://projects.mtjm.eu/work_packages/40</a>)
<ul>
<li>
.spd.hex files. These aren't blobs? Don't remove them? (in coreboot). See deblob script.
Categorize blobs and non-blobs more clearly, explaining what they are for
and why they are (or are not) blobs.
</li>
</ul>
</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 -
" The WP# and HOLD# pins should be tied to VCC! If you leave them unconnected you'll likely experience strange issues."
</li>
<li>
<pehjota> stefanct: We've never had any "strange issues" 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>
<pehjota> 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/>
<pehjota> 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/>
<pehjota> fchmmr: These pins do nothing if they're held high. The "#" (not) means they cause different behavior when held low.
</li>
<li>
<stefanct> 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>
<stefanct> yes...
<stefanct> a small note noting that would be appreciated because there are enough people out there already that ignore those pins and get stuck
>pehjota> 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?
<Kamilion> How about a more useful note that explains the whole discussion you two had succinctly?
<Kamilion> Not everyone is going to be an EE to know about the # indicating the pin should be pulled low to be active.
<Kamilion> reminds me, I need to pull out my pomona and try to fix some intel NIC roms
<stefanct> 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>
Add cubieboard SPI flashing instructions to libreboot.
<a href="https://github.com/mrnuke/coreboot/commits/cubie_mmc?author=mrnuke">mrnuke's github page with patches</a>. mrnuke in IRC knows
about the cubieboard
</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>
<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>
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 machine 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 © 2014, 2015 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>
</div>
</body>
</html>
|
