coreboot October 2015

coreboot@coreboot.org

44 participants
137 discussions

by A. Veek

3 years, 1 month

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?

by Reiner Luett

Hi! On 30.06.2013 19:28, Christian Weinz wrote: > Maybe I didn't include the VGA option in the make menuconfig process. > How can I solve this problem? You need to add the VGA Option ROM (VGA BIOS -> Add VGA BIOS image). I've extracted it from the UEFI, but you also could use these: http://www.coreboot.org/index.php?title=ASRock_E350M1&oldid=11114 at the end of the page or you also may be able to use the default AMD fam14 (Persimmon) vbios. You will need to agree to the click through: http://wwwd.amd.com/support/vbioslic.nsf/userverify?openform http://www.coreboot.org/AMD_DB-FT1_PERSIMMON It's a pity, that bios_extract didn't work for now. You could use the AMI Aptio EFI MMTool with wine: http://win-lite.de/benutzer/fernando/BIOS-Tools/AMI_Aptio_EFI_MMTool_v4.50.… You need to extract OntarioEFIVbios with PCI ID 1002,9802 as Option ROM. Regards, Reiner --

4 years, 4 months

Re: [coreboot] On Intel Boot Guard

by Alexander Couzens

Hi Iru, we aren't still sure which boards use Intel Boot Guard and which doesn't use it. But we expect most board use it, because it's "recommended" by intel - as we dont recommend it. Also there isn't yet a test script for Intel Boot Guard. Can you post a link to that forum post? I would like to look into a x240 flash image. If you have such board it would be nice if you can send me a copy of the flash image via private mail. Cheers, lynxis -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)jabber.ccc.de mobile: +4915123277221

5 years, 9 months

FOSDEM deadlines now!

by Carl-Daniel Hailfinger

Hi, we obviously want to participate in FOSDEM. https://fosdem.org/2016/news/2015-09-24-call-for-participation/ ACT NOW! Some deadlines already expired. Some can still be managed. Main track talks: Deadline 2015-10-30 (10 days left) One hour of entertainment, huge audience. Anyone up for the challenge? Stands: Deadline 2015-11-13 (24 days left) I can send in the proposal if I'm not going to be alone there. How many tables do we want for our stand/booth(s)? Who is coming? Lightning talks: Deadline 2015-11-27 (38 days left) Short and to the point. Your 15-minute elevator pitch. Can you sell the project? All deadlines are at 23.59 UTC Developer room proposal: Deadline EXPIRED Maybe some developer room will accept talks/demos from us. Regards, Carl-Daniel

6 years

Porting Libreboot to the C201 Chromebook (veyron_speedy)

by Paul Kocialkowski

Over the past week or so, I've been working to get Libreboot running on the latest ARM Chromebook: the C201, manufactured by Asus (codename veyron_speedy). The laptop is running with a RK3288 SoC and ships with Google's version of Coreboot preinstalled. It should require no proprietary code nor any proprietary firmware load or microcode update to boot, thus it would be a good fit for Libreboot, as a fully free distribution of Coreboot. In addition to that, the device's embedded controller (that handles aspects of power management as well as the keyboard and a few other things) is a microcontroller that is also running free software: the free embedded controller firmware from Google. Aside from that, it has a soldered Wi-Fi/bluetooth BCM4354 chip (cannot be removed) that has a free driver but requires to load a proprietary firmware on the chip. However, it is easy to work around that issue and not use that chip at all, e.g. using an ath9k_htc dongle on one of the two USB ports. The GPU is a Mali T764, on which Luc has been doing some early work to have free software support for it. It is uncertain[0] how long it will take to have an usable free replacement for it, but now that there is that hardware available, free graphics for Mali T GPUs would mean having a recent laptop running fully free software, down to the firmware level, without losing any major hardware feature, something that has hardly ever been achieved yet. Thus, I believe it is of the utmost importance to back Luc up on this, even if big players like ARM are trying hard to make Lima not happen and to make it difficult for Luc to keep going. Another aspect that I still have to look at in-depth is the ability to use hardware video encoding/decoding. The RK3288 has an auxiliary processor for that task, but it is unclear whether it can be used with free software or not, though the first indications that I've gathered are positive. At this point, I've been able to boot up Debian on the device, and the xfce4 interface is quite usable. It even runs big programs like Iceweasel/Firefox and LibreOffice without inconveniences. However, it cannot run desktop environments that depend on GL acceleration, such as gnome-shell, which is a shame since those would be a good fit for it. The CPU is simply too slow for offering a decent experience with software rendering (llvmpipe). Overall, I truly hope this device creates an incentive to free the last remaining parts that can only work with proprietary software to this day. Its potential would be huge, especially since it's a good fit for travellers. With the security model inherited from Chromium OS, this would be one of the safest laptops to be used by journalists or activists. If Tails was to be ported to it, it would become easy to have a secure and anonymous setup. I have successfully fixed and compiled Coreboot and all the necessary bits and pieces for the C201, so I'll be spending the next few days sending patches, discussing how to integrate it to Libreboot and getting the actual work done. I also plan on documenting all my findings (especially things like how to access UART, how to remove the SPI flash's write protect, how to reflash it externally, etc) on my coding blog, for now. Cheers! References: [0]: http://libv.livejournal.com/27461.html -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/

6 years

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

by Stefan Reinauer

* Martin Roth <gaumless(a)gmail.com> [151026 22:51]: > I'd like to start a discussion about boards, chipsets, drivers, or > other code that can be removed from the tree. > > At the coreboot conference in Bonn, we discussed this some. I believe > that we decided to wait until the next release/branch of the coreboot > tree before removing anything. By planning ahead and deleting the > components immediately after the release, we can list the things that > have been end-of-lifed in the branch release notes. > > By discussing this on the mailing list instead of just pushing commits > to the tree, we can get better buy in from all interested parties. > > > I'd request that these be boards & chips that are no longer being > produced, and haven't been updated in a few years. > > These seem like good candidates to start the discussion: > mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470 > northbridge/via/vx800 - http://review.coreboot.org/#/c/7471 > > As far as I can tell, the last real contributions to these came in > 2009 - all the changes since then have been cleanup and modifications > for other changes across the coreboot tree. Since 2009 is really only 6ys ago, I'm a bit hesitant about the VX800 stuff (while leaving the older CN700 / CX700 in the tree) It also seems VIA gave up on coreboot at this point, so it might not matter, unless we want to work on bringing them back? Is anybody in contact with VIA at this point? > What other directories should be removed from the tree after the next release? I want to add the following boards (and their chipsets and super ios) that have been in the tree and basically unmaintained for 10+ys: * arima/hdama * digitallogic/adl855pc * ibm/e325 * ibm/e326 * iwill/dk8s2 * iwill/dk8x * newisys/khepri * tyan/s2735 * tyan/s2850 * tyan/s2875 * tyan/s2880 * tyan/s2881 * tyan/s2882 * tyan/s2885 * tyan/s2891 * tyan/s2892 * tyan/s2895 * tyan/s4880 * tyan/s4882 > Eventually it would be nice to be able to use submissions to > board-status repo to determine what's being used. We're just not at > that point yet. I think this is a hard problem. Churn on a board's or chipset's code does not necessarily coincide with a board being used or the other way around. A target might just be stable and working well. We need to get to the point where 100% of the boards in the tree are boot tested 100% of the time. Stefan

6 years, 2 months

Re: [coreboot] unbricking an Acer CB5

by robert.maucher

Hello Holger, I am locking forward to flash coreboot to a cb5-311. So I was searching for sources and information about it. The only thing i found was this cb5 unbricking mailinglist and the dev info. How far did you get with the flashing of your cb5? Do you now have corboot running your cb? Do you know some sources and information that would help me? Regards, Robert Maucher dev info: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-de…

6 years, 2 months

Re: [coreboot] Announcing coreboot 4.2

by ron minnich

Nice job all. Patrick, I'm looking forward t the next release detailing how many files and lines were removed :-) include, oh sad, the 440lx :-) ron On Fri, Oct 30, 2015 at 1:38 PM Patrick Georgi <pgeorgi(a)google.com> wrote: > (Halloween 2015 release - just as scary as that sounds) > > Dear coreboot community, > > today marks the release of coreboot 4.2, the second release on our > time based release schedule. > Since 4.1 there were 936 commits by 90 authors, increasing the code > base by approximately 17000 lines of code. We saw 35 new contributors > - welcome to coreboot! More than 34 developers were active as > reviewers in that period. > Thanks go to all contributors who helped shape this release. > > As with 4.1, the release tarballs are available at > http://www.coreboot.org/releases/. There's also a 4.2 tag and branch > in the git repository. > > This marks the first release that features a changelog comparing it to > the previous release. There was some limited testing to make sure that > the code is usable, and it boots on some devices. A structured test > plan will only become part of the release procedure of future > versions. > I'm grateful to Martin for assembling this release's changelog. > > This is also the first release that will be followed by the removal of > old, unused code. There will be a policy on how to announce > deprecation and removal of mainboard and chipset code for future > releases. > > Regards, > Patrick > > Log of commit d5e6618a4f076610e683b174c4dd5108d960c785 to > commit 439a527014fa0cb3e4ef60ba59e5c57c737b4444 > > Changes between 4.1 and 4.2 > --------------------------- > Build system: > - Store a minimized coreboot config file in cbfs instead of the full config > - Store the payload config and revision in CBFS when that info is available > - Add -compression option for cbfs-files-y. Valid entries are now -file, > -type, -align, and -compression > - Change Microcode inclusion method from building .h files to pre-built > binaries > - Update Builder tests for each commit to test utilities and run lint tools > - Many other small makefile and build changes and fixes > - Remove expert mode as a Kconfig option > > Utilities: > - Many fixes and updates to many utilities (158 total commits) > - ifdtool: Update for skylake, handle region masks correctly > - crossgcc: Update to gcc 5.2.0 > - kconfig: Add strict mode to fail on kconfig errors and warnings > - vgabios: Significant fixes to remove issues in linking into coreboot code > - Add script to parse MAINTAINERS file > - Add Kconfig lint tool > - Create a common library to share coreboot routines with utilities > - Significant changes and cleanup to cbfstool (81 commits). Major changes: > - Update cbfstool to change the internal location of FSP binaries when > adding > them > - Decompress stage files on extraction and turn them into ELF binaries > - Header sizes are now variable, containing extended attributes > - Add compression tags to all cbfs headers so all cbfs files can be > compressed > - Add and align CBFS components in one pass instead of two > - Add XIP support for X86 to relocate the romstage when it's added > - Removed locate command as it's no longer needed > - Add bootblock and cbfs_header file types so the master header knows about > them > - Prefer FMAP data to CBFS master header if FMAP data exists > - Add hashes to cbfs file metadata for verification of images > > Payloads: > - SeaBIOS: update stable release from 1.7.5 to 1.8.2 > - Libpayload had some significant changes (61 commits). Major changes: > - Add support for fmap tables > - Add support for SuperSpeed (3.0) USB hubs > - Updates and bugfixes for DesignWare OTG controller (DWC2) > - Add video_printf to print text with specified foreground & background > colors > - Updates to match changes to cbfs/cbfstool > - Add cbgfx, a library to show graphics and text on a display > - Read cbfs offset and size from sysinfo when available > > Vendorcode: > - fsp_baytrail: Support Baytrail FSP Gold 4 release > - AMD binary PI: add support for fan control > - Work to get AMD AGESA to compile correctly as 64-bit code > - Add standalone (XIP) verstage support for x86 to verify romstage > > Mainboards: > - New Mainboards: > - apple/macbookair4_2 - Sandy/Ivy Bridge with Panther / Cougar point > chipset > - asus/kgpe-d16 - AMD Family 10, SB700/SR5650 platform > - emulation/spike-riscv - RISCV virtualized platform > - google/chell - Intel Skylake chrome platform > - google/cyan - Intel Braswell chrome platform > - google/glados - Intel Skylake chrome platform > - google/lars - Intel Skylake chrome platform > - intel/kunimitsu - Intel Skylake chrome platform > - intel/sklrvp - Intel Skylake reference platform > - intel/strago - Intel Braswell chrome platform > - Cleanups of many mainboards - several patches each for: > - amd/bettong > - getac/p470 > - google/auron, google/smaug and google/veyron_rialto > - pcengines/apu1 > - siemens/mc_tcu3 > - Combine the google/veyron_(jerry, mighty, minnie, pinkie, shark & > speedy) > mainboards into the single google/veyron mainboard directory > > Console: > - Add EM100 'hyper term' spi console support in ramstage & smm > - Add console support for verstage > > ARM: > - armv7: use asm coded memory operations for 32/16 bit read/write > - Many cleanups to the nvidia tegra chips (40 patches) > > RISC-V: > - Add trap handling > - Add virtual Memory setup > > X86: > - Remove and re-add Rangeley and Ivy Bridge / panther point FSP platforms > - Update microcode update parser to use stock AMD microcode blobs from CBFS > - ACPI: Align FACS to 64 byte boundary. Fixes FWTS error > - AMD/SB700: Init devices in early boot, restore power state after power > failure. Add IDE/SATA asl code > - Add initial support for AMD Socket G34 processors > - Add tick frequency to timestamp table to calculate boot times more > accurately > - Unify X86 romstage / ramstage linking to match other platforms > - Start preparing X86 bootblock for non-memory-mapped BIOS media > - cpu/amd/car: Add Suspend to RAM (S3) support > - Native VGA init fixes on several platforms > - Significant updates to FSP 1.1 code for cleanup and cbfstool changes > - SMMhandler: on i945..nehalem, crash if LAPIC overlaps with ASEG to > prevent > the memory sinkhole smm hack > Drivers: > - Add native text mode support for the Aspeed AST2050 > - w83795: Add support for for fan control and voltage monitoring > - Intel GMA ACPI consolidation and improvements > - Set up the 8254 timer before running option ROMs > - Resource allocator: Page align memory mapped PCI resources > > Lib: > - Derive fmap name from offset/size > - Several edid fixes > - Updates to cbfs matching changes in cbfstool > > Submodules: > ----------- > 3rdparty/blobs: > Total commits: 16 > Log of commit 61d663e39bc96530900c3232ccea7365ab9dad0b to > commit aab093f0824b6d26b57a1ce220ba0d577e37ad49 > - AMD Merlin Falcon: Update to CarrizoPI 1.1.0.0 (Binary PI 1.4) > - AMD Steppe Eagle: Update to MullinsPI 1.0.0.A (Binary PI 1.1) > - Update microcode to binary blobs. Remove old .h microcode files > > 3rdparty/arm-trusted-firmware: > - No Changes > > 3rdparty/vboot: > Total commits: 41 > Log of commit fbf631c845c08299f0bcbae3f311c5807d34c0d6 to > commit d6723ed12b429834c2627c009aab58f0db20ce73 > - Update the code to determine the write protect line gpio value > - Several updates to futility and image_signing scripts > - Update crossystem to accommodate Android mosys location > - Support reboot requested by secdata > - Add NV flag to default boot legacy OS > > util/nvidia/cbootimage: > - No Changes > > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

6 years, 2 months

Re: [coreboot] coreboot binary policy

by Stefan Reinauer

* Alex Gagniuc <mr.nuke.me(a)gmail.com> [151030 18:59]: > On Fri, Oct 30, 2015 at 9:03 AM, Marc Jones <marcj303(a)gmail.com> wrote: > > It might be a good idea, but that might be too limiting > > I think historically, it has been assumed that everything in blobs is > open up for RE and modification. There are plenty of examples of > people reverse-engineering stuff in blobs, and also modifying the blob > itself [1]. First and foremost, we should protect the project, and > with that, our contributors. Alex, I think this is a great suggestion, but as I have explained to you in person before, from a perspective of reaching a legal agreement this is almost equivalent (if not more effort) than working on an agreement to open source that code to begin with. The coreboot project's objective is not to reimplement what other people have done, but to change the industry to create more open computing devices. That said, if you want to drive an example terms of use with your employer that fulfills your advanced criteria, you are more than welcome to do so, and I believe it would serve as a role model in the silicon industry. I am happy to help with such an arrangement, and would be even happier if we could just open source the code in question. But we can take this offline. > We can have a process where we might grant exceptions from these > (proposed) rules to certain non-ISA blobs. For example, we might > exempt microcode on the basis that (we believe) It's impractical to > RE, and keeping that avenue open is not of any particular value. Reverse engineering is impractical in all cases. Specifically this document is focussing on what BLOBs we can ship in the 3rdparty/blobs directory, not generally which BLOBs are allowed in coreboot. In terms of many blobs (like FSP, hint hint), we are not even at the point where we can redistribute them in 3rdparty/blobs yet. Adding additional restrictions would, if anything, change nothing at all (except that our users will have to get their own collection of BLOBs if they want to participate). > We can grandfather in existing blobs, or we can have a process where > we keep them for a while (a year?) while we try to work out > appropriate licensing terms with the power-that-be of said blob. I would like to get the existing BLOBs into 3rdparty/blobs first before we talk about removing them in a year (e.g. FSP, hint hint). All the best, Stefan

6 years, 2 months

Announcing coreboot 4.2

by Patrick Georgi

(Halloween 2015 release - just as scary as that sounds) Dear coreboot community, today marks the release of coreboot 4.2, the second release on our time based release schedule. Since 4.1 there were 936 commits by 90 authors, increasing the code base by approximately 17000 lines of code. We saw 35 new contributors - welcome to coreboot! More than 34 developers were active as reviewers in that period. Thanks go to all contributors who helped shape this release. As with 4.1, the release tarballs are available at http://www.coreboot.org/releases/. There's also a 4.2 tag and branch in the git repository. This marks the first release that features a changelog comparing it to the previous release. There was some limited testing to make sure that the code is usable, and it boots on some devices. A structured test plan will only become part of the release procedure of future versions. I'm grateful to Martin for assembling this release's changelog. This is also the first release that will be followed by the removal of old, unused code. There will be a policy on how to announce deprecation and removal of mainboard and chipset code for future releases. Regards, Patrick Log of commit d5e6618a4f076610e683b174c4dd5108d960c785 to commit 439a527014fa0cb3e4ef60ba59e5c57c737b4444 Changes between 4.1 and 4.2 --------------------------- Build system: - Store a minimized coreboot config file in cbfs instead of the full config - Store the payload config and revision in CBFS when that info is available - Add -compression option for cbfs-files-y. Valid entries are now -file, -type, -align, and -compression - Change Microcode inclusion method from building .h files to pre-built binaries - Update Builder tests for each commit to test utilities and run lint tools - Many other small makefile and build changes and fixes - Remove expert mode as a Kconfig option Utilities: - Many fixes and updates to many utilities (158 total commits) - ifdtool: Update for skylake, handle region masks correctly - crossgcc: Update to gcc 5.2.0 - kconfig: Add strict mode to fail on kconfig errors and warnings - vgabios: Significant fixes to remove issues in linking into coreboot code - Add script to parse MAINTAINERS file - Add Kconfig lint tool - Create a common library to share coreboot routines with utilities - Significant changes and cleanup to cbfstool (81 commits). Major changes: - Update cbfstool to change the internal location of FSP binaries when adding them - Decompress stage files on extraction and turn them into ELF binaries - Header sizes are now variable, containing extended attributes - Add compression tags to all cbfs headers so all cbfs files can be compressed - Add and align CBFS components in one pass instead of two - Add XIP support for X86 to relocate the romstage when it's added - Removed locate command as it's no longer needed - Add bootblock and cbfs_header file types so the master header knows about them - Prefer FMAP data to CBFS master header if FMAP data exists - Add hashes to cbfs file metadata for verification of images Payloads: - SeaBIOS: update stable release from 1.7.5 to 1.8.2 - Libpayload had some significant changes (61 commits). Major changes: - Add support for fmap tables - Add support for SuperSpeed (3.0) USB hubs - Updates and bugfixes for DesignWare OTG controller (DWC2) - Add video_printf to print text with specified foreground & background colors - Updates to match changes to cbfs/cbfstool - Add cbgfx, a library to show graphics and text on a display - Read cbfs offset and size from sysinfo when available Vendorcode: - fsp_baytrail: Support Baytrail FSP Gold 4 release - AMD binary PI: add support for fan control - Work to get AMD AGESA to compile correctly as 64-bit code - Add standalone (XIP) verstage support for x86 to verify romstage Mainboards: - New Mainboards: - apple/macbookair4_2 - Sandy/Ivy Bridge with Panther / Cougar point chipset - asus/kgpe-d16 - AMD Family 10, SB700/SR5650 platform - emulation/spike-riscv - RISCV virtualized platform - google/chell - Intel Skylake chrome platform - google/cyan - Intel Braswell chrome platform - google/glados - Intel Skylake chrome platform - google/lars - Intel Skylake chrome platform - intel/kunimitsu - Intel Skylake chrome platform - intel/sklrvp - Intel Skylake reference platform - intel/strago - Intel Braswell chrome platform - Cleanups of many mainboards - several patches each for: - amd/bettong - getac/p470 - google/auron, google/smaug and google/veyron_rialto - pcengines/apu1 - siemens/mc_tcu3 - Combine the google/veyron_(jerry, mighty, minnie, pinkie, shark & speedy) mainboards into the single google/veyron mainboard directory Console: - Add EM100 'hyper term' spi console support in ramstage & smm - Add console support for verstage ARM: - armv7: use asm coded memory operations for 32/16 bit read/write - Many cleanups to the nvidia tegra chips (40 patches) RISC-V: - Add trap handling - Add virtual Memory setup X86: - Remove and re-add Rangeley and Ivy Bridge / panther point FSP platforms - Update microcode update parser to use stock AMD microcode blobs from CBFS - ACPI: Align FACS to 64 byte boundary. Fixes FWTS error - AMD/SB700: Init devices in early boot, restore power state after power failure. Add IDE/SATA asl code - Add initial support for AMD Socket G34 processors - Add tick frequency to timestamp table to calculate boot times more accurately - Unify X86 romstage / ramstage linking to match other platforms - Start preparing X86 bootblock for non-memory-mapped BIOS media - cpu/amd/car: Add Suspend to RAM (S3) support - Native VGA init fixes on several platforms - Significant updates to FSP 1.1 code for cleanup and cbfstool changes - SMMhandler: on i945..nehalem, crash if LAPIC overlaps with ASEG to prevent the memory sinkhole smm hack Drivers: - Add native text mode support for the Aspeed AST2050 - w83795: Add support for for fan control and voltage monitoring - Intel GMA ACPI consolidation and improvements - Set up the 8254 timer before running option ROMs - Resource allocator: Page align memory mapped PCI resources Lib: - Derive fmap name from offset/size - Several edid fixes - Updates to cbfs matching changes in cbfstool Submodules: ----------- 3rdparty/blobs: Total commits: 16 Log of commit 61d663e39bc96530900c3232ccea7365ab9dad0b to commit aab093f0824b6d26b57a1ce220ba0d577e37ad49 - AMD Merlin Falcon: Update to CarrizoPI 1.1.0.0 (Binary PI 1.4) - AMD Steppe Eagle: Update to MullinsPI 1.0.0.A (Binary PI 1.1) - Update microcode to binary blobs. Remove old .h microcode files 3rdparty/arm-trusted-firmware: - No Changes 3rdparty/vboot: Total commits: 41 Log of commit fbf631c845c08299f0bcbae3f311c5807d34c0d6 to commit d6723ed12b429834c2627c009aab58f0db20ce73 - Update the code to determine the write protect line gpio value - Several updates to futility and image_signing scripts - Update crossystem to accommodate Android mosys location - Support reboot requested by secdata - Add NV flag to default boot legacy OS util/nvidia/cbootimage: - No Changes -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

6 years, 2 months

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2015