coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

Re: [coreboot] PC Engines apu2 boot regression
by Aaron Durbin 05 May '18

05 May '18

On Sat, May 5, 2018 at 4:26 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > On Sun, May 6, 2018 at 12:17 AM, Aaron Durbin <adurbin(a)google.com> wrote: >>> I find it particularly hard to be civil on your first question, so >>> trying with sarcasm instead. After 5000 or so development hours and >>> direct support from AMD, is the boot sequence for soc/stoneyridge >>> prototypes equally bad, that is, AP CPUs execute through bootblock and >>> verstage? >> >> They currently jump to where they are told at the moment. See >> bootblock_c_entry() in src/soc/amd/stoneyridge/bootblock/bootblock.c. >> There is no running through multiple stages within coreboot. > > I think CAR_GLOBAL equally fails with soc/amd/stoneyridge if you had > SoC with multiple compute units where MTRRs are not shared, thus setup > becomes asymmetric between some cores. Marshall's experiments support > this happens. Agreed. That's a concern w/ running APs through all the stages and not having a symmetric view of the address space. > >> I think you are right that guarding things w/ boot_cpu() would work. >> Is CONFIG_SQUELCH_EARLY_SMP set for all those types of boards? Or do >> we have a weird mix? Or should we have a Kconfig that says 'CAR' is >> not symmetric across cpus thus can't be used? > > I would rather grant AP CPUs access to CAR_GLOBALs by manipulating the > MTRR setup. > > Kyösti

1 0

Re: [coreboot] PC Engines apu2 boot regression
by Kyösti Mälkki 05 May '18

05 May '18

On Sun, May 6, 2018 at 12:17 AM, Aaron Durbin <adurbin(a)google.com> wrote: >> I find it particularly hard to be civil on your first question, so >> trying with sarcasm instead. After 5000 or so development hours and >> direct support from AMD, is the boot sequence for soc/stoneyridge >> prototypes equally bad, that is, AP CPUs execute through bootblock and >> verstage? > > They currently jump to where they are told at the moment. See > bootblock_c_entry() in src/soc/amd/stoneyridge/bootblock/bootblock.c. > There is no running through multiple stages within coreboot. I think CAR_GLOBAL equally fails with soc/amd/stoneyridge if you had SoC with multiple compute units where MTRRs are not shared, thus setup becomes asymmetric between some cores. Marshall's experiments support this happens. > I think you are right that guarding things w/ boot_cpu() would work. > Is CONFIG_SQUELCH_EARLY_SMP set for all those types of boards? Or do > we have a weird mix? Or should we have a Kconfig that says 'CAR' is > not symmetric across cpus thus can't be used? I would rather grant AP CPUs access to CAR_GLOBALs by manipulating the MTRR setup. Kyösti

1 0

Re: [coreboot] FSP 2.0 headers in coreboot
by Nico Huber 05 May '18

05 May '18

On 04.05.2018 23:41, Aaron Durbin via coreboot wrote: > On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui > <kakaroto(a)kakaroto.homelinux.net> wrote: >> Hi, >> >> I've just pushed a commit for review on gerrit >> (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to >> open the discussion here on whether the public coreboot code should >> have the FSP headers that match the public FSP headers or if they >> should match the 'google fsp' headers. I tried myself before [1] and ran against a wall of lies and broken promises. Roughly: - July to September/October: I warned Intel about the situation over all available channels (Gerrit, different corporate support channels, wrote to Vincent who uploaded the first Kabylake FSP to GitHub, several laments about the situation on this mailing list I guess). - After the first Kaby Lake FSP drop on GitHub, Intel commented on Gerrit that the headers there are outdated and internal ones have to be used. - December 11th, Intel commented on Gerrit that everything is sorted out. - December 13th, Intel painted Kabylake FSP "Gold" with 6 months outdated UPDs. >> >> My understanding of the situation is that chromebooks ship with a >> google-modified FSP image and the fsp headers in coreboot have been >> added by google employees even before the FSP was officially made >> public by Intel. I also somewhat understood that the fsp headers in >> coreboot would not be updated to match the public release because it >> would break everyone building coreboot for their chromebooks or >> something like that. > > They aren't modified necessarily. It's more of different views on the > same timeline of a development. Granted, the releases are definitely > not coordinated. I'm not even sure how/who releases the github > blobs/headers on Intel's side. I have more a feeling that different branches exist. > >> >> I'm a bit tired of always having that commit that fixes the header >> applied locally in all my branches, and I think that it makes much >> more sense for coreboot to have the fsp headers that match the public >> release and for the google/chromebook coreboot repository to have the >> "non-standard header" committed to it instead. >> Worst case scenario, we could add #ifdefs to determine what the >> structure contents should be depending on the target platform. >> >> Maybe everyone will say "of course, that makes sense" or maybe >> everyone will say "nope, I disagree", but hopefully we can have the >> discussion here (or on gerrit) and decide how to handle this use case. >> Note: I only pushed for skylake/kabylake, but apollolake/canonlake are >> probably also affected by this mismatch of headers. > > I think we should have both that can be selected through a Kconfig > such that we can bind to the headers correctly. We already had to do > that for edk2 issues as well. I can't think of better alternative at > the moment that supports both. You can not just switch headers. As Youness pointed out in his commit, UPDs used by coreboot are missing in the public release. We'd clutter up the tree with #ifdefs. And once that started, I'm sure, somebody will use that as excuse to practice it further. OTOH, we could just revert the past 10 months of soc/intel/. The major stakeholders had been warned early enough. If somebody gets that through Jenkins, I'll +2. Um, a little more serious: I believe the only solution is to enforce some sane rules about code changes that depend on blob headers and blobbed platforms in general, e.g. (just a draft; but I wouldn't mind if we take it verbatim): (meaning of *shall*, *should* and *recommended* as specified in [2], "changes" refer to new commits for the coreboot master branch) 0. Generally: All platforms should be blob-free. All blobs should be redistributable. Providers of blobs should sign them and take responsibility that the signed blobs were unaltered after compilation (e.g. do not contain malware). It is *recommended* that the public key needed to verify the signature is obtainable through a specific channel (e.g. single responsible contact person) _independently_ from the blob's distribution path. 1. After the coreboot 4.8 release: All changes to a binary-specific header file (including the addition of new files) *shall* be refused, unless a matching binary is publicly available. For each platform that relies on a blob, the coreboot tree *should* point (e.g. git submodule) to a commit containing both the header files and the matching binary. 2. After the coreboot 4.9 release: For each platform that relies on a blob, the coreboot tree *shall* point (e.g. git submodule) to a commit containing both the header files and the matching binary. If the plat- form code within coreboot supports multiple variants of that platform, that commit shall contain all necessary binaries for all variants supported by coreboot, all compatible with the same header files. Unless a pointer as described above exists for a given plat- form that relies on a blob, all changes* to that platform *shall* be refused. All platforms that rely on a blob that is not redistribu- table and whose distribution as an individual file has been stopped or has never happened *shall* be immediately removed from the master branch. *excluding changes to maintain tree-wide compatibility 3. After the coreboot 4.10 release: Unless a pointer as described above exists for a given plat- form that relies on a blob, that platform *shall* be imme- diately removed from the master branch. Unless a signature as described above exists for a given blob, all changes* to platforms that have been launched to market and rely on that blob *shall* be refused. This should give everybody enough time to adapt and the refusal to merge new patches should constantly remind them so they won't forget the matter and panic right before a release. One reason for not writing this up earlier is that it potentially hits a lot of CrOS devices. Though, in the proposed scheme there'd still be 6 months for Google to figure things out. Nico [1] https://review.coreboot.org/#/c/coreboot/+/20477/ [2] http://www.ietf.org/rfc/rfc2119.txt

2 1

Re: [coreboot] PC Engines apu2 boot regression
by Kyösti Mälkki 05 May '18

05 May '18

On Sat, May 5, 2018 at 6:27 PM, Marshall Dawson <marshalldawson3rd(a)gmail.com> wrote: >> So did you hit problems with CAR_GLOBAL in agesa_get_dispatcher(), >> when experimeting CZ vs ST? I don't see why this code works even for >> dual-core ST but I did not evaluate CAR layout. Documentation part for >> fixed MTRRs in gcccar.inc appears to be same. > > > I don't remember specifically where the condition caused a problem. It kind > of seems like it was when the third core tried to run printk, wanted a > global pointer to a global variable, and got back 0xffffffff. It's been too > long to say for certain. IIRC, cores 0 & 1 received fixed MTRR settings > allowing 0x30000-0x3ffff, but 2 & 3 started at 0x40000 and couldn't access > the globals just above 0x30000. It's worth noting that cores in Family 15h > share their MTRRs within a compute unit, so it was never possible for 0 & 1 > to be anything but identical. > Every discovered core adds WB regions to MSR. So if you say the tested CZ had separate compute units, while ST only had one, that would indeed explain it. >> Now, does this MTRR change have potential to actually become _the_ >> fix? I don't see why it could not. It's pretty much all that we1 can do >> with binaryPI, anything else touches the blobs. > > >> Will you sent patch? > Yes. > > I don't think _the_ fix has been pursued yet. It's certainly lower priority > than other things I have going on right now. But in my mind, it's still a > little too hacky. It assumes the hardcoded value of BSP_STACK_BASE_ADDR > stays consistent (which needs to also equal DCACHE_RAM_BASE). Maybe a > better approach is to allow all cores to have access to 100% of the CAR > region. Maybe just their own plus the globals area? I haven't given much > thought to why cores received differing regions in AMD's CAR setup code. > What I would really enjoy seeing is moving CAR above 1MB and skipping all > the fixed MTRR setup, but that's a pretty big rewrite. Keep in mind, this code ends up in your RO bootblock. Give it some high priority on StoneyRidge buglist. > Kyosti, do you want to submit a patch since you're able to test it on other > platforms? I'd be OK with having the 64K region at BSP_STACK_BASE_ADDR > being WB for all cores until a more robust solution is available. I don't > think this is a characteristic of PI blob implementations, by the way. I > would expect all the native AGESA platforms to have the same limitation too. > That's how I have the patch [1] prepared. Kyösti [1] https://review.coreboot.org/#/c/coreboot/+/26115

1 0

Re: [coreboot] PC Engines apu2 boot regression
by Aaron Durbin 05 May '18

05 May '18

On Fri, May 4, 2018 at 8:49 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > On Fri, May 4, 2018 at 8:22 PM, Aaron Durbin <adurbin(a)google.com> wrote: >> On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: >>> On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: >>>> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin <adurbin(a)google.com> wrote: >>>>>> >>>>>> Any idea what can be result of such weird behavior? >>>>> >>> >>> My current guess is AP CPUs do not see initialised memory for >>> _car_region_start .. _end. That region is set up using fixed MTRRs in >>> low memory and probably not synced between cores so early in romstage. >>> >> >> Ugh. Why do we allow the APs to run through all these stages? Is this >> for parallel node memory training? Can we ring fence where the APs >> actually run better? >> > > I have to check closer, but for apu2 this would be in AMD_INIT_EARLY > already, so AP CPUs run way before (the only) memory controller is > configured. I believe there is microcode updates and some CPU > registers that are also synced during AMD_INIT_EARLY. So it is doing > more than just bringing an idle AP task engine. > > I find it particularly hard to be civil on your first question, so > trying with sarcasm instead. After 5000 or so development hours and > direct support from AMD, is the boot sequence for soc/stoneyridge > prototypes equally bad, that is, AP CPUs execute through bootblock and > verstage? They currently jump to where they are told at the moment. See bootblock_c_entry() in src/soc/amd/stoneyridge/bootblock/bootblock.c. There is no running through multiple stages within coreboot. I think you are right that guarding things w/ boot_cpu() would work. Is CONFIG_SQUELCH_EARLY_SMP set for all those types of boards? Or do we have a weird mix? Or should we have a Kconfig that says 'CAR' is not symmetric across cpus thus can't be used?

1 0

Re: [coreboot] PC Engines apu2 boot regression
by Piotr Król 05 May '18

05 May '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/05/2018 11:53 AM, Kyösti Mälkki wrote: > On Sat, May 5, 2018 at 3:06 AM, Marshall Dawson > <marshalldawson3rd(a)gmail.com> wrote: >>> My current guess is AP CPUs do not see initialised memory for >>> _car_region_start .. _end. That region is set up using fixed >>> MTRRs in low memory and probably not synced between cores so >>> early in romstage. >> >> >> Kyosti, I haven't kept a close watch on CAR changes in the other >> AMD systems, however in experimenting with CZ using ST source I >> found that 4 cores had a problem using CAR globals, so I think >> you're on the right track. AMD's CAR setup code assumes each core >> only needs fixed MTRRs configured for their own particular region >> of storage -- they all don't get access to 100% of the CAR area. >> Going from 2 cores (ST) to 4 cores (CZ), the higher two cores >> could no longer access the CAR globals at the bottom of the >> region. Try this hack and see if it improves for you: >> > > Hi Marshall > > Thanks, your suggested MTRR change seems to solve the regression. > It was definetely about CAR_GLOBALs failing for AP CPUs in general. > We just had not hit this case before for typical builds, as use of > POSTCAR_STAGE barely avoided the error from triggering. > > So did you hit problems with CAR_GLOBAL in agesa_get_dispatcher(), > when experimeting CZ vs ST? I don't see why this code works even > for dual-core ST but I did not evaluate CAR layout. Documentation > part for fixed MTRRs in gcccar.inc appears to be same. > > Now, does this MTRR change have potential to actually become _the_ > fix? I don't see why it could not. It's pretty much all that we can > do with binaryPI, anything else touches the blobs. Hi Marshall, Kyösti, also confirm that this patch fix regression on recent master. Will you sent patch? Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlrthdYACgkQsu5x6Weq nkwqPQ//QGpX6w23CWwN/lJQPMIB2Qpw0rdL5GTa2L1axsdL8GLWr+TgRkeleGi4 q77x+jG9xPP5fBkoEiZfBOkZTwhfKIKygtSdwHybs0Qn7aammItCgdOyz1tJj9Gu /i6ncXK3dsWYwOj1r+qkMm0phGQDgq+uW17CnsmOUfXMIMm6ULIF6f/8t/aNvdGC N6gNPIjI7oDlkI73CRZjLV+bWIsFzfvoJWTZrilNz41zxI5ERCKpmGCNy93qPsMl p5GoGZvzE2rwniRqju8oDlw2P+o3OZ3ukAJWbQxid83dn7NHAo95ZFZ8cx7umLvN J+vFrD9n1CzwQRXtqWoSelYmGJkJWxx/p5Co8JK+x2yLDShrojJraV02NX32k4Yd Bf4RZW9nK4QnPqrH647FfBEOBZfX0ruizjTQzFLd7moTYDry8zIOwOuLc3IftT09 edPrxnwlp6q6F8EopGXsnTbqFfbxGRRVzGICvd2/eFtSXZBULFQBfutKYrK8KVaS /VLXSpPQ6f07vZnWQMrCndaHIC0cShnHE1ekb2uY8kmkqzgXZetaKGsDkCXlJVRF vlJEoEu9qWmglqMYzxPF8MnHBx9DLAgFk/AMMmQk5yzv8Ki1m3kgJu9Fxdc0iJ3y Ka9voYxzP2r+K8CaJgvtXYwSeHoIqDdERBAz0lN3KTqGuXtewSs= =0Gj7 -----END PGP SIGNATURE-----

2 1

Re: [coreboot] PC Engines apu2 boot regression
by Kyösti Mälkki 05 May '18

05 May '18

On Sat, May 5, 2018 at 3:06 AM, Marshall Dawson <marshalldawson3rd(a)gmail.com> wrote: >> My current guess is AP CPUs do not see initialised memory for >> _car_region_start .. _end. That region is set up using fixed MTRRs in >> low memory and probably not synced between cores so early in romstage. > > > Kyosti, I haven't kept a close watch on CAR changes in the other AMD > systems, however in experimenting with CZ using ST source I found that 4 > cores had a problem using CAR globals, so I think you're on the right track. > AMD's CAR setup code assumes each core only needs fixed MTRRs configured for > their own particular region of storage -- they all don't get access to 100% > of the CAR area. Going from 2 cores (ST) to 4 cores (CZ), the higher two > cores could no longer access the CAR globals at the bottom of the region. > Try this hack and see if it improves for you: > Hi Marshall Thanks, your suggested MTRR change seems to solve the regression. It was definetely about CAR_GLOBALs failing for AP CPUs in general. We just had not hit this case before for typical builds, as use of POSTCAR_STAGE barely avoided the error from triggering. So did you hit problems with CAR_GLOBAL in agesa_get_dispatcher(), when experimeting CZ vs ST? I don't see why this code works even for dual-core ST but I did not evaluate CAR layout. Documentation part for fixed MTRRs in gcccar.inc appears to be same. Now, does this MTRR change have potential to actually become _the_ fix? I don't see why it could not. It's pretty much all that we can do with binaryPI, anything else touches the blobs. Kyösti

1 0

Re: [coreboot] PC Engines apu2 boot regression
by Kyösti Mälkki 04 May '18

04 May '18

On Fri, May 4, 2018 at 8:22 PM, Aaron Durbin <adurbin(a)google.com> wrote: > On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: >> On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: >>> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin <adurbin(a)google.com> wrote: >>>>> >>>>> Any idea what can be result of such weird behavior? >>>> >> >> My current guess is AP CPUs do not see initialised memory for >> _car_region_start .. _end. That region is set up using fixed MTRRs in >> low memory and probably not synced between cores so early in romstage. >> > > Ugh. Why do we allow the APs to run through all these stages? Is this > for parallel node memory training? Can we ring fence where the APs > actually run better? > I have to check closer, but for apu2 this would be in AMD_INIT_EARLY already, so AP CPUs run way before (the only) memory controller is configured. I believe there is microcode updates and some CPU registers that are also synced during AMD_INIT_EARLY. So it is doing more than just bringing an idle AP task engine. I find it particularly hard to be civil on your first question, so trying with sarcasm instead. After 5000 or so development hours and direct support from AMD, is the boot sequence for soc/stoneyridge prototypes equally bad, that is, AP CPUs execute through bootblock and verstage? Kyösti

1 0

Re: [coreboot] PC Engines apu2 boot regression
by Marshall Dawson 04 May '18

04 May '18

> > My current guess is AP CPUs do not see initialised memory for > _car_region_start .. _end. That region is set up using fixed MTRRs in > low memory and probably not synced between cores so early in romstage. > Kyosti, I haven't kept a close watch on CAR changes in the other AMD systems, however in experimenting with CZ using ST source I found that 4 cores had a problem using CAR globals, so I think you're on the right track. AMD's CAR setup code assumes each core only needs fixed MTRRs configured for their own particular region of storage -- they all don't get access to 100% of the CAR area. Going from 2 cores (ST) to 4 cores (CZ), the higher two cores could no longer access the CAR globals at the bottom of the region. Try this hack and see if it improves for you: diff --git a/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc b/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc index 5a4f7b9..fd3bf81 100644 --- a/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc +++ b/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc @@ -1151,6 +1151,7 @@ SetupStack: or %edi, %edx # #.endif # 0: + or $0x1e000000, %eax # force 30000-40000 for cbmem access _WRMSR # # Enable MTRR defaults as UC type -- Ugh. Why do we allow the APs to run through all these stages? Is this > for parallel node memory training? Can we ring fence where the APs > actually run better? > Aaron, on Stoney Ridge all cores needed to be alive in order to do memory training. It wasn't that they were used in the algorithm (as far as I've seen); they simply had to be there to prevent the northbridge from blowing up. I've long since forgotten what internal designs AMD used for Family 15h and 16h, but it seems likely the same limitation applies on Family 16h too. We occasionally discuss a different methodology of shutting down the APs immediately when they're released, and not letting them run through to InitEarly(). It seems like that ought to allow the northbridge to behave as expected during training in InitPost(). Thanks, Marshall On Fri, May 4, 2018 at 11:22 AM, Aaron Durbin via coreboot < coreboot(a)coreboot.org> wrote: > On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> > wrote: > > On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> > wrote: > >> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin <adurbin(a)google.com> > wrote: > >>>> > >>>> Any idea what can be result of such weird behavior? > >>> > > > > My current guess is AP CPUs do not see initialised memory for > > _car_region_start .. _end. That region is set up using fixed MTRRs in > > low memory and probably not synced between cores so early in romstage. > > > > Ugh. Why do we allow the APs to run through all these stages? Is this > for parallel node memory training? Can we ring fence where the APs > actually run better? > > > > > diff --git a/src/console/init.c b/src/console/init.c > > index 8f71b09..4731e7e 100644 > > --- a/src/console/init.c > > +++ b/src/console/init.c > > @@ -35,7 +35,7 @@ static int console_loglevel = CONFIG_DEFAULT_CONSOLE_ > LOGLEVEL; > > > > static inline int get_log_level(void) > > { > > - if (car_get_var(console_inited) == 0) > > + if (boot_cpu() && car_get_var(console_inited) == 0) > > return -1; > > if (CONSOLE_LEVEL_CONST) > > return get_console_loglevel(); > > > > Kyösti > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] FSP 2.0 headers in coreboot
by Aaron Durbin 04 May '18

04 May '18

On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: > Hi, > > I've just pushed a commit for review on gerrit > (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to > open the discussion here on whether the public coreboot code should > have the FSP headers that match the public FSP headers or if they > should match the 'google fsp' headers. > > My understanding of the situation is that chromebooks ship with a > google-modified FSP image and the fsp headers in coreboot have been > added by google employees even before the FSP was officially made > public by Intel. I also somewhat understood that the fsp headers in > coreboot would not be updated to match the public release because it > would break everyone building coreboot for their chromebooks or > something like that. They aren't modified necessarily. It's more of different views on the same timeline of a development. Granted, the releases are definitely not coordinated. I'm not even sure how/who releases the github blobs/headers on Intel's side. > > I'm a bit tired of always having that commit that fixes the header > applied locally in all my branches, and I think that it makes much > more sense for coreboot to have the fsp headers that match the public > release and for the google/chromebook coreboot repository to have the > "non-standard header" committed to it instead. > Worst case scenario, we could add #ifdefs to determine what the > structure contents should be depending on the target platform. > > Maybe everyone will say "of course, that makes sense" or maybe > everyone will say "nope, I disagree", but hopefully we can have the > discussion here (or on gerrit) and decide how to handle this use case. > Note: I only pushed for skylake/kabylake, but apollolake/canonlake are > probably also affected by this mismatch of headers. I think we should have both that can be selected through a Kconfig such that we can bind to the headers correctly. We already had to do that for edk2 issues as well. I can't think of better alternative at the moment that supports both. > > Thanks, > Youness. > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
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 May 2018