coreboot January 2017

coreboot@coreboot.org

75 participants
186 discussions

Re: [coreboot] How does intelmetool's support for Skylake?
by Shawn 29 Jan '17

29 Jan '17

Sunrise Point-H & Sunrise Point-LP can be supported by intelmetool: https://github.com/zamaudio/intelmetool Tested it on Alienware 13R2 & P10S-M WS and it's working perfectly. On Thu, Jan 5, 2017 at 3:20 PM, Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> wrote: > Hello Shawn, > > Happy New Year to you too. I wish you and all Coreboot community to be > blessed by Health. :-) > > Needless to say, I found your changes there, but just yesterday evening. > > Here they are: > https://github.com/zamaudio/intelmetool/commit/052350ae131b34b95f55a56c35e3… > > I also fetched the latest coreboot few moments the same time, and checked: > these changes are not incorporated in the latest Coreboot: > 4.5-759-gab8f7d315e > > So, I'll ask kindly Damien to add these changes into Coreboot (there are a > bit more lines that you added there). > > Damien (Zammit), > > could you, please, update Coreboot intelmetool with the latest changes? > > I'll look (later) into two latest net links you have provided to me. :-) > > Thank you, > Zoran > > On Thu, Jan 5, 2017 at 7:22 AM, Shawn <citypw(a)gmail.com> wrote: >> >> Hi Zoran, >> >> Happy new year;-) >> >> intelmetool merged the patch, plz check: >> >> https://github.com/zamaudio/intelmetool >> >> If you're going to only neutralize the ME, you can use external >> programmer && try me_cleaner: >> >> https://github.com/corna/me_cleaner/ >> >> We've only tested a few coreboot supported mainboards on neutralizing >> ME( I'm afarid your hardware isn't on the list-_-): >> >> >> https://github.com/hardenedlinux/hardenedlinux_profiles/tree/master/coreboot >> >> On Wed, Jan 4, 2017 at 8:28 PM, Zoran Stojsavljevic >> <zoran.stojsavljevic(a)gmail.com> wrote: >> > Hello Shawn, >> > >> > I am late, I apologize... New Year, everything is slow, me either. >> > >> > For me, the link you have provided does not work?! it is HTTP 404 (page >> > not >> > found). Could you, please, repost the valid link? Or to attach the given >> > patch to this email? >> > >> > With the normal Coreboot intelmetool (where I added one more printk() to >> > explore what are the device ids the tool looks into), I have the >> > following: >> > >> > [root@localhost intelmetool]# uname -a >> > Linux localhost.localdomain 4.8.15-300.fc25.x86_64 #1 SMP Thu Dec 15 >> > 23:10:23 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux >> > [1]+ Done emacs intelmetool.h >> > [root@localhost intelmetool]# ./intelmetool -s >> > dev->vendor_id = 0x8086, dev->device_id = 0x9c22 >> > dev->vendor_id = 0x8086, dev->device_id = 0x9c03 >> > dev->vendor_id = 0x8086, dev->device_id = 0x9c43 >> > Bad news, you have a `8 Series LPC Controller` so you have ME hardware >> > on >> > board and you can't control or disable it, continuing... >> > >> > Error mapping physical memory 0x0000004275159040 [0x4000] ERRNO=1 >> > Segmentation fault (core dumped) >> > >> > [root@localhost intelmetool]# lspci -nn | grep 9c22 >> > 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller >> > [8086:9c22] (rev 04) >> > [root@localhost intelmetool]# lspci -nn | grep 9c03 >> > 00:1f.2 SATA controller [0106]: Intel Corporation 8 Series SATA >> > Controller 1 >> > [AHCI mode] [8086:9c03] (rev 04) >> > [root@localhost intelmetool]# lspci -nn | grep 9c43 >> > 00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller >> > [8086:9c43] (rev 04) >> > [root@localhost intelmetool]# >> > >> > Yet, in intelmetool.h it says explicitly: >> > >> > // Definitely has ME and is very difficult to remove >> > [snap] >> > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_FULL 0x9c41 >> > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_PREM 0x9c43 >> > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_BASE 0x9c45 >> > >> > Coreboot ME pros, any comment on my HW (i5-4300U HSW ULT + PCH >> > LynxPoint)? >> > Appreciate any help! >> > >> > Thank you, >> > Zoran >> > >> > On Fri, Dec 30, 2016 at 11:25 AM, Shawn <citypw(a)gmail.com> wrote: >> >> >> >> This is a work around patch( I think?): >> >> >> >> >> >> https://github.com/hardenedlinux/intelmetool/commit/ad778fc347b2bb0494abe21… >> >> >> >> ./intelmetool -s >> >> RCBA at 0x00000000 >> >> MEI not hidden on PCI, checking if visible >> >> MEI found: [8086:9d3a] Sunrise Point-LP CSME HECI >> >> >> >> ME Status : 0xa0000245 >> >> ME Status 2 : 0x86110306 >> >> >> >> ME: FW Partition Table : OK >> >> ME: Bringup Loader Failure : NO >> >> ME: Firmware Init Complete : YES >> >> ME: Manufacturing Mode : NO >> >> ME: Boot Options Present : NO >> >> ME: Update In Progress : NO >> >> ME: Current Working State : Normal >> >> ME: Current Operation State : M0 with UMA >> >> ME: Current Operation Mode : Normal >> >> ME: Error Code : No Error >> >> ME: Progress Phase : Clean Moff->Mx wake >> >> ME: Power Management Event : Pseudo-global reset >> >> ME: Progress Phase State : Unknown 0x11 >> >> >> >> PCI READ [bc] : 0x000000bc >> >> ME: Extend Register not valid >> >> >> >> ME seems okay on this board >> >> WRITE [00] : CB: 0x80040007 >> >> WRITE [00] : CB: 0x000002ff >> >> READ [08] : CB: 0x801c0007 >> >> READ [08] : CB: 0x000082ff >> >> READ [08] : CB: 0x000b0000 >> >> READ [08] : CB: 0x0000049c >> >> READ [08] : CB: 0x000b0000 >> >> READ [08] : CB: 0x0000049c >> >> READ [08] : CB: 0x000b0000 >> >> READ [08] : CB: 0x0000049c >> >> ME: Firmware Version 11.0.1180.0 (code) 11.0.1180.0 (recovery) >> >> 11.0.1180.0 (fitc) >> >> WRITE [00] : CB: 0x80080007 >> >> WRITE [00] : CB: 0x00000203 >> >> WRITE [00] : CB: 0x00000000 >> >> READ [08] : CB: 0x800d0007 >> >> READ [08] : CB: 0x00008203 >> >> READ [08] : CB: 0x00000000 >> >> READ [08] : CB: 0x111a4004 >> >> READ [08] : CB: 0x00000031 >> >> ME Capability: Full Network manageability : OFF >> >> ME Capability: Regular Network manageability : OFF >> >> ME Capability: Manageability : OFF >> >> ME Capability: Small business technology : OFF >> >> ME Capability: Level III manageability : OFF >> >> ME Capability: IntelR Anti-Theft (AT) : OFF >> >> ME Capability: IntelR Capability Licensing Service (CLS) : ON >> >> ME Capability: IntelR Power Sharing Technology (MPC) : OFF >> >> ME Capability: ICC Over Clocking : ON >> >> ME Capability: Protected Audio Video Path (PAVP) : ON >> >> ME Capability: IPV6 : OFF >> >> ME Capability: KVM Remote Control (KVM) : OFF >> >> ME Capability: Outbreak Containment Heuristic (OCH) : OFF >> >> ME Capability: Virtual LAN (VLAN) : ON >> >> ME Capability: TLS : OFF >> >> ME Capability: Wireless LAN (WLAN) : OFF >> >> exiting >> >> >> >> On Fri, Dec 30, 2016 at 11:04 AM, Shawn <citypw(a)gmail.com> wrote: >> >> > Hi Zoran, >> >> > >> >> > Thanks for the info. I added my Device ID into the intelmetool.h: >> >> > >> >> > diff --git a/intelmetool.h b/intelmetool.h >> >> > index d79d6b0..16ca43a 100644 >> >> > --- a/intelmetool.h >> >> > +++ b/intelmetool.h >> >> > @@ -225,6 +225,7 @@ >> >> > #define PCI_DEVICE_ID_INTEL_ICH9DO 0x2914 >> >> > #define PCI_DEVICE_ID_INTEL_ICH9R 0x2916 >> >> > #define PCI_DEVICE_ID_INTEL_ICH9 0x2918 >> >> > +#define PCI_DEVICE_ID_INTEL_SUNRISE 0x9d3a >> >> > >> >> > #define PCI_DEV_CAN_DISABLE_ME_IF_PRESENT(x) ( \ >> >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH8 ) || \ >> >> > @@ -232,6 +233,7 @@ >> >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9DH ) || \ >> >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9DO ) || \ >> >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9R ) || \ >> >> > + ( (x) == PCI_DEVICE_ID_INTEL_SUNRISE ) || \ >> >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9 )) >> >> > >> >> > // Not sure at all >> >> > >> >> > This one should be the ME? >> >> > +-16.0 Intel Corporation Sunrise Point-LP CSME HECI [8086:9d3a] >> >> > >> >> > #./intelmetool -s >> >> > Not sure if ME hardware is present because you have a `Sunrise >> >> > Point-LP CSME HECI`, but it is possible to disable it if you do, >> >> > continuing... >> >> > RCBA at 0x00000000 >> >> > MEI not hidden on PCI, checking if visible >> >> > MEI device not found, huh? >> >> > exiting >> >> > >> >> > >> >> > >> >> > On Thu, Dec 29, 2016 at 12:50 AM, Zoran Stojsavljevic >> >> > <zoran.stojsavljevic(a)gmail.com> wrote: >> >> >>>> I'm not sure if intelmetool support Skylake as well. >> >> >> >> >> >> Investigated more. The coreboot intelmetool is the latest one, as I >> >> >> understood (comparing one from github and coreboot). >> >> >> >> >> >> And Sunrise Point is NOT supported (look into latest coreboot's >> >> >> coreboot/util/intelmetool/intelmetool.h). You can try to add it (as >> >> >> Device >> >> >> ID), manually, peek around the C code, and see if this can help you. >> >> >> >> >> >> Zoran >> >> >> >> >> >> On Wed, Dec 28, 2016 at 5:26 PM, Zoran Stojsavljevic >> >> >> <zoran.stojsavljevic(a)gmail.com> wrote: >> >> >>> >> >> >>> Hello Shawn, >> >> >>> >> >> >>> Please, follow my CLI transcript from my Future Fedora 26 VM over >> >> >>> WIN10 >> >> >>> (now rawhide) with Fedora 4.8.15 kernel implanted (kernel >> >> >>> 4.10.0-rc0 >> >> >>> gives >> >> >>> me lot of griefs, I do not trust it, so I eliminated it for now): >> >> >>> >> >> >>> [zoran@localhost ~]$ cd projects/ >> >> >>> [zoran@localhost projects]$ mkdir intelmetool >> >> >>> [zoran@localhost projects]$ cd intelmetool/ >> >> >>> [zoran@localhost intelmetool]$ pwd >> >> >>> /home/zoran/projects/intelmetool >> >> >>> [zoran@localhost intelmetool]$ uname -r >> >> >>> 4.8.15-300.fc25.x86_64 >> >> >>> [zoran@localhost intelmetool]$ git clone >> >> >>> https://github.com/zamaudio/intelmetool.git >> >> >>> Cloning into 'intelmetool'... >> >> >>> remote: Counting objects: 214, done. >> >> >>> remote: Total 214 (delta 0), reused 0 (delta 0), pack-reused 214 >> >> >>> Receiving objects: 100% (214/214), 72.42 KiB | 0 bytes/s, done. >> >> >>> Resolving deltas: 100% (125/125), done. >> >> >>> [zoran@localhost intelmetool]$ ls -al >> >> >>> total 12 >> >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . >> >> >>> drwxrwxr-x. 10 zoran zoran 4096 Dec 28 17:05 .. >> >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 intelmetool >> >> >>> [zoran@localhost intelmetool]$ cd intelmetool/ >> >> >>> [zoran@localhost intelmetool]$ ls -al >> >> >>> total 100 >> >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . >> >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. >> >> >>> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git >> >> >>> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore >> >> >>> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c >> >> >>> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h >> >> >>> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE >> >> >>> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile >> >> >>> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c >> >> >>> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h >> >> >>> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c >> >> >>> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c >> >> >>> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h >> >> >>> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md >> >> >>> [zoran@localhost intelmetool]$ su -m >> >> >>> Password: >> >> >>> [root@localhost intelmetool]# make >> >> >>> gcc -Wall -O0 -g -I. -c me_status.c -o me_status.o >> >> >>> gcc -Wall -O0 -g -I. -c me.c -o me.o >> >> >>> me.c: In function ‘mei_dump’: >> >> >>> me.c:63:18: warning: variable ‘csr’ set but not used >> >> >>> [-Wunused-but-set-variable] >> >> >>> struct mei_csr *csr; >> >> >>> ^~~ >> >> >>> gcc -Wall -O0 -g -I. -c mmap.c -o mmap.o >> >> >>> mmap.c: In function ‘map_physical_exact’: >> >> >>> mmap.c:11:26: warning: passing argument 1 of ‘mmap’ makes pointer >> >> >>> from >> >> >>> integer without a cast [-Wint-conversion] >> >> >>> virt_addr = mmap(mapto, len, PROT_WRITE | PROT_READ, >> >> >>> MAP_SHARED|MAP_FIXED, >> >> >>> ^~~~~ >> >> >>> In file included from mmap.h:4:0, >> >> >>> from mmap.c:1: >> >> >>> /usr/include/sys/mman.h:57:14: note: expected ‘void *’ but argument >> >> >>> is >> >> >>> of >> >> >>> type ‘uint64_t {aka long unsigned int}’ >> >> >>> extern void *mmap (void *__addr, size_t __len, int __prot, >> >> >>> ^~~~ >> >> >>> gcc -Wall -O0 -g -I. -o intelmetool intelmetool.o me_status.o me.o >> >> >>> mmap.o >> >> >>> -lpci >> >> >>> [root@localhost intelmetool]# date >> >> >>> Wed Dec 28 17:07:26 CET 2016 >> >> >>> [root@localhost intelmetool]# ls -al >> >> >>> total 228 >> >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:07 . >> >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. >> >> >>> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git >> >> >>> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore >> >> >>> -rwxr-xr-x. 1 root root 47008 Dec 28 17:07 intelmetool >> >> >>> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c >> >> >>> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h >> >> >>> -rw-rw-r--. 1 zoran zoran 22144 Dec 28 17:06 intelmetool.o >> >> >>> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE >> >> >>> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile >> >> >>> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c >> >> >>> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h >> >> >>> -rw-r--r--. 1 root root 28984 Dec 28 17:07 me.o >> >> >>> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c >> >> >>> -rw-r--r--. 1 root root 15704 Dec 28 17:07 me_status.o >> >> >>> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c >> >> >>> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h >> >> >>> -rw-r--r--. 1 root root 7648 Dec 28 17:07 mmap.o >> >> >>> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md >> >> >>> [root@localhost intelmetool]# ./intelmetool >> >> >>> ME is not present on your board because we found a `82371AB/EB/MB >> >> >>> PIIX4 >> >> >>> ISA`, you are safe, exiting >> >> >>> [root@localhost intelmetool]# >> >> >>> _______ >> >> >>> >> >> >>> Do NOT forget: I run Fedora rawhide on VMWorkstation 12.5.2 Type 2 >> >> >>> HYP >> >> >>> on >> >> >>> the top of WIN10 64 Pro! >> >> >>> >> >> >>> Please, do the same on Mint18 distro on raw HW, and see if this >> >> >>> will >> >> >>> give >> >> >>> you some different results then what you have presently? >> >> >>> >> >> >>> Please, let us know! >> >> >>> >> >> >>> Zoran >> >> >>> >> >> >>> On Wed, Dec 28, 2016 at 11:06 AM, Shawn <citypw(a)gmail.com> wrote: >> >> >>>> >> >> >>>> Hi Zoran, >> >> >>>> >> >> >>>> I created hwdb.bin via: >> >> >>>> >> >> >>>> # udevadm hwdb --update >> >> >>>> >> >> >>>> The result is still "segfault". dmesg: >> >> >>>> >> >> >>>> [ 972.044664] intelmetool[5055]: segfault at 16 ip >> >> >>>> 000000000040169e >> >> >>>> sp 000072ed96a44680 error 4 in intelmetool[400000+6000] >> >> >>>> [ 972.044674] grsec: Segmentation fault occurred at >> >> >>>> 0000000000000016 >> >> >>>> in /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 >> >> >>>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 >> >> >>>> gid/egid:0/0 >> >> >>>> [ 972.044685] grsec: denied resource overstep by requesting 4096 >> >> >>>> for >> >> >>>> RLIMIT_CORE against limit 0 for >> >> >>>> /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 >> >> >>>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 >> >> >>>> gid/egid:0/0 >> >> >>>> >> >> >>>> >> >> >>>> On Mon, Dec 26, 2016 at 9:49 PM, Zoran Stojsavljevic >> >> >>>> <zoran.stojsavljevic(a)gmail.com> wrote: >> >> >>>> > Not sure if your strace log has anything to do with intelmetool. >> >> >>>> > >> >> >>>> > I did on your strace log the following (and in RED is possible >> >> >>>> > cause of >> >> >>>> > your >> >> >>>> > problems): >> >> >>>> > >> >> >>>> > [zoran@localhost projects]$ cat crash.log | grep ENOENT >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > open("/usr/share/misc/pci.ids.gz", O_RDONLY) = -1 ENOENT (No >> >> >>>> > such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > connect(4, {sa_family=AF_LOCAL, >> >> >>>> > sun_path="/var/run/nscd/socket"}, >> >> >>>> > 110) >> >> >>>> > = -1 >> >> >>>> > ENOENT (No such file or directory) >> >> >>>> > connect(4, {sa_family=AF_LOCAL, >> >> >>>> > sun_path="/var/run/nscd/socket"}, >> >> >>>> > 110) >> >> >>>> > = -1 >> >> >>>> > ENOENT (No such file or directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > open("/root/.pciids-cache", O_RDONLY) = -1 ENOENT (No such >> >> >>>> > file >> >> >>>> > or >> >> >>>> > directory) >> >> >>>> > open("/etc/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 >> >> >>>> > ENOENT >> >> >>>> > (No >> >> >>>> > such >> >> >>>> > file or directory) >> >> >>>> > open("/etc/udev/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No >> >> >>>> > such >> >> >>>> > file or >> >> >>>> > directory) >> >> >>>> > open("/usr/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 >> >> >>>> > ENOENT >> >> >>>> > (No >> >> >>>> > such file or directory) >> >> >>>> > open("/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 >> >> >>>> > ENOENT >> >> >>>> > (No >> >> >>>> > such >> >> >>>> > file or directory) >> >> >>>> > [zoran@localhost projects]$ >> >> >>>> > >> >> >>>> > I guess, you have one very important missing file in your Linux >> >> >>>> > configuration, this one: /etc/systemd/hwdb/hwdb.bin... >> >> >>>> > /etc/udev/hwdb.bin ?! >> >> >>>> > >> >> >>>> > Here is good read: >> >> >>>> > https://www.freedesktop.org/software/systemd/man/hwdb.html >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd-hwdb&ampsect=8 >> >> >>>> > >> >> >>>> > Have no idea who is creating this file, but you can check your >> >> >>>> > Linux >> >> >>>> > distro >> >> >>>> > / tree with the following paths to find hwdb.bin: >> >> >>>> > >> >> >>>> > /etc/systemd/hwdb/hwdb.bin >> >> >>>> > /etc/udev/hwdb.bin <<======= In my Fedora >> >> >>>> > rawhide VM >> >> >>>> > (future Fedora 26) I have here hwdb.bin ======= >> >> >>>> > /usr/lib/systemd/hwdb/hwdb.bin >> >> >>>> > /lib/systemd/hwdb/hwdb.bin >> >> >>>> > >> >> >>>> > If you don't have in any, please, create one with the following >> >> >>>> > link: >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd-hwdb&ampsect=8 >> >> >>>> > >> >> >>>> > Please, let us know! >> >> >>>> > >> >> >>>> > Zoran >> >> >>>> > >> >> >>>> > On Mon, Dec 26, 2016 at 3:42 PM, Shawn <citypw(a)gmail.com> wrote: >> >> >>>> >> >> >> >>>> >> Hi, >> >> >>>> >> >> >> >>>> >> intelmetool occurs "segfault" on my laptop running Mint 18 with >> >> >>>> >> PaX/Grsecurity 4.7.10. The PCI info: >> >> >>>> >> >> >> >>>> >> -[0000:00]-+-00.0 Intel Corporation Sky Lake Host Bridge/DRAM >> >> >>>> >> Registers [8086:1904] >> >> >>>> >> +-02.0 Intel Corporation Sky Lake Integrated >> >> >>>> >> Graphics >> >> >>>> >> [8086:1916] >> >> >>>> >> +-04.0 Intel Corporation Skylake Processor Thermal >> >> >>>> >> Subsystem [8086:1903] >> >> >>>> >> +-14.0 Intel Corporation Sunrise Point-LP USB 3.0 >> >> >>>> >> xHCI >> >> >>>> >> Controller [8086:9d2f] >> >> >>>> >> +-14.2 Intel Corporation Sunrise Point-LP Thermal >> >> >>>> >> subsystem [8086:9d31] >> >> >>>> >> +-15.0 Intel Corporation Sunrise Point-LP Serial IO >> >> >>>> >> I2C >> >> >>>> >> Controller [8086:9d60] >> >> >>>> >> +-15.1 Intel Corporation Sunrise Point-LP Serial IO >> >> >>>> >> I2C >> >> >>>> >> Controller [8086:9d61] >> >> >>>> >> +-16.0 Intel Corporation Sunrise Point-LP CSME HECI >> >> >>>> >> [8086:9d3a] >> >> >>>> >> +-1c.0-[01]----00.0 NVIDIA Corporation GM107M >> >> >>>> >> [GeForce >> >> >>>> >> GTX >> >> >>>> >> 960M] [10de:139b] >> >> >>>> >> +-1c.4-[02]----00.0 Samsung Electronics Co Ltd NVMe >> >> >>>> >> SSD >> >> >>>> >> Controller [144d:a802] >> >> >>>> >> +-1c.6-[03]----00.0 Qualcomm Atheros Killer E2400 >> >> >>>> >> Gigabit >> >> >>>> >> Ethernet Controller [1969:e0a1] >> >> >>>> >> +-1c.7-[04]----00.0 Qualcomm Atheros QCA6174 >> >> >>>> >> 802.11ac >> >> >>>> >> Wireless Network Adapter [168c:003e] >> >> >>>> >> +-1d.0-[05]----00.0 Samsung Electronics Co Ltd NVMe >> >> >>>> >> SSD >> >> >>>> >> Controller [144d:a802] >> >> >>>> >> +-1d.2-[06-3e]-- >> >> >>>> >> +-1f.0 Intel Corporation Sunrise Point-LP LPC >> >> >>>> >> Controller >> >> >>>> >> [8086:9d48] >> >> >>>> >> +-1f.2 Intel Corporation Sunrise Point-LP PMC >> >> >>>> >> [8086:9d21] >> >> >>>> >> +-1f.3 Intel Corporation Sunrise Point-LP HD Audio >> >> >>>> >> [8086:9d70] >> >> >>>> >> \-1f.4 Intel Corporation Sunrise Point-LP SMBus >> >> >>>> >> [8086:9d23] >> >> >>>> >> >> >> >>>> >> The crash log was attached! I'm not sure if intelmetool support >> >> >>>> >> Skylake as well. One tiny feature of PaX/Grsecurity prevent the >> >> >>>> >> ioperm >> >> >>>> >> for killing the potential threats in case which >> >> >>>> >> the adversary re-flash the SPI ROM once they get the root priv. >> >> >>>> >> It >> >> >>>> >> does affect flashrom but intelmetool. I also ran intelmetool on >> >> >>>> >> the >> >> >>>> >> distro( Mint 18) kernel and got the same result. >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> -- >> >> >>>> >> GNU powered it... >> >> >>>> >> GPL protect it... >> >> >>>> >> God blessing it... >> >> >>>> >> >> >> >>>> >> regards >> >> >>>> >> Shawn >> >> >>>> >> >> >> >>>> >> -- >> >> >>>> >> coreboot mailing list: coreboot(a)coreboot.org >> >> >>>> >> https://www.coreboot.org/mailman/listinfo/coreboot >> >> >>>> > >> >> >>>> > >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> -- >> >> >>>> GNU powered it... >> >> >>>> GPL protect it... >> >> >>>> God blessing it... >> >> >>>> >> >> >>>> regards >> >> >>>> Shawn >> >> >>> >> >> >>> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > GNU powered it... >> >> > GPL protect it... >> >> > God blessing it... >> >> > >> >> > regards >> >> > Shawn >> >> >> >> >> >> >> >> -- >> >> GNU powered it... >> >> GPL protect it... >> >> God blessing it... >> >> >> >> regards >> >> Shawn >> > >> > >> >> >> >> -- >> GNU powered it... >> GPL protect it... >> God blessing it... >> >> regards >> Shawn > > -- GNU powered it... GPL protect it... God blessing it... regards Shawn

1 0

FILO 0.6.0 payload bootloader - Questions?
by qma ster 29 Jan '17

29 Jan '17

I have successfully built and added FILO bootloader to my Lenovo G505S coreboot image! First of all, I had to use Xubuntu 16.04.1 *i386* because FILO fails to compile on x86_64 bit system. Also: from *./coreboot/payloads/libpayload/drivers/storage/ahci.c * removed two " #if IS_ENABLED(CONFIG_LP_STORAGE_AHCI_ONLY_TESTED) ... #endif " parts, --- because there are only three tested controllers in a list and FILO doesnt even try to initialize the not listed controllers - despite that they could work! By default, FILO just outputs "ahci: Not using untested SATA controller" message, without any option for a user to try forcing its usage to test it and made it a tested controller... now FILO outputs the following log: Booting from CBFS... coreboot: ... version (its from the beginning of December 2016) ... FILO version 0.6.0 (user@pc) date-of-the-build ahci: Found SATA controller 00:11.00 (1022:7801) <--- this is AMD SATA AHCI controller, built-in inside Bolton A76M FCH Southbridge of Lenovo G505S ahci: ATA drive on port #1. ata: Identified [my 1TB HDD drive model here] ahci: ATAPI drive on port #2. atapi: Identified [my DVD drive model here] ERROR: No such CMOS option (boot_devices) Then, it shows me FILO screen with " root_dev = unset " message on top, and FILO command line Questions: could you give some good examples about how to use FILO ? Do I have to set boot_devices in CMOS through nvramcui payload, or it is possible to choose that root_dev in FILO - if yes, how? I tried some random commands like filo> kernel hda:/vmlinuz but it tells: Disk read error dev=1 drive=0 sector=0 Disk read error dev=1 drive=0 sector=2 Disk read error dev=1 drive=0 sector=2 Disk read error dev=1 drive=0 sector=128 Disk read error dev=1 drive=0 sector=16 Disk read error dev=1 drive=0 sector=64 Disk read error dev=1 drive=0 sector=0 Disk read error dev=1 drive=0 sector=64 Disk read error dev=1 drive=0 sector=0 Disk read error dev=1 drive=0 sector=0 Unknown filesystem type. Error 15: Filo not found. EDIT: found https://www.coreboot.org/FILO but its too basic - for example, it does not tell how I could see the list of available devices. When I run "probe" command it only tells 6 messages "IDE channel X not found" (with X changing 0,0,1,1,2,2,3,3) - does not show SATA drive, despite I know that it successfully initialized, because it output its model and brand Please give any real world FILO usage examples with a modern Linux, it will help a lot! Best regards, qmastery

1 0

Let’s solve the Asus KCMA-D8 mess
by Paul Menzel 29 Jan '17

29 Jan '17

Dear coreboot folks, As many of you know, last week was not pretty [1]. Unfortunately, no solution was found. Chances are slim, that the involved parties will get along in the future, but hopefully they will. I had hoped, that the community would have been asked for help before to find a solution, that (all?) the money could not be raised. Also, the coreboot project has the source code for the Asus KCMA-D8, and the REACTS infrastructure is run to build test the board to find regressions. I propose, that the community steps in for Minifree(?) and raises the $15,000 instead to settle the debts, forget about it and go on. I’ll take my 1000 € pledge for the TALOS workstation and put 500 € on top, so ten percents are covered. Is anybody with me? Smaller amounts are as welcome as bigger. If nobody else wants to, I would note down the amounts, already transferred. Having not done that before, I hope tax rules and regulations don’t make that difficult. Please advice how to best transfer the money. I believe in our community, and I am hopeful to settle this. Thanks, Paul [1] see the thread *ASUS KCMA-D8 workstation board port offer*

3 2

Re: [coreboot] Documentation creation for the coreboot wiki - what to do?
by Timothy Pearson 29 Jan '17

29 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/29/2017 01:28 PM, Marshall Dawson wrote: > I agree with Martin's assessment. I'll elaborate that the suppliers are > simply delivering what their revenue generators ask for. Those are > overwhelmingly ODMs and OEMs who demand that solutions be provided to > them, not Swiss Army knives or DIY kits. That's why suppliers design > software that runs on MEs, IMCs, PSPs, sideband controllers, etc. > Customers rarely care about what a product could do; they want to know > what it does. I'll also add that there is are actually two markets for people that care about building something to execute a task that the OEM didn't know about. The problem is you're really looking at very low end (embedded, where the processor is not the primary solution, only part of the overall system) and very high end (where a good chunk of your trade secrets may revolve around how you're using the machine and what you quietly stuck onto it without the OEM's knowledge). There is absolutely no reason for anyone to use mid range computing systems in these type of roles. This primarily is a factor of cost; on the embedded side you can't justify using a more powerful / complex processor with more to go wrong than what you actually need, and on the high end the investment in developing the secret IP dwarfs the cost of the machines themselves. Therefore, I assert that market forces dictate libre firmware (and possibly certain classes of libre software) will not be available for mid range general purpose computing systems barring a massive shift in semiconductor manufacturing. The only argument one could theoretically make is security, but again this applies moreso to large organizations that are going to be using very specific types of machines and are going to be willing to pay more for the secure computers. There is no benefit to an average Joe (Windows user, uploads all their data to Facebook, likes to torrent movies and games, etc.) to have their firmware secured. When something goes wrong enough that they can't use their PC, they'll just wipe, reload, and continue on. Even if an APT embedded itself in their firmware they won't be aware of it or experience any sensible financial loss from the situation -- just look at the IoT hack last year for a good example. Did any of the "owners" of the hacked IoT devices receive a fine for their role, or lose access to the device? No. So why would average Joe care one bit about security, and why would the OEMs creating hardware for average Joe pay more for securable systems? I hate to say it, but libre software is now the domain of those who just want to connect to cloud services or retrocompute, and those organizations with large enough budgets and valuable enough IP to justify the extra cost. It's not a matter of the OEMs being evil, it's a matter of the market adjusting to meet the demands of the 95% at the expense of the 5%, even if the 5% were heavily contributing to society as a whole. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYjkwjAAoJEK+E3vEXDOFb1fAIAKvCINVZazjphz3ja0oY5YHx jT+fnTP7cJ5l1g9aqKZH4cl4th8k1+VMn/MqGsNjn2J/+11/MUnY6QpHrU9mqsLq bxEvrK9ZPX06GdVN2gtf35/Z5p9xL+GwN7yUtQfCGdrjtujert4VtyOYFiR/NWTR p/9H0kVrZEd32wYLSb2/d3GbA3802gxbJtJx/f4Q4xh1So46RORfNJ3X3XYg7xH8 rkkQs8EXK3mezKSLfajD/8gbNdm2A2oOY6uZiHD0M0Tvc/Fz3er/mVbMNlZ29Z7p r5w5SyhDPOPP5NzInatDZodeI9x5QHJ6ZVheHfqyISWbmzIRQ9Qc+alD+ukNrt4= =KMDF -----END PGP SIGNATURE-----

1 0

Re: [coreboot] Documentation creation for the coreboot wiki - what to do?
by Taiidan＠gmx.com 29 Jan '17

29 Jan '17

On 01/28/2017 08:48 PM, Martin Roth wrote: > On Fri, Jan 27, 2017 at 5:16 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: >> I would like to know as to how much we are allowed to indicate that x86 >> OEM's are generally hostile to the FOSFW movement? I don't want to ruffle >> any feathers, as these days they are already significantly ruffled. > Hi Talidan, > My personal opinion here is that you're incorrect. I don't think > that they're hostile at all. I think that the corporations don't see > the value in catering to the few people who are interested in > completely open firmware. They're trying to solve issues, and the > solutions that they've chosen just happen to completely lock out third > party firmware. > > If you want to change that, I'd say that you have to be noticed, and > noticed in a POSITIVE light. If the coreboot community just complains > about the current situation, we're not going to get anywhere. There > are plenty of people at these companies who feel the same way that we > do about these sorts of issues, and we only make it harder by saying > that the OEMs are 'hostile' or 'evil'. They aren't - they're just > looking to create value for their shareholders by leveraging > synergistic solutions. Or something like that. :) > > So while this is just my opinion, I'd recommend just keeping to the > facts about the issues, and not going beyond that. Feel free to point > out the issues that Intel's bootguard or AMD's PSP present for us, but > I'd try to refrain from anything beyond that. If you do want to go > beyond that, please make it plain that it's coming from you as an > individual, and may or may not reflect the coreboot community as a > whole. > > If we want to change things, we need an argument that makes sense to > the companies we want to change - Something financial. > > Martin > The only issue is that there won't be a free firmware community in a few years due to the actions of intel and AMD as there is no way to shut off boot guard or ME/PSP. I don't consider a system with FSP/MRC/ME to be "free" firmware as coreboot does hardly anything in that situation. AMD used to be chill, they released the AGESA code - but then they took it closed source again....I would really like to know why. IMO getting intelligence agencies and major corporations involved in the free firmware movement is what will save it, assured computing is all the rage these days - china and russia are making their own CPU designs and DARPA is interested in hardware verification. What corporation that deals with sensitive IP wants a black box supervisor processor (magic backdoor) on their every device? They currently do not know how much they need it, let us hope that will change.

2 1

KGPE-D16 with over 128GB RAM - works reliably yet?
by Taiidan＠gmx.com 29 Jan '17

29 Jan '17

Is anyone using this configuration? does it work reliably? I am asking as I don't know if this has been fixed yet. For a real server platform this is a must have, the ram issues are the one valid point that leah made... - Thanks in advance for any replies

3 3

Re: [coreboot] 8 GB DIMMs on Nehalem (Arrandale)
by Stefan Tauner 29 Jan '17

29 Jan '17

On Sun, 29 Jan 2017 07:15:18 +0100 Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> wrote: > > The current raminit for Nehalem in coreboot is not able to train the two > > 8 GB DIMMs I have tested so far. I have added a debug output to > > choose_reg178 in the first loop before the margins are compared to > > STANDARD_MIN_MARGIN that shows that all margins are 0. > > I would suggest to you to do the following: to return to the platform true > BIOS, and to see if BIOS works with your Arrandale i5-520M (Thinkpad 410). > Then you can try several different DIMM configurations, and see if BIOS > supports up to maximum of 32GB (4 X 8GB DIMM). > > Then, from these BIOS experiments, you can draw obvious conclusions in > relations with Coreboot MRC algorithm. :-) The T410s does have only two slots (NB: T410 is a completely different model with a different casing). The 4-slot system is the W510 with the clarkdale i7 CPU that does not have coreboot support at all. In the T410s the vendor firmware and coreboot work fine with 2x 4GB DIMMs but as soon as there is one 8GB DIMM even if it is the only stick and no matter in which slot it is, things go crazy with the vendor firmware and the raminit code of coreboot stops in the middle as described earlier. So there is nothing obvious left to try regarding DIMM combinations in the T410s. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Documentation creation for the coreboot wiki - what to do?
by Taiidan＠gmx.com 29 Jan '17

29 Jan '17

I have been given a wiki account and I would like some input as to what is needed in terms of maintance, documentation updating, tutorial creation etc? I am a sysadmin so it is good to offload this kind of stuff to me so that you guys are free to do the programming bits. So far I have updated various pages with info from myself or that has been gleaned from the mailing list and I would like to know how I am doing? I have never edited a wiki before. https://www.coreboot.org/Special:Contributions/Taiidan I have 3 coreboot motherboards that all lack complete featurelists and two lack build tutorials which I will remedy, I will also create pages for getting started (a newbie page), security, virtualization support/board buyers guide information (ie: which mobos have/support hvm, iommu/iommu gfx, sr-iov, etc) and info about which coreboot motherboards are suitable for modern gaming and also a POWER arch intro page using the info that people have provided on the mailing list. I would like to know as to how much we are allowed to indicate that x86 OEM's are generally hostile to the FOSFW movement? I don't want to ruffle any feathers, as these days they are already significantly ruffled. I was able to figure all this out but for the free firmware movement to survive it needs to be spread to a wider audience thus things need to be made a little bit easier, I have plenty of linux sysadmin acquaintances but none of them use coreboot because they aren't yet fanatical enough about FOSFW to bother with the difficulty level.

2 1

Re: [coreboot] Proposal for new "Commenting" wiki text (was: [RFC] Deciding on style for multi-line comments)
by Nico Huber 29 Jan '17

29 Jan '17

Hi folks, sorry to revive this old, stale topic. I got stalled by a request to ensure the comment style with a script. Now, that I had a look at checkpatch.pl, I don't think this could be done easily without risking many false positives. So I'm again asking to commit my proposal below. I've incorporated the comments from Martin. Even if it's not going to be my preferred style, I would really appre- ciate it if we could agree on one style. Nico > == Commenting == > > Comments are good, but there is also a danger of over-commenting. NEVER > try to explain HOW your code works in a comment: it's much better to > write the code so that the _working_ is obvious, and it's a waste of > time to explain badly written code. > > Generally, you want your comments to tell WHAT your code does, not HOW. > Also, try to avoid complex comments inside a function body: if the > function is so complex that you need to separately comment parts of it, > you should probably go back to chapter 6 for a while. You can make > small comments to note or warn about something particularly clever (or > ugly), but try to avoid excess. Instead, put the comments at the head > of the function, telling people what it does, and possibly WHY it does > it. > > coreboot style for comments is the C89 "/* ... */" style. You may also > use C99-style "// ..." comments. > > The preferred style for concise multi-line comments that explain a > single piece of code is: > > /* This is the preferred style for > two or three line comments that > avoids excessive blank lines. */ > > Note that there shouldn't be leading asterisks on new lines in the > concise style. > > The preferred style for long multi-line comments is: > > /* > * This is the preferred style for multi-line > * comments in the coreboot source code. > * > * Description: A column of asterisks on the left side, > * with beginning and ending almost-blank lines. > */ > > Some rules of thumb to decide which style to use: > * If you are commenting a whole function (indentation level 0) or > something high level (indentation level 1), use the long style. > * If you want to explain a single piece of code and your comment > doesn't span multiple paragraphs, use the concise style. > * Otherwise you might want to ask yourself why what you're going to > explain doesn't deserve an own function. > > It's also important to comment data, whether they are basic types or > derived types. To this end, use just one data declaration per line (no > commas for multiple data declarations). This leaves you room for a > small comment on each item, explaining its use. > > If the author has reasonable arguments for breaking the recommended > style guide to improve readability, others should be respectful of those > differences.

2 1

Re: [coreboot] Does the 62xx Series Opteron work *securely* without microcode?
by Timothy Pearson 29 Jan '17

29 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/27/2017 12:20 PM, Andrés Domínguez wrote: > 2017-01-26 16:12 GMT+01:00 ron minnich <rminnich(a)gmail.com>: >> >> A decade later? You should buy a new computer. > > Core 2 duo is more than a decade old and I think that it should be > good enough for a lot of tasks. > > Andrés > Something to think about: have you tried developing modern software on that Core 2 Duo? Are you OK with only having hardware that can consume software (libre or not) that was created (compiled) on more powerful, non-free systems? I'd like to see some discussion on this particular topic, especially since it ties in so closely with the start of GNU and libre software as we know it today -- it was recognised early on that a libre compiler was needed for libre software to be truly free. Yet here we are, again restricting the tools needed to compile software to non-free systems. Apologies if this is off topic. :-) - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYi5DuAAoJEK+E3vEXDOFbcAIH/1ZWgxiSMMjMs+I3Ye6J3lSM XZT7+D82ivcPtdsC/rT/eOisU6/ZSumPpVqRqaBFf+Zg2c0acHDKjtGF5lQ/G8GX gR2acgc6b5/F0Om739H1GKOAt3prQZvjQWY+P83rs3QFVkxuoKO0HDD8aNCnoa8Y 8hBnGd21ayZ0pedMljYJJj9kwDVhV4vw5CpPwJDg7slfHcqbvMvxt67UlqAtFJkU lCFJiCqAdZb68DVo6Mh3LW9Zf0fPHmE5GMjEms930qXjGOQ/VX3an6SZ0zSspJfg n095JhdhVi0bh5RyijRo08UAPhU3J/14oQkFZi/lfUuWVmgj3Ooa47YG+wlKG9Y= =epO4 -----END PGP SIGNATURE-----

6 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2017