coreboot November 2017

coreboot@coreboot.org

61 participants
110 discussions

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Scheithauer, Mario 06 Nov '17

06 Nov '17

Hi all, > • Are you able to boot Yocto with the current combination you have? We haven’t tested Yocto, but we can boot a Lubuntu. > Where did you obtain a VBIOS file? Intel provides the VBIOS in its MRx packages for the CRBs. You need to contact Intel for this. > • Is it specifically VBIOS, or is it a VBT.dat file? Or are you running SeaVGABIOS? I think you need a complete VBIOS bxt_1003.dat (64kB) for SeaBios. The vbt.dat (5kB) is need by GOP driver. But we haven’t done anything with that yet. Mario Von: Tahnia Lichtenstein [mailto:unlich@gmail.com] Gesendet: Freitag, 3. November 2017 13:46 An: Scheithauer, Mario (DF MC MTS R&D SWRT 4); coreboot(a)coreboot.org Betreff: Re: [coreboot] Problems changing payload on Intel Leaf Hill Hi Mario, Thank you very much for sharing, that already helps a lot!! I can spot quite a lot of differences to my own build settings. I've been pursuing a Grub2 payload in the meantime (no success so far), will now return to SeaBIOS and try and incorporate the necessary changes you suggested. Just a couple of questions so far: * Are you able to boot Yocto with the current combination you have? * I have all the blobs around coreboot, except the VBIOS... I have tried all the options in https://www.coreboot.org/VGA_support, but I suspect the reference bootloader images provided by Intel does not use a VBIOS file. I also cannot find a suitable VBIOS on Intel's website. (By the way, thanks for the FIT decomposition tip, I did not know this was possible... I took great pains to find the correct blobs on Intel's website, would have been much easier to just use FIT!) Where did you obtain a VBIOS file? * Is it specifically VBIOS, or is it a VBT.dat file? Or are you running SeaVGABIOS? Many thanks again! Best regards, Tahnia On Fri, Nov 3, 2017 at 2:01 PM, Scheithauer, Mario <Mario.Scheithauer(a)siemens.com<mailto:Mario.Scheithauer@siemens.com>> wrote: Hi Cameron, > Did you modify the FSP blobs at all? Yes, we made some adjustments for our mainboard (mc_apl1). But they shouldn’t play a decisive role (power states, PCIe settings). > The reason I ask is that my coreboot build hangs in the FspSiliconInit(). Then you will get pretty far. We are currently still using the MR2 FSP package for APL-I. As IFWI template we use the BIOS version v178.10 for the CRBs. These components are provided by Intel. That’s it. The CRB should boot with this combination. Mario > -----Ursprüngliche Nachricht----- > Von: Cameron Craig [mailto:Cameron.Craig@exterity.com<mailto:Cameron.Craig@exterity.com>] > Gesendet: Freitag, 3. November 2017 11:51 > An: Scheithauer, Mario (DF MC MTS R&D SWRT 4); ahW@n > Cc: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> > Betreff: RE: [coreboot] Problems changing payload on Intel Leaf Hill > > Hi Mario, > > I've been attempting to build coreboot(master) for the Leaf Hill CRB, with no > success so far. > > Did you modify the FSP blobs at all? > I had a look at your config, the filenames "FSP_MR2_M_ECC_MOD" caught my > eye. > > The reason I ask is that my coreboot build hangs in the FspSiliconInit(). > > Cheers, > Cameron > > > > Cameron Craig | Graduate Software Engineer | Exterity Limited > tel: +44 1383 828 250<tel:%2B44%201383%20828%20250> | fax: | mobile: > e: Cameron.Craig(a)exterity.com<mailto:Cameron.Craig@exterity.com> | w: www.exterity.com<http://www.exterity.com> > > > > ____________________________________________________________________ > __ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ____________________________________________________________________ > __ -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by ahW＠n 06 Nov '17

06 Nov '17

Hi Mario, I have built my coreboot.rom now but still having problem booting it up (see black screen on monitor). I am not sure few of these settings in my .config is correct or not:- CONFIG_VGA_BIOS_ID="1106,3230" (how to know and confirm this is my ID? is this important?) CONFIG_VGA_BIOS_FILE="3rdparty/blobs/mainboard/intel/apollolake_rvp/Vbt.bsf" (I have Vbt.bin and Vbt.bsf downloaded from Intel FSP_MR3, am I pionting to the correct one?) CONFIG_FMDFILE="src/mainboard/intel/leafhill/leafhill.$(CONFIG_COREBOOT_ROMSIZE_KB).fmd" (OK to use fmd from leafhill?) CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/intel/ apollolake_rvp/Vbt.bin" CONFIG_CHECKLIST_DATA_FILE_LOCATION="src/vendorcode/intel/fsp/fsp2_0/checklist" (I actually didn't see this file exist, is this important?) These settings I believed are correct, please point it out if I am wrong:- CONFIG_IFWI_FILE_NAME=(edit APLI_B0B1D0E0_IFWI_X64_R_178_10_PROD_SPI.bin using FIT.exe and change protection settings) CONFIG_IFD_BIN_PATH=(descriptor.bin decomposed from APLI_B0B1D0E0_IFWI_X64_ R_178_10_PROD_SPI.bin using FIT.exe) CONFIG_FSP_M_FILE=(Fsp_M.fd split from Fsp.fd using SplitFspBin.py) CONFIG_FSP_S_FILE=(Fsp_S.fd split from Fsp.fd using SplitFspBin.py) Blow is my bootup log I can see:- coreboot-4.6-1941-g383ef6e-dirty Wed Nov 1 21:59:08 UTC 2017 bootblock starting... FMAP: Found "FLASH" version 1.1 at 300000. FMAP: base = 0 size = 1000000 #areas = 11 FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'fallback/romstage' CBFS: Found @ offset 80 size 7214 coreboot-4.6-1941-g383ef6e-dirty Wed Nov 1 21:59:08 UTC 2017 romstage starting... pm1_sts: 0000 pm1_en: 0000 pm1_cnt: 00000000 gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 prsts: 00000000 tco_sts: 00000008 gen_pmcon1: 08004004 gen_pmcon2: 00003a00 gen_pmcon3: 00000000 prev_sleep_state 0 FMAP: Found "FLASH" version 1.1 at 300000. FMAP: base = 0 size = 1000000 #areas = 11 FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'fspm.bin' CBFS: Found @ offset 18540 size 59000 FMAP: area RW_MRC_CACHE found @ eae000 (65536 bytes) *REGF fail reading first metadata block.* *MRC: region file invalid in 'RW_MRC_CACHE'* *FMAP: area RW_VAR_MRC_CACHE found @ ebe000 (4096 bytes)* *REGF fail reading first metadata block.* *MRC: region file invalid in 'RW_VAR_MRC_CACHE'* ***************************************************** looking at few lines above fail reading??!! does it matter? * CBMEM: IMD: root @ 7afff000 254 entries. IMD: root @ 7affec00 62 entries. External stage cache: IMD: root @ 7b7ff000 254 entries. IMD: root @ 7b7fec00 62 entries. CPU: frequency set to 2000 MHz WEAK: src/soc/intel/apollolake/romstage.c/mainboard_save_dimm_info called MTRR Range: Start=7a000000 End=7b000000 (Size 1000000) MTRR Range: Start=ff000000 End=0 (Size 1000000) MTRR Range: Start=7b000000 End=7b800000 (Size 800000) FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'fallback/postcar' CBFS: Found @ offset 147680 size 421c Decompressing stage fallback/postcar @ 0x7abc6fc0 (33544 bytes) Loading module at 7abc7000 with entry 7abc7000. filesize: 0x3fd0 memsize: 0x82c8 Processing 124 relocs. Offset value of 0x78bc7000 coreboot-4.6-1941-g383ef6e-dirty Wed Nov 1 21:59:08 UTC 2017 postcar starting... FMAP: Found "FLASH" version 1.1 at 300000. FMAP: base = 0 size = 1000000 #areas = 11 FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'fallback/ramstage' CBFS: Found @ offset 7380 size 10cd8 Decompressing stage fallback/ramstage @ 0x7ab94fc0 (199152 bytes) Loading module at 7ab95000 with entry 7ab95000. filesize: 0x22678 memsize: 0x309b0 Processing 2129 relocs. Offset value of 0x7aa95000 coreboot-4.6-1941-g383ef6e-dirty Wed Nov 1 21:59:08 UTC 2017 ramstage starting... BS: BS_PRE_DEVICE times (us): entry 2 run 2 exit 0 FMAP: Found "FLASH" version 1.1 at 300000. FMAP: base = 0 size = 1000000 #areas = 11 FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'fsps.bin' CBFS: Found @ offset 717c0 size 2a000 FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'vbt.bin' CBFS: Found @ offset 9b800 size 1a00 I think I totally lost :( please let me know if you have any idea on how I can debug further. Thank you. -ahwan On Fri, Nov 3, 2017 at 6:18 PM, Scheithauer, Mario < Mario.Scheithauer(a)siemens.com> wrote: > Hi Ahwan, > > > > Oh sorry, I forgot to attach the .config file for coreboot in my previous > mail. > > We have adjusted the memory settings (romstage.c) in the leafhill > directory for the Oxbow Hill CRB. With these settings the memory > initialization should work for Juniper Hill and Oxbow Hill CRB. Both CRBs > use the same memory modules – DDR3L. But for the Leaf Hill CRB you need > different settings, because there are other DIMM modules on it – LPDDR4. > > > > Mario > > > > > > *Von:* coreboot [mailto:coreboot-bounces@coreboot.org] *Im Auftrag von * > ahW@n via coreboot > *Gesendet:* Freitag, 3. November 2017 08:38 > *An:* coreboot(a)coreboot.org > *Betreff:* Re: [coreboot] Problems changing payload on Intel Leaf Hill > > > > Hi Mario, > > > > I read your reply and saw you have APL CRB Oxbow Hill with coreboot + > SeaBios running. > > I am using the same board and wanted to build the coreboot but failed. > > I think I have the required files ready (bootable UEFI BIOS file, > fitimage.bin, Fsp.fd ...) > > But still failed to build my coreboot. > > I wonder I am having correct .config settings. > > Can you share your settings? > > I check the attachment in previous list but all that is for leafhill, I > wonder are they same and valid for both Oxbox Hill and Leafhill? > > Please advise, thank you. > > > > - ahwan > > > > > > > Scheithauer, Mario Mario.Scheithauer at siemens.com > > > Wed Nov 1 16:28:45 CET 2017 > > > Previous message (by thread): [coreboot] Coreboot support on H8SGL-F > > > Next message (by thread): [coreboot] Problems changing payload on Intel > Leaf Hill > > > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > > Hi Tahnia, > > > > > > We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) + > SeaBios (master) running. > > > Attached are all necessary coreboot adaptions and the config file for > SeaBios. > > > After the generation, a hack in coreboot.rom is still necessary so that > SeaBios can find the VBIOS. > > > SeaBios expects at the end of the CBFS the address from the beginning of > the CBFS section (see SeaBiosPointer.jpg). > > > Furthermore you have to pay attention to the IGD PCI ID. Intel uses > different PCI Device IDs in different CPU versions for IGD (5a84 or 5a85). > > > The console output only works via MMIO on the CRB. Therefore you need > the LPSS UART0 Micro USB port. > > > With all these adjustments we can boot a system on the CRB and have full > console output. > > > Now you just need all the necessary blobs around coreboot (IFWI, FSP, > VBIOS, uCode). > > > You can use the Intel FIT tool to separate the most of the components > from the original BIOS. > > > > > > Hope that helps, > > > Mario >

1 0

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by ahW＠n 06 Nov '17

06 Nov '17

Hi Mario, I have built my coreboot.rom now but still having problem booting it up (see black screen on monitor). I am not sure few of these settings in my .config is correct or not:- CONFIG_VGA_BIOS_ID="1106,3230" (how to know and confirm this is my ID? is this important?) CONFIG_VGA_BIOS_FILE="3rdparty/blobs/mainboard/intel/apollolake_rvp/Vbt.bsf" (I have Vbt.bin and Vbt.bsf downloaded from Intel FSP_MR3, am I pionting to the correct one?) CONFIG_FMDFILE="src/mainboard/intel/leafhill/leafhill.$( CONFIG_COREBOOT_ROMSIZE_KB).fmd" (OK to use fmd from leafhill?) CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/ intel/apollolake_rvp/Vbt.bin" CONFIG_CHECKLIST_DATA_FILE_LOCATION="src/vendorcode/intel/fsp/fsp2_0/checklist" (I actually didn't see this file exist, is this important?) These settings I believed are correct, please point it out if I am wrong:- CONFIG_IFWI_FILE_NAME=(edit APLI_B0B1D0E0_IFWI_X64_R_178_10_PROD_SPI.bin using FIT.exe and change protection settings) CONFIG_IFD_BIN_PATH=(descriptor.bin decomposed from APLI_B0B1D0E0_IFWI_X64_R_178_10_PROD_SPI.bin using FIT.exe) CONFIG_FSP_M_FILE=(Fsp_M.fd split from Fsp.fd using SplitFspBin.py) CONFIG_FSP_S_FILE=(Fsp_S.fd split from Fsp.fd using SplitFspBin.py) Blow is my bootup log I can see:- coreboot-4.6-1941-g383ef6e-dirty Wed Nov 1 21:59:08 UTC 2017 bootblock starting... FMAP: Found "FLASH" version 1.1 at 300000. FMAP: base = 0 size = 1000000 #areas = 11 FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'fallback/romstage' CBFS: Found @ offset 80 size 7214 coreboot-4.6-1941-g383ef6e-dirty Wed Nov 1 21:59:08 UTC 2017 romstage starting... pm1_sts: 0000 pm1_en: 0000 pm1_cnt: 00000000 gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 prsts: 00000000 tco_sts: 00000008 gen_pmcon1: 08004004 gen_pmcon2: 00003a00 gen_pmcon3: 00000000 prev_sleep_state 0 FMAP: Found "FLASH" version 1.1 at 300000. FMAP: base = 0 size = 1000000 #areas = 11 FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'fspm.bin' CBFS: Found @ offset 18540 size 59000 FMAP: area RW_MRC_CACHE found @ eae000 (65536 bytes) *REGF fail reading first metadata block.* *MRC: region file invalid in 'RW_MRC_CACHE'* *FMAP: area RW_VAR_MRC_CACHE found @ ebe000 (4096 bytes)* *REGF fail reading first metadata block.* *MRC: region file invalid in 'RW_VAR_MRC_CACHE'* ***************************************************** looking at few lines above fail reading??!! does it matter? * CBMEM: IMD: root @ 7afff000 254 entries. IMD: root @ 7affec00 62 entries. External stage cache: IMD: root @ 7b7ff000 254 entries. IMD: root @ 7b7fec00 62 entries. CPU: frequency set to 2000 MHz WEAK: src/soc/intel/apollolake/romstage.c/mainboard_save_dimm_info called MTRR Range: Start=7a000000 End=7b000000 (Size 1000000) MTRR Range: Start=ff000000 End=0 (Size 1000000) MTRR Range: Start=7b000000 End=7b800000 (Size 800000) FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'fallback/postcar' CBFS: Found @ offset 147680 size 421c Decompressing stage fallback/postcar @ 0x7abc6fc0 (33544 bytes) Loading module at 7abc7000 with entry 7abc7000. filesize: 0x3fd0 memsize: 0x82c8 Processing 124 relocs. Offset value of 0x78bc7000 coreboot-4.6-1941-g383ef6e-dirty Wed Nov 1 21:59:08 UTC 2017 postcar starting... FMAP: Found "FLASH" version 1.1 at 300000. FMAP: base = 0 size = 1000000 #areas = 11 FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'fallback/ramstage' CBFS: Found @ offset 7380 size 10cd8 Decompressing stage fallback/ramstage @ 0x7ab94fc0 (199152 bytes) Loading module at 7ab95000 with entry 7ab95000. filesize: 0x22678 memsize: 0x309b0 Processing 2129 relocs. Offset value of 0x7aa95000 coreboot-4.6-1941-g383ef6e-dirty Wed Nov 1 21:59:08 UTC 2017 ramstage starting... BS: BS_PRE_DEVICE times (us): entry 2 run 2 exit 0 FMAP: Found "FLASH" version 1.1 at 300000. FMAP: base = 0 size = 1000000 #areas = 11 FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'fsps.bin' CBFS: Found @ offset 717c0 size 2a000 FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size b9d800 CBFS: 'IAFW Locator' located CBFS at [300800:e9e000) CBFS: Locating 'vbt.bin' CBFS: Found @ offset 9b800 size 1a00 I think I totally lost :( please let me know if you have any idea on how I can debug further. Thank you. -ahwan On Fri, Nov 3, 2017 at 6:18 PM, Scheithauer, Mario < Mario.Scheithauer(a)siemens.com> wrote: > Hi Ahwan, > > > > Oh sorry, I forgot to attach the .config file for coreboot in my previous > mail. > > We have adjusted the memory settings (romstage.c) in the leafhill > directory for the Oxbow Hill CRB. With these settings the memory > initialization should work for Juniper Hill and Oxbow Hill CRB. Both CRBs > use the same memory modules – DDR3L. But for the Leaf Hill CRB you need > different settings, because there are other DIMM modules on it – LPDDR4. > > > > Mario > > > > > > *Von:* coreboot [mailto:coreboot-bounces@coreboot.org] *Im Auftrag von * > ahW@n via coreboot > *Gesendet:* Freitag, 3. November 2017 08:38 > *An:* coreboot(a)coreboot.org > *Betreff:* Re: [coreboot] Problems changing payload on Intel Leaf Hill > > > > Hi Mario, > > > > I read your reply and saw you have APL CRB Oxbow Hill with coreboot + > SeaBios running. > > I am using the same board and wanted to build the coreboot but failed. > > I think I have the required files ready (bootable UEFI BIOS file, > fitimage.bin, Fsp.fd ...) > > But still failed to build my coreboot. > > I wonder I am having correct .config settings. > > Can you share your settings? > > I check the attachment in previous list but all that is for leafhill, I > wonder are they same and valid for both Oxbox Hill and Leafhill? > > Please advise, thank you. > > > > - ahwan > > > > > > > Scheithauer, Mario Mario.Scheithauer at siemens.com > > > Wed Nov 1 16:28:45 CET 2017 > > > Previous message (by thread): [coreboot] Coreboot support on H8SGL-F > > > Next message (by thread): [coreboot] Problems changing payload on Intel > Leaf Hill > > > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > > Hi Tahnia, > > > > > > We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) + > SeaBios (master) running. > > > Attached are all necessary coreboot adaptions and the config file for > SeaBios. > > > After the generation, a hack in coreboot.rom is still necessary so that > SeaBios can find the VBIOS. > > > SeaBios expects at the end of the CBFS the address from the beginning of > the CBFS section (see SeaBiosPointer.jpg). > > > Furthermore you have to pay attention to the IGD PCI ID. Intel uses > different PCI Device IDs in different CPU versions for IGD (5a84 or 5a85). > > > The console output only works via MMIO on the CRB. Therefore you need > the LPSS UART0 Micro USB port. > > > With all these adjustments we can boot a system on the CRB and have full > console output. > > > Now you just need all the necessary blobs around coreboot (IFWI, FSP, > VBIOS, uCode). > > > You can use the Intel FIT tool to separate the most of the components > from the original BIOS. > > > > > > Hope that helps, > > > Mario >

1 0

IOMMU/PCI passthrough on the PCENGINES APU2 board
by Christoph Pomaska 05 Nov '17

05 Nov '17

Hi, I am currently trying to get IOMMU on the APU2 board to work and found this commit: https://review.coreboot.org/#/c/15165/ What is the current state of that code? (Seems like there is need of an update regarding the added variants of the board to the master tree) Is there still being worked on? Best regards Christoph

2 1

Re: [coreboot] KGPE-D16 AMD-vi fails because combined sata is enabled
by Thierry Laurion 05 Nov '17

05 Nov '17

Thank you for the clarification. I'll try to figure this out later this week. Any help would be appreciated. I suppose I should file an issue. Will do. Le ven. 3 nov. 2017 04:19, Patrick Georgi <pgeorgi(a)google.com> a écrit : > That's the bitfield item's size field, not its default value. > > > > Am Fr., 3. Nov. 2017 um 04:56 Uhr schrieb Thierry Laurion < > thierry.laurion(a)gmail.com>: > >> As I understand the code, KGPE-d16 doesn't use AGESA part (nor any?). >> >> Any reason why this value would be defaulting to enabled for whole sb700 >> dependents? >> >> --- a/src/vendorcode/amd/cimx/sb700/SBTYPE.h >> +++ b/src/vendorcode/amd/cimx/sb700/SBTYPE.h >> @@ -133,7 +133,7 @@ typedef struct _AMDSBCFG >> UINT32 SataPortMultCap :1; //6, 0:OFF 1:ON >> UINT32 SataReserved :2; //8:7, Reserved >> UINT32 SataClkAutoOff :1; //9, >> AutoClockOff for IDE modes 0:Disabled, 1:Enabled >> - UINT32 SataIdeCombinedMode :1; //10, >> SataIDECombinedMode 0:Disabled, 1:Enabled >> + UINT32 SataIdeCombinedMode :0; //10, >> SataIDECombinedMode 0:Disabled, 1:Enabled >> UINT32 SataIdeCombMdPriSecOpt:1; //11, Combined >> Mode, SATA as primary or secondary 0:primary 1:secondary >> UINT32 SataReserved1 :6; //17:12, Not >> used currently >> UINT32 SataEspPort :6; //23:18 SATA >> port is external accessiable on a signal only connector (eSATA:) >> >> >> Le jeu. 2 nov. 2017 à 09:33, Peter Stuge <peter(a)stuge.se> a écrit : >> >>> Thierry Laurion wrote: >>> > ENABLE_IDE_COMBINED_MODE available for sp800 but not for sp700, for >>> ewhich >>> > sp5100 is derived from: >>> .. >>> > Suggested Workaround >>> > Disable combined mode by setting a platform BIOS callback option to >>> CIMx >>> > called "SataIdeCombinedMode" to 0. >>> .. >>> > Is there something i'm missing? Is it possible to disable combined >>> > sata mode for sb700 from coreboot? >>> >>> SB700 mainboard support seems copypasted rather than engineered. The >>> sustainable solution is to move sb700_cfg.c from src/mainboard/*/ >>> to src/southbridge/amd/cimx/sb700/ and hook the configuration in that >>> file into Kconfig. >>> >>> Until someone does that, you could indeed change the assignment of >>> that option by looking for >>> >>> SataIdeCombinedMode >>> >>> in the source code, if a sb700_cimx_config() function is called for >>> this board - but that might not be the case if the board port chose >>> not to use that part of AGESA. >>> >>> >>> //Peter >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot >>> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > <https://maps.google.com/?q=ABC-Str.+19,+20354+Hamburg&entry=gmail&source=g> > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >

1 0

AMG G-series - Steppe eagle - PCI IRQ Routing to 8259 PIC
by Abhishek Chaudhary 05 Nov '17

05 Nov '17

Hi, I am facing an issue routing the interrupts from the Ethernet devices which are on GPP PCIe 1, GPP PCIe 2, and GPP PCIe 3 on a custom hardware that is running AMD G-series - Steppe eagle (Mullins, Family 16h Model 30h-3Fh) . I am attempting to use the PCI IRQ from the Ethernet devices, but this is not working. I am trying to route the PCI IRQ to legacy PIC using C00/C01 Interrupt Router. I have verified the interrupt was generated by the Ethernet end device but we don’t see it getting received by the PIC. I am using FCH in PIC mode, and have local APIC and IOAPIC disabled. In this mode I am able to receive interrupts through PIC from Serial IRQ and from 8254 timer on IRQ0. There are some limitations with the OS so i cannot use IOAPIC, only legacy PIC can be used. I do not have much experience with AMD platforms so i am sure what wrong i am doing. Any input will be very helpful. Thanks Abhishek.

1 0

Re: [coreboot] BayTrail PCIe problems (hangup) in FSP (in U-Boot)
by Zoran Stojsavljevic 05 Nov '17

05 Nov '17

And, to add to this case be spicy... Very spicy in this World (of final interests)! https://embedded.communities.intel.com/thread/13579 Thank you, Mr Roese! Thank you very much! You got it! Here is the right addressee to solve the problem... But what the "initial genesis" guy answered, does it make any sense? As well, as the Creator of U-Boot (says he) prays to the Open Source Church?! But hey, interests are changing over time (sure), and what? Really? And we all change Churches, Religions, and U Tell me what? Why? Greed is Good, Greed is Right... Doesn't it, Mr, Denk (I addressed you here, directly)!? And, yes, I am also involved. In this mess. Not running away from my woes! https://www.youtube.com/watch?v=R8y6DJAeolo Zoran _______ On Fri, Nov 3, 2017 at 8:20 PM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > > I don't understand your note at all Zoran, but I am not alone it seems. > > I am not one who is asking for help here. It is U-Boot creators, not > knowing how to solve (particular) INTEL mess. But if you all agree with > this, I have not at all problem with this mess. You asked for it, didn't > you, all??? > > And... You all do the particular solutions. Today reverse engineering, > tomorrow some partial SW from who-ever-supplies-this, after tomorrow with > the binary blobs. Whatever works better/best for anybody... Today one API, > tomorrow another... After tomorrow something completely different! > Redesigned APIs, completely. ;-) > > It seems that I cleared it all, didn't I? > > Good Luck with the sporadic solutions (whatever works the best/at all in > particular cases)! > > Zoran > > On Fri, Nov 3, 2017 at 2:48 PM, ron minnich <rminnich(a)gmail.com> wrote: > >> >> >> On Fri, Nov 3, 2017 at 5:54 AM Zoran Stojsavljevic < >> zoran.stojsavljevic(a)gmail.com> wrote: >> >>> >>> >>> Your guy Stefan is here, asking for a help. Stefan got the straight >>> answer: FSP/Coreboot (intermingled), then U_Boot as payload... You got that? >>> >>> >>> >> >> Stefan got a suggestion from me that running u-boot as a coreboot payload >> might be easier, as it insulates u-boot from having to deal with FSP. I >> also commented that I had no complaint with them running without coreboot, >> since the more open source firmware we have the better. Either path is >> fine, whatever works best for u-boot. >> >> I don't understand your note at all Zoran, but I am not alone it seems. >> >> ron >> > >

1 0

Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15) CRB?
by Jay Talbott 05 Nov '17

05 Nov '17

Ok, I tried XIP. It stopped at some ddxx post code this time (should have wrote it down). I power cycled to see if it was repeatable, and now the board doesn’t boot at all. It powers on (LEDs, CPU fan, …), but the post code display remains blank, and it doesn’t appear to be doing anything, as if it’s otherwise dead. Furthermore, restoring the factory UEFI BIOS no longer boots either. Now what? Any suggestions? - Jay Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) JayTalbott(a)sysproconsulting.com http://www.sysproconsulting.com <http://www.sysproconsulting.com/> From: Matt DeVillier [mailto:matt.devillier@gmail.com] Sent: Saturday, November 04, 2017 10:58 AM To: Jay Talbott Cc: Nico Huber; coreboot; Stefan Reinauer Subject: Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15) CRB? On Sat, Nov 4, 2017 at 12:48 PM, Jay Talbott <JayTalbott(a)sysproconsulting.com> wrote: Hi Matt, I’ll try XIP and see what happens… but how would that impact the UPD signature? The signature is defined in coreboot/src/vendorcode/intel/fsp/fsp2_0/skykabylake/FspUpd.h, as well as in FspUpd.h in the headers included with the FSP on GitHub. ok, but those signatures match for all three FSP segments (coreboot and github) -- in fact, the FspUpd.h file is exactly the same between the two, and I've verified that's what's in the blobs as well. ref: https://raw.githubusercontent.com/coreboot/coreboot/master/src/vendorcode/i… https://raw.githubusercontent.com/IntelFsp/FSP/Kabylake/KabylakeFspBinPkg/I… - Jay Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. <https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gm…> Gilbert, AZ 85298 <https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gm…> (480) 704-8045 (480) 445-9895 (FAX) JayTalbott(a)sysproconsulting.com http://www.sysproconsulting.com <http://www.sysproconsulting.com/> From: Matt DeVillier [mailto:matt.devillier@gmail.com] Sent: Saturday, November 04, 2017 9:59 AM To: Jay Talbott Cc: Nico Huber; coreboot; Stefan Reinauer Subject: Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15) CRB? On Sat, Nov 4, 2017 at 11:18 AM, Jay Talbott <JayTalbott(a)sysproconsulting.com> wrote: Ok, more details... I'm currently building Coreboot off the end of the master branch as of commit 43a285f983f6c29467d7f30f7e2b402926bd5c6f, but might back up to the commit where the RVP7 support was added to see if that helps: https://github.com/coreboot/coreboot/commit/2ed14f61d1a2976d0ebce59fcc67bd61 <https://github.com/coreboot/coreboot/commit/2ed14f61d1a2976d0ebce59fcc67bd6…> fce4100d I'm using the KBL FSP from GitHub: https://github.com/IntelFsp/FSP/tree/Kabylake/KabylakeFspBinPkg I got the SplitFspBin.py tool and split the FSP into its three separate components. And, eventually, found the right microcode files and made them into a binary blob using a modified version of the microcode2bin.sh script I found in the coreboot tree. My .config file (renamed as config.txt) is attached. you need to use the execute in place (XIP) option for FSP-M in your config Note that the signature in the Fsp_M binary UPD struct is what does not match what's in the corresponding FSP header file - and not just the header file in the coreboot tree, but the one published as part of the FSP package on GitHub. So something is definitely amiss here with this published FSP package. I'm not seeing any hardcoded signature value in FspmUpd.h (as there is in FSP 1.1) - can you point to a specific file/line number? I do not have the serial console working yet, so all I've had to go by are post codes, and the last post code I was getting was 0x34, which I tracked down to be a hardcoded (grr...) value at the beginning of do_fsp_memory_init() in file memory_init.c of the FSP 2.0 driver (./src/drivers/intel/fsp2_0)... static void do_fsp_memory_init(struct fsp_header *hdr, bool s3wake, const struct memranges *memmap) { uint32_t status; fsp_memory_init_fn fsp_raminit; FSPM_UPD fspm_upd, *upd; FSPM_ARCH_UPD *arch_upd; uint32_t fsp_version; post_code(0x34); fsp_version = fsp_memory_settings_version(hdr); upd = (FSPM_UPD *)(hdr->cfg_region_offset + hdr->image_base); if (upd->FspUpdHeader.Signature != FSPM_UPD_SIGNATURE) die("Invalid FSPM signature!\n"); ... I added a post code as part of the if to confirm that the signature mis-match was where the code was hanging. So I'm 100% certain that the mis-match exists with this particular FSP. Also, although the signature is the same, there are a few other differences between the header files included with the FSP and those currently in coreboot, but nothing that would seemingly account for this issue. Note that this particular FSP release on GitHub does NOT include any release notes to indicate for which SkyLake/Kaby Lake variants (-H, -U, -Y, etc.) it is applicable, but someone from Intel suggested that it's only applicable to -H. If that's the case, then how was the RVP7 support ever validated prior to integration into the coreboot tree? Which FSP was actually used? And does that even have anything to do with the signature mis-match issue? Nobody seems to know. I've been trying to get support on this through various channels at Intel that so far have not been particularly helpful, and it's extremely frustrating. I've sent several e-mails to various folks, including the individual that upstreamed the RVP7 support to coreboot and the individual who published the FSP to GitHub, which remain unanswered. Any help from the coreboot community would be most appreciated! Thanks! - Jay Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. <https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gm…> Gilbert, AZ 85298 <https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gm…> (480) 704-8045 (480) 445-9895 (FAX) JayTalbott(a)sysproconsulting.com http://www.sysproconsulting.com > -----Original Message----- > From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Nico > Huber > Sent: Saturday, November 04, 2017 5:38 AM > To: Jay Talbott; coreboot(a)coreboot.org > Cc: Stefan Reinauer > Subject: Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15) > CRB? > > Hi Jay, > > On 04.11.2017 01:26, Jay Talbott wrote: > > I'm trying to get coreboot up and running on an Intel RVP15 CRB, which is > > the same as the RVP7 except that the RVP15 has DDR4 memory instead of > DDR3. > > > > There is a mainboard solution for the RVP7 in coreboot. However, the > current > > KabyLake FSP published on GitHub doesn't seem like it's the right FSP for > > the SkyLake-U/KabyLake-U. If nothing else, there's a problem with that FSP > > such that the signature in the FSP-M UPD header does not match the > signature > > in the corresponding header files, so when the FSP 2.0 driver in coreboot > > goes to check that they are a match, execution dies right there. > > > > if (upd->FspUpdHeader.Signature != FSPM_UPD_SIGNATURE) > > die("Invalid FSPM signature!\n"); > > > > (coreboot/src/drivers/intel/fsp2_0/memory_init.c, in function > > do_fsp_memory_init) > > > > I don't want to bypass that check in the code in case the FSP posted to > > GitHub isn't the right FSP for this particular SoC. > > the FSP binary is probably the correct one, but you have to separate it > into three pieces: FSP-T, FSP-M, FSP-S. Did you do that? Only FSP-M and > FSP-S are needed in coreboot. There is a script (SplitFspBin.py in EDK > II) that can separate the blobs, I have no idea why Intel puts them to- > gether at all. > > IIRC, there is no version check on the binary. You have to compare the > header files used in coreboot and those that come with the binary manu- > ally. Generally, the binaries on github work with corebot. But they seem > to come out of a different development process at Intel. The Intel deve- > lopers working on coreboot seem to have no clue that the binaries on > github exist at all. And if you compare the history of the header files > in coreboot to those on github you'll see that Intel either pushes the > wrong headers or the binaries on github and the binaries used for core- > boot development are not from the same branch. It's really creepy (and > hard to tell which of the versions are the one with the backdoors oO). > > > Obviously, somebody at Intel has the right FSP that works for these boards > > in order to validate that the coreboot implementation worked prior to > > upstreaming it to the repo. I'm just not sure how to get the right one so > > that I can get this booting. > > As you have access to a CRB, your contact to Intel is probably better > than mine. You have to ask Intel. OEMs/ODMs/IBVs, they all seem to have > access to the binaries used for coreboot development... IMHO, a huge > offense to the coreboot community that we get to maintain the code for > blobs that we'll never see; not even the binaries! > > > Furthermore, I have yet to get the serial console working on the DB-9 serial > > port. I have the jumpers on the board configured to connect it to UART #2, > > and configured in coreboot accordingly, but I get nothing for console > > output. > > Please attach your .config file and point to the source revision you are > using. Hard to tell anything w/o the code. > > Nico > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

2 4

Who has experience with the Intel RVP7 (or RVP15) CRB?
by Jay Talbott 04 Nov '17

04 Nov '17

I'm trying to get coreboot up and running on an Intel RVP15 CRB, which is the same as the RVP7 except that the RVP15 has DDR4 memory instead of DDR3. There is a mainboard solution for the RVP7 in coreboot. However, the current KabyLake FSP published on GitHub doesn't seem like it's the right FSP for the SkyLake-U/KabyLake-U. If nothing else, there's a problem with that FSP such that the signature in the FSP-M UPD header does not match the signature in the corresponding header files, so when the FSP 2.0 driver in coreboot goes to check that they are a match, execution dies right there. if (upd->FspUpdHeader.Signature != FSPM_UPD_SIGNATURE) die("Invalid FSPM signature!\n"); (coreboot/src/drivers/intel/fsp2_0/memory_init.c, in function do_fsp_memory_init) I don't want to bypass that check in the code in case the FSP posted to GitHub isn't the right FSP for this particular SoC. Obviously, somebody at Intel has the right FSP that works for these boards in order to validate that the coreboot implementation worked prior to upstreaming it to the repo. I'm just not sure how to get the right one so that I can get this booting. Furthermore, I have yet to get the serial console working on the DB-9 serial port. I have the jumpers on the board configured to connect it to UART #2, and configured in coreboot accordingly, but I get nothing for console output. Any help would be most appreciated! Thanks, - Jay Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) <mailto:JayTalbott@sysproconsulting.com> JayTalbott(a)sysproconsulting.com <http://www.sysproconsulting.com/> http://www.sysproconsulting.com

4 6

Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15) CRB?
by Jay Talbott 04 Nov '17

04 Nov '17

Hi Matt, I’ll try XIP and see what happens… but how would that impact the UPD signature? The signature is defined in coreboot/src/vendorcode/intel/fsp/fsp2_0/skykabylake/FspUpd.h, as well as in FspUpd.h in the headers included with the FSP on GitHub. - Jay Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) JayTalbott(a)sysproconsulting.com http://www.sysproconsulting.com <http://www.sysproconsulting.com/> From: Matt DeVillier [mailto:matt.devillier@gmail.com] Sent: Saturday, November 04, 2017 9:59 AM To: Jay Talbott Cc: Nico Huber; coreboot; Stefan Reinauer Subject: Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15) CRB? On Sat, Nov 4, 2017 at 11:18 AM, Jay Talbott <JayTalbott(a)sysproconsulting.com> wrote: Ok, more details... I'm currently building Coreboot off the end of the master branch as of commit 43a285f983f6c29467d7f30f7e2b402926bd5c6f, but might back up to the commit where the RVP7 support was added to see if that helps: https://github.com/coreboot/coreboot/commit/2ed14f61d1a2976d0ebce59fcc67bd61 <https://github.com/coreboot/coreboot/commit/2ed14f61d1a2976d0ebce59fcc67bd6…> fce4100d I'm using the KBL FSP from GitHub: https://github.com/IntelFsp/FSP/tree/Kabylake/KabylakeFspBinPkg I got the SplitFspBin.py tool and split the FSP into its three separate components. And, eventually, found the right microcode files and made them into a binary blob using a modified version of the microcode2bin.sh script I found in the coreboot tree. My .config file (renamed as config.txt) is attached. you need to use the execute in place (XIP) option for FSP-M in your config Note that the signature in the Fsp_M binary UPD struct is what does not match what's in the corresponding FSP header file - and not just the header file in the coreboot tree, but the one published as part of the FSP package on GitHub. So something is definitely amiss here with this published FSP package. I'm not seeing any hardcoded signature value in FspmUpd.h (as there is in FSP 1.1) - can you point to a specific file/line number? I do not have the serial console working yet, so all I've had to go by are post codes, and the last post code I was getting was 0x34, which I tracked down to be a hardcoded (grr...) value at the beginning of do_fsp_memory_init() in file memory_init.c of the FSP 2.0 driver (./src/drivers/intel/fsp2_0)... static void do_fsp_memory_init(struct fsp_header *hdr, bool s3wake, const struct memranges *memmap) { uint32_t status; fsp_memory_init_fn fsp_raminit; FSPM_UPD fspm_upd, *upd; FSPM_ARCH_UPD *arch_upd; uint32_t fsp_version; post_code(0x34); fsp_version = fsp_memory_settings_version(hdr); upd = (FSPM_UPD *)(hdr->cfg_region_offset + hdr->image_base); if (upd->FspUpdHeader.Signature != FSPM_UPD_SIGNATURE) die("Invalid FSPM signature!\n"); ... I added a post code as part of the if to confirm that the signature mis-match was where the code was hanging. So I'm 100% certain that the mis-match exists with this particular FSP. Also, although the signature is the same, there are a few other differences between the header files included with the FSP and those currently in coreboot, but nothing that would seemingly account for this issue. Note that this particular FSP release on GitHub does NOT include any release notes to indicate for which SkyLake/Kaby Lake variants (-H, -U, -Y, etc.) it is applicable, but someone from Intel suggested that it's only applicable to -H. If that's the case, then how was the RVP7 support ever validated prior to integration into the coreboot tree? Which FSP was actually used? And does that even have anything to do with the signature mis-match issue? Nobody seems to know. I've been trying to get support on this through various channels at Intel that so far have not been particularly helpful, and it's extremely frustrating. I've sent several e-mails to various folks, including the individual that upstreamed the RVP7 support to coreboot and the individual who published the FSP to GitHub, which remain unanswered. Any help from the coreboot community would be most appreciated! Thanks! - Jay Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) JayTalbott(a)sysproconsulting.com http://www.sysproconsulting.com > -----Original Message----- > From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Nico > Huber > Sent: Saturday, November 04, 2017 5:38 AM > To: Jay Talbott; coreboot(a)coreboot.org > Cc: Stefan Reinauer > Subject: Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15) > CRB? > > Hi Jay, > > On 04.11.2017 01:26, Jay Talbott wrote: > > I'm trying to get coreboot up and running on an Intel RVP15 CRB, which is > > the same as the RVP7 except that the RVP15 has DDR4 memory instead of > DDR3. > > > > There is a mainboard solution for the RVP7 in coreboot. However, the > current > > KabyLake FSP published on GitHub doesn't seem like it's the right FSP for > > the SkyLake-U/KabyLake-U. If nothing else, there's a problem with that FSP > > such that the signature in the FSP-M UPD header does not match the > signature > > in the corresponding header files, so when the FSP 2.0 driver in coreboot > > goes to check that they are a match, execution dies right there. > > > > if (upd->FspUpdHeader.Signature != FSPM_UPD_SIGNATURE) > > die("Invalid FSPM signature!\n"); > > > > (coreboot/src/drivers/intel/fsp2_0/memory_init.c, in function > > do_fsp_memory_init) > > > > I don't want to bypass that check in the code in case the FSP posted to > > GitHub isn't the right FSP for this particular SoC. > > the FSP binary is probably the correct one, but you have to separate it > into three pieces: FSP-T, FSP-M, FSP-S. Did you do that? Only FSP-M and > FSP-S are needed in coreboot. There is a script (SplitFspBin.py in EDK > II) that can separate the blobs, I have no idea why Intel puts them to- > gether at all. > > IIRC, there is no version check on the binary. You have to compare the > header files used in coreboot and those that come with the binary manu- > ally. Generally, the binaries on github work with corebot. But they seem > to come out of a different development process at Intel. The Intel deve- > lopers working on coreboot seem to have no clue that the binaries on > github exist at all. And if you compare the history of the header files > in coreboot to those on github you'll see that Intel either pushes the > wrong headers or the binaries on github and the binaries used for core- > boot development are not from the same branch. It's really creepy (and > hard to tell which of the versions are the one with the backdoors oO). > > > Obviously, somebody at Intel has the right FSP that works for these boards > > in order to validate that the coreboot implementation worked prior to > > upstreaming it to the repo. I'm just not sure how to get the right one so > > that I can get this booting. > > As you have access to a CRB, your contact to Intel is probably better > than mine. You have to ask Intel. OEMs/ODMs/IBVs, they all seem to have > access to the binaries used for coreboot development... IMHO, a huge > offense to the coreboot community that we get to maintain the code for > blobs that we'll never see; not even the binaries! > > > Furthermore, I have yet to get the serial console working on the DB-9 serial > > port. I have the jumpers on the board configured to connect it to UART #2, > > and configured in coreboot accordingly, but I get nothing for console > > output. > > Please attach your .config file and point to the source revision you are > using. Hard to tell anything w/o the code. > > Nico > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

2 1

← Newer
1
...
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2017