coreboot September 2018

coreboot@coreboot.org

59 participants
160 discussions

Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
by Naresh G. Solanki 12 Sep '18

12 Sep '18

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

Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
by Jose Trujillo 12 Sep '18

12 Sep '18

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

1 0

Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
by Jose Trujillo 12 Sep '18

12 Sep '18

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

1 0

Re: [coreboot] Coffee Lake FSP Released
by Nico Huber 12 Sep '18

12 Sep '18

On 8/23/18 11:47 PM, Zimmer, Vincent wrote: > We agree > > See https://github.com/IntelFsp/FSP/blob/master/FSP_License.pdf > This is great news. Nate, Vincent thank you very much! IMHO, you two just doubled what Intel did for coreboot so far; in one day! This is the first time in five years that we can again have a coreboot for current Intel systems that compiles to something bootable out of the box*. Just checkout, select your board, build, flash :D Thanks again, Nico * Disclaimer: It will take some time until we have the configs set up, but it's at least feasible now.

2 1

Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
by Jose Trujillo 12 Sep '18

12 Sep '18

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

1 0

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by Jonathan Neuschäfer 11 Sep '18

11 Sep '18

On Fri, Jun 22, 2018 at 03:04:06PM +0800, Shawn wrote: > Hi Jonathan, > > On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer [...] > > With the unfinished coreboot port, I want it to look like this (although > > *a lot* of work has to be done on coreboot first, and I'm currently not > > actively working on that, for a few months): > > > > MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux, or > > MSEL (ROM0) -> coreboot (+bbl?) -> Linux > > > > ZSBL can be skipped, so you don't need to run closed source ROM code, at > > least as far as the hardware is concerned. > > > Is ZSBL really can be skipped? I thought it was part of internal ROM > inside the chip. Yes. If you set the MSEL switches to 0001, the code in the MSEL ROM (aka. ROM0) jumps directly into the memory-mapped SPI flash, instead of into the big ROM1, where ZSBL is. Coreboot doesn't yet support this mode, but the hardware allows it. > > (And note that this is just the situation on this particular SoC. Other > > SoCs from SiFive or other vendors may boot differently.) > > > Well, if FSBL is the place where coreboot comes into play, we might > only have two options: 1, Reversing the FSBL which is ~9k assembly LOC > 2, SiFive make the FSBL open source( I don't see any reason why they > don't do it if they intend to build an open eco-system for RISC-V). A high-level list of tasks that FSBL performs is in the manual[1]: • Switch core frequency to 1 GHz (or 500 MHz if TLCLKSEL =1) by configuring and running off the on-chip PLL • Configure DDR PLL, PHY, and controller • Set GEM GXL TX PLL to 125 MHz and reset it • If there is an external PHY, reset it • Download BBL from a partition with GUID type 2E54B353-1271-4842-806F-E436D6AF69851 • Scan the OTP for the chip serial number • Copy the embedded DTB to DDR, filling in FSBL version, memory size, and MAC address • Enable 15 of the 16 L2 ways (this removes almost all of the L2 LIM memory) • Jump to DDR memory (0x8000_0000) Initializing the PLLs and reading the OTP ROM should be easy enough because both are documented in, I think, sufficient detail. Section 20.3 describes the initialization sequence for the DRAM controller, but leaves out the values for the register for "memory timing settings, PAD mode configuration, initialization, and training." It says: "Please contact SiFive directly to determine the complete register settings for your application." I will ask on the forum. Assuming that SiFive will tell us the values of the missing configuration registers, I don't think we need to reverse-engineer FSBL. Greetings, Jonathan Neuschäfer [1]: https://www.sifive.com/documentation/chips/freedom-u540-c000-manual/

5 10

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 11 Sep '18

11 Sep '18

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. 3 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 1395655: (UNINIT) /src/soc/sifive/fu540/clint.c: 24 in mtime_init() /src/soc/sifive/fu540/clint.c: 25 in mtime_init() ________________________________________________________________________________________________________ *** CID 1395655: (UNINIT) /src/soc/sifive/fu540/clint.c: 24 in mtime_init() 18 #include <soc/addressmap.h> 19 #include <soc/clint.h> 20 21 void mtime_init(void) 22 { 23 long hart_id = read_csr(mhartid); >>> CID 1395655: (UNINIT) >>> Using uninitialized value "sp". 24 HLS()->time = (uint64_t *)(FU540_CLINT + 0xbff8); 25 HLS()->timecmp = (uint64_t *)(FU540_CLINT + 0x4000 + 8 * hart_id); 26 } 27 28 void set_msip(int hartid, int val) 29 { 30 long hart_id = read_csr(mhartid); 31 write32((void *)(FU540_CLINT + 4 * hart_id), !!val); /src/soc/sifive/fu540/clint.c: 25 in mtime_init() 19 #include <soc/clint.h> 20 21 void mtime_init(void) 22 { 23 long hart_id = read_csr(mhartid); 24 HLS()->time = (uint64_t *)(FU540_CLINT + 0xbff8); >>> CID 1395655: (UNINIT) >>> Using uninitialized value "sp". 25 HLS()->timecmp = (uint64_t *)(FU540_CLINT + 0x4000 + 8 * hart_id); 26 } 27 28 void set_msip(int hartid, int val) 29 { 30 long hart_id = read_csr(mhartid); 31 write32((void *)(FU540_CLINT + 4 * hart_id), !!val); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] Questions about using coreboot riscv with qemu
by ron minnich 11 Sep '18

11 Sep '18

I used to use spike exclusively. But, if you have a bit of money spend, get an arty board and get the bitstream and use "real" hardware. Lots better. On Tue, Sep 11, 2018 at 3:44 PM Angel Pons <th3fanbus(a)gmail.com> wrote: > Hello, > > > qemu-system-x86_64 -bios build/coreboot.rom -serial stdio > > Note that this command is for x86_64, which is not the architecture the > author of this thread is referring to (RISC-V) > > Regards, > > Angel Pons > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Questions about using coreboot riscv with qemu
by Angel Pons 11 Sep '18

11 Sep '18

Hello, > qemu-system-x86_64 -bios build/coreboot.rom -serial stdio Note that this command is for x86_64, which is not the architecture the author of this thread is referring to (RISC-V) Regards, Angel Pons

1 0

Questions about using coreboot riscv with qemu
by Liam Naddell 11 Sep '18

11 Sep '18

This is my first time using a mailing list btw, sorry. I was wondering how I could test the images I have built with `make riscv-crossgcc && make` using qemu. I tried running qemu-system-riscv64(the one gotten from the riscv-linux port), with the name of the image produced(coreboot.rom), and it did nothing. qemu-system-riscv64 ./build/coreboot.rom qemu-system-riscv64: Trying to execute code outside RAM or ROM at 0x0000000000000000 This usually means one of the following happened: (1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) (2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end (3) Your guest kernel has a bug and crashed by jumping off into nowhere This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. Execution cannot continue; stopping here. I also tried this using the -bios flag, and by using the make-spike-elf script with the -bios flag, and I still got nothing. It would be really nice if somebody could help me :).

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2018