coreboot August 2022

coreboot@coreboot.org

32 participants
30 discussions

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 26 Aug '22

26 Aug '22

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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1493415: Null pointer dereferences (REVERSE_INULL) /src/soc/intel/alderlake/hsphy.c: 71 in heci_get_hsphy_payload() ________________________________________________________________________________________________________ *** CID 1493415: Null pointer dereferences (REVERSE_INULL) /src/soc/intel/alderlake/hsphy.c: 71 in heci_get_hsphy_payload() 65 uint32_t reserved[2]; 66 uint32_t status; 67 uint8_t hash_type; 68 uint8_t hash[MAX_HASH_SIZE]; 69 } __packed reply; 70 >>> CID 1493415: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "buf_size" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 71 if (!buf || !buf_size || !hash_buf || !hash_alg) { 72 printk(BIOS_ERR, "%s: Invalid parameters\n", __func__); 73 return -1; 74 } 75 76 reply_size = sizeof(reply); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Fwd: Issues with ACPI _CRS and E820 memory map
by Tim Wawrzynczak 25 Aug '22

25 Aug '22

Hello fellow coreboot folks, I recently received this message from some associates in the Linux kernel community which describes a bug in coreboot firmware for many Intel boards. The gist of it related to inconsistencies between the hostbridge's _CRS method in ACPI and the E820 table (although technically generated by the payload, the e820 table is generally, AFAIK, converted straight from the LB_TAG_MEMORY entry in the coreboot table by most payloads). I have some thoughts on how to address this, but I would like to hear the community's thoughts first. Thanks, -Tim ---------- Forwarded message --------- From: Bjorn Helgaas <helgaas(a)kernel.org> Date: Thu, Aug 11, 2022 at 12:30 PM Subject: Issues with ACPI _CRS and E820 memory map To: <linux-pci(a)vger.kernel.org> Cc: Hans de Goede <hdegoede(a)redhat.com>, Myron Stowe <mstowe(a)redhat.com>, Kai-Heng Feng <kai.heng.feng(a)canonical.com>, Andy Shevchenko < andriy.shevchenko(a)linux.intel.com>, <linux-acpi(a)vger.kernel.org>, < linux-kernel(a)vger.kernel.org> This is a heads-up about what I think is a firmware defect in the way some platforms build _CRS methods. We've had a Linux workaround for several years, but the workaround breaks some new machines, so the workaround will be disabled for 2023 and newer machines. Machines that depend on the workaround include: - Dell Precision T3500 - Lenovo ThinkPad X1 Gen 2 - Asus C523NA (Coral) Chromebook - Likely any machine using coreboot firmware The current versions of the machines above work fine, but 2023 versions with similar firmware are likely to break unless the firmware changes. Please forward this to any firmware folks who may be able to help with this issue. Bjorn SUMMARY A Linux change will break future platforms that rely on the E820 memory map to exclude portions of the PCI host bridge windows reported by ACPI _CRS methods. Linux discovers PCI host bridge MMIO windows by evaluating the _CRS method of the ACPI PNP0A03 device that describes the host bridge. It uses these windows to assign address space to PCI BARs. In some cases these _CRS methods are incomplete or incorrect, and it's hard for an OS to work around this. Below are examples of typical problems with _CRS methods. PLATFORMS REPORT NON-WINDOW SPACE VIA _CRS Sometimes _CRS includes host bridge register space or space assigned to hidden PCI devices that are not enumerable by the OS. When an OS assigns this space to PCI devices, it may cause conflicts or devices may not work. This appears to be a firmware defect. Many platforms report this non-window space as "reserved" in the E820 memory map, and since 2010, Linux has worked around the _CRS defect by excluding these E820 "reserved" regions from the host bridge MMIO windows [4]. Example 1: _CRS includes space that's not usable for PCI devices [1]: E820: [mem 0xdceff000-0xdfa0ffff] reserved PNP0A08 _CRS: [mem 0xdfa00000-0xfebfffff] Note that [mem 0xdfa00000-0xdfa0ffff] is included in both the E820 entry and _CRS. If Linux assigns [mem 0xdfa00000-0xdfbfffff] to a PCI device, the system doesn't resume correctly from suspend. If Linux avoids the [mem 0xdfa00000-0xdfa0ffff] area and instead assigns [mem 0xdfb00000-0xdfcfffff], resume works correctly. Example 2: _CRS includes space assigned to a "hidden" PCI device [2, 5]: PCI: 00:0d.0 10 base d0000000 limit d0ffffff mem (fixed) # BIOS log E820: [mem 0xd0000000-0xd0ffffff] PNP0A08 _CRS: [mem 0x80000000-0xe0000000] The 00:0d.0 device is assigned the [mem 0xd0000000-0xd0ffffff] space, but the device is hidden so the OS cannot enumerate it, so the OS doesn't know what space the device consumes. PLATFORMS SUPPLY E820 ENTRIES COVERING ENTIRE _CRS WINDOWS Some recent platforms supply E820 "reserved" regions that cover entire PCI host bridge windows. If Linux excludes these E820 regions from the windows, it cannot assign space to PCI BARs, which means hot-added devices don't work. Example 3: E820 has a "reserved" region that completely covers the 32-bit MMIO window from _CRS [3]: E820: [mem 0x4bc50000-0xcfffffff] reserved PNP0A08 _CRS: [mem 0x65400000-0xbfffffff] Historically, Linux has avoided putting PCI devices in E820 reserved regions to avoid the problems in examples 1 and 2. Avoiding those regions in this case means Linux can't assign space for hot-added devices, so they don't work. LINUX PLANS As far as I know, the ACPI spec does not require an OS to exclude space from _CRS resources based on the E820 memory map, and these conflicting requirements make it impractical for Linux to do so. The "avoid E820 regions" workaround worked for several years, but it no longer works because of platforms that advertise E820 regions that cover *entire* _CRS windows. We plan to make Linux stop excluding E820 regions from _CRS resources for platforms with a BIOS date of 2023 or newer, so new platforms or new BIOS releases that rely on excluding E820 regions may break [6]. Linux is likely to be broken on future versions of these platforms unless the firmware updates _CRS methods. If these platforms do not update _CRS methods to be complete and accurate, Linux may not boot. The user's options are to: - Manually boot with a kernel command line option like "pci=use_e820". - Wait for an updated kernel with a platform-specific workaround. WHY DOESN'T THIS AFFECT MICROSOFT WINDOWS? Short answer: I suspect it *does*, but it's less likely to be a problem on Windows. As far as I know, Windows does not exclude MMIO space from _CRS based on the E820 memory map. But Windows allocates PCI BARs from the top down, while Linux allocates from the bottom up. Most of the issues happen with space at the bottom of the _CRS MMIO windows, so Linux is more likely to trip over them than Windows is. REFERENCES [1] https://bugzilla.redhat.com/show_bug.cgi?id=2029207 [2] https://lore.kernel.org/linux-pci/4e9fca2f-0af1-3684-6c97-4c35befd5019@redh… [3] https://bugzilla.kernel.org/show_bug.cgi?id=206459 [4] https://bugzilla.kernel.org/show_bug.cgi?id=16228 [5] https://review.coreboot.org/plugins/gitiles/coreboot/+/dbcf7b16219d%5E%21/ [6] https://git.kernel.org/linus/0ae084d5a674

2 2

Coffee Lake Refresh RVP11 + Integrated graphics initialisation + Uefipayload
by Moorthi M.s 25 Aug '22

25 Aug '22

Hi, I am developing coreboot along with Uefipayload for CFL H RVP11 CRB. I have added the required binary files (me, desc, ec and gbe) by extracting from the BIOS image. I have also extracted and added the vbt.bin from BIOS to coreboot. For graphics initialisation, i selected "Run a GOP driver" and for Framebuffer mode, i selected "Linear high resolution framebuffer". Compiled and loaded the coreboot image with above configuration. Coreboot booted and the debug prints are displayed in UART port, but nothing came in the graphics. The Display is connected to the DP port of the CRB. And i checked the debug prints, there it is mentioned as "GMA: Found valid VBT in CBFS" and in the next line "Graphics hand-off block not found". From the above prints i assume that the vbt.bin is proper but still the FSP is not returning the graphics HOB. I am using coreboot 4.17 for my development. Is there any other configurations need to be done with respect to integrated graphics? Regards, Moorthi S

2 3

CBFS CSE version Mismatch
by Sameeruddin Shaik 23 Aug '22

23 Aug '22

hi , I built a coreboot image for ADL RVP, In that image cse lite cbfs version is not matching with the cse lite RO and RW version. As a result, target is updating the CBFS cse lite and rebooting again and again. Any Thoughts on how to fix this?. Below is the log ------------------------------ romstage starting (log level: 8)... [0m [0m[DEBUG] pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000 [0m [0m[DEBUG] gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 [0m [0m[DEBUG] gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 [0m [0m[DEBUG] gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 [0m [0m[DEBUG] gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 [0m [0m[DEBUG] TCO_STS: 0000 0000 [0m [0m[DEBUG] GEN_PMCON: a1054000 00000204 [0m [0m[DEBUG] GBLRST_CAUSE: 00000040 00000000 [0m [0m[DEBUG] HPR_CAUSE0: 00000000 [0m [0m[DEBUG] prev_sleep_state 5 [0m [0m[DEBUG] cse_lite: Number of partitions = 3 [0m [0m[DEBUG] cse_lite: Current partition = RO [0m [0m[DEBUG] cse_lite: Next partition = RO [0m [0m[DEBUG] cse_lite: Flags = 0x3 [0m [0m[DEBUG] cse_lite: RO version = 16.0.15.1752 (Status=0x0, Start=0x2000, End=0x19bfff) [0m [0m[DEBUG] cse_lite: RW version = 16.0.15.1752 (Status=0x0, Start=0x205000, End=0x439fff) [0m [0m[DEBUG] FMAP: area SI_ME found @ 81000 (5763072 bytes) [0m [0m[INFO ] SF: Detected 00 0000 with sector size 0x1000, total 0x2000000 [0m [0m[DEBUG] cse_lite: CSE RW partition: offset = 0x205000, size = 0x235000 [0m [0m[DEBUG] FMAP: area FW_MAIN_A found @ 610000 (4718528 bytes) [0m [0m[INFO ] MMAP window: SPI flash base=0x1000000, Host base=0xff000000, Size=0x1000000 [0m [0m[INFO ] MMAP window: SPI flash base=0x600000, Host base=0xf9600000, Size=0xa00000 [0m [0m[INFO ] CBFS: Found 'me_rw.version' @0xa4b80 size 0xd in mcache @0xfef877e8 [0m [0m[DEBUG] cse_lite: CSE CBFS RW version : 16.0.15.1620 [0m [0m[DEBUG] cse_lite: CSE RW update is initiated [0m [0m[DEBUG] FMAP: area ME_RW_A found @ a90000 (3604480 bytes) [0m [0m[INFO ] CBFS: Found 'me_rw' @0x0 size 0x235000 [0m [0m[INFO ] CBFS: Found 'me_rw.hash' @0xa4bc0 size 0x20 in mcache @0xfef87810 [0m [0m[SPEW ] cse_lite: Computed SHA of CSE CBFS RW Image matches the provided hash in the metadata [0m [0m[DEBUG] cse_lite: Sending DATA CLEAR HECI command [0m [0m[DEBUG] HECI: Send HMRFPO Enable Command [0m [0m[SPEW ] Erasing flash addr 286000 + 4 KiB [0m [0m[SPEW ] Erasing flash addr 287000 + 4 KiB [0m [0m[SPEW ] Erasing flash addr 288000 + 4 KiB [0m --sameer.

2 2

Issues with ACPI _CRS and E820 memory map
by Tim Wawrzynczak 22 Aug '22

22 Aug '22

Re-forwarding the prior email as an attachment per Paul M's request. -Tim

1 0

Comment faire ? How to ?
by s.ginape＠tutanota.com 22 Aug '22

22 Aug '22

Bonjour, J'ai en ma possession un mw-gmlk-2_5g4l et je voudrais le passer sous coreboot. Comment puis flasher le bios? Y-a-t-il une image à mettre sur une clé USB? Cordialement. Hello I have in my possession a mw-gmlk-2_5g4l and I would like to pass it under coreboot. How to flash the bios? Is there an image to put on a USB flash drive? Kind regards.

1 0

Issue tracker version update / disabling of login methods
by Felix Singer 19 Aug '22

19 Aug '22

Hi all, the Redmine developers released version 5.0 some months ago and updating to this version will have some effects on us. So, I would like to open a thread to discuss these issues with you and how we deal with that situation. Currently, we are on the 4.2 branch and it still gets security and bug fixes, but I can't tell at which point they will stop supporting it. We enabled the login over OpenID, which is implemented natively and not integrated over a plugin. With version 5.0, support for that was removed. I assume this is due to that the implementation is based on an older OpenID standard and there are not many users of it anymore (TM). The newer standard seems to be called "OpenID Connect", but it's not supported by Redmine. Also, we are using a plugin which allows the login over a Google account. The compatibility of that plugin breaks with version 5.0. The problem is that we have users for both and with version 5.0 they won't be able to use these methods anymore. However, I have an idea for a solution. I took a look at the Redmine database and I played around with the Google login method. My tests showed that it creates a normal user account, as it is done with the registration, just with the little difference that no password is set disabling the login over password. These accounts also have an user name and an email address. As soon as I set a password, I was able to login using the user name. So, my idea is that we just go with these changes and affected users use the functionality to reset their password, which means they will have a "normal" user account then. In preparation to that version update, we should disable these login methods so that no new users will make use of them. Other ideas? What's your opinion? // Felix

3 4

Intel sandybridge northbridge with ibexpeak southbridge?
by Hal Martin 18 Aug '22

18 Aug '22

Hello, I have a platform (Advantech NAMB-3250MB, used in some Riverbed appliances) which uses Sandy/Ivy Bridge CPUs, but has a DH89xxCC southbridge which according to ifdtool is Ibex Peak. [3] The ME firmware version from the vendor firmware is 6.0.50.1244 which also corresponds to Ibex Peak (Series 5) and not Cougar Point (Series 6). [1] I did not know it was possible to pair a Series 5 chipset with Sandy/Ivy Bridge, since the DH89xxCC only supports DMI 1 (intel-communications-chipset-89xx-series-datasheet.pdf page 5) and Sandy/Ivy Bridge support DMI 2.0 [2] It would appear that using northbridge/intel/sandybridge with southbridge/intel/ibexpeak in coreboot is not supported: /opt/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/romstage/northbridge/intel/sandybridge/early_dmi.o: in function `early_init_dmi': /opt/coreboot/src/northbridge/intel/sandybridge/early_dmi.c:175: undefined reference to `early_pch_init_native_dmi_pre' /opt/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: /opt/coreboot/src/northbridge/intel/sandybridge/early_dmi.c:215: undefined reference to `early_pch_init_native_dmi_post' /opt/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/romstage/northbridge/intel/sandybridge/raminit.o: in function `init_dram_ddr3': /opt/coreboot/src/northbridge/intel/sandybridge/raminit.c:322: undefined reference to `early_pch_init_native' src/arch/x86/Makefile.inc:185: recipe for target 'build/cbfs/fallback/romstage.debug' failed make: *** [build/cbfs/fallback/romstage.debug] Error 1 There is no early_pch_init_native_* in src/southbridge/intel/ibexpeak Is it safe to assume that IronLake northbridge is not applicable to Sandy/Ivy Bridge CPUs? In which case, I guess the only way this platform could ever be supported is if the missing early_pch_init_native_* functions are implemented for IbexPeak? Kind regards, Hal Martin [1] https://en.wikichip.org/wiki/intel/management_engine [2] https://www.intel.com/content/www/us/en/products/platforms/details/crystal-… [3] ./ifdtool dump.bin PCH Revision: 5 series Ibex Peak FLMAP0: 0x02040002 NR: 2 FRBA: 0x40 NC: 1 FCBA: 0x20 FLMAP1: 0x10100206 ISL: 0x10 FPSBA: 0x100 NM: 2 FMBA: 0x60 FLMAP2: 0x00000120 PSL: 0x0001 FMSBA: 0x200 FLUMAP1: 0x000002ef Intel ME VSCC Table Length (VTL): 2 Intel ME VSCC Table Base Address (VTBA): 0x000ef0 ME VSCC table: JID0: 0x004b25bf SPI Component Vendor ID: 0xbf SPI Component Device ID 0: 0x25 SPI Component Device ID 1: 0x4b VSCC0: 0x20092009 Lower Erase Opcode: 0x20 Lower Write Enable on Write Status: 0x50 Lower Write Status Required: Yes Lower Write Granularity: 1 bytes Lower Block / Sector Erase Size: 4KB Upper Erase Opcode: 0x20 Upper Write Enable on Write Status: 0x50 Upper Write Status Required: Yes Upper Write Granularity: 1 bytes Upper Block / Sector Erase Size: 4KB OEM Section: 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Found Region Section FLREG0: 0x00000000 Flash Region 0 (Flash Descriptor): 00000000 - 00000fff FLREG1: 0x07ff0400 Flash Region 1 (BIOS): 00400000 - 007fffff FLREG2: 0x03ff0001 Flash Region 2 (Intel ME): 00001000 - 003fffff FLREG3: 0x00000fff Flash Region 3 (GbE): 00fff000 - 00000fff (unused) FLREG4: 0x00000fff Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused) Found Component Section FLCOMP 0x0010001c Dual Output Fast Read Support: not supported Read ID/Read Status Clock Frequency: 20MHz Write/Erase Clock Frequency: 20MHz Fast Read Clock Frequency: 20MHz Fast Read Support: supported Read Clock Frequency: 20MHz Component 2 Density: 4MB Component 1 Density: 8MB FLILL 0x00000000 Invalid Instruction 3: 0x00 Invalid Instruction 2: 0x00 Invalid Instruction 1: 0x00 Invalid Instruction 0: 0x00 FLPB 0x00000000 Flash Partition Boundary Address: 0x000000 Found PCH Strap Section PCHSTRP0 : 0x00205602 PCHSTRP1 : 0x0000010f PCHSTRP2 : 0x90000000 PCHSTRP3 : 0x00000000 PCHSTRP4 : 0x00c8e000 PCHSTRP5 : 0x00000000 PCHSTRP6 : 0x00000000 PCHSTRP7 : 0x00000000 PCHSTRP8 : 0x00000000 PCHSTRP9 : 0x00000000 PCHSTRP10 : 0x00010044 PCHSTRP11 : 0x99000097 PCHSTRP12 : 0x00000000 PCHSTRP13 : 0x00000000 PCHSTRP14 : 0x00000000 PCHSTRP15 : 0x0000000e AltMeDisable bit is not set Found Master Section FLMSTR1: 0xffff0000 (Host CPU/BIOS) Platform Data Region Write Access: enabled GbE Region Write Access: enabled Intel ME Region Write Access: enabled Host CPU/BIOS Region Write Access: enabled Flash Descriptor Write Access: enabled Platform Data Region Read Access: enabled GbE Region Read Access: enabled Intel ME Region Read Access: enabled Host CPU/BIOS Region Read Access: enabled Flash Descriptor Read Access: enabled Requester ID: 0x0000 FLMSTR2: 0xffff0000 (Intel ME) Platform Data Region Write Access: enabled GbE Region Write Access: enabled Intel ME Region Write Access: enabled Host CPU/BIOS Region Write Access: enabled Flash Descriptor Write Access: enabled Platform Data Region Read Access: enabled GbE Region Read Access: enabled Intel ME Region Read Access: enabled Host CPU/BIOS Region Read Access: enabled Flash Descriptor Read Access: enabled Requester ID: 0x0000 FLMSTR3: 0xffff0118 (GbE) Platform Data Region Write Access: enabled GbE Region Write Access: enabled Intel ME Region Write Access: enabled Host CPU/BIOS Region Write Access: enabled Flash Descriptor Write Access: enabled Platform Data Region Read Access: enabled GbE Region Read Access: enabled Intel ME Region Read Access: enabled Host CPU/BIOS Region Read Access: enabled Flash Descriptor Read Access: enabled Requester ID: 0x0118 Found Processor Strap Section ????: 0x00000000 ????: 0xffffffff ????: 0xffffffff ????: 0xffffffff ????: 0xffffffff ????: 0xffffffff ????: 0xffffffff ????: 0xffffffff

2 1

DDR4 detection issue in the Memory Down approach on the intel Denverton board
by Somanna Ankaiah 18 Aug '22

18 Aug '22

Greetings . We are working on intel c508 intel denverton board . It has a soldered 4GB DDR4 connected to Channel 0 , Dimm 0 . Below are the changes made : 1. We are using harcuvar board as a reference . I have selected * Enable Memory down option in menu config 2. Added spd values file in src/mainboard/intel/harcuvar/spd/spd_filename.hex 3. spd.bn getting generated in CBFS FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 43844 none cpu_microcode_blob.bin 0xac40 microcode 11264 none fallback/ramstage 0xd8c0 stage 71762 none config 0x1f180 raw 1353 none revision 0x1f740 raw 694 none spd.bin 0x1fa40 spd 512 none fallback/dsdt.aml 0x1fc80 raw 7791 none fallback/postcar 0x21b40 stage 23808 none fallback/payload 0x27880 simple elf 656810 none (empty) 0xc7e80 null 6651672 none fspt.bin 0x71fdc0 fsp 4096 none (empty) 0x720e00 null 3992 none fspm.bin 0x721dc0 fsp 589824 none (empty) 0x7b1e00 null 3992 none fsps.bin 0x7b2dc0 fsp 102400 none (empty) 0x7cbe00 null 114584 none bootblock 0x7e7dc0 bootblock 32768 none COREBOOT-4.13 PrivateBuild:saurabh Thu Jun 30 18:39:22 IST 2022 bootblock starting FSP TempRamInit successful... Timestamp - end of bootblock: 47603172 FMAP: Found "FLASH" version 1.1 at 0x810000. FMAP: base = 0xff000000 size = 0x1000000 #areas = 4 FMAP: area COREBOOT found @ 810200 (8322560 bytes) CBFS DEBUG: Looking for next file @0x0... CBFS DEBUG: Found CBFS header @0x0 (type 2, attr +0x0, data +0x38, length 0x20) CBFS DEBUG: File name: 'cbfs master header' CBFS DEBUG: Looking for next file @0x58... CBFS DEBUG: Found CBFS header @0x80 (type 16, attr +0x0, data +0x64, length 0xab44) CBFS DEBUG: File name: 'fallback/romstage' CBFS: Found 'fallback/romstage' @0x80 size 0xab44 Timestamp - starting to load romstage: 136192248 Timestamp - finished loading romstage: 143418624 BS: bootblock times (exec / console): total (unknown) / 74 ms 4. Tried giving 512 values CONFIG_DIMM_SPD_SIZE=512 5. Using 4GB DDR4 module. MT40A512M16LY-062E IT:E We are using Fitc tool to generate full FW image, getting below error and got stuck after loading the build ====================================================================================== COREBOOT-4.13 PrivateBuild:saurabh Thu Jun 30 18:39:22 IST 2022 romstage starting FSP TempRamInit was successful... Board ID: 0x52. GPIO table: 0xff81a144, entry num: 0x1! Changing GpioPad PID: c2 Offset: 0x400 PadModeP1: 0 P2: 1 R: 0x45000200 Fx45000600 ! TCO base address set to 0x400! FMAP: area COREBOOT found @ 810200 (8322560 bytes) CBFS DEBUG: Looking for next file @0x0... CBFS DEBUG: Found CBFS header @0x0 (type 2, attr +0x0, data +0x38, length 0x20) CBFS DEBUG: File name: 'cbfs master header' CBFS DEBUG: Looking for next file @0x58... CBFS DEBUG: Found CBFS header @0x80 (type 16, attr +0x0, data +0x64, length 0xab44) CBFS DEBUG: File name: 'fallback/romstage' CBFS DEBUG: Looking for next file @0xac28... CBFS DEBUG: Found CBFS header @0xac40 (type 83, attr +0x38, data +0x50, length 0x2c00) CBFS DEBUG: File name: 'cpu_microcode_blob.bin' CBFS DEBUG: Looking for next file @0xd890... CBFS DEBUG: Found CBFS header @0xd8c0 (type 16, attr +0x0, data +0x38, length 0x11853) CBFS DEBUG: File name: 'fallback/ramstage' CBFS DEBUG: Looking for next file @0x1f14b... CBFS DEBUG: Found CBFS header @0x1f180 (type 80, attr +0x28, data +0x38, length 0x549) CBFS DEBUG: File name: 'config' CBFS DEBUG: Looking for next file @0x1f701... CBFS DEBUG: Found CBFS header @0x1f740 (type 80, attr +0x28, data +0x38, length 0x2b6) CBFS DEBUG: File name: 'revision' CBFS DEBUG: Looking for next file @0x1fa2e... CBFS DEBUG: Found CBFS header @0x1fa40 (type 171, attr +0x28, data +0x38, length 0x200) CBFS DEBUG: File name: 'spd.bin' CBFS DEBUG: Looking for next file @0x1fc78... CBFS DEBUG: Found CBFS header @0x1fc80 (type 80, attr +0x38, data +0x48, length 0x1e6f) CBFS DEBUG: File name: 'fallback/dsdt.aml' CBFS DEBUG: Looking for next file @0x21b37... CBFS DEBUG: Found CBFS header @0x21b40 (type 16, attr +0x0, data +0x38, length 0x5d00) CBFS DEBUG: File name: 'fallback/postcar' CBFS DEBUG: Looking for next file @0x27878... CBFS DEBUG: Found CBFS header @0x27880 (type 32, attr +0x0, data +0x38, length 0xa05aa) CBFS DEBUG: File name: 'fallback/payload' CBFS DEBUG: Looking for next file @0xc7e62... CBFS DEBUG: Found CBFS header @0xc7e80 (type -1, attr +0x0, data +0x28, length 0x657f18) CBFS DEBUG: Looking for next file @0x71fdc0... CBFS DEBUG: Found CBFS header @0x71fdc0 (type 96, attr +0x28, data +0x40, length 0x1000) CBFS DEBUG: File name: 'fspt.bin' CBFS DEBUG: Looking for next file @0x720e00... CBFS DEBUG: Found CBFS header @0x720e00 (type -1, attr +0x0, data +0x28, length 0xf98) CBFS DEBUG: Looking for next file @0x721dc0... CBFS DEBUG: Found CBFS header @0x721dc0 (type 96, attr +0x28, data +0x40, length 0x90000) CBFS DEBUG: File name: 'fspm.bin' CBFS: Found 'fspm.bin' @0x721dc0 size 0x90000 Spec version: v2.0 Revision: 0.0.1, Build Number 18 Type: release/test image ID: DNV-FSP0, base 0xfff32000 + 0x90000 Config region 0x18c + 0x200 Memory init offset 0x450 Timestamp - before RAM initialization: 2111263908 FMAP: area RW_MRC_CACHE found @ 800000 (65536 bytes) MRC: no data in 'RW_MRC_CACHE' bootmode is set to: 0 Relaxing the Security Config for SPI. mupd->FspmConfig.RelaxSecConfig FMAP: area COREBOOT found @ 810200 (8322560 bytes) CBFS DEBUG: Looking for next file @0x0... CBFS DEBUG: Found CBFS header @0x0 (type 2, attr +0x0, data +0x38, length 0x20) CBFS DEBUG: File name: 'cbfs master header' CBFS DEBUG: Looking for next file @0x58... CBFS DEBUG: Found CBFS header @0x80 (type 16, attr +0x0, data +0x64, length 0xab44) CBFS DEBUG: File name: 'fallback/romstage' CBFS DEBUG: Looking for next file @0xac28... CBFS DEBUG: Found CBFS header @0xac40 (type 83, attr +0x38, data +0x50, length 0x2c00) CBFS DEBUG: File name: 'cpu_microcode_blob.bin' CBFS DEBUG: Looking for next file @0xd890... CBFS DEBUG: Found CBFS header @0xd8c0 (type 16, attr +0x0, data +0x38, length 0x11853) CBFS DEBUG: File name: 'fallback/ramstage' CBFS DEBUG: Looking for next file @0x1f14b... CBFS DEBUG: Found CBFS header @0x1f180 (type 80, attr +0x28, data +0x38, length 0x549) CBFS DEBUG: File name: 'config' CBFS DEBUG: Looking for next file @0x1f701... CBFS DEBUG: Found CBFS header @0x1f740 (type 80, attr +0x28, data +0x38, length 0x2b6) CBFS DEBUG: File name: 'revision' CBFS DEBUG: Looking for next file @0x1fa2e... CBFS DEBUG: Found CBFS header @0x1fa40 (type 171, attr +0x28, data +0x38, length 0x200) CBFS DEBUG: File name: 'spd.bin' CBFS: Found 'spd.bin' @0x1fa40 size 0x200 SPD spd_data[i] 23 SPD spd_data[i] 11 SPD spd_data[i] c SPD spd_data[i] 3 SPD spd_data[i] 56 SPD spd_data[i] 21 SPD spd_data[i] 0 SPD spd_data[i] 8 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 3 SPD spd_data[i] 2 SPD spd_data[i] b SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 8 SPD spd_data[i] d SPD spd_data[i] fc SPD spd_data[i] ab SPD spd_data[i] ae SPD spd_data[i] 0 SPD spd_data[i] 78 SPD spd_data[i] 78 SPD spd_data[i] 78 SPD spd_data[i] 11 SPD spd_data[i] 8 SPD spd_data[i] 80 SPD spd_data[i] f0 SPD spd_data[i] a SPD spd_data[i] 20 SPD spd_data[i] 8 SPD spd_data[i] 0 SPD spd_data[i] 5 SPD spd_data[i] 0 SPD spd_data[i] f0 SPD spd_data[i] 2b SPD spd_data[i] 34 SPD spd_data[i] 2b SPD spd_data[i] 0 SPD spd_data[i] 78 SPD spd_data[i] 0 SPD spd_data[i] 14 SPD spd_data[i] 3c SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] c SPD spd_data[i] 2b SPD spd_data[i] 2d SPD spd_data[i] 4 SPD spd_data[i] 16 SPD spd_data[i] 35 SPD spd_data[i] 23 SPD spd_data[i] d SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 2c SPD spd_data[i] b SPD spd_data[i] 3 SPD spd_data[i] 24 SPD spd_data[i] 35 SPD spd_data[i] c SPD spd_data[i] 3 SPD spd_data[i] 2d SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] ec SPD spd_data[i] 9c SPD spd_data[i] b4 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] e7 SPD spd_data[i] c1 SPD spd_data[i] a9 SPD spd_data[i] 4d SPD spd_data[i] f SPD spd_data[i] 11 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 38 SPD spd_data[i] 41 SPD spd_data[i] 54 SPD spd_data[i] 46 SPD spd_data[i] 35 SPD spd_data[i] 31 SPD spd_data[i] 32 SPD spd_data[i] 36 SPD spd_data[i] 34 SPD spd_data[i] 48 SPD spd_data[i] 5a SPD spd_data[i] 2d SPD spd_data[i] 32 SPD spd_data[i] 47 SPD spd_data[i] 31 SPD spd_data[i] 41 SPD spd_data[i] 32 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 32 SPD spd_data[i] 80 SPD spd_data[i] 2c SPD spd_data[i] 41 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 SPD spd_data[i] 0 Memory Down function is enabled! 0x0000000000000d0a: IA32_MTRRCAP: SMRR, WC, FIX, 10 variable MTRRs 0x0000000000000800: IA32_MTRR_DEF_TYPE: E, UC 0x0000000000000000: IA32_MTRR_FIX64K_00000 0x00000000 - 0x0007ffff: UC 0x0000000000000000: IA32_MTRR_FIX16K_80000 0x00080000 - 0x0009ffff: UC 0x0000000000000000: IA32_MTRR_FIX16K_A0000 0x000a0000 - 0x000bffff: UC 0x0000000000000000: IA32_MTRR_FIX4K_C0000 0x000c0000 - 0x000c7fff: UC 0x0000000000000000: IA32_MTRR_FIX4K_C8000 0x000c8000 - 0x000cffff: UC 0x0000000000000000: IA32_MTRR_FIX4K_D0000 0x000d0000 - 0x000d7fff: UC 0x0000000000000000: IA32_MTRR_FIX4K_D8000 0x000d8000 - 0x000dffff: UC 0x0000000000000000: IA32_MTRR_FIX4K_E0000 0x000e0000 - 0x000e7fff: UC 0x0000000000000000: IA32_MTRR_FIX4K_E8000 0x000e8000 - 0x000effff: UC 0x0000000000000000: IA32_MTRR_FIX4K_F0000 0x000f0000 - 0x000f7fff: UC 0x0000000000000000: IA32_MTRR_FIX4K_F8000 0x000f8000 - 0x000fffff: UC 0x00000000fef00006: PHYBASE0: Address = 0x00000000fef00000, WB 0x0000007ffff00800: PHYMASK0: Length = 0x0000000000100000, Valid 0x00000000ff000005: PHYBASE1: Address = 0x00000000ff000000, WP 0x0000007fff000800: PHYMASK1: Length = 0x0000000001000000, Valid 0x0000000000000000: PHYBASE2 0x0000000000000000: PHYMASK2: Disabled 0x0000000000000000: PHYBASE3 0x0000000000000000: PHYMASK3: Disabled 0x0000000000000000: PHYBASE4 0x0000000000000000: PHYMASK4: Disabled 0x0000000000000000: PHYBASE5 0x0000000000000000: PHYMASK5: Disabled 0x0000000000000000: PHYBASE6 0x0000000000000000: PHYMASK6: Disabled 0x0000000000000000: PHYBASE7 0x0000000000000000: PHYMASK7: Disabled 0x0000000000000000: PHYBASE8 0x0000000000000000: PHYMASK8: Disabled 0x0000000000000000: PHYBASE9 0x0000000000000000: PHYMASK9: Disabled Architectural UPD values for MemoryInit at: 0xfef0fce0 0x01: Revision 0x00000000: NvsBufferPtr 0xfefb0000 --> 0xfef60100: StackBase 0x0004ff00: StackSize 0x00000000 --> 0x00002000: BootLoaderTolumSize 0x00000000: BootMode UPD values for MemoryInit: 0x02: PcdSmmTsegSize 0x00: PcdFspDebugPrintErrorLevel 0xa0: PcdSpdSmbusAddress_0_0 0xa2: PcdSpdSmbusAddress_0_1 0xa4: PcdSpdSmbusAddress_1_0 0xa6: PcdSpdSmbusAddress_1_1 0x00: PcdMrcRmtSupport 0x0c: PcdMrcRmtCpgcExpLoopCntValue 0x06: PcdMrcRmtCpgcNumBursts 0x00: PcdMemoryPreservation 0x01: PcdFastBoot 0x01: PcdEccSupport 0x00: PcdHsuartDevice 0x00 --> 0x01: PcdMemoryDown 0x01: PcdEnableSATA0 0x01: PcdEnableSATA1 0x01: PcdEnableIQAT 0x00: PcdSmbusSpdWriteDisable 0x00: PcdEnableMeShutdown 0x01: PcdEnableXhci 0x06: PcdDdrFreq 0x00: PcdMmioSize 0x01: PcdMeHeciCommunication 0x14: PcdHsioLanesNumber 0x00000000: PcdFiaMuxConfigPtr 0x00: PcdHalfWidthEnable 0x01: PcdTclIdle 0x03: PcdInterleaveMode 0x00: PcdMemoryThermalThrottling 0x00: PcdSkipMemoryTest 0x08: PcdUsb2Port1Pin 0x08: PcdUsb2Port2Pin 0x08: PcdUsb2Port3Pin 0x08: PcdUsb2Port4Pin 0x08: PcdUsb3Port1Pin 0x08: PcdUsb3Port2Pin 0x08: PcdUsb3Port3Pin 0x08: PcdUsb3Port4Pin 0x00: PcdIOxAPIC0_199 0x00: PcdDmapX16 0xfef0fcc0: 44 4e 56 55 50 44 5f 4d 01 00 00 00 00 00 00 00 DNVUPD_M........ 0xfef0fcd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xfef0fce0: 01 00 00 00 00 00 00 00 00 01 f6 fe 00 ff 04 00 ................ 0xfef0fcf0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . .............. 0xfef0fd00: 02 00 a0 a2 a4 a6 00 0c 06 00 01 01 00 01 00 10 ................ 0xfef0fd10: f1 fe 01 01 01 00 00 01 06 00 01 14 00 00 00 00 ................ 0xfef0fd20: 76 65 72 73 69 6f 6e 20 78 78 78 00 00 00 00 00 version xxx..... 0xfef0fd30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xfef0fd40: 00 01 03 00 00 00 00 00 00 08 08 08 08 08 08 08 ................ 0xfef0fd50: 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 ................ 0xfef0fd60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ... 0xfef0feb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 aa 55 ...............U Calling FspMemoryInit: 0xfff32450 0xfef0fcc0: raminit_upd 0xfef10f6c: &hob_list_ptr Timestamp - calling FspMemoryInit: 4524096604 Any help on this is highly appreciated . Thanks Somanna Ankaiah

2 3

RFC: Deprecating VBOOT_VBNV_CMOS
by Yu-Ping Wu 15 Aug '22

15 Aug '22

Hi, There's an ongoing effort to expand vboot nvdata (nvstorage) from 16 to 64 bytes [issue <https://issuetracker.google.com/issues/172342278>]. To reduce unnecessary complexity of our firmware code accessing nvdata, we'd like to drop 16-byte nvdata support from the firmware codebase (crossystem still needs to support both though). One obstacle is the CMOS nvdata backend (VBOOT_VBNV_CMOS). We're not sure if there would be enough CMOS space for all boards using that. In addition, because CMOS loses state when the battery is removed, newer boards usually select VBOOT_VBNV_CMOS_BACKUP_TO_FLASH to backup nvdata to flash. Considering that, this seems like a good opportunity to migrate CMOS to flash nvdata [issue <https://issuetracker.google.com/issues/235293589>]. One problem we faced is that many old platforms such as broadwell don't support writing to the flash in early stages (BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES). Therefore it looks like we'd need to drop vboot support on them (for example CB:65782 <https://review.coreboot.org/c/coreboot/+/65782>). An alternative would be to keep the CMOS backend around as "deprecated" and not allow 64-byte nvdata for it, but that would at best be a transitory solution for a couple of years, not forever. If there's any concern, please let me know. We have firmware branches for ChromeOS devices, so modifying ToT code wouldn't affect old devices in any way. However, I'm not sure how non-ChromeOS boards (such as mainboard/lenovo/haswell) would be affected by this. Please cc more people if needed. -- Yu-Ping Wu | Software Engineer | yupingso(a)google.com | +886 937 057 080

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2022