coreboot

coreboot@coreboot.org

6 participants
39686 discussions

[coreboot - Bug #509] (New) SD Card hotplug not working on Apollo Lake
by CoolStar Organization 27 Sep '23

27 Sep '23

Issue #509 has been reported by CoolStar Organization. ---------------------------------------- Bug #509: SD Card hotplug not working on Apollo Lake https://ticket.coreboot.org/issues/509 * Author: CoolStar Organization * Status: New * Priority: Normal * Category: chipset configuration * Target version: master * Start date: 2023-09-27 * Affected versions: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master * Needs backport to: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master * Affected hardware: Apollo Lake * Affected OS: Linux, Windows 10, Windows 11 ---------------------------------------- Something is broken with the SD Card enumeration on Apollo Lake where hotplug is broken in both Linux and Windows -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

2 1

[coreboot - Bug #121] T520: Hangs in OS
by Anastasios Koutian 26 Sep '23

26 Sep '23

Issue #121 has been updated by Anastasios Koutian. Patrick Rudolph wrote in #note-75: > I compared the vendor ACPI code for T520 and T530: > - The T520 is missing _CST entries, thus the C-states are reported in FADT. I couldn't find a firmware dump that has a FADT. > - The T530 has _CST, but the latencies are higher: For C3 148usec, vs 63 in coreboot. > It's possible that too short advertised exit latencies causes issues when meeting deadlines within the kernel. > The kernel will pick deeper C-states, while it shouldn't, as it assumes that those wake much faster. Hi Patrick, I have done some digging with MSRs but never looked into this particular one. I have a spare T420 motherboard now and I could flash the vendor firmware back in, to examine the value. If that would contribute to solving this issue, I'd be happy to do it. Thank you for looking into this. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1667 * Author: Julz Buckton * Status: New * Priority: Normal * Start date: 2017-06-09 ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 24 Sep '23

24 Sep '23

Issue #121 has been updated by Patrick Rudolph. I compared the vendor ACPI code for T520 and T530: - The T520 is missing _CST entries, thus the C-states are reported in FADT. I couldn't find a firmware dump that has a FADT. - The T530 has _CST, but the latencies are higher: For C3 148usec, vs 63 in coreboot. It's possible that too short advertised exit latencies causes issues when meeting deadlines within the kernel. The kernel will pick deeper C-states, while it shouldn't, as it assumes that those wake much faster. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1666 * Author: Julz Buckton * Status: New * Priority: Normal * Start date: 2017-06-09 ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 24 Sep '23

24 Sep '23

Issue #121 has been updated by Patrick Rudolph. Does limiting the max C-state in MSR MSR_PKG_CST_CONFIG_CONTROL also work around the issue? What setting is being used on vendor firmware for MSR MSR_PKG_CST_CONFIG_CONTROL? Currently the code doesn't check if the processor supports C6/C3 sleep states, it just assumes it does. According to the BWG, when bus masters, that cannot tolerate long bus master latency, are present, the BM_STS avoidance must be used for C3/C6 states. It sounds a bit like this could be the case here. The CPU is in C3/C6 and takes too long to wake in order to handle the bus master request. If enabled the acpi_idle_bm_check() would then prevent the CPU from entering a higher C-state (deeper sleep) when a bus master is active (similar to what intel_idle.max_cstate=2 does). ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1665 * Author: Julz Buckton * Status: New * Priority: Normal * Start date: 2017-06-09 ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Anastasios Koutian 24 Sep '23

24 Sep '23

Issue #121 has been updated by Anastasios Koutian. File defconfig added The issue is resolved for me after doing the following: a) Change motherboards from FRU 04W2049 (dGPU + iGPU) to FRU 04W2045 (iGPU). b) Update coreboot to 4.21 with EDK II (defconfig is attached). System has been stable for 6+ hours with no c-state limit. Previously it would freeze after 1-3 hours. Everything else is the same as my previous post. I recommend anyone still facing this issue to try the above. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1664 * Author: Julz Buckton * Status: New * Priority: Normal * Start date: 2017-06-09 ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

Jasper Lake: Commit 21e61847 (ramtop caching) causes FSP-M to fail with EFI_UNSUPPORTED
by Jonathon Hall 22 Sep '23

22 Sep '23

2 1

2023-09-20 - coreboot Leadership meeting minutes
by coreboot org 20 Sep '23

20 Sep '23

# 2023-09-20 - coreboot Leadership meeting minutes ## Attendees: MartinR, MarshallD, MattD, RonM, TimC, FelixH, KarthikR, JuliusW, DanielM, JonathanH, SimonG, JonM, StefanR, NicoH, MinaW ## Minutes: ### sjg - RFC: Post-build control of serial console * https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/F5NP… * outside of the thread: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/D2PI… * Enable/Disable the serial console on images with the console previously disabled/enabled. * In CrOS, both serial and non-serial are built. * Put control in the boot block. * Martin] This presents multiple issues: * Changing the bootblock will mess up cbfs verification * On AMD platforms, the bootblock is part of the AMDFW binary, not in the typical place. * CBFSTOOL would access the “coreboot control block” to enable/disable serial. CBFS attribute - use a magic number in the boot block. * [Martin] Let’s separate this into 2 issues - do we want this feature & how to enable it. * [Matt] What’s the size difference & impact to boot time. * No impact if serial is disabled at build time (since this feature of course will not be enabled) * Size of the serial drivers * Boot time is not impacted unless serial is enabled. * Stefan] We have defaults for cmos settings that can be changed (though obviously not all systems have cmos). There’s no uniformity across all platforms. Let’s make enabling/disabling options flexible so that we can use different back-ends depending on the platform. Can’t write to CMOS when the machine is up and running. * Julius] CBFS attributes are already (mostly) written up. * CBFS may not be a good option because of the code needed to read it. * [martin]This is just an argument about how to set up a new configuration mechanism. * Let’s use something that works with the current CMOS option mechanism. * Stefan] Let’s see if we can get rid of the ChromeOS GBB flags while we do this. * Julius] this is being discussed, but not really relevant here. We can already put the existing GBB flags in CBFS. * Martin] Let’s not add yet another method of configuration. * Smmstore - SJG: uses an FMAP region so available later in bootblock? * CMOS - SJG: not controlled by firmware image * can we use the options API? * one drawback?? is that it uses strings to access the values * Stefan] Can only be modified when the board is running. * Devicetree - SJG: build-time * CBI - SJG: doesn't this fetch from the EC? * Martin] Yes * Storing things in the SPI ROM. - that is this proposal. * Martin] I believe that there’s already a method for doing this that’s implemented. * CBFS flag files - SJG: available later in bootblock? * VPD - SJG: not available in bootblock? * Kconfig? - SJG: build-time * Nobody disagrees with the idea of being able to enable/disable the serial console at runtime, the thing that needs to be figured out is the method. ### [Nico] What to do about undisclosed downstream coreboot used in production? (cf. discussion of [CB:77466](https://review.coreboot.org/c/coreboot/+/77466)) * Martin] There was a misunderstanding about whether this code was used in production images or not. From the discussion last meeting, as David described it, the EINJ is strictly for debug. * What’s our official position? * [Martin] We decided this in the last meeting. EINJ is *debug* code and would never be used in a production image. It’s useful code, so the agreement was that it should be left in coreboot, but could be moved to vendorcode. * How could we push back? E.g. ask to add absence of such conflicts to the criteria for “OCP accepted” badge? * [Martin] I think pushing back should be handled on a case-by case basis. * Concerns: * It seems unfair to deny the addition of new blob support on one hand and allow direct linking to proprietary code on the other. * [Martin] Are you arguing that we should allow other blobs because of a blob that’s never going to be used in production images? * Weakening the idea of the GPL might make it harder to get code out of companies that see a business advantage in their work. * [Martin] How does this weaken the GPL? * We need better communication about what any code that is used along with sources outside of the tree are for. There needs to be a maintainer for these items. * Let’s discuss this further later. ### [MartinR] Formatting arguments: What’s the coreboot standard for wrapped lines? * Should they match the start of the previous block or just use two tabs beyond the previous indentation? Or something else? * Julius] Decide on place-by-place basis - let the developer decide. * Can we start using clang-format for everything so that we can stop arguing about formatting? * Julius] Let the author decide - new contributors should just follow the existing format. * Ron] This worked well on other platforms - Rust & Go communities - just format it and move on. * Nico] We decided on clang-format already. * Martin] We just need to finish the implementation. Clang format versions caused issues. * Jon] Not using clang-format causes confusion and keeps people from wanting to update patches. * Felixs] hook up clang-format to the CI and allow the reviewers to decide * Ron] this would keep the current situation. Make the automaton the arbiter. * Simon] Agrees with ron - let’s not argue about formatting. * Clang-format would be done a directory at a time. * Felix] Patches that are in flight will be problematic. * There’s a script to reformat patches: clang/tools/clang-format/clang-format-diff.py * Martin] I will pick up the existing patch for the clang-format config, and we can discuss the configuration settings. I’ll send out a sample to the mailing list and write up some instructions on how to use it. * We can use the clang-format from the coreboot toolchain. ### [MartinR] I’m planning on hiring someone to help with this meeting. Duties include: * Announcing the upcoming meeting on IRC, Slack & Discord. * Helping keep minutes during the meeting * Sending the minutes to the mailing list at the conclusion of the meeting. I’ve already picked a person, and hope they’ll start attending in the next few meetings. I’m paying for this out of my own pocket to avoid any issues with having the SFC pay someone, which involves contracts & whatnot. # Next meeting October 4th, 2023 * [Meeting link](https://meet.google.com/pyt-newq-rbb) * [coreboot Calendar](https://coreboot.org/calendar.html) # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 1

RFC: Post-build control of serial console
by Keith Hui 18 Sep '23

18 Sep '23

Hi Simon, > Why not CMOS RAM / VVRAM? - If we allocate some space in CMOS for console / logging settings, then it would allow a similar feature. But it involves changing settings on the device. Each board would need to provide some CMOS options for this feature as part of the layout file. It would not be possible to enable console output without running some code on the device to update the CMOS RAM. (Pardon the formatting; I copied this out of my semi-regular digest) Many boards already have this space allocated in their cmos.layout. Take for example my sandybridge board, asus/p8z77-m: # coreboot config options: console 395 4 e 4 debug_level [...] # debug_level 4 0 Emergency 4 1 Alert 4 2 Critical 4 3 Error 4 4 Warning 4 5 Notice 4 6 Info 4 7 Debug 4 8 Spew Setting this to 0 suppresses almost all outputs unless it's a "I'm going to die()" scream. For development/hacking we do want to start with debug outputs on the console. If after ample testing a build has proved itself to be stable, cmos.default (that is a separate file) in CBFS can be patched to change the default log level. This would be done through cbfstool (albeit indirectly - extract, patch, re-insert) or a hex editor. I'd propose a tool that operates on this binary cmos.layout instead. In short, in my opinion, we don't need a new construct. Regards Keith

2 1

[coreboot - Bug #505] (New) Intel Harcuvar CRB Denverton_NS С3000. Only 15 cores of a 16 core processor is defined in the operating system.
by Dmitry Ponamorev 15 Sep '23

15 Sep '23

Issue #505 has been reported by Dmitry Ponamorev. ---------------------------------------- Bug #505: Intel Harcuvar CRB Denverton_NS С3000. Only 15 cores of a 16 core processor is defined in the operating system. https://ticket.coreboot.org/issues/505 * Author: Dmitry Ponamorev * Status: New * Priority: Normal * Assignee: Angel Pons * Category: board support * Target version: 4.15 * Start date: 2023-08-22 * Affected versions: 4.15 * Affected hardware: Intel Harcuvar CRB, Intel(R) Atom(TM) CPU C3958 * Affected OS: Debian 11, Ubunto 20.04 (and later) ---------------------------------------- Found a bug with the definition of not all processor cores of the Intel(R) Atom(TM) CPU C3958 processor in operating systems. The Debian or Ubuntu operating system defines only 15 cores. The problem concerns exactly the 16th core processor. For processors with fewer cores, the number of cores is determined correctly. The problem was found in coreboot version 4.14 and later. Version coreboot 4.11 did not have this problem. Most likely this is due to incorrect initialization of apic_id. (apic_id 0) An example of the initialization output of the processor cores is below: Will perform SMM setup. CPU: Intel(R) Atom(TM) CPU C3958 @ 2.00GHz. AP: slot 1 apic_id 6, MCU rev: 0x00000034 AP: slot 13 apic_id 1e, MCU rev: 0x00000034 AP: slot 6 apic_id a, MCU rev: 0x00000034 AP: slot 14 apic_id e, MCU rev: 0x00000034 AP: slot 5 apic_id 4, MCU rev: 0x00000034 AP: slot 2 apic_id 10, MCU rev: 0x00000034 AP: slot 4 apic_id 14, MCU rev: 0x00000034 AP: slot 11 apic_id 1c, MCU rev: 0x00000034 AP: slot 15 apic_id 8, MCU rev: 0x00000034 AP: slot 8 apic_id 16, MCU rev: 0x00000034 AP: slot 10 apic_id c, MCU rev: 0x00000034 AP: slot 3 apic_id 1a, MCU rev: 0x00000034 AP: slot 9 apic_id 2, MCU rev: 0x00000034 AP: slot 7 apic_id 12, MCU rev: 0x00000034 AP: slot 12 apic_id 18, MCU rev: 0x00000034 smm_place_entry_code: smbase 7ffe8400, stack_top 7fe08000 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffec000, cpu = 0 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9000, cpu = 12 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe8800, cpu = 14 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9c00, cpu = 9 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe8400, cpu = 15 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeb800, cpu = 2 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9400, cpu = 11 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe8c00, cpu = 13 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffea000, cpu = 8 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeb400, cpu = 3 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeb000, cpu = 4 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffea400, cpu = 7 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9800, cpu = 10 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffebc00, cpu = 1 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffea800, cpu = 6 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeac00, cpu = 5 Initializing CPU #0 Turbo is unavailable CPU #0 initialized Initializing CPU #8 Initializing CPU #12 Initializing CPU #14 Initializing CPU #4 Initializing CPU #9 Initializing CPU #10 Initializing CPU #1 Initializing CPU #15 Initializing CPU #7 Initializing CPU #11 Initializing CPU #3 Initializing CPU #2 Initializing CPU #13 Initializing CPU #6 CPU #7 initialized CPU #14 initialized CPU #15 initialized CPU #2 initialized CPU #6 initialized CPU #12 initialized Initializing CPU #5 CPU #3 initialized CPU #1 initialized CPU #10 initialized CPU #4 initialized CPU #11 initialized CPU #5 initialized CPU #9 initialized CPU #8 initialized CPU #13 initialized -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 2

First time using coreboot+edk2, I didn't get to see the beginning.
by Keith Hui 14 Sep '23

14 Sep '23

tldr: After my latest reflash of coreboot with edk2 payload, serial log didn't start flowing right away and no on screen activity until OS on drive has begun booting. What gives? After hacking on coreboot with SeaBIOS for so long, I finally tried edk2. It wasn't the smoothest transition. My testing hard drive has a bit of special hackery done[1] in hope it will boot under both legacy and UEFI schemes. I did add SeaBIOS as secondary payload, and it couldn't boot. Then I pulled out the main drive out of my laptop which is all UEFI, and it booted fine after probably 30 seconds of nothing - the first thing I saw on screen is the Fedora spinner. Nothing from edk2 or grub on the drive. There also was a bit of delay on my connected serial console, then when info finally started flowing, it's already well into ramstage. And when I checked cbmem, it unfortunately overflowed so I lost logs of raminit, which would be most important given my patch train now under review. It would take a warm reboot before I start getting the head of the boot logs. I didn't set a boot logo. What more set up I have to do to get my edk2 and grub boot menu back? I've attached logs from minicom, cbmem, and my Kconfig, if it helps. Thanks for any insights. Keith [1] If I remember correctly, it is GPT partitioned with ESP plus a BIOS boot partition where grub can hide itself.

4 4

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