coreboot November 2017

coreboot@coreboot.org

61 participants
110 discussions

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Cameron Craig 03 Nov '17

03 Nov '17

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 | fax: | mobile: e: Cameron.Craig(a)exterity.com | w: www.exterity.com ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________

2 1

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

03 Nov '17

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<http://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] BayTrail PCIe problems (hangup) in FSP (in U-Boot)
by Stefan Roese 03 Nov '17

03 Nov '17

Hi Ron, On 02.11.2017 16:20, ron minnich wrote: > Simon Glass has done excellent work with making u-boot run as a coreboot > payload for at least 5 years now. You might want to talk to him. It > might help avoid a lot of unnecessary work. Just a thought. I'm in contact with Simon, thanks for the notice. He also did a lot of work on getting U-Boot running as a standalone bootloader on some x86 platforms (e.g. MinnowMax). I understand that it is debatable, if this is "needed" or not. Even though diversity might help all parties - at least from my point of view. In this special case, I might have triggered a bug / issue in the Intel FSP and solving this might also help the coreboot project / community. Thanks, Stefan > On Thu, Nov 2, 2017 at 7:31 AM Peter Stuge <peter(a)stuge.se > <mailto:peter@stuge.se>> wrote: > > Hi Stefan, > > Stefan Roese wrote: > > I'm facing a PCIe init related problem most likely caused in the > > Intel FSP in our BayTrail U-Boot port (not coreboot!). I hope you > > don't mind me posting this question on this coreboot list, since > > here many more people are present with Intel FSP knowledge. > > I think you are actively hurting the overall ecosystem by working on > a different project (FSP in U-Boot) which overlaps with coreboot > efforts. > > The only thing that makes sense is for U-Boot to focus on being a > payload that is started by coreboot (this has already been done) and > for your issues to be solved within the coreboot frame. > > Anything else is an obviously selfish effort by Denx and I don't see > why the coreboot community would support that. Please know that I > have no bias against Denx, since I had no experience with Denx I > thus far always erred on the side of giving benefit of the doubt. > > At the very least, you should have framed your question in a coreboot > setting, if you want to engage with the coreboot community. > > That is of course still very much possible. > > > //Peter > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot > > >

4 4

Re: [coreboot] KGPE-D16 AMD-vi fails because combined sata is enabled
by Patrick Georgi 03 Nov '17

03 Nov '17

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 Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Zoran Stojsavljevic 03 Nov '17

03 Nov '17

>> ahwan writes >> Please advise, thank you. Mario (Werner), You should offer to this guy job (Siemens Motion Control) in DE (Bayern). He is tough guy, as I read/percept. I am (dead) serious. Zoran Stojsavljevic On Fri, Nov 3, 2017 at 8:37 AM, ahW@n via coreboot <coreboot(a)coreboot.org> wrote: > 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 > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

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

03 Nov '17

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] KGPE-D16 AMD-vi fails because combined sata is enabled
by Peter Stuge 03 Nov '17

03 Nov '17

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

2 1

Re: [coreboot] X230 coreboot potential issues?
by Nico Huber 03 Nov '17

03 Nov '17

Hi, On 27.10.2017 22:10, Hans Fritz wrote: > Hi, I installed coreboot on my X230, it works very well except for > these two things: > > When the screen goes to sleep and I move the mouse to wake it up, it > wakes up at full brightness regardless of what the setting was before > it went to sleep. If I press the button to lower or increase > brightness, it switches back to what it was before sleeping. This > didn't happen with the same Linux install but on the stock BIOS. this is a known issue. It actually was there all the time but only got more visible with the introduction of ACPI/OpRegion for the inte- grated GFX. Here is what I found out so far (on my ArchLinux): w/o OpRegion: 1. `acpi_video` driver gets loaded, systemd restores brightness from last shutdown. 2. `i915` driver gets loaded, reads the current brightness. 3. `i915` exposes backlight as `intel_backlight`, systemd restores brightness from last shutdown here as well. Every time `i915` power cycles the backlight, it restores the value it has seen when it was loaded. w/ Opregion the order somehow changes to 2. 1. 3., now `i915` always restores to 100% that it read before systemd restored the brightness. A sane solution would be to extend XBCM in `src/drivers/intel/gma/acpi/ configure_brightness_levels.asl` to always notify `i915` when we change the backlight through OpRegion mailbox 3. > > The Fn key used to wake up the computer, but it doesn't anymore. Most > Fn key combinations still work, except for Fn+F3 (lock screen). This > was fine with the same Ubuntu install and the stock BIOS. IIRC, this is configurable in the vendor BIOS and likely a option in the EC that nobody missed enough to implement it in coreboot. Might be as simple as h8_fn_ctrl_swap(). Fn+F3 might just need a little more ACPI code. > > Any thoughts? Are these issues with coreboot? Should I file an issue somewhere? Yes please, https://ticket.coreboot.org/ Nico

2 1

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building
by ahW＠n 03 Nov '17

03 Nov '17

Zoran, and others, I wanted to build coreboot for APL CRP too. Tried to compile but failed at last command I think. *Image written successfully to build/cbfs/fallback/ifwi.bin.tmp.* *INFO: Performing operation on 'IFWI' region...* *E: Image is missing 'IFWI' region* *E: The image will be left unmodified.* *src/soc/intel/apollolake/Makefile.inc:128: recipe for target 'files_added' failed* *make: *** [files_added] Error 1* Have been searching around for solution and correct steps to do so but still no luck... Have you get your APL coreboot working? I tried CONFIG_IFWI_FILE_NAME pointed to an original UEFI BIOS file (direct SPI flashable binary, tested). Also tried use FIT to regenerate new file with changes below:- Platform Protection/Platform Integrity OOEM Public Key Hash => 00..00 Platform Protection/Boot Guard Configuration/ Boot profile 2 => 0 I am not sure I have the correct .config Anyone here can advise what I am doing wrong or am I missing anything? Thank you. user@localhost:~/coreboot$ build/util/cbfstool/cbfstool build/coreboot.rom print Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 26852 none cpu_microcode_blob.bin 0x69c0 microcode 0 none fallback/ramstage 0x6a40 stage 67533 none vgaroms/seavgabios.bin 0x17280 raw 26624 none config 0x1db00 raw 424 none revision 0x1dd00 raw 576 none fallback/postcar 0x1df80 stage 16464 none fallback/dsdt.aml 0x22040 raw 99 none fallback/payload 0x22100 payload 63073 none payload_config 0x317c0 raw 1632 none payload_revision 0x31e80 raw 239 none (empty) 0x31fc0 null 8052440 none mrc.cache 0x7dfec0 mrc_cache 65536 none (empty) 0x7eff00 null 32664 none bootblock 0x7f7ec0 bootblock 32768 none user@localhost:~/coreboot$ build/util/cbfstool/ifwitool ./build/cbfs/fallback/ifwi.bin.tmp print Header BPDT Signature 0x000055aa Descriptor count 13 BPDT Version 1 XOR checksum 0x0 IFWI Version 0x0 FIT Tool Version 0x472000c00000003 BPDT entries Entry # Sub-Partition Name Type Flags Offset Size File Offset ========================================================================================================================================================================================================= 1 DLMP CSE_IDLM 9 0x00000000 0x0 0x0 0x0 2 IFP_OVERRIDE IFP_OVERRIDE 10 0x00000000 0x200 0x10 0x200 3 S_BPDT S-BPDT 5 0x00000000 0xe9000 0x149000 0xe9000 4 RBEP CSE_RBE 1 0x00000000 0x69000 0xa000 0x69000 5 UFS_PHY UFS Phy 12 0x00000000 0x0 0x0 0x0 6 UFS_GPP UFS GPP 13 0x00000000 0x0 0x0 0x0 7 UEP UEP 17 0x00000000 0x210 0x108 0x210 8 IBBP Bootblock 4 0x00000000 0x1000 0x64000 0x1000 9 SMIP SMIP 0 0x00000000 0x65000 0x4000 0x65000 10 PMCP PMC firmware 14 0x00000000 0x73000 0x10000 0x73000 11 FTPR CSE_BUP 2 0x00000000 0x83000 0x5c000 0x83000 12 UCOD Microcode 3 0x00000000 0xdf000 0x8000 0xdf000 13 DEBUG_TOKENS Debug Tokens 11 0x00000000 0xe7000 0x2000 0xe7000 ========================================================================================================================================================================================================= Header S-BPDT Signature 0x000055aa Descriptor count 3 BPDT Version 1 XOR checksum 0x0 IFWI Version 0x0 FIT Tool Version 0x472000c00000003 S-BPDT entries Entry # Sub-Partition Name Type Flags Offset Size File Offset ========================================================================================================================================================================================================= 1 IUNP IUNIT 15 0x00000000 0xea000 0x2000 0xea000 2 NFTP CSE_MAIN 7 0x00000000 0xec000 0x106000 0xec000 3 ISHP ISH 8 0x00000000 0x1f2000 0x40000 0x1f2000 ==================================================================================================================================================================================

1 0

Does S3 work on Haswell boards?
by Аладышев Константин 02 Nov '17

02 Nov '17

I have problem with S3 mode on Haswell board. Everything is fine if S3 time is very small (<15 seconds), but if it is longer, coreboot won't resume. It fails on quick_ram_check. I've enabled mrc.cache and ME in coreboot. I use ME binary from original board and MRC.bin from Google Panther. Log from S3 resume: """ Disabling Watchdog reboot... done. SMBus controller enabled. Setting up static northbridge registers... done. Initializing Graphics... Back from haswell_early_initialization() Resume from S3 detected. CPU id(40651) ucode:0000001c Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz AES supported, TXT supported, VT supported PCH type: LP Premium, device id: 9c43, rev id 4 Starting UEFI PEI System Agent CBFS: CBFS_HEADER_ROM_ADDRESS: 0xfffff7d0/0x1000000 CBFS: CBFS location: 0xf00000~0xfff7c0, align: 64 CBFS: Looking for 'mrc.cache' starting from 0xf00000. CBFS: - load entry 0xf00000 file name (16 bytes)... CBFS: (unmatched file @0xf00000: bootsplash.jpg) CBFS: - load entry 0xf187c0 file name (16 bytes)... CBFS: (unmatched file @0xf187c0: bootorder) CBFS: - load entry 0xf18b80 file name (16 bytes)... CBFS: (unmatched file @0xf18b80: cmos_layout.bin) CBFS: - load entry 0xf19040 file name (32 bytes)... CBFS: (unmatched file @0xf19040: pci8086,0a26.rom) CBFS: - load entry 0xf29080 file name (72 bytes)... CBFS: (unmatched file @0xf29080: cpu_microcode_blob.bin) CBFS: - load entry 0xf2e100 file name (32 bytes)... CBFS: (unmatched file @0xf2e100: etc/usb-time-sigatt) CBFS: - load entry 0xf2e140 file name (16 bytes)... CBFS: (unmatched file @0xf2e140: config) CBFS: - load entry 0xf2fa00 file name (16 bytes)... CBFS: (unmatched file @0xf2fa00: revision) CBFS: - load entry 0xf2fc80 file name (16 bytes)... CBFS: (unmatched file @0xf2fc80: ) CBFS: - load entry 0xf2ff80 file name (76 bytes)... CBFS: (unmatched file @0xf2ff80: fallback/romstage) CBFS: - load entry 0xf38f00 file name (32 bytes)... CBFS: (unmatched file @0xf38f00: fallback/ramstage) CBFS: - load entry 0xf4d0c0 file name (32 bytes)... CBFS: (unmatched file @0xf4d0c0: fallback/payload) CBFS: - load entry 0xf5e8c0 file name (32 bytes)... CBFS: (unmatched file @0xf5e8c0: pci8086,1521.rom) CBFS: - load entry 0xf6e900 file name (16 bytes)... CBFS: (unmatched file @0xf6e900: ) CBFS: - load entry 0xf9ffc0 file name (40 bytes)... CBFS: (unmatched file @0xf9ffc0: mrc.bin) CBFS: - load entry 0xfceb40 file name (16 bytes)... CBFS: (unmatched file @0xfceb40: ) CBFS: - load entry 0xfdffc0 file name (40 bytes)... CBFS: Found file (offset=0xfe0000, len=65536). find_current_mrc_cache_local: picked entry 0 from cache block prepare_mrc_cache: at fffe0010, size fe0 checksum 9771 CBFS: CBFS_HEADER_ROM_ADDRESS: 0xfffff7d0/0x1000000 CBFS: CBFS location: 0xf00000~0xfff7c0, align: 64 CBFS: Looking for 'mrc.bin' starting from 0xf00000. CBFS: - load entry 0xf00000 file name (16 bytes)... CBFS: (unmatched file @0xf00000: bootsplash.jpg) CBFS: - load entry 0xf187c0 file name (16 bytes)... CBFS: (unmatched file @0xf187c0: bootorder) CBFS: - load entry 0xf18b80 file name (16 bytes)... CBFS: (unmatched file @0xf18b80: cmos_layout.bin) CBFS: - load entry 0xf19040 file name (32 bytes)... CBFS: (unmatched file @0xf19040: pci8086,0a26.rom) CBFS: - load entry 0xf29080 file name (72 bytes)... CBFS: (unmatched file @0xf29080: cpu_microcode_blob.bin) CBFS: - load entry 0xf2e100 file name (32 bytes)... CBFS: (unmatched file @0xf2e100: etc/usb-time-sigatt) CBFS: - load entry 0xf2e140 file name (16 bytes)... CBFS: (unmatched file @0xf2e140: config) CBFS: - load entry 0xf2fa00 file name (16 bytes)... CBFS: (unmatched file @0xf2fa00: revision) CBFS: - load entry 0xf2fc80 file name (16 bytes)... CBFS: (unmatched file @0xf2fc80: ) CBFS: - load entry 0xf2ff80 file name (76 bytes)... CBFS: (unmatched file @0xf2ff80: fallback/romstage) CBFS: - load entry 0xf38f00 file name (32 bytes)... CBFS: (unmatched file @0xf38f00: fallback/ramstage) CBFS: - load entry 0xf4d0c0 file name (32 bytes)... CBFS: (unmatched file @0xf4d0c0: fallback/payload) CBFS: - load entry 0xf5e8c0 file name (32 bytes)... CBFS: (unmatched file @0xf5e8c0: pci8086,1521.rom) CBFS: - load entry 0xf6e900 file name (16 bytes)... CBFS: (unmatched file @0xf6e900: ) CBFS: - load entry 0xf9ffc0 file name (40 bytes)... CBFS: Found file (offset=0xfa0000, len=191236). System Agent: Starting up... System Agent: S3 resume detected System Agent: Initializing PCH install_ppi: overwrite GUID {ed097352-9041-445a-80b6-b29d509e8845} install_ppi: overwrite GUID {908c7f8b-5c48-47fb-8357-f5fd4e235276} System Agent: Initializing PCH (SMBUS) System Agent: Initializing PCH (USB) System Agent: Initializing PCH (SA Init) System Agent: Initializing PCH (Me UMA) System Agent: Initializing Memory System Agent: Done. Sanity checking heap. System Agent Version 1.6.1 Build 2 memcfg DDR3 clock 1600 MHz memcfg channel assignment: A: 0, B 1, C 2 memcfg channel[0] config (00600010): ECC inactive enhanced interleave mode on rank interleave on DIMMA 4096 MB width x8 or x32 single rank, selected DIMMB 0 MB width x8 or x32 single rank memcfg channel[1] config (00600000): ECC inactive enhanced interleave mode on rank interleave on DIMMA 0 MB width x8 or x32 single rank, selected DIMMB 0 MB width x8 or x32 single rank ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : NO ME: Manufacturing Mode : YES ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Initializing ME: Current Operation State : Bring up ME: Current Operation Mode : Normal ME: Error Code : Debug Failure ME: Progress Phase : BUP Phase ME: Power Management Event : Clean global reset ME: Progress Phase State : 0x7b before quick_ram_check RAM INIT FAILURE! """" It seems like DRAM controller and ME are initialized correctly (like in normal boot), what can be wrong? Does S3 work on Haswell boards?

4 3

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