September 2018 - coreboot - mail.coreboot.org

Re: [coreboot] Kabylake unable to boot with post code 0x71
by Jose Trujillo Sept. 17, 2018

Sept. 17, 2018

Dear Naresh: You are right; it never returns from the FSP function (fsp_silicon_init). chip_fsp20.c Ln.169 void soc_init_pre_device(void *chip_info) { printk(BIOS_INFO, "Entering: fsp_silicon_init"); // Added /* Perform silicon specific init. */ fsp_silicon_init(romstage_handoff_is_resume()); /* swap enabled PCI ports in device tree if needed */ printk(BIOS_INFO, "Entering: pcie_override_devicetree"); // Added pcie_override_devicetree_after_silicon_init(); printk(BIOS_INFO, "Exit: soc_init_pre_device"); // Added } Serial dump. .... Enabling SMIs. Locking SMM. VMX : param.enable = 0 VMX: pre-conditions not met VMX: pre-conditions not met VMX: pre-conditions not met SGX: pre-conditions not met VMX: pre-conditions not met SGX: pre-conditions not met POST: 0x71 SGX: pre-conditions not met SGX: pre-conditions not met Entering: fsp_silicon_init <------ never returns from FSP. .... About the FSP header version I am not sure how exactly to obtain it but getting the binary decription from BCT I got: Header Revision: 0x3 Image Revision: 0x3050000 3.0.5 ???? See the attached file for more details about the FSP binary. Please advise. Thank you, Jose Trujillo. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, September 14, 2018 6:58 PM, Naresh G. Solanki <naresh.solanki.2011(a)gmail.com> wrote: > With available data. It is most likely that it might have stuck > somewhere in function > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/ch… > You can add printk in that function & other functions called by it to > bisect & confirm the exact position of hang.. > Also can you please check FSP binary version you are using versus FSP > header version checked-out in coreboot(which is currently 2.9.2). > They should be > > On Fri, Sep 14, 2018 at 7:55 PM Jose Trujillo via coreboot > coreboot(a)coreboot.org wrote: > > > Here is Naresh.... > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Friday, September 14, 2018 4:49 PM, Naresh G. Solanki naresh.solanki.2011(a)gmail.com wrote: > > Can you also provide latest complete log. > > On Fri 14 Sep, 2018, 2:10 PM Jose Trujillo via coreboot, coreboot(a)coreboot.org wrote: > > > > > Thank you Naresh, > > > I added the missing PCH device id following your advise, also enabled DEBUG_BOOT_STATE but I am still not able to get more information via serial debug about the exact location of the problem (but now I am certain is in the coreboot code not in FSP). > > > I suspect the code involved aound this issue is hardwaremain.c and device.c.... > > > Only the first "boot" just after flash I notice that the ethernet and SATA LEDs blink for a fraction of a second then reboots. > > > After that, the following attempts to boot I don't see LED activity neither reboots, just halted in some kind of loop. > > > According to the serial dump the las printed text is "0x71" but my question is if the serial port gets broken still during "BS_DEV_INIT_CHIPS" or is already doing "BS_DEV_ENUMERATE". > > > As Naresh pointed my PCH H chipset "Kabylake-H HM175" was not added to the list; I added it but may be is needed to do something else to make it work. > > > Or istill is misconfigured (attached my .config file for your review)... I someone has a similar system working and want to share its configuration files to compare them myself I will be grateful. > > > Jose Trujillo. > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > > On Wednesday, 12 September 2018 19:33, Naresh G. Solanki naresh.solanki.2011(a)gmail.com wrote: > > > Hi > > > > > > > PCH: device id a152 (rev 31) is Unknown > > > > > > This indicates that LPCID 0xa152 is not added. > > > The #define should be added in source path: https://review.coreboot.org/cgit/coreboot.git/tree/src/include/device/pci_i… > > > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/common/blo… > > > & > > > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/bo… > > > as well. > > > Additionally you can enable config DEBUG_BOOT_STATE to understand where exactly its stuck. > > > Regards, > > > Naresh G. Solanki > > > On Wed, Sep 12, 2018 at 9:24 PM Jose Trujillo via coreboot coreboot(a)coreboot.org wrote: > > > > > > > Dear All, > > > > About the memory I just changed the dimm to address A0 and now coreboot is reporting correctly 1 dimm detected. > > > > But still no luck on the 0x71 post code loop (looks it is in some kind of loop because is still responsive to power and reset buttons). > > > > I don't know where this loop could be located (coreboot or FSP). > > > > The description on the post_codes.h file shows the following: > > > > .... > > > > /** > > > > > > > > - \brief Initializing Chips > > > > - > > > > - Boot State Machine: bs_dev_init_chips() > > > > */ > > > > #define POST_BS_DEV_INIT_CHIPS 0x71 > > > > .... > > > > > > > > > > > > Any advice on this issue? > > > > Attached is the serial dump with extra information. > > > > Thank you > > > > Jose Trujillo > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > > > On Wednesday, 12 September 2018 16:12, Jose Trujillo ce.autom(a)protonmail.com wrote: > > > > To begin with the system didn't find memory attached... > > > > but there is memory attached, SPD address mismatch? I will check. > > > > .... > > > > .......Timeout while sending command 0x0d to EC! > > > > recv_ec_data: 0xff > > > > recv_ec_data: 0xff > > > > SPD index 7 > > > > No memory dimm at address A0 > > > > No memory dimm at address A2 > > > > No memory dimm at address A6 > > > > .... > > > > 0 DIMMs found > > > > .... > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > > > On Wednesday, 12 September 2018 13:29, Jose Trujillo via coreboot coreboot(a)coreboot.org wrote: > > > > Dear coreboot engineers: > > > > Right now I am stuck with a Kabylake system with the following message: > > > > .... > > > > CPU #1 initialized > > > > apic_id: 0x06 done. > > > > microcode: updated to revision 0x8d date=2018-01-21 > > > > CPU #3 initialized > > > > bsp_do_flight_plan done after 220 msecs. > > > > CPU: frequency set to 3600 MHz > > > > Enabling SMIs. > > > > Locking SMM. > > > > VMX : param.enable = 0 > > > > VMX: pre-conditions not met > > > > SGX: pre-conditions not met > > > > VMX: pre-conditions not met > > > > VMX: pre-conditions not met > > > > SGX: pre-conditions not met > > > > SGX: pre-conditions not met > > > > VMX: pre-conditions not met > > > > SGX: pre-conditions not met > > > > POST: 0x71 > > > > .... > > > > May be some configuration is missing and I am trying to find this out myself but if someone of you can give a hint on how to resolve it I will be grateful. > > > > Attached is the full serial dump. > > > > Thank you, > > > > Jose Trujillo > > > > -- > > > > coreboot mailing list: coreboot(a)coreboot.org > > > > https://mail.coreboot.org/mailman/listinfo/coreboot > > > > > > -- > > > Best regards, > > > Naresh G. Solanki > > > -- > > > 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 > > -- > > Best regards, > Naresh G. Solanki

1 0

Re: [coreboot] Initializing the VBIOS in coreboot does not currently work. VBIOS initialized in SeaBios works correctly
by Jorge Fernandez Monteagudo Sept. 17, 2018

Sept. 17, 2018

Hi Martin! Thanks for answering! Do you have more info about this issue? How it begins? Any related commit or entry in the mailing list? ________________________________ De: Martin Roth <gaumless(a)gmail.com> Enviado: sábado, 15 de septiembre de 2018 10:14:56 Para: Jorge Fernandez Monteagudo Cc: coreboot Asunto: Re: [coreboot] Initializing the VBIOS in coreboot does not currently work. VBIOS initialized in SeaBios works correctly I don't think the issue was ever fully debugged. On Thu, Sep 13, 2018 at 7:05 AM Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com> wrote: > > Hi, > > > Anybody could give me more info about this message I've seen in: > > > https://www.coreboot.org/Board:amd/parmer > > > at the end you can see: > > > Other issues > > VBIOS > > Initializing the VBIOS in coreboot does not currently work. VBIOS initialized in SeaBios works correctly. This issue is being debugged as of March 27, 2013. > > > I'm having problems setting the video in the Tianocore payload (see https://mail.coreboot.org/pipermail/coreboot/2018-September/087304.html) > and maybe are related. Is the issue closed? > > Thanks! > Jorge > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Downloading an archive of the coreboot wiki
by Taiidan＠gmx.com Sept. 15, 2018

Sept. 15, 2018

Would this be the best way to do it? I want to do it in a way that I can host my own mediawiki server for me and my associates who consider it better than the new documentation method (which AFAIK the community voted against) wget -r -k -np -p -l 0 http://coreboot.com/wiki

2 1

Re: [coreboot] Initializing the VBIOS in coreboot does not currently work. VBIOS initialized in SeaBios works correctly
by Martin Roth Sept. 15, 2018

Sept. 15, 2018

I don't think the issue was ever fully debugged. On Thu, Sep 13, 2018 at 7:05 AM Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com> wrote: > > Hi, > > > Anybody could give me more info about this message I've seen in: > > > https://www.coreboot.org/Board:amd/parmer > > > at the end you can see: > > > Other issues > > VBIOS > > Initializing the VBIOS in coreboot does not currently work. VBIOS initialized in SeaBios works correctly. This issue is being debugged as of March 27, 2013. > > > I'm having problems setting the video in the Tianocore payload (see https://mail.coreboot.org/pipermail/coreboot/2018-September/087304.html) > and maybe are related. Is the issue closed? > > Thanks! > Jorge > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Kabylake unable to boot with post code 0x71
by Naresh G. Solanki Sept. 14, 2018

Sept. 14, 2018

With available data. It is most likely that it might have stuck somewhere in function https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/ch… You can add printk in that function & other functions called by it to bisect & confirm the exact position of hang.. Also can you please check FSP binary version you are using versus FSP header version checked-out in coreboot(which is currently 2.9.2). They should be On Fri, Sep 14, 2018 at 7:55 PM Jose Trujillo via coreboot <coreboot(a)coreboot.org> wrote: > > Here is Naresh.... > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, September 14, 2018 4:49 PM, Naresh G. Solanki <naresh.solanki.2011(a)gmail.com> wrote: > > Can you also provide latest complete log. > > On Fri 14 Sep, 2018, 2:10 PM Jose Trujillo via coreboot, <coreboot(a)coreboot.org> wrote: >> >> Thank you Naresh, >> >> I added the missing PCH device id following your advise, also enabled DEBUG_BOOT_STATE but I am still not able to get more information via serial debug about the exact location of the problem (but now I am certain is in the coreboot code not in FSP). >> >> I suspect the code involved aound this issue is hardwaremain.c and device.c.... >> >> >> Only the first "boot" just after flash I notice that the ethernet and SATA LEDs blink for a fraction of a second then reboots. >> After that, the following attempts to boot I don't see LED activity neither reboots, just halted in some kind of loop. >> >> According to the serial dump the las printed text is "0x71" but my question is if the serial port gets broken still during "BS_DEV_INIT_CHIPS" or is already doing "BS_DEV_ENUMERATE". >> >> As Naresh pointed my PCH H chipset "Kabylake-H HM175" was not added to the list; I added it but may be is needed to do something else to make it work. >> Or istill is misconfigured (attached my .config file for your review)... I someone has a similar system working and want to share its configuration files to compare them myself I will be grateful. >> >> Jose Trujillo. >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Wednesday, 12 September 2018 19:33, Naresh G. Solanki <naresh.solanki.2011(a)gmail.com> wrote: >> >> Hi >> >> >PCH: device id a152 (rev 31) is Unknown >> >> This indicates that LPCID 0xa152 is not added. >> >> The #define should be added in source path: https://review.coreboot.org/cgit/coreboot.git/tree/src/include/device/pci_i… >> >> https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/common/blo… >> >> & >> >> https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/bo… >> >> as well. >> >> >> >> Additionally you can enable config DEBUG_BOOT_STATE to understand where exactly its stuck. >> >> >> Regards, >> >> Naresh G. Solanki >> >> >> On Wed, Sep 12, 2018 at 9:24 PM Jose Trujillo via coreboot <coreboot(a)coreboot.org> wrote: >>> >>> Dear All, >>> About the memory I just changed the dimm to address A0 and now coreboot is reporting correctly 1 dimm detected. >>> >>> But still no luck on the 0x71 post code loop (looks it is in some kind of loop because is still responsive to power and reset buttons). >>> I don't know where this loop could be located (coreboot or FSP). >>> The description on the post_codes.h file shows the following: >>> .... >>> /** >>> * \brief Initializing Chips >>> * >>> * Boot State Machine: bs_dev_init_chips() >>> */ >>> #define POST_BS_DEV_INIT_CHIPS 0x71 >>> .... >>> >>> Any advice on this issue? >>> Attached is the serial dump with extra information. >>> >>> Thank you >>> Jose Trujillo >>> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Wednesday, 12 September 2018 16:12, Jose Trujillo <ce.autom(a)protonmail.com> wrote: >>> >>> To begin with the system didn't find memory attached... >>> but there is memory attached, SPD address mismatch? I will check. >>> .... >>> .......Timeout while sending command 0x0d to EC! >>> recv_ec_data: 0xff >>> recv_ec_data: 0xff >>> SPD index 7 >>> No memory dimm at address A0 >>> No memory dimm at address A2 >>> No memory dimm at address A6 >>> .... >>> 0 DIMMs found >>> .... >>> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Wednesday, 12 September 2018 13:29, Jose Trujillo via coreboot <coreboot(a)coreboot.org> wrote: >>> >>> Dear coreboot engineers: >>> >>> Right now I am stuck with a Kabylake system with the following message: >>> .... >>> CPU #1 initialized >>> apic_id: 0x06 done. >>> microcode: updated to revision 0x8d date=2018-01-21 >>> CPU #3 initialized >>> bsp_do_flight_plan done after 220 msecs. >>> CPU: frequency set to 3600 MHz >>> Enabling SMIs. >>> Locking SMM. >>> VMX : param.enable = 0 >>> VMX: pre-conditions not met >>> SGX: pre-conditions not met >>> VMX: pre-conditions not met >>> VMX: pre-conditions not met >>> SGX: pre-conditions not met >>> SGX: pre-conditions not met >>> VMX: pre-conditions not met >>> SGX: pre-conditions not met >>> POST: 0x71 >>> .... >>> >>> May be some configuration is missing and I am trying to find this out myself but if someone of you can give a hint on how to resolve it I will be grateful. >>> >>> Attached is the full serial dump. >>> >>> Thank you, >>> Jose Trujillo >>> >>> >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> >> >> -- >> Best regards, >> Naresh G. Solanki >> >> >> -- >> 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 -- Best regards, Naresh G. Solanki

1 0

Re: [coreboot] Kabylake unable to boot with post code 0x71
by Jose Trujillo Sept. 14, 2018

Sept. 14, 2018

Here is Naresh.... ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, September 14, 2018 4:49 PM, Naresh G. Solanki <naresh.solanki.2011(a)gmail.com> wrote: > Can you also provide latest complete log. > > On Fri 14 Sep, 2018, 2:10 PM Jose Trujillo via coreboot, <coreboot(a)coreboot.org> wrote: > >> Thank you Naresh, >> >> I added the missing PCH device id following your advise, also enabled DEBUG_BOOT_STATE but I am still not able to get more information via serial debug about the exact location of the problem (but now I am certain is in the coreboot code not in FSP). >> >> I suspect the code involved aound this issue is hardwaremain.c and device.c.... >> >> Only the first "boot" just after flash I notice that the ethernet and SATA LEDs blink for a fraction of a second then reboots. >> After that, the following attempts to boot I don't see LED activity neither reboots, just halted in some kind of loop. >> >> According to the serial dump the las printed text is "0x71" but my question is if the serial port gets broken still during "BS_DEV_INIT_CHIPS" or is already doing "BS_DEV_ENUMERATE". >> >> As Naresh pointed my PCH H chipset "Kabylake-H HM175" was not added to the list; I added it but may be is needed to do something else to make it work. >> Or istill is misconfigured (attached my .config file for your review)... I someone has a similar system working and want to share its configuration files to compare them myself I will be grateful. >> >> Jose Trujillo. >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Wednesday, 12 September 2018 19:33, Naresh G. Solanki <naresh.solanki.2011(a)gmail.com> wrote: >> >>> Hi >>> >>>>PCH: device id a152 (rev 31) is Unknown >>> >>> This indicates that LPCID 0xa152 is not added. >>> >>> The #define should be added in source path: >>> https://review.coreboot.org/cgit/coreboot.git/tree/src/include/device/pci_i… >>> >>> https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/common/blo… >>> >>> & >>> >>> https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/bo… >>> >>> as well. >>> >>> Additionally you can enable config DEBUG_BOOT_STATE to understand where exactly its stuck. >>> >>> Regards, >>> >>> Naresh G. Solanki >>> >>> On Wed, Sep 12, 2018 at 9:24 PM Jose Trujillo via coreboot <coreboot(a)coreboot.org> wrote: >>> >>>> Dear All, >>>> About the memory I just changed the dimm to address A0 and now coreboot is reporting correctly 1 dimm detected. >>>> >>>> But still no luck on the 0x71 post code loop (looks it is in some kind of loop because is still responsive to power and reset buttons). >>>> I don't know where this loop could be located (coreboot or FSP). >>>> The description on the post_codes.h file shows the following: >>>> .... >>>> /** >>>> * \brief Initializing Chips >>>> * >>>> * Boot State Machine: bs_dev_init_chips() >>>> */ >>>> #define POST_BS_DEV_INIT_CHIPS 0x71 >>>> .... >>>> >>>> Any advice on this issue? >>>> Attached is the serial dump with extra information. >>>> >>>> Thank you >>>> Jose Trujillo >>>> >>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>>> On Wednesday, 12 September 2018 16:12, Jose Trujillo <ce.autom(a)protonmail.com> wrote: >>>> >>>>> To begin with the system didn't find memory attached... >>>>> but there is memory attached, SPD address mismatch? I will check. >>>>> .... >>>>> .......Timeout while sending command 0x0d to EC! >>>>> recv_ec_data: 0xff >>>>> recv_ec_data: 0xff >>>>> SPD index 7 >>>>> No memory dimm at address A0 >>>>> No memory dimm at address A2 >>>>> No memory dimm at address A6 >>>>> .... >>>>> 0 DIMMs found >>>>> .... >>>>> >>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>>>> On Wednesday, 12 September 2018 13:29, Jose Trujillo via coreboot <coreboot(a)coreboot.org> wrote: >>>>> >>>>>> Dear coreboot engineers: >>>>>> >>>>>> Right now I am stuck with a Kabylake system with the following message: >>>>>> .... >>>>>> CPU #1 initialized >>>>>> apic_id: 0x06 done. >>>>>> microcode: updated to revision 0x8d date=2018-01-21 >>>>>> CPU #3 initialized >>>>>> bsp_do_flight_plan done after 220 msecs. >>>>>> CPU: frequency set to 3600 MHz >>>>>> Enabling SMIs. >>>>>> Locking SMM. >>>>>> VMX : param.enable = 0 >>>>>> VMX: pre-conditions not met >>>>>> SGX: pre-conditions not met >>>>>> VMX: pre-conditions not met >>>>>> VMX: pre-conditions not met >>>>>> SGX: pre-conditions not met >>>>>> SGX: pre-conditions not met >>>>>> VMX: pre-conditions not met >>>>>> SGX: pre-conditions not met >>>>>> POST: 0x71 >>>>>> .... >>>>>> >>>>>> May be some configuration is missing and I am trying to find this out myself but if someone of you can give a hint on how to resolve it I will be grateful. >>>>>> >>>>>> Attached is the full serial dump. >>>>>> >>>>>> Thank you, >>>>>> Jose Trujillo >>>> >>>> -- >>>> coreboot mailing list: coreboot(a)coreboot.org >>>> https://mail.coreboot.org/mailman/listinfo/coreboot >>> >>> -- >>> Best regards, >>> Naresh G. Solanki >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com Sept. 14, 2018

Sept. 14, 2018

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1395707: (UNINIT) /src/arch/riscv/arch_timer.c: 25 in timer_monotonic_get() /src/arch/riscv/arch_timer.c: 27 in timer_monotonic_get() ________________________________________________________________________________________________________ *** CID 1395707: (UNINIT) /src/arch/riscv/arch_timer.c: 25 in timer_monotonic_get() 19 #include <stddef.h> 20 #include <timer.h> 21 #include <mcall.h> 22 23 void timer_monotonic_get(struct mono_time *mt) 24 { >>> CID 1395707: (UNINIT) >>> Using uninitialized value "sp". 25 if (HLS()->time == NULL) 26 die("time not set in HLS"); 27 mono_time_set_usecs(mt, (long)read64((void *)(HLS()->time))); /src/arch/riscv/arch_timer.c: 27 in timer_monotonic_get() 21 #include <mcall.h> 22 23 void timer_monotonic_get(struct mono_time *mt) 24 { 25 if (HLS()->time == NULL) 26 die("time not set in HLS"); >>> CID 1395707: (UNINIT) >>> Using uninitialized value "sp". 27 mono_time_set_usecs(mt, (long)read64((void *)(HLS()->time))); ** CID 1395706: Memory - illegal accesses (OVERRUN) /src/arch/x86/acpi_bert_storage.c: 324 in new_cper_ia32x64_ctx() ________________________________________________________________________________________________________ *** CID 1395706: Memory - illegal accesses (OVERRUN) /src/arch/x86/acpi_bert_storage.c: 324 in new_cper_ia32x64_ctx() 318 }; 319 320 if (type > CPER_IA32X64_CTX_MEMMAPPED) 321 return NULL; 322 323 if (cper_ia32x64_proc_num_ctxs(x86err) == I32X64SEC_VALID_CTXNUM_MAX) { >>> CID 1395706: Memory - illegal accesses (OVERRUN) >>> Overrunning array "ctx_names" of 5 4-byte elements at element index 7 (byte offset 28) using index "type" (which evaluates to 7). 324 printk(BIOS_ERR, "Error: New IA32X64 %s context entry would exceed max allowable contexts\n", 325 ctx_names[type]); 326 return NULL; 327 } 328 329 size = cper_ia32x64_ctx_sz_bytype(type, num); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] Kabylake unable to boot with post code 0x71
by Naresh G. Solanki Sept. 14, 2018

Sept. 14, 2018

Can you also provide latest complete log. On Fri 14 Sep, 2018, 2:10 PM Jose Trujillo via coreboot, < coreboot(a)coreboot.org> wrote: > Thank you Naresh, > > I added the missing PCH device id following your advise, also enabled DEBUG_BOOT_STATE > but I am still not able to get more information via serial debug about the > exact location of the problem (but now I am certain is in the coreboot code > not in FSP). > > I suspect the code involved aound this issue is hardwaremain.c and > device.c.... > > > Only the first "boot" just after flash I notice that the ethernet and SATA > LEDs blink for a fraction of a second then reboots. > After that, the following attempts to boot I don't see LED activity > neither reboots, just halted in some kind of loop. > > According to the serial dump the las printed text is "0x71" but my > question is if the serial port gets broken still during "BS_DEV_INIT_CHIPS" > or is already doing "BS_DEV_ENUMERATE". > > As Naresh pointed my PCH H chipset "Kabylake-H HM175" was not added to the > list; I added it but may be is needed to do something else to make it work. > Or istill is misconfigured (attached my .config file for your review)... I > someone has a similar system working and want to share its configuration > files to compare them myself I will be grateful. > > Jose Trujillo. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Wednesday, 12 September 2018 19:33, Naresh G. Solanki < > naresh.solanki.2011(a)gmail.com> wrote: > > Hi > > >PCH: device id a152 (rev 31) is Unknown > > This indicates that LPCID 0xa152 is not added. > > The #define should be added in source path: https://review.coreboot.org/cgit/coreboot.git/tree/src/include/device/pci_i… > > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/common/blo… > > & > > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/bo… > > as well. > > > > Additionally you can enable config DEBUG_BOOT_STATE to understand where exactly its stuck. > > > Regards, > > Naresh G. Solanki > > > On Wed, Sep 12, 2018 at 9:24 PM Jose Trujillo via coreboot < > coreboot(a)coreboot.org> wrote: > >> Dear All, >> About the memory I just changed the dimm to address A0 and now coreboot >> is reporting correctly 1 dimm detected. >> >> But still no luck on the 0x71 post code loop (looks it is in some kind of >> loop because is still responsive to power and reset buttons). >> I don't know where this loop could be located (coreboot or FSP). >> The description on the post_codes.h file shows the following: >> .... >> /** >> * \brief Initializing Chips >> * >> * Boot State Machine: bs_dev_init_chips() >> */ >> #define POST_BS_DEV_INIT_CHIPS 0x71 >> .... >> >> Any advice on this issue? >> Attached is the serial dump with extra information. >> >> Thank you >> Jose Trujillo >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Wednesday, 12 September 2018 16:12, Jose Trujillo < >> ce.autom(a)protonmail.com> wrote: >> >> To begin with the system didn't find memory attached... >> but there is memory attached, SPD address mismatch? I will check. >> .... >> .......Timeout while sending command 0x0d to >> EC! >> recv_ec_data: >> 0xff >> recv_ec_data: >> 0xff >> SPD index >> 7 >> No memory dimm at address >> A0 >> No memory dimm at address >> A2 >> No memory dimm at address A6 >> .... >> 0 DIMMs found >> .... >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Wednesday, 12 September 2018 13:29, Jose Trujillo via coreboot < >> coreboot(a)coreboot.org> wrote: >> >> Dear coreboot engineers: >> >> Right now I am stuck with a Kabylake system with the following message: >> .... >> CPU #1 >> initialized >> apic_id: 0x06 >> done. >> microcode: updated to revision 0x8d >> date=2018-01-21 >> CPU #3 >> initialized >> bsp_do_flight_plan done after 220 >> msecs. >> CPU: frequency set to 3600 >> MHz >> Enabling >> SMIs. >> Locking >> SMM. >> VMX : param.enable = >> 0 >> VMX: pre-conditions not >> met >> SGX: pre-conditions not >> met >> VMX: pre-conditions not >> met >> VMX: pre-conditions not >> met >> SGX: pre-conditions not >> met >> SGX: pre-conditions not >> met >> VMX: pre-conditions not >> met >> SGX: pre-conditions not >> met >> POST: 0x71 >> .... >> >> May be some configuration is missing and I am trying to find this out >> myself but if someone of you can give a hint on how to resolve it I will be >> grateful. >> >> Attached is the full serial dump. >> >> Thank you, >> Jose Trujillo >> >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > > > -- > Best regards, > Naresh G. Solanki > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Kabylake unable to boot with post code 0x71
by Jose Trujillo Sept. 14, 2018

Sept. 14, 2018

Thank you Naresh, I added the missing PCH device id following your advise, also enabled DEBUG_BOOT_STATE but I am still not able to get more information via serial debug about the exact location of the problem (but now I am certain is in the coreboot code not in FSP). I suspect the code involved aound this issue is hardwaremain.c and device.c.... Only the first "boot" just after flash I notice that the ethernet and SATA LEDs blink for a fraction of a second then reboots. After that, the following attempts to boot I don't see LED activity neither reboots, just halted in some kind of loop. According to the serial dump the las printed text is "0x71" but my question is if the serial port gets broken still during "BS_DEV_INIT_CHIPS" or is already doing "BS_DEV_ENUMERATE". As Naresh pointed my PCH H chipset "Kabylake-H HM175" was not added to the list; I added it but may be is needed to do something else to make it work. Or istill is misconfigured (attached my .config file for your review)... I someone has a similar system working and want to share its configuration files to compare them myself I will be grateful. Jose Trujillo. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, 12 September 2018 19:33, Naresh G. Solanki <naresh.solanki.2011(a)gmail.com> wrote: > Hi > >>PCH: device id a152 (rev 31) is Unknown > > This indicates that LPCID 0xa152 is not added. > > The #define should be added in source path: > https://review.coreboot.org/cgit/coreboot.git/tree/src/include/device/pci_i… > > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/common/blo… > > & > > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/bo… > > as well. > > Additionally you can enable config DEBUG_BOOT_STATE to understand where exactly its stuck. > > Regards, > > Naresh G. Solanki > > On Wed, Sep 12, 2018 at 9:24 PM Jose Trujillo via coreboot <coreboot(a)coreboot.org> wrote: > >> Dear All, >> About the memory I just changed the dimm to address A0 and now coreboot is reporting correctly 1 dimm detected. >> >> But still no luck on the 0x71 post code loop (looks it is in some kind of loop because is still responsive to power and reset buttons). >> I don't know where this loop could be located (coreboot or FSP). >> The description on the post_codes.h file shows the following: >> .... >> /** >> * \brief Initializing Chips >> * >> * Boot State Machine: bs_dev_init_chips() >> */ >> #define POST_BS_DEV_INIT_CHIPS 0x71 >> .... >> >> Any advice on this issue? >> Attached is the serial dump with extra information. >> >> Thank you >> Jose Trujillo >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Wednesday, 12 September 2018 16:12, Jose Trujillo <ce.autom(a)protonmail.com> wrote: >> >>> To begin with the system didn't find memory attached... >>> but there is memory attached, SPD address mismatch? I will check. >>> .... >>> .......Timeout while sending command 0x0d to EC! >>> recv_ec_data: 0xff >>> recv_ec_data: 0xff >>> SPD index 7 >>> No memory dimm at address A0 >>> No memory dimm at address A2 >>> No memory dimm at address A6 >>> .... >>> 0 DIMMs found >>> .... >>> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Wednesday, 12 September 2018 13:29, Jose Trujillo via coreboot <coreboot(a)coreboot.org> wrote: >>> >>>> Dear coreboot engineers: >>>> >>>> Right now I am stuck with a Kabylake system with the following message: >>>> .... >>>> CPU #1 initialized >>>> apic_id: 0x06 done. >>>> microcode: updated to revision 0x8d date=2018-01-21 >>>> CPU #3 initialized >>>> bsp_do_flight_plan done after 220 msecs. >>>> CPU: frequency set to 3600 MHz >>>> Enabling SMIs. >>>> Locking SMM. >>>> VMX : param.enable = 0 >>>> VMX: pre-conditions not met >>>> SGX: pre-conditions not met >>>> VMX: pre-conditions not met >>>> VMX: pre-conditions not met >>>> SGX: pre-conditions not met >>>> SGX: pre-conditions not met >>>> VMX: pre-conditions not met >>>> SGX: pre-conditions not met >>>> POST: 0x71 >>>> .... >>>> >>>> May be some configuration is missing and I am trying to find this out myself but if someone of you can give a hint on how to resolve it I will be grateful. >>>> >>>> Attached is the full serial dump. >>>> >>>> Thank you, >>>> Jose Trujillo >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > Best regards, > Naresh G. Solanki

1 0

Initializing the VBIOS in coreboot does not currently work. VBIOS initialized in SeaBios works correctly
by Jorge Fernandez Monteagudo Sept. 13, 2018

Sept. 13, 2018

Hi, Anybody could give me more info about this message I've seen in: https://www.coreboot.org/Board:amd/parmer at the end you can see: Other issues VBIOS Initializing the VBIOS in coreboot does not currently work. VBIOS initialized in SeaBios works correctly. This issue is being debugged as of March 27, 2013. I'm having problems setting the video in the Tianocore payload (see https://mail.coreboot.org/pipermail/coreboot/2018-September/087304.html) and maybe are related. Is the issue closed? Thanks! Jorge

1 0