coreboot September 2018

coreboot@coreboot.org

59 participants
160 discussions

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Nico Huber 26 Sep '18

26 Sep '18

Hi, On 9/26/18 9:19 AM, Jose Trujillo via coreboot wrote: > No, don't change it, you change the size of coreboot only if during the > building process "make" complain that there is not enough space but in > your case your build was already successful leave it like that. this advice seems very weird to me. I'm not experienced with Bay Trail. But unless there is a bug in the Bay Trail code, you should always set the correct ROM_SIZE (to the full flash chip size). Otherwise you may introduce bugs in code that relies on this setting (e.g. saving the MRC cache might fail and so would S3 resume). CBFS_SIZE however is the setting to adjust according to your needs. It should be at most the size of the BIOS region. > > In the rare circumstance that more space is required you can increase > coreboot size to 4MB and istill will fit into your system 5MB of space > available. > > "ifdtool" will inject coreboot in the top of the BYT_orig.bin and save > as BYT_orig.bin.new that you can flash to your system. I assume this doesn't work oob if you set ROM_SIZE correctly. But it is unnecessary to craft a single file by hand. You can either only flash the BIOS region (recommended) or add the other regions in coreboot's config (HAVE_{IFD,ME,GBE}_BIN). Nico

2 1

Re: [coreboot] how users can control additional features?
by Patrick Rudolph 26 Sep '18

26 Sep '18

On 2018-09-23 12:22 PM, Nico Huber wrote: > Hi Lynxis, > > TLDR; I would prefer NVRAM settings and reading (but not writing) NVRAM > from ASL code directly. > > On 9/15/18 10:05 PM, Alexander Couzens wrote: >> I would like to merge https://review.coreboot.org/c/coreboot/+/12888 >> But how the user can control this feature (and all other "special >> features")? > > ideally at compile time, IMHO. But if you need runtime configuration > `nvramtool` is the obvious answer. > >> Should coreboot add an acpi function and the OS offer a UI >> (e.g. /sys/class/foo/feature)? > That'd be great. It does not even have to be ACPI aware. > I don't see where you would store that setting then. If it should sur- > vive a reboot, it has to be backed by NVRAM. But no matter what that is > (CMOS as of now or maybe flash in the future), it will be really hard > to write from ASL code. > >> Add a nvram option? (and set a acpi variable based on nvram, so we >> don't need SMM) > > Yes, that seems to be the right way. I agreed to do it in SMM because > reading NVRAM seemed hard to do in ASL. I'm not convinced any more. > Setting a variable during boot would have the downside that you always > have to reboot before a change takes effect. > > One reason not to implement option-table reading in ASL was that the > CMOS option table seems legacy. Though, nobody is really working on > a replacement (some people use the flash for settings now but most > ppl. focus on payload configuration and not coreboot). > > A hybrid solution might do it too: Instead of writing a variable for > ACPI, coreboot could emit an ASL method that implements the NVRAM read > (a method, to be future-proof). For the current option table, coreboot > would simply have to translate the cmos.layout with its bit locations > into a OperationRegion/Field definition and such ASL method would just > return one of the entries. > Using OperationRegion/Field definition is a bad idea as the OS likes to cache field elements. By using nvramtool the real NVRAM content could be changed, without the OS being notified. Ofc this is not a problem with flash backed NVRAM settings. > ... thinking further about it, the cmos.layout translation could also > be done at compile time. Heck, we would just have to add some code to > nvramtool to output the OpRegion/Field definition. The more I think > about it, the easier it seems to solve ;) > > OTOH, translating it at compile time would mean that we store the > cmos.layout redundantly in the coreboot image. Well, one would have > to replace cmos_layout.bin and cmos_layout.aml together in case (again > something that nvramtool could learn). > > Nico While it's possible to add those feature I would like to see a flash based solution, that also works on non x86 and is more flexible. For example: I don't want to hardcode the EC settings in each mainboard cmos.layout. The same for southbridge (ahci/ide) and northbridge (hyperthreading) related settings. It would be great if the build system picks up all the layout files, does a sanity check on them and then generates a board specific NV settings layout file. Patrick

2 1

Re: [coreboot] Loading Linux payloads on RISC-V
by 王翔 26 Sep '18

26 Sep '18

This elf file is position-independent and can be loaded to any location. We can add a simple script to handle it. 1. Convert vmlinux to binary by objcopy, the binary file name is flat_file 2. Write a simple assembly file (tmp.S), convert binary to object, the file name is obj_file ``` .section .text .globl _start _start: .incbin "flat_file" ``` command: as tmp.S -o obj_file 3. Relink. Linker script like this(tmp.ld): ``` ENTRY(_start) SECTIONS { . = target_address; .text : { *(.text) } } ``` command: ld -T tmp.ld obj_file 在2018年09月25 20时51分, "Philipp Hug"<philipp(a)hug.cx>写道: Am Di., 25. Sep. 2018 um 13:50 Uhr schrieb Jonathan Neuschäfer <j.neuschaefer(a)gmx.net>: Would FIT support require discussion/cooperation with other projects like Linux or u-boot? What seems to be missing is the kernel image format to be used within the FIT. e.g. look at arm64: https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/head.S#L73 https://github.com/coreboot/coreboot/blob/master/src/arch/arm64/fit_payload… Philipp

2 1

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Nico Huber 26 Sep '18

26 Sep '18

Hi Zvika, On 9/25/18 10:59 PM, Zvi Vered wrote: > Thank you very much for the detail information. > The output of ifdtool in layout.txt is: > 00000000:00000fff fd > 00300000:007fffff bios > 00001000:002fffff me > > So the original bios size is 0x500000 = 5MB > > You wrote: > if the size of the original BIOS is bigger or equal than coreboot build > you are good to go ahead. > > The original "ROM chip size" in menuconfig is 2MB. Should I change it to > 8MB ? yes, and CBFS_SIZE should be set to something <= 0x500000. > > I'm aware my board is not identical to the "Bayley Bay FSP-based CRB" > Should I use another board as reference ? You should use whatever reference is closest to your board. Major dif- ferences to look out for are: GPIO/pin config, embedded controller (it's unlikely that coreboot already has code for yours), how the RAM is con- nected (e.g. DIMMs or soldered down?). Well, and everything else in the mainboard's directory. If your board is not obviously similar to a supported board, you have a lot of work ahead of you. Nico > > Best regards, > Zvika > > > On Tue, Sep 25, 2018 at 10:16 AM Jose Trujillo <ce.autom(a)protonmail.com> > wrote: > >> Hello Zvika: >> >> First get the correct original full 8MB FW from the manufacturer or dump >> it from the board with the command in EFI: >> "ftp -d BYT_orig.bin" and double save it. >> >> 2.- in coreboot/util/ifdtool do make and sudo make install. >> 3.- in terminal go to the FW directory and do: "ifdtool BYT_orig.bin -f >> fw_layout.txt" >> a).- in "fw_layout.txt" you will get the BIOS area size from the >> original FW (just substract). >> b).- if the size of the original BIOS is bigger or equal than >> coreboot build you are good to go ahead. >> 4.- copy/move "BYT_orig.bin" in the directory which resides the coreboot >> folder (not inside the coreboot folder) and do: >> ifdtool -i BIOS:./coreboot/build/coreboot.rom CB_baytrail.bin >> 5.- flash it: "fpt -f CB_baytrail.bin" booting from UEFI. >> >> If the build was correctly done and followed accurately those steps the >> system should boot. >> >> Good luck, >> Jose Trujillo. >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Monday, September 24, 2018 10:18 PM, Zvi Vered <veredz72(a)gmail.com> >> wrote: >> >> Hello, >> >> I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: >> >> CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 >> Northbridge: 8086:0f00 (Bay Trail) >> Southbridge: 8086:0f1c (Bay Trail) >> IGD: 8086:0f31 (unknown) >> >> In coreboot configuration I selected: >> Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB >> The default ROM chip size is 2MB. >> This is also the size of coreboot.rom created after "make" >> >> The board has 8MB BIOS flash. >> It's delivered with a BIOS programming utility that runs under EFI shell. >> >> The original BIOS has 2 versions: rom (5MB) and bin (8MB) >> I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. >> >> I got: >> 3 - Error: ROM file size does not match existing BIOS size. >> Should I convert coreboot.rom to coreboot.bin ? How ? >> If not, how can I program coreboot.rom ? >> >> Thank you, >> Zvika >> >> >> > >

1 0

Re: [coreboot] SPI controller and Lock bits
by Nico Huber 26 Sep '18

26 Sep '18

Hi Youness, Am 26.09.18 um 01:30 schrieb Youness Alaoui: > There's a couple of things happening here : > First, the FLOCKDN bit is set which prevents us from enabling the > write protection. the BIOS Interface lock down is controlled by the > chipset_lockdown config variable, but the FLOCKDN is not behind a > config variable. > The second thing is that if I wanted to use the protected ranges > feature to lock specific regions, they are all getting locked using > the discrete lock register even while being unused. The locking of the > protected ranges was added in this change : > https://review.coreboot.org/c/coreboot/+/21064 and it passed without > notice among the move that the commit was supposed to do. > > The commit states that the lockdown is meant to "support platform > security guidelines", but I think that this is not actually good > because coreboot leaves everything read-write and locks down the > registers so we can't make it read-only. I think that the security > guidelines would say to disable the write protection before locking > the registers down. the code is flawed, I'm not sure if I noticed during review, probably only when it was too late. It seems to me that these "security guide- lines" have two issues: 1. They are written with UEFI style security in mind (e.g. updates in SMM). 2. They are meant to be understandable for a humble reader and hence can't comprise all the details (like threat models etc.) for real security. They seem to be for getting-a-green-light-in-CHIPSEC security. Not sure how CHIPSEC would react if the individual PRR locks aren't set. But feel free to remove the locking of unset PR registers on any path where we don't set FLOCKDN. > > Either way, I'm going to need to add a way to make this configurable, > so my main questions here are : > - Should I create a new config variable to decide on whether or not to > lock the spi registers and another one to decide on whether or not to > lock the protected ranges ? I would prefer to have a single Kconfig option like INTEL_CHIPSET_ LOCKDOWN (sb/intel/common) but for FLOCKDN only. This option for the whole chipset lockdown on older platforms only made sense because the lockdown was done in SMM to allow the payload to call into coreboot. As SMM is not a good idea and reimplementing the whole lockdown in the pay- load isn't either, just skipping flash locking bits seems to be the right way. Please take care that this only affects a clean boot, i.e. not a resume when the payload is not going to be executed. > - Should I make the chipset_lockdown (currently used for locking the > BIOS CNTL register from LPC and SPI controllers) into an OR-ed flags > variable where we can say : chipset_lockdown = LOCKDOWN_COREBOOT | > LOCKDOWN_SPI | LOCKDOWN_PROTECTED_RANGES ? The current `chipset_lockdown` option is nonsense. 1. during review when I noticed a flaw in the LOCKDOWN_FSP path, the answer was something like "but we set it to coreboot for all boards in the tree". So it seems the author didn't even intend to add an option but just did it because eve- rything else was an option? 2. Having to maintain two variants in core- boot makes it harder to keep it secure. Please just kill this option and all but the LOCKDOWN_COREBOOT path. Then add the Kconfig option men-tioned above on this path. > - Should I make a single new config variable to decide what to > lockdown (LPC_BIOS, SPI_BIOS, SPI_BAR, SPI_PROTECTED_RANGES) and only > set them if the CHIPSET_LOCKDOWN_COREBOOT is set ? And if > chipset_lockdown is set to CHIPSET_LOCKDOWN_FSP not lockdown anything > at all ? > - Do we want to keep the protected ranges locked down at all, have > them configurable or completely remove that as I don't see the point > in using the discrete lock register ? I would prefer to have the PR registers locked right after they are set, in the same function. Also remove fast_spi_pr_dlock() or at least fix the comment above it, it seems the author didn't understand the meaning of "discrete" in this context. Optionally, if CHIPSEC complains other- wise, set the discrete locks for empty PRRs before setting FLOCKDN. AIUI, FLOCKDN always locks the PRRs. > Once I see a consensus on what's the best way to move forward, I'll > implement it and push it for review. Thank you for looking into this it would be very nice to have this cleaned up. I guess if we do it right, we'll have less code that is more useful. > Note: I think these only affect hardware sequencing though so I assume > someone could always use software sequencing to do the writes. As long > as the FLOCKDN bit isn't set though, I could remove all write-related > opcodes from the software sequencing register, which would also > prevent someone using swseq to do writes. In the past, we (at secunet) had FLOCKDN always set in the payload just like you plan to do. We also made it the payload's responsibility to set the OPMENU accordingly before setting FLOCKDN. You can have write op- codes in the menu, they won't work on protected regions. But if you have a partially protected flash (e.g. vboot), they are still useful. Also note that swseq is not an option anymore since Skylake (IIRC, the ME protects the flash-cycle go bit in its default configuration). With only hwseq, you can only access the flash chip's first status register which makes many security features unusable. So we have to rely on the protected regions :-/ I hope Intel is going to fix that for future plat- forms (or with an ME update if that could add more hwseq commands). Nico

1 0

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Jose Trujillo 26 Sep '18

26 Sep '18

You are welcome, No, don't change it, you change the size of coreboot only if during the building process "make" complain that there is not enough space but in your case your build was already successful leave it like that. In the rare circumstance that more space is required you can increase coreboot size to 4MB and istill will fit into your system 5MB of space available. "ifdtool" will inject coreboot in the top of the BYT_orig.bin and save as BYT_orig.bin.new that you can flash to your system. Please follow Nico's recommendations and be aware that is highly likely that the system will not boot the first time and you will need an external programmer for restoring the system. Have a good day, Jose Trujillo. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, September 25, 2018 11:59 PM, Zvi Vered <veredz72(a)gmail.com> wrote: > Hi Jose, > > Thank you very much for the detail information. > The output of ifdtool in layout.txt is: > 00000000:00000fff fd > 00300000:007fffff bios > 00001000:002fffff me > > So the original bios size is 0x500000 = 5MB > > You wrote: > if the size of the original BIOS is bigger or equal than coreboot build you are good to go ahead. > > The original "ROM chip size" in menuconfig is 2MB. Should I change it to 8MB ? > > I'm aware my board is not identical to the "Bayley Bay FSP-based CRB" > Should I use another board as reference ? > > Best regards, > Zvika > > On Tue, Sep 25, 2018 at 10:16 AM Jose Trujillo <ce.autom(a)protonmail.com> wrote: > >> Hello Zvika: >> >> First get the correct original full 8MB FW from the manufacturer or dump it from the board with the command in EFI: >> "ftp -d BYT_orig.bin" and double save it. >> >> 2.- in coreboot/util/ifdtool do make and sudo make install. >> 3.- in terminal go to the FW directory and do: "ifdtool BYT_orig.bin -f fw_layout.txt" >> a).- in "fw_layout.txt" you will get the BIOS area size from the original FW (just substract). >> b).- if the size of the original BIOS is bigger or equal than coreboot build you are good to go ahead. >> 4.- copy/move "BYT_orig.bin" in the directory which resides the coreboot folder (not inside the coreboot folder) and do: >> ifdtool -i BIOS:./coreboot/build/coreboot.rom CB_baytrail.bin >> 5.- flash it: "fpt -f CB_baytrail.bin" booting from UEFI. >> >> If the build was correctly done and followed accurately those steps the system should boot. >> >> Good luck, >> Jose Trujillo. >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Monday, September 24, 2018 10:18 PM, Zvi Vered <veredz72(a)gmail.com> wrote: >> >>> Hello, >>> >>> I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: >>> >>> CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 >>> Northbridge: 8086:0f00 (Bay Trail) >>> Southbridge: 8086:0f1c (Bay Trail) >>> IGD: 8086:0f31 (unknown) >>> >>> In coreboot configuration I selected: >>> Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB >>> The default ROM chip size is 2MB. >>> This is also the size of coreboot.rom created after "make" >>> >>> The board has 8MB BIOS flash. >>> It's delivered with a BIOS programming utility that runs under EFI shell. >>> >>> The original BIOS has 2 versions: rom (5MB) and bin (8MB) >>> I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. >>> >>> I got: >>> 3 - Error: ROM file size does not match existing BIOS size. >>> Should I convert coreboot.rom to coreboot.bin ? How ? >>> If not, how can I program coreboot.rom ? >>> >>> Thank you, >>> Zvika

1 0

Coreboot, TPMs and Payloads
by Jorge Fernandez Monteagudo 26 Sep '18

26 Sep '18

Hi, I have a quick question. Is there any code in Coreboot to extend the payload to be loaded in the PCR0 if the TPM is enabled? I've been able to see the startup command executed but I don't know if anything else is implemented. Maybe is this implemented in some staging Coreboot branch? Any hint is welcome! Thanks! Jorge

1 0

SPI controller and Lock bits
by Youness Alaoui 25 Sep '18

25 Sep '18

Hi, I'm trying to add a way to lock the SPI flash to be read-only via software *after* coreboot boots. The scenario is basically with using Heads, you could authenticate to it (with a yubikey/nitrokey/librem key) then be able to flash a new rom (update your BIOS), but once you boot an OS, Heads would first lock the flash so it can't be written to. This should add some security to avoid any malware writing to the flash, or someone booting into a USB stick and using that to flash a malicious BIOS, but still gives the user the freedom of updating their flash whenever they want to. The problem is that I can't make the flash read-only because the SPI interface is already locked down by coreboot (see src/soc/intel/skylake/lockdown.c and src/soc/intel/common/block/fast_spi/fast_spi.c). There's a couple of things happening here : First, the FLOCKDN bit is set which prevents us from enabling the write protection. the BIOS Interface lock down is controlled by the chipset_lockdown config variable, but the FLOCKDN is not behind a config variable. The second thing is that if I wanted to use the protected ranges feature to lock specific regions, they are all getting locked using the discrete lock register even while being unused. The locking of the protected ranges was added in this change : https://review.coreboot.org/c/coreboot/+/21064 and it passed without notice among the move that the commit was supposed to do. The commit states that the lockdown is meant to "support platform security guidelines", but I think that this is not actually good because coreboot leaves everything read-write and locks down the registers so we can't make it read-only. I think that the security guidelines would say to disable the write protection before locking the registers down. Either way, I'm going to need to add a way to make this configurable, so my main questions here are : - Should I create a new config variable to decide on whether or not to lock the spi registers and another one to decide on whether or not to lock the protected ranges ? - Should I make the chipset_lockdown (currently used for locking the BIOS CNTL register from LPC and SPI controllers) into an OR-ed flags variable where we can say : chipset_lockdown = LOCKDOWN_COREBOOT | LOCKDOWN_SPI | LOCKDOWN_PROTECTED_RANGES ? - Should I make a single new config variable to decide what to lockdown (LPC_BIOS, SPI_BIOS, SPI_BAR, SPI_PROTECTED_RANGES) and only set them if the CHIPSET_LOCKDOWN_COREBOOT is set ? And if chipset_lockdown is set to CHIPSET_LOCKDOWN_FSP not lockdown anything at all ? - Do we want to keep the protected ranges locked down at all, have them configurable or completely remove that as I don't see the point in using the discrete lock register ? Once I see a consensus on what's the best way to move forward, I'll implement it and push it for review. Note: I think these only affect hardware sequencing though so I assume someone could always use software sequencing to do the writes. As long as the FLOCKDN bit isn't set though, I could remove all write-related opcodes from the software sequencing register, which would also prevent someone using swseq to do writes. Thanks, Youness.

1 0

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Zvi Vered 25 Sep '18

25 Sep '18

Hi Jose, Thank you very much for the detail information. The output of ifdtool in layout.txt is: 00000000:00000fff fd 00300000:007fffff bios 00001000:002fffff me So the original bios size is 0x500000 = 5MB You wrote: if the size of the original BIOS is bigger or equal than coreboot build you are good to go ahead. The original "ROM chip size" in menuconfig is 2MB. Should I change it to 8MB ? I'm aware my board is not identical to the "Bayley Bay FSP-based CRB" Should I use another board as reference ? Best regards, Zvika On Tue, Sep 25, 2018 at 10:16 AM Jose Trujillo <ce.autom(a)protonmail.com> wrote: > Hello Zvika: > > First get the correct original full 8MB FW from the manufacturer or dump > it from the board with the command in EFI: > "ftp -d BYT_orig.bin" and double save it. > > 2.- in coreboot/util/ifdtool do make and sudo make install. > 3.- in terminal go to the FW directory and do: "ifdtool BYT_orig.bin -f > fw_layout.txt" > a).- in "fw_layout.txt" you will get the BIOS area size from the > original FW (just substract). > b).- if the size of the original BIOS is bigger or equal than > coreboot build you are good to go ahead. > 4.- copy/move "BYT_orig.bin" in the directory which resides the coreboot > folder (not inside the coreboot folder) and do: > ifdtool -i BIOS:./coreboot/build/coreboot.rom CB_baytrail.bin > 5.- flash it: "fpt -f CB_baytrail.bin" booting from UEFI. > > If the build was correctly done and followed accurately those steps the > system should boot. > > Good luck, > Jose Trujillo. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, September 24, 2018 10:18 PM, Zvi Vered <veredz72(a)gmail.com> > wrote: > > Hello, > > I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: > > CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 > Northbridge: 8086:0f00 (Bay Trail) > Southbridge: 8086:0f1c (Bay Trail) > IGD: 8086:0f31 (unknown) > > In coreboot configuration I selected: > Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB > The default ROM chip size is 2MB. > This is also the size of coreboot.rom created after "make" > > The board has 8MB BIOS flash. > It's delivered with a BIOS programming utility that runs under EFI shell. > > The original BIOS has 2 versions: rom (5MB) and bin (8MB) > I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. > > I got: > 3 - Error: ROM file size does not match existing BIOS size. > Should I convert coreboot.rom to coreboot.bin ? How ? > If not, how can I program coreboot.rom ? > > Thank you, > Zvika > > >

1 0

Re: [coreboot] Flashing Coreboot on Lenovo G505s
by Anac 25 Sep '18

25 Sep '18

On 09/24/2018 12:37 AM, Mike Banon wrote: > Hello Anac! I am "mikeb" , wrote these BIOS / KB9012 flashing articles > at DP wiki ;-) Thanks a lot for that work, your support and sharing all the super useful info and hints here! > Operating CH341A is very easy: I wrote the instructions for Bus Pirate > because of its' confusing pinout, and thought CH341A pretty is > obvious. But, seeing there are requests like yours from time to time, > finally I've expanded that flashing article with two extra photos, > they should explain everything - > http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate#CH… > You just need to make sure that the pins of your programmer and chip > are matching each other, e.g. CS - chip select. Also, remember to > disconnect all the power sources from your laptop (both battery and > power adapter) and before plugging the programmer into USB you need to > connect its' SOIC8 clip, and after the flashing you disconnect USB > first and SOIC8 clip second. Yes, for someone who has never done it, that sort of info is priceless. Just like your advice to put insulation tape at the bottom of CH341A - it may even save hardware from getting fried (thinking of short cables, big fingers, SOIC clip sliding off the chip and all). Thanks to Awokd, Matt and Nico, too. And of course to Taiidan for promoting the G505s. Sincerely, Anac

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
16
Older →

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 September 2018