coreboot November 2017

coreboot@coreboot.org

61 participants
110 discussions

OliveHillPlus board GPP PCIe ports - No link before AGESA Calls.
by Abhishek Chaudhary 08 Nov '17

08 Nov '17

Hi Everyone, I am working onAMD OliveHillPlus board that has AMD G-series - Steppe eagle (Mullins, Family 16h Model 30h-3Fh). I am running coreboot that calls AGESA APIs to initialize the platform. What i observed is the GPP PCIe ports (Device 2, Func 1,2,3,4) doesn't indicate link as active unless amdinitreset, amdinitearly, and amdinitpost calls are made. My question is, in Bootlog for OliveHillPlus has serail prints before any AGESA calls. Since serial port must be connected on GPP PCIe port and these ports are not active before first 3 AGESA calls, how serial port is able to communicate? When i connected a OXPCI serial card on mini PICe port that Coreboot supports, the serial card was not getting initialized by Coreboot. Is there some way to configure the PCIe ports early enough (before making any AGESA call)? Any inputs will be very helpful. Thanks, Abhishek.

1 0

New Subscriber
by Robert Walz 08 Nov '17

08 Nov '17

Hello coreboot community, I'm 23 years old and I'm studying computer science in germany. I want to flash coreboot on my Lenovo T420 with Raspberry Pi's SPI, read a lot of content on coreboot.org, but I would have some more questions. 1) About VBIOS: I have Sandy Bridge with integrated graphics (Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller) so it wouldn't be necessary to build the coreboot.rom with a VBIOS, I want to boot with SeaBIOS without graphics. But if I don't add the VBIOS, what is used after the boot? For example I dumped the current vbios.rom of the VGA compatible controller in linux with echo 1 | tee /sys/devices/pci0000\:00/0000\:00\:02.0/rom cat /sys/devices/pci0000\:00/0000\:00\:02.0/rom > vbios.rom and disassembled it with ndisasm -k 0,3 vbios.rom | less strings vbios.rom | less Where is this current vbios stored and for what is it needed? Can I replace it with coreboots VBIOS? Or is it even not necessary and its deleted, if I use coreboot without VBIOS? 2) About proprietary BIOS Is it possible to download a "full" BIOS (with descriptor, me, ...), like it is stored on the mainboard flash chip?, because on the lenovo support webpage I can only find BIOS-Updates, with an empty offset for the descriptor, the intel me and the GbE followed by the BIOS. And this .FL1 file is even biggen then 8 MiB, maybe because it also includes the EC? 3) About the EC Is it possible to create a full EC, which I can flash on the mainboard chip with the raspberry pi?, or does an open source EC already exist for the T420 (I just found one for T400 on libreboot). Is the EC store on another chip? I can write a tutorial for the webpage about flashing the T420 with raspberry pi's SPI, if required let me know. Additionally I try to use the me_cleaner to reduce the ME code to a minimum. Thanks in advance! Regards Robert

1 0

ASUS KFSN4-DRE Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 08 Nov '17

08 Nov '17

The ASUS KFSN4-DRE fails verification for branch master as of commit 5bcb23ebbb85d9616f8ba2a82e48178559b350e6 The following tests failed: BOOT_FAILURE Commits since last successful test: 5bcb23e mb/google/poppy/variants/nautilus: Enable Dialog DA7219 support 351059a mb/google/poppy/variants/nautilus: add nhlt support 83670c5 soc/intel/kabylake: Add Dialog da7219 NHLT blob support See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Zoran Stojsavljevic 07 Nov '17

07 Nov '17

> The vbt.dat (5kB) is need by GOP driver. But we haven’t done anything with that yet. Mario, Your English is much better, as I remembered it. Way! ;-) And from me the present/gift for/to the cause: https://en.wikipedia.org/wiki/Coreboot/VBT Zoran On Mon, Nov 6, 2017 at 10:32 AM, Scheithauer, Mario < Mario.Scheithauer(a)siemens.com> wrote: > Hi all, > > > > > • Are you able to boot Yocto with the current combination you > have? > > We haven’t tested Yocto, but we can boot a Lubuntu. > > > Where did you obtain a VBIOS file? > > Intel provides the VBIOS in its MRx packages for the CRBs. You need to > contact Intel for this. > > > • Is it specifically VBIOS, or is it a VBT.dat file? Or are you > running SeaVGABIOS? > > I think you need a complete VBIOS bxt_1003.dat (64kB) for SeaBios. > > The vbt.dat (5kB) is need by GOP driver. But we haven’t done anything with > that yet. > > > > Mario > > > > > > *Von:* Tahnia Lichtenstein [mailto:unlich@gmail.com] > *Gesendet:* Freitag, 3. November 2017 13:46 > *An:* Scheithauer, Mario (DF MC MTS R&D SWRT 4); coreboot(a)coreboot.org > > *Betreff:* Re: [coreboot] Problems changing payload on Intel Leaf Hill > > > > Hi Mario, > > > > Thank you very much for sharing, that already helps a lot!! I can spot > quite a lot of differences to my own build settings. > > > > I've been pursuing a Grub2 payload in the meantime (no success so far), > will now return to SeaBIOS and try and incorporate the necessary changes > you suggested. > > > > Just a couple of questions so far: > > - Are you able to boot Yocto with the current combination you have? > - I have all the blobs around coreboot, except the VBIOS... I have > tried all the options in https://www.coreboot.org/VGA_support, but I > suspect the reference bootloader images provided by Intel does not use a > VBIOS file. I also cannot find a suitable VBIOS on Intel's website. (By the > way, thanks for the FIT decomposition tip, I did not know this was > possible... I took great pains to find the correct blobs on Intel's > website, would have been much easier to just use FIT!) Where did you obtain > a VBIOS file? > - Is it specifically VBIOS, or is it a VBT.dat file? Or are you > running SeaVGABIOS? > > Many thanks again! > > > > Best regards, > > Tahnia > > > > On Fri, Nov 3, 2017 at 2:01 PM, Scheithauer, Mario < > Mario.Scheithauer(a)siemens.com> wrote: > > > Hi Cameron, > > > Did you modify the FSP blobs at all? > Yes, we made some adjustments for our mainboard (mc_apl1). > But they shouldn’t play a decisive role (power states, PCIe settings). > > > The reason I ask is that my coreboot build hangs in the FspSiliconInit(). > Then you will get pretty far. > We are currently still using the MR2 FSP package for APL-I. > As IFWI template we use the BIOS version v178.10 for the CRBs. > These components are provided by Intel. > That’s it. The CRB should boot with this combination. > > Mario > > > -----Ursprüngliche Nachricht----- > > Von: Cameron Craig [mailto:Cameron.Craig@exterity.com] > > Gesendet: Freitag, 3. November 2017 11:51 > > An: Scheithauer, Mario (DF MC MTS R&D SWRT 4); ahW@n > > Cc: coreboot(a)coreboot.org > > Betreff: Re: [coreboot] Problems changing payload on Intel Leaf Hill > > > > > Hi Mario, > > > > I've been attempting to build coreboot(master) for the Leaf Hill CRB, > with no > > success so far. > > > > Did you modify the FSP blobs at all? > > I had a look at your config, the filenames "FSP_MR2_M_ECC_MOD" caught my > > eye. > > > > The reason I ask is that my coreboot build hangs in the FspSiliconInit(). > > > > Cheers, > > Cameron > > > > > > > > Cameron Craig | Graduate Software Engineer | Exterity Limited > > tel: +44 1383 828 250 | fax: | mobile: > > e: Cameron.Craig(a)exterity.com | w: www.exterity.com > > > > > > > > ____________________________________________________________________ > > __ > > This email has been scanned by the Symantec Email Security.cloud service. > > For more information please visit http://www.symanteccloud.com > > ____________________________________________________________________ > > __ > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Cameron Craig 07 Nov '17

07 Nov '17

Hi Ahwan, >Checked the postcodes and yes, last code is 0x93. >And from the debug I noticed there are a lot of "CBFS: Unmatched xxxxx" >print out. >Do you get similar outputs from yours? Yes, I get a similar output (attached). I'm not concerned about the "CBFS: Unmatched..." debug messages (still returns 0 for "Success") [1]. But what I would be concerned about is if you get a log message "xxx not found". If it describes something you are expecting it to find, then there is a problem. [1]: https://github.com/coreboot/coreboot/blob/fec0328c5f653233859d4aec7dae0b94a… Cheers, Cameron Cameron Craig | Graduate Software Engineer | Exterity Limited tel: +44 1383 828 250 | fax: | mobile: e: Cameron.Craig(a)exterity.com | w: www.exterity.com ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________

2 1

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Tahnia Lichtenstein 07 Nov '17

07 Nov '17

Hi Mario, Cameron, coreboot folks, Thank you all so much for the help!! I managed to get SeaBIOS to work (technically it was running all along, there was just no output and hence no evidence to believe it ran.) As I mentioned previously, I am not running coreboot master branch, instead using the Intel-distributed variant based on an outdated coreboot commit (Apollo_Lake_CB_MR1). So my config might not be useful to all who are using coreboot master. But it is attached nonetheless. I had previously tried including the bxt_1003.dat, when this didn't work I tried using vbt.dat, but I think I might have configured them in the wrong places. It works when I include both. Also, Craig, thanks! I previously used the wrong bootloader image to try and extract the VBIOS with the UEFItool (tried using Intel's precompiled coreboot image with UEFI payload, named "coreboot.release.SPI.Bx.Win.bin", which does not contain any VBIOS image, for some reason). It does work when I extract it from Intel's UEFI image, named "APLI_IFWI_X64_R_113_40E_SPI.bin". On my build, it was not necessary to manually update the CBFS locations for SeaBIOS. But it was necessary to update the MMIO mapping for debug UART output. Brilliant, I would never have figured this out. In which document do I find the MMIO mapping again? I think I did read it at some point but it got lost between the mass of information! (I'm new to Intel architecture, coreboot, all payloads, and bootloader development in general! Massive learning curve, too much information to absorb at once!) I suspect similar changes would be required to witness output from Tianocore, will try that soon. Thanks to all again, I really really appreciate it! (Would send virtual beer by manner of thanks, is that acceptable?) Tahnia On Mon, Nov 6, 2017 at 11:32 AM, Scheithauer, Mario < Mario.Scheithauer(a)siemens.com> wrote: > Hi all, > > > > > • Are you able to boot Yocto with the current combination you > have? > > We haven’t tested Yocto, but we can boot a Lubuntu. > > > Where did you obtain a VBIOS file? > > Intel provides the VBIOS in its MRx packages for the CRBs. You need to > contact Intel for this. > > > • Is it specifically VBIOS, or is it a VBT.dat file? Or are you > running SeaVGABIOS? > > I think you need a complete VBIOS bxt_1003.dat (64kB) for SeaBios. > > The vbt.dat (5kB) is need by GOP driver. But we haven’t done anything with > that yet. > > > > Mario > > > > > > *Von:* Tahnia Lichtenstein [mailto:unlich@gmail.com] > *Gesendet:* Freitag, 3. November 2017 13:46 > *An:* Scheithauer, Mario (DF MC MTS R&D SWRT 4); coreboot(a)coreboot.org > *Betreff:* Re: [coreboot] Problems changing payload on Intel Leaf Hill > > > > Hi Mario, > > > > Thank you very much for sharing, that already helps a lot!! I can spot > quite a lot of differences to my own build settings. > > > > I've been pursuing a Grub2 payload in the meantime (no success so far), > will now return to SeaBIOS and try and incorporate the necessary changes > you suggested. > > > > Just a couple of questions so far: > > - Are you able to boot Yocto with the current combination you have? > - I have all the blobs around coreboot, except the VBIOS... I have > tried all the options in https://www.coreboot.org/VGA_support, but I > suspect the reference bootloader images provided by Intel does not use a > VBIOS file. I also cannot find a suitable VBIOS on Intel's website. (By the > way, thanks for the FIT decomposition tip, I did not know this was > possible... I took great pains to find the correct blobs on Intel's > website, would have been much easier to just use FIT!) Where did you obtain > a VBIOS file? > - Is it specifically VBIOS, or is it a VBT.dat file? Or are you > running SeaVGABIOS? > > Many thanks again! > > > > Best regards, > > Tahnia > > > > On Fri, Nov 3, 2017 at 2:01 PM, Scheithauer, Mario < > Mario.Scheithauer(a)siemens.com> wrote: > > > Hi Cameron, > > > Did you modify the FSP blobs at all? > Yes, we made some adjustments for our mainboard (mc_apl1). > But they shouldn’t play a decisive role (power states, PCIe settings). > > > The reason I ask is that my coreboot build hangs in the FspSiliconInit(). > Then you will get pretty far. > We are currently still using the MR2 FSP package for APL-I. > As IFWI template we use the BIOS version v178.10 for the CRBs. > These components are provided by Intel. > That’s it. The CRB should boot with this combination. > > Mario > > > -----Ursprüngliche Nachricht----- > > Von: Cameron Craig [mailto:Cameron.Craig@exterity.com] > > Gesendet: Freitag, 3. November 2017 11:51 > > An: Scheithauer, Mario (DF MC MTS R&D SWRT 4); ahW@n > > Cc: coreboot(a)coreboot.org > > Betreff: Re: [coreboot] Problems changing payload on Intel Leaf Hill > > > > > Hi Mario, > > > > I've been attempting to build coreboot(master) for the Leaf Hill CRB, > with no > > success so far. > > > > Did you modify the FSP blobs at all? > > I had a look at your config, the filenames "FSP_MR2_M_ECC_MOD" caught my > > eye. > > > > The reason I ask is that my coreboot build hangs in the FspSiliconInit(). > > > > Cheers, > > Cameron > > > > > > > > Cameron Craig | Graduate Software Engineer | Exterity Limited > > tel: +44 1383 828 250 | fax: | mobile: > > e: Cameron.Craig(a)exterity.com | w: www.exterity.com > > > > > > > > ____________________________________________________________________ > > __ > > This email has been scanned by the Symantec Email Security.cloud service. > > For more information please visit http://www.symanteccloud.com > > ____________________________________________________________________ > > __ > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > > >

1 0

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Tahnia Lichtenstein 07 Nov '17

07 Nov '17

Hi Ahwan, CONFIG_VGA_BIOS_ID="1106,3230" (how to know and confirm this is my ID? is this important?) Run a linux instance on the board (using the BIOS/bootloader that came with the board) and run the following command in a linux terminal: lspci -nn This will give you a list of PCI devices with their device ID's, search for the VGA device in this list. On my Oxbow Hill the VGA device's ID is 8086,5a84 (I think most onboard Intel devices start with 8086, and I think Intel's display devices are standardised to be either 5a84 or 5a85... but I am speaking under correction). I have this configured (and at last it's working, yay!!!! Much joy!) CONFIG_VGA_BIOS_ID="8086,5a84" # CONFIG_ONBOARD_VGA_IS_PRIMARY is not set CONFIG_VGA_BIOS=y CONFIG_VGA_BIOS_FILE="../intel/fsp/mainboard/leafhill/bxt_1003.dat" (this file came with the Intel distribution of coreboot, named Apollo_Lake_CB_MR1, Apollo_Lake_CB_MR2 or Apollo_Lake_CB_MR3. You can ask your FAE for these folders, as I think the links are no longer available for download anymore.) CONFIG_GOP_SUPPORT=y CONFIG_VBT_FILE="../intel/fsp/mainboard/leafhill/vbt.dat" My config file is attached, but I am not currently using coreboot master, I am using the above mentioned Intel variants of coreboot (based on very outdated coreboot commit!) So there will be drastic differences with regards to coreboot architecture, and not sure if my VGA setup will work with coreboot master branch. Not sure yet if I am going to migrate to coreboot master branch. Good luck :) Tahnia On Tue, Nov 7, 2017 at 5:59 AM, ahW@n via coreboot <coreboot(a)coreboot.org> wrote: > Hi Cameron, > > Checked the postcodes and yes, last code is 0x93. > And from the debug I noticed there are a lot of *"CBFS: Unmatched xxxxx"* > print out. > Do you get similar outputs from yours? > > BTW, still wondering I was using the correct binaries in my config or not. > What about yours settings for these ... :- > CONFIG_VGA_BIOS_ID="1106,3230" (how to know and confirm this is my > ID? is this important?) > CONFIG_VGA_BIOS_FILE="3rdparty/blobs/mainboard/intel/apollolake_rvp/Vbt.bsf" > (I have Vbt.bin and Vbt.bsf downloaded from Intel FSP_MR3, am I pionting to > the correct one?) > CONFIG_FMDFILE="src/mainboard/intel/leafhill/ > leafhill.$(CONFIG_COREBOOT_ROMSIZE_KB).fmd" (OK to use fmd from leafhill?) > CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/ > intel/apollolake_rvp/Vbt.bin" > CONFIG_CHECKLIST_DATA_FILE_LOCATION="src/vendorcode/intel/fsp/fsp2_0/checklist" > (I actually didn't see this file exist, is this important?) > > Thank you. > - ahwan > > > On Mon, Nov 6, 2017 at 10:45 PM, Cameron Craig <Cameron.Craig(a)exterity.com > > wrote: > >> Hi Ahwan, >> >> >coreboot-4.6-1941-g383ef6e-dirty Wed Nov 1 21:59:08 UTC 2017 ramstage >> >starting... >> >BS: BS_PRE_DEVICE times (us): entry 2 run 2 exit 0 >> >FMAP: Found "FLASH" version 1.1 at 300000. >> >FMAP: base = 0 size = 1000000 #areas = 11 >> >FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size >> >b9d800 >> >CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) >> >CBFS: Locating 'fsps.bin' >> >CBFS: Found @ offset 717c0 size 2a000 >> >FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size >> >b9d800 >> >CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) >> >CBFS: Locating 'vbt.bin' >> >CBFS: Found @ offset 9b800 size 1a00 >> > >> > >> >I think I totally lost :( >> >please let me know if you have any idea on how I can debug further. >> >Thank you. >> > >> >-ahwan >> >> To me this looks like the FspSiliconInit() hang that a few of us are >> experiencing with the ApolloLake FSP MR3. >> >> This has been raised with Intel. In the meantime I'm trying to get my >> hands on the MR2 FSP (which should just work) through my Intel rep. >> >> You could turn on postcodes in the coreboot menuconfig, and if the last >> postcode is 0x93 (about to call FspSiliconInit()), then you might have the >> same problem. >> >> Cheers, >> Cameron >> >> >> >> >> Cameron Craig | Graduate Software Engineer | Exterity Limited >> tel: +44 1383 828 250 | fax: | mobile: >> e: Cameron.Craig(a)exterity.com | w: www.exterity.com >> >> >> >> ______________________________________________________________________ >> This email has been scanned by the Symantec Email Security.cloud service. >> For more information please visit http://www.symanteccloud.com >> ______________________________________________________________________ >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Cameron Craig 07 Nov '17

07 Nov '17

Hi Ahwan, >coreboot-4.6-1941-g383ef6e-dirty Wed Nov 1 21:59:08 UTC 2017 ramstage >starting... >BS: BS_PRE_DEVICE times (us): entry 2 run 2 exit 0 >FMAP: Found "FLASH" version 1.1 at 300000. >FMAP: base = 0 size = 1000000 #areas = 11 >FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size >b9d800 >CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) >CBFS: Locating 'fsps.bin' >CBFS: Found @ offset 717c0 size 2a000 >FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size >b9d800 >CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) >CBFS: Locating 'vbt.bin' >CBFS: Found @ offset 9b800 size 1a00 > > >I think I totally lost :( >please let me know if you have any idea on how I can debug further. >Thank you. > >-ahwan To me this looks like the FspSiliconInit() hang that a few of us are experiencing with the ApolloLake FSP MR3. This has been raised with Intel. In the meantime I'm trying to get my hands on the MR2 FSP (which should just work) through my Intel rep. You could turn on postcodes in the coreboot menuconfig, and if the last postcode is 0x93 (about to call FspSiliconInit()), then you might have the same problem. Cheers, Cameron Cameron Craig | Graduate Software Engineer | Exterity Limited tel: +44 1383 828 250 | fax: | mobile: e: Cameron.Craig(a)exterity.com | w: www.exterity.com ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________

2 1

ASUS KFSN4-DRE Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 06 Nov '17

06 Nov '17

The ASUS KFSN4-DRE fails verification for branch master as of commit 1ab8c01050c539b1af9edc5d2fd13a79bb71d053 The following tests failed: BOOT_FAILURE Commits since last successful test: 1ab8c01 gru: Fix and export SPK_PA_EN GPIO for Scarlet 59e9080 endian: Fix bebitenc() to actually encode big-endian See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] AMG G-series - Steppe eagle - PCI IRQ Routing to 8259 PIC
by Rudolf Marek 06 Nov '17

06 Nov '17

Hi Abhishek, Please can you check if you programmed the ELCR registers 0x4d0/0x4d1 to level for PCI registers? In other words, you should set bits to 1 to corresponding IRQ to be level triggered. Eg. for IRQ 5, you need to write 1 to bit5 to 8bit I/O port 0x4d0 For IRQ 9, you need to program bit 1 of 0x4d1 You can also check the PCI status register (reg of Ethernet device, there is "interrupt pending" bit, to verify that the device actually tries to trigger the IRQ. Also, you can check if INTX disable is not set in PCI register by accident. lspci -vvv Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- You should see DisINTx- and INTx+ (if interrupt is pending). The local APIC has also individual vector interrupt disable bits (but you say local apic is disabled, normally for te local APIC should have programmed EXTINT mode on LINT0, or virtual wire in IOAPIC) Has this platform more than 1 IOAPIC, or just IOAPIC in SB? Thanks Rudolf

2 1

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2017