coreboot

coreboot@coreboot.org

42 participants
38504 discussions

by Mick

Dear everyone, For my master project I will apply hardening techniques (sanitizers/CFI) to System Mangement Mode (SMM). Now for my evaluation, I want to test code in SMM and ideally cover all SMI handlers coreboot offers. However, in my experience, System Management Interrupts (SMIs) rarely trigger and the variety in SMIs is also rather low (testing via QEMU). I was wondering whether anyone is familiar with testing such a low-level component. In the coreboot repository, I couldn't find any tests related to SMM and looking online also hasn't provided me any answers. Is there anyone who has experience with similar problems or can perhaps point me into the right direction, as I am inexperienced with testing such low-level components. I hope I've explained myself clearly, if not, please indicate so! Kind regards, Mick

5 hours, 34 minutes

Debugging Windows 10 BSOD

by Raul Rangel

I'm trying to boot the Windows 10 Installer on a picasso based device using coreboot + tianocore. I keep getting a BSOD after the windows logo shows with the very descriptive stop code `ACPI BIOS ERROR`. I've enabled bootdebug on the USB stick using the following: bcdedit /store H:\boot\bcd /bootdebug {bootmgr} on bcdedit /store H:\boot\bcd /bootdebug {default} on bcdedit /store H:\boot\bcd /debug {debug} on Here is the BCD: C:\Windows\system32>bcdedit /store h:\boot\bcd Windows Boot Manager -------------------- identifier {bootmgr} description Windows Boot Manager locale en-US inherit {globalsettings} bootdebug Yes default {default} displayorder {default} toolsdisplayorder {memdiag} timeout 30 Windows Boot Loader ------------------- identifier {default} device ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f} path \windows\system32\boot\winload.exe description Windows Setup locale en-US inherit {bootloadersettings} bootdebug Yes osdevice ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f} systemroot \windows bootmenupolicy Standard detecthal Yes winpe Yes debug Yes ems No C:\Windows\system32>bcdedit /store h:\boot\bcd /dbgsettings debugtype Serial debugport 1 baudrate 115200 I have also added the SPCR table: [000h 0000 4] Signature : "SPCR" [Serial Port Console Redirection table] [004h 0004 4] Table Length : 00000050 [008h 0008 1] Revision : 02 [009h 0009 1] Checksum : F1 [00Ah 0010 6] Oem ID : "COREv4" [010h 0016 8] Oem Table ID : "COREBOOT" [018h 0024 4] Oem Revision : 0000002A [01Ch 0028 4] Asl Compiler ID : "CORE" [020h 0032 4] Asl Compiler Revision : 20200925 [024h 0036 1] Interface Type : 00 [025h 0037 3] Reserved : 000000 [028h 0040 12] Serial Port Register : [Generic Address Structure] [028h 0040 1] Space ID : 00 [SystemMemory] [029h 0041 1] Bit Width : 20 [02Ah 0042 1] Bit Offset : 00 [02Bh 0043 1] Encoded Access Width : 03 [DWord Access:32] [02Ch 0044 8] Address : 00000000FEDC9000 [034h 0052 1] Interrupt Type : 03 [035h 0053 1] PCAT-compatible IRQ : 04 [036h 0054 4] Interrupt : 00000004 [03Ah 0058 1] Baud Rate : 00 [03Bh 0059 1] Parity : 00 [03Ch 0060 1] Stop Bits : 00 [03Dh 0061 1] Flow Control : 00 [03Eh 0062 1] Terminal Type : 00 [04Ch 0076 1] Reserved : 00 [040h 0064 2] PCI Device ID : FFFF [042h 0066 2] PCI Vendor ID : FFFF [044h 0068 1] PCI Bus : 00 [045h 0069 1] PCI Device : 00 [046h 0070 1] PCI Function : 00 [047h 0071 4] PCI Flags : 00000000 [04Bh 0075 1] PCI Segment : 00 [04Ch 0076 4] Reserved : 00000000 And the DBG2 table: [000h 0000 4] Signature : "DBG2" [Debug Port table type 2] [004h 0004 4] Table Length : 0000005C [008h 0008 1] Revision : 00 [009h 0009 1] Checksum : 78 [00Ah 0010 6] Oem ID : "COREv4" [010h 0016 8] Oem Table ID : "COREBOOT" [018h 0024 4] Oem Revision : 00000000 [01Ch 0028 4] Asl Compiler ID : "CORE" [020h 0032 4] Asl Compiler Revision : 20200925 [024h 0036 4] Info Offset : 0000002C [028h 0040 4] Info Count : 00000001 [02Ch 0044 1] Revision : 00 [02Dh 0045 2] Length : 0030 [02Fh 0047 1] Register Count : 01 [030h 0048 2] Namepath Length : 000A [032h 0050 2] Namepath Offset : 0026 [034h 0052 2] OEM Data Length : 0000 [Optional field not present] [036h 0054 2] OEM Data Offset : 0000 [Optional field not present] [038h 0056 2] Port Type : 8000 [03Ah 0058 2] Port Subtype : 0000 [03Ch 0060 2] Reserved : 0000 [03Eh 0062 2] Base Address Offset : 0016 [040h 0064 2] Address Size Offset : 0022 [042h 0066 12] Base Address Register : [Generic Address Structure] [042h 0066 1] Space ID : 00 [SystemMemory] [043h 0067 1] Bit Width : 20 [044h 0068 1] Bit Offset : 00 [045h 0069 1] Encoded Access Width : 03 [DWord Access:32] [046h 0070 8] Address : 00000000FEDC9000 [04Eh 0078 4] Address Size : 000000F8 [052h 0082 10] Namepath : "\_SB.FUR0" Given all this I have yet to see windows dump anything to the serial console. The device just reboots after the BSOD message. Does anyone have any experience debugging Windows boot errors? Can you share any tips? :) Thanks, Raul

6 hours, 20 minutes

Re: Testing code present in SMM

by Mick

Hello Peter, Thank you for your response! Cool! And ambitious. :) > Yeah, the project is pretty hacky, to be frank, and will be limited to the setup where SMRAM is from a0000h to bffffh. In general coreboot makes an attempt to not go overboard with SMM code, in > particular the QEMU board code may have almost none, to the point where > it's far from representative for modern platforms. > Yes, I'm aware of coreboot's stance on SMM. If I recall correctly, QEMU seemed to have trouble clearing the SMI_STS register. We will likely use hardware to test the setup. You're confirming my fear related to testing SMM in QEMU. I hope we will be able to see more SMM activity on a real board, but I don't know what to expect, as I have trouble finding sources that discuss how SMM is used in the "wild" (besides articles on reversing and exploiting SMM). Are you aware whether SMM is tested (for new functionality, for instance), and if so, how that is being done? Or is this done by using existing hardware setups? I do not have a lot of experience with low-level hardware. Thanks for your input :). Kind regards, Mick

1 day, 11 hours

Questions about Asus A88XM-E

by magiccat1＠protonmail.com

All, I have an Asus A88XM-E, and I am trying to install Coreboot on it. 1 ) The chip that came with the board says "GD25Q64(B)" (8192 kB, SPI). I think the chip definitely broken somehow. Everytime I tried to flashrom, it says Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00000fff: 0xd0c ERASE FAILED! when I tried sudo flashrom -w build/coreboot.rom --programmer ch341a_spi, it says Verifying flash... FAILED at 0x00000000! Expected=0x5f, Found=0xff, failed byte count from 0x00000000-0x007fffff: 0xb5 Your flash chip is in an unknown state. I am having a hard time flashing back to original bios as well. Can I buy W25Q64FVAIG to replace? The chip says GD25B64BP1G . Is that caused by using 5 V to be broken? I only performed flashrom -w and flashrom -r . 2) For configuration, I copied this configuration: https://review.coreboot.org/cgit/board-status.git/tree/asus/a88xm-e/4.12-32… to .config and added the board. I have exported the vga bios from Linux using: cp /sys/devices/pci0000:00/0000:00:01.0/rom vgabios.bin . The above config does not work with make, it tries to go to a webpage for secondary payload, and that webpage is changed. Removing those two lines CONFIG_COREINFO_SECONDARY_PAYLOAD=y && CONFIG_TINT_SECONDARY_PAYLOAD=y will let me build the rom. When I do sudo flashrom -w build/coreboot.rom --programmer ch341a_spi, it sometimes says write done: Erasing and writing flash chip... Erase/write done. Verifying flash... FAILED at 0x00000000! Expected=0x5f, Found=0xff, failed byte count from 0x00000000-0x007fffff: 0xb5 Your flash chip is in an unknown state. When I boot with Coreboot, I see a black screen. I renamed vgabios.bin to pci1002,990c.rom, and I put that file in the ~/Coreboot/ folder. Thanks for helping out,

1 day, 13 hours

basic support for AMD APU

by Tom Psyborg

Hi Is there any basic code in coreboot tree for recent AMD APUs ? Specifically Bristol Ridge FX-9830P is of my interest, how much work is needed to get laptop booting it?

5 days

Proper way to obtain GbE.bin for Denverton atom

by Balaji Sivakumar

Hello Everyone, I am currently working on a custom Denverton board similar to the Intel Harcuvar board. I am working to enable the Intel Lan controller, Did anyone generate the GbE.binary(firmware) for the Intel Lan controller of denverton atom or should i check with Intel for binary? We are using flash descriptor and ME binaries integrated into the coreboot, similar way i am working to integrate the GbE binary as well part of coreboot to properly initialize the Lan controller. -- Thanks, Balaji

5 days, 6 hours

Problems with CAR setup on Tiger Lake

by Michał Żygowski

Dear coreboot community, I have a Tiger Lake UP3 RVP and I try to build a working coreboot on it, however facing an early stuck during CAR setup. Tried different approaches: - native coreboot's CAR setup - the last seen post code is 0x26 - FSP-T CAR setup - the last seen post code is 0x7F (which is TempRamInit Exit event according to FSP integration guide), FSP from public repo, Client variant Used microcode from original RVP firmware. Are there any patches that I have to apply to make it working? Best regards, -- Michał Żygowski Firmware Engineer https://3mdeb.com | @3mdeb_com

5 days, 15 hours

Documentation update

by bzt

Hi everyone, Is there any chance to get this trivial commit merged? https://review.coreboot.org/c/coreboot/+/45829 I've added description of missing payloads and links to Documentation/payloads.md Low priority, but would be nice to have. Thanks, bzt

1 week

Questions about Supermicro X10SL7-F potential with coreboot

by wellywood2018＠gmail.com

Hi everyone, I have a motherboard (Supermicro X10SL7-F) that appears to be very similar to the supported board X10SLM+-F I would like comment on whether anyone thinks running coreboot on this board would be possible! And if so what work would need to be done to make it a reality. 1. Board description: Vendor: Supermicro Board name: X10SL7-F CPU: Intel Xeon E3-1231 v3 (Haswell) Northbridge: ? Southbridge: Intel C222 Express PCH This board also contains a built-in LSI 2308 disk controller providing 8 SAS2 ports 2. Output of lspci -tvnn on Ubuntu Server 18.04.5: -[0000:00]-+-00.0 Intel Corporation Xeon E3-1200 v3 Processor DRAM Controller [8086:0c08] +-01.0-[01]-- +-01.1-[02]----00.0 LSI Logic / Symbios Logic SAS2308 PCI-Express Fusion-MPT SAS-2 [1000:0086] +-14.0 Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] +-1a.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] +-1c.0-[03-04]----00.0-[04]----00.0 ASPEED Technology, Inc. ASPEED Graphics Family [1a03:2000] +-1c.2-[05]----00.0 Intel Corporation I210 Gigabit Network Connection [8086:1533] +-1c.3-[06]----00.0 Intel Corporation I210 Gigabit Network Connection [8086:1533] +-1d.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] +-1f.0 Intel Corporation C222 Series Chipset Family Server Essential SKU LPC Controller [8086:8c52] +-1f.2 Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c02] +-1f.3 Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] \-1f.6 Intel Corporation 8 Series Chipset Family Thermal Management Controller [8086:8c24] 3. Output of superiotool -dV on Ubuntu Server 18.04.5: superiotool r6637 Probing for Nuvoton Super I/O at 0x2e... Found Nuvoton NCT6776F (C) (id=0xc333) at 0x2e Register dump: idx 10 11 13 14 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 2a 2b 2c 2d 2e 2f val ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff def ff ff 00 00 ff ff ff ff f0 78 00 00 ff ff c3 33 ff 00 64 00 MM 00 00 c0 00 81 00 00 MM LDN 0x00 (FDC) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val ff ff ff ff ff ff ff ff ff ff def 01 03 f0 06 02 0e 00 ff 00 00 LDN 0x01 (Parallel Port) idx 30 60 61 70 74 f0 val ff ff ff ff ff ff def 01 03 78 07 04 3f LDN 0x02 (UART A) idx 30 60 61 70 f0 f2 val ff ff ff ff ff ff def 01 03 f8 04 00 00 LDN 0x03 (UART B, IR) idx 30 60 61 70 f0 f1 f2 val ff ff ff ff ff ff ff def 01 02 f8 03 00 00 00 LDN 0x05 (Keyboard Controller) idx 30 60 61 62 63 70 72 f0 val ff ff ff ff ff ff ff ff def 00 00 00 00 00 00 00 83 LDN 0x06 (CIR) idx 30 60 61 70 f0 f1 f2 f3 val ff ff ff ff ff ff ff ff def 00 00 00 00 08 09 32 00 LDN 0x07 (GPIO6, GPIO7, GPIO8, GPIO9) idx 30 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee f4 f5 f6 f7 f8 val ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff def 03 ff 00 00 00 ef 00 00 00 ff 00 00 00 00 00 00 ff 00 00 00 00 LDN 0x08 (WDT1, GPIO0, GPIO1, GPIOA) idx 30 60 61 e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 val ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff def 02 00 00 ff 00 00 00 ef ff 00 00 00 00 00 00 00 LDN 0x09 (GPIO2, GPIO3, GPIO4, GPIO5) idx 30 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ee f0 f1 f2 f4 f5 f6 f7 fe val ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff def 04 df 00 00 00 ff 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 00 00 LDN 0x0a (ACPI) idx e0 e1 e2 e3 e4 e5 e6 e7 e9 ee f0 f2 f3 f4 f6 f7 fe val ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff def 01 00 00 00 00 02 1c 00 00 00 00 00 00 00 00 c0 00 LDN 0x0b (Hardware Monitor, Front Panel LED) idx 30 60 61 62 63 70 e0 e1 e2 f0 f1 f2 f5 f6 f7 f8 f9 fa val ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff def 00 00 00 00 00 00 7f 7f ff 00 00 00 10 00 87 47 00 00 LDN 0x0d (VID) idx e0 e1 e2 e3 e4 e5 e6 e9 ee ef f0 f4 f5 val ff ff ff ff ff ff ff ff ff ff ff ff ff def 00 00 00 00 00 00 00 00 88 00 00 00 00 LDN 0x0e (CIR WAKE-UP) idx 30 60 61 70 val ff ff ff ff def 00 00 00 00 LDN 0x0f (GPIO Push-Pull or Open-drain) idx e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 f0 f1 f2 val ff ff ff ff ff ff ff ff ff ff ff ff ff def ff df ff fe f6 ff ff d3 ff 9f 00 00 00 LDN 0x14 (SVID) idx e0 e1 e3 e4 val ff ff ff ff def 00 80 00 00 LDN 0x16 (Deep Sleep) idx 30 e0 e1 e2 val ff ff ff ff def 20 20 04 05 LDN 0x17 (GPIOA) idx e0 e1 e2 e3 e4 e5 val ff ff ff ff ff ff def 01 00 00 00 01 00 4. Output of flashrom -p internal -V on Ubuntu Server 18.04.5: flashrom v0.9.9-r1954 on Linux 4.15.0-112-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.3.1, GCC 5.3.1 20160424, little endian Command line (3 args): flashrom -p internal -V Calibrating delay loop... OS timer resolution is 1 usecs, 3692M loops per second, 10 myus = 9 us, 100 myus = 118 us, 1000 myus = 1031 us, 10000 myus = 9740 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. Using Internal DMI decoder. DMI string chassis-type: "Main Server Chassis" DMI string system-manufacturer: "Supermicro" DMI string system-product-name: "X10SL7-F" DMI string system-version: "0123456789" DMI string baseboard-manufacturer: "Supermicro" DMI string baseboard-product-name: "X10SL7-F" DMI string baseboard-version: "1.01 " Found chipset "Intel C222" with PCI ID 8086:8c52. This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... Root Complex Register Block address = 0xfed1c000 GCS = 0xc61: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap: enabled (A16(+) inverted) 0xfff80000/0xffb80000 FWH IDSEL: 0x0 0xfff00000/0xffb00000 FWH IDSEL: 0x0 0xffe80000/0xffa80000 FWH IDSEL: 0x1 0xffe00000/0xffa00000 FWH IDSEL: 0x1 0xffd80000/0xff980000 FWH IDSEL: 0x2 0xffd00000/0xff900000 FWH IDSEL: 0x2 0xffc80000/0xff880000 FWH IDSEL: 0x3 0xffc00000/0xff800000 FWH IDSEL: 0x3 0xff700000/0xff300000 FWH IDSEL: 0x4 0xff600000/0xff200000 FWH IDSEL: 0x5 0xff500000/0xff100000 FWH IDSEL: 0x6 0xff400000/0xff000000 FWH IDSEL: 0x7 0xfff80000/0xffb80000 FWH decode enabled 0xfff00000/0xffb00000 FWH decode enabled 0xffe80000/0xffa80000 FWH decode enabled 0xffe00000/0xffa00000 FWH decode enabled 0xffd80000/0xff980000 FWH decode enabled 0xffd00000/0xff900000 FWH decode enabled 0xffc80000/0xff880000 FWH decode enabled 0xffc00000/0xff800000 FWH decode enabled 0xff700000/0xff300000 FWH decode enabled 0xff600000/0xff200000 FWH decode enabled 0xff500000/0xff100000 FWH decode enabled 0xff400000/0xff000000 FWH decode enabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching enabled, caching enabled, BIOS_CNTL = 0x09: BIOS Lock Enable: disabled, BIOS Write Enable: enabled SPIBAR = 0x00007fb3b1769000 + 0x3800 0x04: 0xf008 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 Warning: SPI Configuration Lockdown activated. Reading OPCODES... done 0x06: 0x0000 (HSFC) HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0 0x50: 0x00005a5b (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0x5a, BRRA 0x5b 0x54: 0x000f0000 FREG0: Warning: Flash Descriptor region (0x00000000-0x0000ffff) is read-only. 0x58: 0x0fff0500 FREG1: BIOS region (0x00500000-0x00ffffff) is read-write. 0x5C: 0x04ff0020 FREG2: Warning: Management Engine region (0x00020000-0x004fffff) is locked. 0x60: 0x001f0010 FREG3: Gigabit Ethernet region (0x00010000-0x0001ffff) is read-write. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see https://flashrom.org/ME for details. Writes have been disabled for safety reasons. You can enforce write support with the ich_spi_force programmer option, but you will most likely harm your hardware! If you force flashrom you will get no support if something breaks. On a few mainboards it is possible to enable write access by setting a jumper (see its documentation or the board itself). 0x90: 0x80 (SSFS) SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0 0x91: 0xf94010 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=0, SME=0, SCF=1 0x94: 0x0006 (PREOP) 0x96: 0x003b (OPTYPE) 0x98: 0x05200302 (OPMENU) 0x9C: 0x00009f9f (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x80802005 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1 0xC8: 0x00002005 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20 0xD0: 0x50444653 (FPB) OK. The following protocols are supported: FWH, SPI. Found Micron/Numonyx/ST flash chip "N25Q128..3E" (16384 kB, SPI) mapped at physical address 0x00000000ff000000. Chip status register is 0x00. Chip status register: Status Register Write Disable (SRWD, SRP, ...) is not set Chip status register: Block Protect 3 (BP3) is not set Chip status register: Top/Bottom (TB) is top Chip status register: Block Protect 2 (BP2) is not set Chip status register: Block Protect 1 (BP1) is not set Chip status register: Block Protect 0 (BP0) is not set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set Found Micron/Numonyx/ST flash chip "N25Q128..3E" (16384 kB, SPI). This chip may contain one-time programmable memory. flashrom cannot read and may never be able to write it, hence it may not be able to completely clone the contents of this chip (see man page for details). No operations were specified. Restoring MMIO space at 0x7fb3b176c8a0 Restoring PCI config space for 00:1f:0 reg 0xdc Segmentation fault (core dumped) 5. https://www.supermicro.com/en/products/motherboard/X10SL7-F

1 week, 1 day

[RFC] Amendment to our coding style about text blocks

by Nico Huber

Hi coreboot folks, I've just pushed a small RFC commit for our coding style: https://review.coreboot.org/c/coreboot/+/49542 From the commit message: It seems since the increase of the code line length to 96 chars, many developers felt encouraged to increase the line length of running text as well. However, text blocks wider than 72 chars are generally harder to read. Let's try to add a sane rule about it. The addition: +This does not apply to running text, e.g. block comments. For text +blocks, the usual limit of 72 chars is strongly encouraged to increase +readability. This may be counted additionally to any indentation, but +the overall line length should not exceed 96 chars. So, that's what it's about. I'd like to see all sorts of opinions on the matter. Maybe there is a reason to deviate from common typesetting rules that I just don't see yet. Generally, I'd prefer to not treat all text like code. Nico

1 week, 2 days

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot