coreboot May 2019

coreboot@coreboot.org

49 participants
56 discussions

How to add NUVOTON NCT6776F support with serial port logic enabled ???
by dponamorev＠gmail.com 18 May '19

18 May '19

There is a Lanner FW-7573 platform based on the Intel Rangeley Atom C2000 series processor. To work with the Serial port in this platform, the NUVOTON NCT6776F chip is connected via the LPC bus to the processor. I just can’t get Serial port working for debuging. I take as a basis intel littleplains board. I tried to add NCT6776F support following the example of other boards - without success. There is no output to the console, and in Linux, the superiotool program does not see the NCT6776F. On the official version of the BIOS I loaded linux OS and took a dump. (superiotool r => Found Nuvoton NCT6776F/D (C) (id=0xc333) at 0x4e) ) How to add NUVOTON NCT6776F support with serial port logic enabled ??? in devicetree.cb I add: device pci 1f.0 on # LPC bridge chip superio/nuvoton/nct6776 device pnp 4e.0 off end # Floppy device pnp 4e.1 off end # Parallel port device pnp 4e.2 on # COM1 io 0x60 = 0x3f8 irq 0x70 = 4 end device pnp 4e.3 off end # COM2, IR device pnp 4e.5 off end # Keyboard device pnp 4e.6 off end # CIR device pnp 4e.7 off end # GPIO6 device pnp 4e.107 off end # GPIO7 device pnp 4e.207 off end # GPIO8 device pnp 4e.307 off end # GPIO9 device pnp 4e.8 off end # WDT device pnp 4e.108 off end # GPIO0 device pnp 4e.208 off end # GPIOA device pnp 4e.308 off end # GPIOBASE device pnp 4e.109 off end # GPIO1 device pnp 4e.209 off end # GPIO2 device pnp 4e.309 off end # GPIO3 device pnp 4e.409 off end # GPIO4 device pnp 4e.509 off end # GPIO5 device pnp 4e.609 off end # GPIO6 device pnp 4e.709 off end # GPIO7 device pnp 4e.a on end # ACPI device pnp 4e.b off end # HWM, front pannel LED device pnp 4e.d off end # VID device pnp 4e.e off end # CIR WAKE-UP device pnp 4e.f off end # GPIO device pnp 4e.14 off end # SVID device pnp 4e.16 off end # Deep sleep device pnp 4e.17 off end # GPIOA end end # LPC bridge In superio.asl i add: #undef SUPERIO_DEV #undef SUPERIO_PNP_BASE #define SUPERIO_DEV SIO0 #define SUPERIO_PNP_BASE 0x4e #define NCT6776_SHOW_PP #define NCT6776_SHOW_SP1 #define NCT6776_SHOW_KBC #define NCT6776_SHOW_HWM #define NCT6776_SHOW_GPIO #include <superio/nuvoton/nct6776/acpi/superio.asl> in romstage.c add function mainboard_config_superio: void mainboard_config_superio(void) { /* Enable UART */ nuvoton_pnp_enter_conf_state(GLOBAL_DEV); /* Select SIO pin states. */ As in Dump........ pnp_write_config(GLOBAL_DEV, 0x13, 0xff); pnp_write_config(GLOBAL_DEV, 0x14, 0xff); pnp_write_config(GLOBAL_DEV, 0x1b, 0x53); pnp_write_config(GLOBAL_DEV, 0x1c, 0x80); pnp_write_config(GLOBAL_DEV, 0x24, 0x24); pnp_write_config(GLOBAL_DEV, 0x27, 0xc0); pnp_write_config(GLOBAL_DEV, 0x2b, 0x03); pnp_write_config(GLOBAL_DEV, 0x2a, 0x00); pnp_write_config(GLOBAL_DEV, 0x2c, 0x80); /* Power RAM in S3. */ //pnp_set_logical_device(ACPI_DEV); //pnp_write_config(ACPI_DEV, 0xe4, 0x10); pnp_set_logical_device(SERIAL_DEV); nuvoton_pnp_exit_conf_state(GLOBAL_DEV); nuvoton_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE); }

3 2

Re: Lenovo G505s, results irqpoll
by Mike Banon 17 May '19

17 May '19

> is running the cbfstool line mandatory after building the coreboot even if I built for each laptop separately? Not mandatory. That's only if you would like to make a universal build that could be flashed to both G505S laptops. Now CC'ing to coreboot mailing list... On Thu, May 16, 2019 at 10:50 AM <bruts(a)netc.fr> wrote: > > I created a vm to build/patch coreboot, for each build i started clean, then patched with your scripts, however I never manually used cbfstool, I only replaced the atombios during "make menuconfig" (so .config reads either pci1002,6665.rom or pci1002,6663.rom). > is running the cbfstool line mandatory after building the coreboot even if I built for each laptop separately? > (if not, then maybe i should do a rebuild) > > > De : Mike Banon <mikebdp2(a)gmail.com> > À : bruts(a)netc.fr > Sujet : Re: Lenovo G505s, results irqpoll > Date : 16/05/2019 06:17:02 Europe/Paris > Copie à : awokd <awokd(a)danwin1210.me> > > Which AtomBIOS you've added to your coreboot? Currently, coreboot's > .config can't be set up to include both HD-8570M and R5-M230 roms even > with my patch, you could only have there one ROM for integrated iGPU > and one ROM for discrete dGPU. If after building the coreboot you > don't run > > ./build/cbfstool $COREBOOT_ROM_PATH add -f $VGABIOS_PATH -n > pci****,****.rom -t optionrom > > command to add the AtomBIOS for another dGPU as well, your coreboot > build will not be fully universal. Although it will make dGPU working > on a one type of discrete G505S, it will not be working with the same > coreboot ROM on another. So, regarding the difference at your > messages: > > > R5 M230 show: > > [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM > > > > HD 8570M show: > > [drm:radeon_get_bios [radeon]] *ERROR* ACPI VFCT image header truncated > > - maybe the coreboot ROM flashed to your G505S with R5-M230 dGPU, > contains only the AtomBIOS for HD-8570M dGPU, - can't find for R5-M230 > and there's such an error. E.g. if you built a coreboot.rom and simply > flashed it to both G505S without adding another AtomBIOS. > > "*ERROR* ACPI VFCT image header truncated" is not critical and your > GPU can work with it, but "*ERROR* Unable to locate a BIOS ROM" is > critical. > > P.S. Hopefully you could get a public e-mail that's "for coreboot / > etc. mailing lists", so that we'll be able to repost this knowledge > above to these mailing list archives with your current "brutc(a)netc.fr" > removed everywhere, and also continue discussing freely with your new > e-mail > > On Wed, May 15, 2019 at 10:31 PM <bruts(a)netc.fr> wrote: > > > > Hi there! thanks for your reply. > > > > >> I took a peek too. The only notes.log I found was under R5 > > M230/Qubes/notes. Most of them don't seem bad except the ones about the > > PCI ROM header signature seem to say that GPU isn't getting initialized. > > It might still be available for passthrough, though? Might not even > > matter if dom0 can't use it. > > > > sorry, one notes.log was not saved for whatever reason, but the GPU error is also showing when booting Ubuntu, > > so maybe this is something for Mike to have a look at? you can find notes.log also in Ubuntu folder. > > > > R5 M230 show: > > [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM > > > > HD 8570 show: > > [drm:radeon_get_bios [radeon]] *ERROR* ACPI VFCT image header truncated > > > > perhaps this error is expected, i don't know. > > > > >> Yes, it seems to manifest most when I use the keyboard and/or mouse > > while it's still booting up VMs. Basically, I'll put in my user > > password, then not touch anything until it's all the way up (wifi > > connected, etc.) The more impatient I got, the more it happened. :) > > > > Yes I experienced the same! Would be nice eventually we find the reason for this happening, but no big deal right now. > > > > >> shutdown Qubes > > @awokd: remove ioctl on qubes device is busy << that line appears multiple times on shutdown of Qubes, that's also normal right? > > i can remember i read some post somewhere at some stage that explained this, but i forgot. > > > > OK, enjoy your evening! > > > > > > De : awokd <awokd(a)danwin1210.me> > > À : bruts(a)netc.fr; > > mikebdp2(a)gmail.com > > Sujet : Re: Lenovo G505s, result111s irqpoll > > Date : 15/05/2019 21:01:34 Europe/Paris > > > > bruts(a)netc.fr wrote on 5/15/19 4:29 PM: > > > > > > @awokd: thanks for your advise, adding irqpoll to kernelopts fixed the usb problem! > > > > > > When inserting UFD, it appears several times as you can see on the screenshot image (attached), is that normal behavior? It's not resulting in any errors, but just checking with you. > > > > > > Yes, that's by design. > > > > > @mikeb: i booted both laptops with Ubuntu 18.04 and Qubes 4.01 - i will attach a zip file containing the journalctl, there are a few 'errors' that I want to check with you: see notes.log (most errors or warnings are the same, but some differ for both laptops/os). > > > > I took a peek too. The only notes.log I found was under R5 > > M230/Qubes/notes. Most of them don't seem bad except the ones about the > > PCI ROM header signature seem to say that GPU isn't getting initialized. > > It might still be available for passthrough, though? Might not even > > matter if dom0 can't use it. > > > > > Also some behavior I found with Qubes only: > > > > > > > > > > > > - when laptops are powered off and then booted, a few times after I got the log-in screen for Qubes, the mouse and keyboard stopped responding. > > > > > > the system was still responsive, but obviously i could not do anything anymore. > > > > > > @awokd: you had this yourself? it just occurs a few times really, cannot replicate it, just random it seems, but only on a cold boot. > > > > Yes, it seems to manifest most when I use the keyboard and/or mouse > > while it's still booting up VMs. Basically, I'll put in my user > > password, then not touch anything until it's all the way up (wifi > > connected, etc.) The more impatient I got, the more it happened. :) > > > > > - only the laptop with the hd8750, when poweroff from a terminal the logoff splash screen of Qubes remains frozen en poweroff does not complete. > > > > > > also this happens random so far, but quite frequently, i will try to find anything in logs related to that (any suggestions are welcome where to look). > > > > > >

2 2

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 17 May '19

17 May '19

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 22 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1401394: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/broadwell/romstage/raminit.c: 125 in raminit() ________________________________________________________________________________________________________ *** CID 1401394: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/broadwell/romstage/raminit.c: 125 in raminit() 119 mrc_cache_stash_data(MRC_TRAINING_DATA, 0, 120 pei_data->data_to_save, 121 pei_data->data_to_save_size); 122 123 printk(BIOS_DEBUG, "create cbmem for dimm information\n"); 124 mem_info = cbmem_add(CBMEM_ID_MEMINFO, sizeof(struct memory_info)); >>> CID 1401394: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "mem_info" when calling "memset". [Note: The source code implementation of the function has been overridden by a builtin model.] 125 memset(mem_info, 0, sizeof(*mem_info)); 126 /* Translate pei_memory_info struct data into memory_info struct */ 127 mem_info->dimm_cnt = pei_data->meminfo.dimm_cnt; 128 for (int i = 0; i < MIN(DIMM_INFO_TOTAL, PEI_DIMM_INFO_TOTAL); i++) { 129 struct dimm_info *dimm = &mem_info->dimm[i]; 130 const struct pei_dimm_info *pei_dimm = ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Bring Microcode updates in CBFS .bin format
by Kinky Nekoboi 17 May '19

17 May '19

Hello Everybody, can somebody explain to me howto how the scripts in 3rdparty/blobs/cpu/intel/microcode/ alter the microcode. Iwant to make the Microcode update provided by debian: http://deb.debian.org/debian/pool/non-free/i/intel-microcode/intel-microcod… I would like to alter the scripts an make a commit to master. greetings kinky_nekoboi

2 1

Re: Intel® FSP External Architecture Specification v2.1 Has Been Released
by Zaolin 16 May '19

16 May '19

Okay will do. Another point would be FSP-M multi core ram training for example. I will mark issues with the enhancement flag. Best Regards, Philipp On 16.05.19 17:05, Zimmer, Vincent wrote: > > Of course. Intel is open to feedback. Near-term perhaps some of the > issues you’ve observed could be posted to > https://github.com/IntelFsp/FSP/issues ? > > > > Vincent > > *From:*Zaolin [mailto:zaolin@das-labor.org] > *Sent:* Thursday, May 16, 2019 9:01 AM > *To:* Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com>; > coreboot(a)coreboot.org > *Subject:* [coreboot] Re: Intel® FSP External Architecture > Specification v2.1 Has Been Released > > > > Hey Nate, > > Would it be possible for us to influence future specifications as well. > > The community experienced some issues with the overall FSP-S design and > > we would like to discuss that with your team. > > > > Best Regards, > > Philipp > > On 16.05.19 04:36, Desimone, Nathaniel L wrote: > > Hi Everyone, > > > > We are pleased to announce that the FSP External Architecture > Specification v2.1 has been posted to https://www.intel.com/fsp! > > > > *Highlights* > > > > * *Dispatch Mode*– A new optional FSP boot mode intended to ease > integration of FSP with PI spec bootloaders. In dispatch mode, > FSP-M and FSP-S are containers that expose firmware volumes > (FVs) directly to the bootloader. The PEIMs in these FVs are > executed directly in the context of the PEI environment > provided by the bootloader. In dispatch mode, the > /FspMemoryInit/(), /FspSiliconInit/(), and /NotifyPhase/() > API’s are not used. /NotifyPhase/() is replaced by FSP-S > containing DXE drivers that provide a native implementation of > equivalent events for each of the /NotifyPhase/() invocations. > > > > */_Dispatch mode is entirely optional._/* FSP 2.1 is fully > backwards compatible with FSP 2.0, all of the APIs still work > the same way. We have no plans to change that. While dispatch > mode is the biggest new feature, it is also largely not > relevant for coreboot. > > > * *More Robust Error Reporting *– The current FSP 2.0 just > returns an EFI_STATUS code without any context. If that status > code is anything other than EFI_SUCCESS, FSP 2.0 gives very > little visibility in to what specifically may be going wrong. > FSP 2.1 adds the FSP_ERROR_INFO_HOB, which provides more > granularity on FSP error data and will aid in the debug of > error codes returned by FSP. > > > > * *Improved Graphics Support*– Starting with FSP 2.1, in > addition to the EFI_PEI_GRAPHICS_INFO_HOB, FSP will now also > produce the EFI_PEI_GRAPHICS_DEVICE_INFO_HOB. This enables the > implementation of a generic graphics driver. > > > > * *Improved Memory Utilization*– /FspMemoryInit/() will now run > on top of the existing bootloader stack instead of > establishing it own stack. his allows the stack memory to be > reused after /FspMemoryInit/() returns to the bootloader. > After /FspMemoryInit/(), large amounts of DRAM will be > available. So FSP will split its stack and global data at this > point, since the memory pressure is gone. > > > > *Roadmap* > > > > AmberLakeFspBinPkg has been released on > https://github.com/IntelFsp/FSP, which provides the first > implementation of FSP 2.1. This FSP is backward compatible with > Kaby Lake, so there should be a good amount of existing hardware > available for those who are interested in trying FSP 2.1. Looking > forward, our upcoming Ice Lake and Comet Lake platforms will have > FSP 2.1 binaries once they are released. > > > > *Does Anything Need to Change in coreboot?* > > > > For the most part no. There are some new header structure > definitions to bring in. Optionally, coreboot can now report any > data provided by FSP_ERROR_INFO_HOB and a generic graphics driver > can now be written leveraging EFI_PEI_GRAPHICS_DEVICE_INFO_HOB. > > > > _______________________________________________ > > coreboot mailing list -- coreboot(a)coreboot.org <mailto:coreboot@coreboot.org> > > To unsubscribe send an email to coreboot-leave(a)coreboot.org <mailto:coreboot-leave@coreboot.org> >

1 0

Re: Intel® FSP External Architecture Specification v2.1 Has Been Released
by Zaolin 16 May '19

16 May '19

Hey Nate, Would it be possible for us to influence future specifications as well. The community experienced some issues with the overall FSP-S design and we would like to discuss that with your team. Best Regards, Philipp On 16.05.19 04:36, Desimone, Nathaniel L wrote: > > Hi Everyone, > > > > We are pleased to announce that the FSP External Architecture > Specification v2.1 has been posted to https://www.intel.com/fsp! > > > > *Highlights* > > > > * *Dispatch Mode*– A new optional FSP boot mode intended to ease > integration of FSP with PI spec bootloaders. In dispatch mode, > FSP-M and FSP-S are containers that expose firmware volumes (FVs) > directly to the bootloader. The PEIMs in these FVs are executed > directly in the context of the PEI environment provided by the > bootloader. In dispatch mode, the /FspMemoryInit/(), > /FspSiliconInit/(), and /NotifyPhase/() API’s are not used. > /NotifyPhase/() is replaced by FSP-S containing DXE drivers that > provide a native implementation of equivalent events for each of > the /NotifyPhase/() invocations. > > > > */_Dispatch mode is entirely optional._/* FSP 2.1 is fully > backwards compatible with FSP 2.0, all of the APIs still work the > same way. We have no plans to change that. While dispatch mode is > the biggest new feature, it is also largely not relevant for coreboot. > > * *More Robust Error Reporting *– The current FSP 2.0 just returns > an EFI_STATUS code without any context. If that status code is > anything other than EFI_SUCCESS, FSP 2.0 gives very little > visibility in to what specifically may be going wrong. FSP 2.1 > adds the FSP_ERROR_INFO_HOB, which provides more granularity on > FSP error data and will aid in the debug of error codes returned > by FSP. > > > > * *Improved Graphics Support*– Starting with FSP 2.1, in addition to > the EFI_PEI_GRAPHICS_INFO_HOB, FSP will now also produce the > EFI_PEI_GRAPHICS_DEVICE_INFO_HOB. This enables the implementation > of a generic graphics driver. > > > > * *Improved Memory Utilization*– /FspMemoryInit/() will now run on > top of the existing bootloader stack instead of establishing it > own stack. his allows the stack memory to be reused after > /FspMemoryInit/() returns to the bootloader. After > /FspMemoryInit/(), large amounts of DRAM will be available. So FSP > will split its stack and global data at this point, since the > memory pressure is gone. > > > > *Roadmap* > > > > AmberLakeFspBinPkg has been released on > https://github.com/IntelFsp/FSP, which provides the first > implementation of FSP 2.1. This FSP is backward compatible with Kaby > Lake, so there should be a good amount of existing hardware available > for those who are interested in trying FSP 2.1. Looking forward, our > upcoming Ice Lake and Comet Lake platforms will have FSP 2.1 binaries > once they are released. > > > > *Does Anything Need to Change in coreboot?* > > > > For the most part no. There are some new header structure definitions > to bring in. Optionally, coreboot can now report any data provided by > FSP_ERROR_INFO_HOB and a generic graphics driver can now be written > leveraging EFI_PEI_GRAPHICS_DEVICE_INFO_HOB. > > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org

2 1

Can't build (for g505s) with crossgcc-x64 toolchain, builds fine with crossgcc-i386
by Mike Banon 16 May '19

16 May '19

Here's a final part of coreboot build log for crossgcc-x64 build attempt. This does not happen while building with crossgcc-i386, so seems to be x64-only problem. CC romstage/lib/stack.o CC romstage/lib/timestamp.o CC romstage/lib/version.o CC romstage/mainboard/lenovo/g505s/BiosCallOuts.o CC romstage/mainboard/lenovo/g505s/OemCustomize.o CC romstage/mainboard/lenovo/g505s/buildOpts.o CC romstage/mainboard/lenovo/g505s/romstage.o CC romstage/northbridge/amd/agesa/family15tn/dimmSpd.o CC romstage/northbridge/amd/agesa/family15tn/state_machine.o CC romstage/southbridge/amd/agesa/hudson/early_setup.o CC romstage/southbridge/amd/agesa/hudson/imc.o CC romstage/southbridge/amd/agesa/hudson/ramtop.o CC romstage/southbridge/amd/agesa/hudson/smbus.o CC romstage/southbridge/amd/agesa/hudson/smbus_spd.o CC romstage/vendorcode/amd/agesa/common/agesa-entry.o LINK cbfs/fallback/romstage.debug /home/mikeb/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/console/vtxprintf.o: in function `number': /home/mikeb/coreboot/src/console/vtxprintf.c:104: undefined reference to `__udivmoddi4' /home/mikeb/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/lib/gcc.o: in function `__wrap___udivdi3': /home/mikeb/coreboot/src/lib/gcc.c:33: undefined reference to `__udivdi3' src/arch/x86/Makefile.inc:251: recipe for target 'build/cbfs/fallback/romstage.debug' failed make: *** [build/cbfs/fallback/romstage.debug] Error 1

3 2

Intel® FSP External Architecture Specification v2.1 Has Been Released
by Desimone, Nathaniel L 16 May '19

16 May '19

Hi Everyone, We are pleased to announce that the FSP External Architecture Specification v2.1 has been posted to https://www.intel.com/fsp! Highlights * Dispatch Mode – A new optional FSP boot mode intended to ease integration of FSP with PI spec bootloaders. In dispatch mode, FSP-M and FSP-S are containers that expose firmware volumes (FVs) directly to the bootloader. The PEIMs in these FVs are executed directly in the context of the PEI environment provided by the bootloader. In dispatch mode, the FspMemoryInit(), FspSiliconInit(), and NotifyPhase() API’s are not used. NotifyPhase() is replaced by FSP-S containing DXE drivers that provide a native implementation of equivalent events for each of the NotifyPhase() invocations. [cid:image003.png@01D50B35.B9A8D740] Dispatch mode is entirely optional. FSP 2.1 is fully backwards compatible with FSP 2.0, all of the APIs still work the same way. We have no plans to change that. While dispatch mode is the biggest new feature, it is also largely not relevant for coreboot. * More Robust Error Reporting – The current FSP 2.0 just returns an EFI_STATUS code without any context. If that status code is anything other than EFI_SUCCESS, FSP 2.0 gives very little visibility in to what specifically may be going wrong. FSP 2.1 adds the FSP_ERROR_INFO_HOB, which provides more granularity on FSP error data and will aid in the debug of error codes returned by FSP. * Improved Graphics Support – Starting with FSP 2.1, in addition to the EFI_PEI_GRAPHICS_INFO_HOB, FSP will now also produce the EFI_PEI_GRAPHICS_DEVICE_INFO_HOB. This enables the implementation of a generic graphics driver. * Improved Memory Utilization – FspMemoryInit() will now run on top of the existing bootloader stack instead of establishing it own stack. his allows the stack memory to be reused after FspMemoryInit() returns to the bootloader. After FspMemoryInit(), large amounts of DRAM will be available. So FSP will split its stack and global data at this point, since the memory pressure is gone. Roadmap AmberLakeFspBinPkg has been released on https://github.com/IntelFsp/FSP, which provides the first implementation of FSP 2.1. This FSP is backward compatible with Kaby Lake, so there should be a good amount of existing hardware available for those who are interested in trying FSP 2.1. Looking forward, our upcoming Ice Lake and Comet Lake platforms will have FSP 2.1 binaries once they are released. Does Anything Need to Change in coreboot? For the most part no. There are some new header structure definitions to bring in. Optionally, coreboot can now report any data provided by FSP_ERROR_INFO_HOB and a generic graphics driver can now be written leveraging EFI_PEI_GRAPHICS_DEVICE_INFO_HOB.

1 0

New Intel microcode release for migiating ZOMBIELOAD FALLOUT AND OTHERS
by Kinky Nekoboi 15 May '19

15 May '19

Someone should push them to coreboot. Debian already has them.

4 4

Documentation change needs review
by avg＠google.com 14 May '19

14 May '19

Hi, I'm looking for a reviewer for a small documentation update: https://review.coreboot.org/c/coreboot/+/32540 Alan

1 0

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 2019