coreboot October 2020

coreboot@coreboot.org

37 participants
33 discussions

Universal Payload Project
by Paul Menzel 29 Oct '20

29 Oct '20

Dear coreboot, GRUB, and SeaBIOS folks, In #coreboot(a)irc.freenode.net somebody mentioned the Universal Payload Project [1]. > The goal of this project is to define an interface between a first > stage platform initialization bootloader and a second stage payload. As there also is a specification [2], I just wanted to make you aware of it, in case you have comments. Please keep in mind, that I do not know more details, so please do not jump to conclusions. Kind regards, Paul [1]: https://github.com/universalpayload/Introduction [2]: https://universalpayload.github.io/documentation/spec/spec.html

1 0

[RFC] Change in CBFS "stage" binary format
by Julius Werner 29 Oct '20

29 Oct '20

Hi folks, As some of you may know, I've been working on a way to add verification directly into CBFS (as opposed to the current vboot that can only verify images as a whole) for a while (I have presented at OSFC 2019: https://www.youtube.com/watch?v=Hs_EhewBgtM and published a general design document: https://osfc.io/uploads/talk/paper/47/The_future_of_firmware_verification_i…). As part of this work I have been very careful to keep all these changes fully backwards-compatible so that existing payloads with their own CBFS implementations will continue to work. I have now come across a fundamental problem that I cannot solve without introducing a small backwards-incompatible change: the CBFS "stage" format that is used to store the code for coreboot stages (e.g. romstage, ramstage) consists of a small "stage header" containing things like load address and size in front of the actual binary code. From the point of view of the generic CBFS structure, both that header and the code are part of the "file data" (and not the generic CBFS "file header" that contains things like the file name or generic CBFS attributes). This creates a tough chicken-and-egg problem when verifying pre-RAM stages, because (for platforms that actually load pre-RAM stages and don't execute in-place, like Arm platforms running from SRAM) the stage needs to be directly loaded into the final location it should execute out of, but the load address containing that location is in the stage header. My verification design works on whole files, so the stage header cannot be trusted before the whole file was loaded and hashed. But I can't load it without information from the stage header, and there's generally not enough scratch space in these pre-RAM environments to first load it somewhere else and then copy it over to its final destination after verification. My solution to this problem is to move the stage header out of the file data into a CBFS attribute that is stored in the generic CBFS file header. File headers are verified separately so they can already be trusted by the time the file data needs to be loaded. I think this is arguably a somewhat cleaner approach anyway (the concept of CBFS attributes just didn't exist yet when the stage format was originally designed, so it wasn't written that way to start with), but of course these new stages will be incompatible to the old ones. I believe this is okay because the "stage" format is generally only used for parts of coreboot itself (e.g. romstage, ramstage), whereas the payload and other binaries the payload may want to chain-load should be using the "simple ELF" (SELF) format anyway. Since coreboot is always built as a whole, when you're gonna build the new version all your stages will be in the new format and all code that loads them will know how to load the new format, so you should be fine. Tying this into a payload build system that is not aware of these changes should be okay because that payload shouldn't try to add extra files using the "stage" format, and shouldn't try to load any stages (if it wants to chain-load things it should be using the SELF format with cbfstool add-payload, not add-stage). But this file format has remained untouched for the whole 10+ years CBFS existed, so I thought I should ask before I do it. If you know any payloads that do use the "stage" format for files outside of coreboot itself and that couldn't adapt to this change for some reason, or have any other concerns about unexpected problems this could be causing you, please let me know here or on the CL: https://review.coreboot.org/46484 Note that for cbfstool, this will also mean that newer versions of cbfstool will only support the new format. I think this should also be okay because coreboot is built as a whole, i.e. all your stages are added with a cbfstool version that was built from the same code base version as the coreboot code trying to load these stages. But it does mean that if you have an old version of cbfstool stashed away somewhere and try to use it to cbfstool print -v or cbfstool extract a new coreboot image, it won't be able to show load address or entry point for the new stages or convert them back into an ELF file on extraction (or vice versa for new versions of cbfstool on old images). So if you do a lot of after-the-fact cbfstool manipulation on different versions of coreboot images (which is probably only done by people trying to debug something?), you may need to keep two cbfstool versions to switch back-and-forth between for a while. It would be possible to make the new cbfstool version support both formats for reading/extracting but that's a bunch of extra work that I hope I can avoid unless people really feel like this is gonna be a widespread problem. Also note that I'm not planning to touch the SELF (payload) format (which also has a header in the "file data" part) -- I will keep that as it is because I think it's much more likely that external payloads are using it for their own purposes that I don't want to break. It's also not necessary because SELFs are mostly just used in post-RAM environments and the SELF loader code already requires it (on non-memory-mapped platforms) to be loaded to a separate scratch buffer before copying the individual pieces to where they need to go. When we have that buffer anyway, it's easy to verify the whole file in there before examining the header.

1 0

[RFC] Replace strapping entries in coreboot table
by Tim Wawrzynczak 29 Oct '20

29 Oct '20

Hi coreboot community, Currently there are 3 different "strapping" entries in the coreboot tables, and with the recent addition of fw_config ( https://review.coreboot.org/c/coreboot/+/41209), we would also like to add the 64-bit fw_config field (updated here https://review.coreboot.org/c/coreboot/+/45939) to the coreboot table as well. In this patch (https://review.coreboot.org/c/coreboot/+/46605), I am proposing to deprecate the 3 current "strapping" entries (board ID, ram code and SKU ID), and add them all to 1 entry, containing board ID, ram code, SKU ID as well as fw_config. This saves the overhead of parsing 4 different entries to obtain board configuration information. Would like to hear any thoughts on this, - Tim

5 14

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 27 Oct '20

27 Oct '20

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. 2 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 2 of 2 defect(s) ** CID 1435893: Integer handling issues (BAD_SHIFT) /tests/lib/imd-test.c: 30 in align_up_pow2() ________________________________________________________________________________________________________ *** CID 1435893: Integer handling issues (BAD_SHIFT) /tests/lib/imd-test.c: 30 in align_up_pow2() 24 #define SM_ENTRY_ID 0xB001 25 26 #define INVALID_REGION_ID 0xC001 27 28 static uint32_t align_up_pow2(uint32_t x) 29 { >>> CID 1435893: Integer handling issues (BAD_SHIFT) >>> In expression "1 << log2_ceil(x)", shifting by a negative amount has undefined behavior. The shift amount, "log2_ceil(x)", is -1. 30 return (1 << log2_ceil(x)); 31 } 32 33 static size_t max_entries(size_t root_size) 34 { 35 return (root_size - sizeof(struct imd_root_pointer) - sizeof(struct imd_root)) ** CID 1435892: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1435892: Null pointer dereferences (FORWARD_NULL) /tests/lib/imd-test.c: 605 in test_imd_entry_at() 599 fail_msg("Cannot allocate enough memory - fail test"); 600 imd_handle_init(&imd, (void *)(LIMIT_ALIGN + (uintptr_t)base)); 601 602 assert_int_equal(0, imd_create_empty(&imd, LG_ROOT_SIZE, LG_ENTRY_ALIGN)); 603 604 /* Fail when entry is NULL */ >>> CID 1435892: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "e" to "imd_entry_at", which dereferences it. 605 assert_null(imd_entry_at(&imd, e)); 606 607 entry = imd_entry_add(&imd, LG_ENTRY_ID, LG_ENTRY_SIZE); 608 assert_non_null(entry); 609 610 r = (struct imd_root *)imd.lg.r; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 23 Oct '20

23 Oct '20

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 1435826: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/cpu/x86/mtrr/mtrr.c: 487 in calc_var_mtrr_range() ________________________________________________________________________________________________________ *** CID 1435826: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/cpu/x86/mtrr/mtrr.c: 487 in calc_var_mtrr_range() 481 size_msb = fms64(size); 482 483 /* All MTRR entries need to have their base aligned to the mask 484 * size. The maximum size is calculated by a function of the 485 * min base bit set and maximum size bit set. */ 486 if (addr_lsb > size_msb) >>> CID 1435826: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "1 << size_msb" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 487 mtrr_size = 1 << size_msb; 488 else 489 mtrr_size = 1 << addr_lsb; 490 491 if (var_state->prepare_msrs) 492 prep_var_mtrr(var_state, base, mtrr_size, mtrr_type); ** CID 1435825: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/cpu/x86/mtrr/mtrr.c: 489 in calc_var_mtrr_range() ________________________________________________________________________________________________________ *** CID 1435825: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/cpu/x86/mtrr/mtrr.c: 489 in calc_var_mtrr_range() 483 /* All MTRR entries need to have their base aligned to the mask 484 * size. The maximum size is calculated by a function of the 485 * min base bit set and maximum size bit set. */ 486 if (addr_lsb > size_msb) 487 mtrr_size = 1 << size_msb; 488 else >>> CID 1435825: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "1 << addr_lsb" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 489 mtrr_size = 1 << addr_lsb; 490 491 if (var_state->prepare_msrs) 492 prep_var_mtrr(var_state, base, mtrr_size, mtrr_type); 493 494 size -= mtrr_size; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Issue with BMC module
by Ale 22 Oct '20

22 Oct '20

Hello everyone, I have a kgpe d16 motherboard with coreboot and seabios, for now I have only one CPU mounted (the 2nd socket is empty) with 64 gb of ram: if I power on the PC without the BMC module, fans will spin at the maximum speed and I can see seabios and boot the OS; if I put in the BMC module with openBMC installed then fans spin at lower RPM but the seabios is not shown anymore (and, therefor, the pc cannot boot the OS). Do you have some idea of why this happens? Maybe I need 2 processor for openBMC to work fine? Thank you very much! Best regards Alessio

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 20 Oct '20

20 Oct '20

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 156 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 20 of 156 defect(s) ** CID 1434841: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/stm/Stm/StmPkg/Core/StmResource.c: 351 in IsResourceNodeValid() ________________________________________________________________________________________________________ *** CID 1434841: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/stm/Stm/StmPkg/Core/StmResource.c: 351 in IsResourceNodeValid() 345 } 346 break; 347 case MMIO_RANGE: 348 if (ResourceNode->Header.Length != sizeof(STM_RSC_MMIO_DESC)) { 349 goto CheckFail; 350 } >>> CID 1434841: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "ResourceNode->Mmio.RWXAttributes & -8 /* ~((1 | 2) | 4) */" is always 0 regardless of the values of its operands. This occurs as a value. 351 if ((ResourceNode->Mmio.RWXAttributes & ~(STM_RSC_MMIO_R | STM_RSC_MMIO_W | STM_RSC_MMIO_X)) != 0) { 352 goto CheckFail; 353 } 354 if (ResourceNode->Mmio.Reserved != 0) { 355 goto CheckFail; 356 } ** CID 1434840: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434840: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/SmmVmcallHandler.c: 435 in SmmVmcallHandler() 429 if (StmVmcallHandler == NULL) { 430 DEBUG((EFI_D_INFO, "%ld SmmVmcallHandler - GetSmmVmcallHandlerByIndex - %x!\n", Index, (UINTN)ReadUnaligned32 ((UINT32 *)&Reg->Rax))); 431 // Should not happen 432 CpuDeadLoop (); 433 Status = ERROR_INVALID_API; 434 } else { >>> CID 1434840: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rbx" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 435 AddressParameter = ReadUnaligned32 ((UINT32 *)&Reg->Rbx) + LShiftU64 (ReadUnaligned32 ((UINT32 *)&Reg->Rcx), 32); 436 Status = StmVmcallHandler (Index, AddressParameter); 437 } 438 439 WriteUnaligned32 ((UINT32 *)&Reg->Rax, Status); 440 if (Status == STM_SUCCESS) { ** CID 1434839: (UNUSED_VALUE) /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeLoadVm.c: 569 in PostPeVmProc() /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeLoadVm.c: 573 in PostPeVmProc() ________________________________________________________________________________________________________ *** CID 1434839: (UNUSED_VALUE) /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeLoadVm.c: 569 in PostPeVmProc() 563 if (mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Launched) { 564 Rflags = AsmVmResume (&mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Register); 565 // BUGBUG: - AsmVmLaunch if AsmVmResume fail 566 if (VmRead32 (VMCS_32_RO_VM_INSTRUCTION_ERROR_INDEX) == 567 VmxFailErrorVmResumeWithNonLaunchedVmcs) { 568 DEBUG ((EFI_D_ERROR, "%ld :-(\n", (UINTN)CpuIndex)); >>> CID 1434839: (UNUSED_VALUE) >>> Assigning value from "AsmVmLaunch(&mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Register)" to "Rflags" here, but that stored value is overwritten before it can be used. 569 Rflags = AsmVmLaunch (&mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Register); 570 } 571 } else { 572 mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Launched = TRUE; 573 Rflags = AsmVmLaunch (&mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Register); 574 DEBUG ((EFI_D_ERROR, "PostPeVmProc - somehow we did not launch\n")); /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeLoadVm.c: 573 in PostPeVmProc() 567 VmxFailErrorVmResumeWithNonLaunchedVmcs) { 568 DEBUG ((EFI_D_ERROR, "%ld :-(\n", (UINTN)CpuIndex)); 569 Rflags = AsmVmLaunch (&mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Register); 570 } 571 } else { 572 mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Launched = TRUE; >>> CID 1434839: (UNUSED_VALUE) >>> Assigning value from "AsmVmLaunch(&mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Register)" to "Rflags" here, but that stored value is overwritten before it can be used. 573 Rflags = AsmVmLaunch (&mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Register); 574 DEBUG ((EFI_D_ERROR, "PostPeVmProc - somehow we did not launch\n")); 575 mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Launched = FALSE; 576 } 577 DEBUG ((EFI_D_ERROR, "%ld PostPeVmProc - Problem in SMI during VM/PE\n", CpuIndex)); 578 } ** CID 1434838: Null pointer dereferences (FORWARD_NULL) /3rdparty/stm/Stm/StmPkg/Core/Init/StmInit.c: 759 in BspInit() ________________________________________________________________________________________________________ *** CID 1434838: Null pointer dereferences (FORWARD_NULL) /3rdparty/stm/Stm/StmPkg/Core/Init/StmInit.c: 759 in BspInit() 753 Rsdp = FindAcpiRsdPtr (); 754 DEBUG ((EFI_D_INFO, "Rsdp - %08x\n", Rsdp)); 755 if (Rsdp == NULL) { 756 DEBUG ((EFI_D_INFO, "Null Rsdp - Can not continue\n", Rsdp)); 757 CpuDeadLoop (); 758 } >>> CID 1434838: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "Rsdp". 759 Rsdt = (EFI_ACPI_DESCRIPTION_HEADER *)(UINTN)Rsdp->RsdtAddress; 760 DEBUG ((EFI_D_INFO, "Rsdt - %08x\n", Rsdt)); 761 DEBUG ((EFI_D_INFO, "RsdtLen - %08x\n", Rsdt->Length)); 762 if ((Rsdp->Revision >= 2) && (Rsdp->XsdtAddress < (UINT64)(UINTN)-1)) { 763 Xsdt = (EFI_ACPI_DESCRIPTION_HEADER *)(UINTN)Rsdp->XsdtAddress; 764 DEBUG ((EFI_D_INFO, "Xsdt - %016lx\n", Xsdt)); ** CID 1434837: (SIZEOF_MISMATCH) /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeLoadVm.c: 227 in LaunchPeVm() /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeLoadVm.c: 219 in LaunchPeVm() ________________________________________________________________________________________________________ *** CID 1434837: (SIZEOF_MISMATCH) /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeLoadVm.c: 227 in LaunchPeVm() 221 222 DEBUG((EFI_D_INFO, 223 "%ld LaunchPeVM - Initiating PE/VM run number: %d\n", 224 CpuIndex, 225 PeVmData[PeType].UserModule.RunCount)); 226 >>> CID 1434837: (SIZEOF_MISMATCH) >>> Adding "8UL /* sizeof (UINT64) */" to pointer "PeVmData[PeType].SharedPageStm" of type "UINTN *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "UINTN". Most likely, "sizeof (UINT64)" is extraneous and should be replaced with 1. 227 DEBUG((EFI_D_INFO, 228 "%ld LaunchPeVM - SharedPageStm 0x%016llx 0x%016llx\n", 229 CpuIndex, 230 *((UINT64 *)(PeVmData[PeType].SharedPageStm)), 231 *((UINT64 *)(PeVmData[PeType].SharedPageStm + sizeof(UINT64))))); 232 /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeLoadVm.c: 219 in LaunchPeVm() 213 mGuestContextCommonSmm[PeType].GuestContextPerCpu[0].Register.Rcx, 214 mGuestContextCommonSmm[PeType].GuestContextPerCpu[0].Register.Rdx)); 215 216 PeVmData[PeType].UserModule.RunCount++; 217 // set the runcount into the STM shared page 218 >>> CID 1434837: (SIZEOF_MISMATCH) >>> Adding "8UL /* sizeof (UINT64) */" to pointer "PeVmData[PeType].SharedPageStm" of type "UINTN *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "UINTN". Most likely, "sizeof (UINT64)" is extraneous and should be replaced with 1. 219 *((UINT64 *)(PeVmData[PeType].SharedPageStm + sizeof(UINT64))) = 220 PeVmData[PeType].UserModule.RunCount; 221 222 DEBUG((EFI_D_INFO, 223 "%ld LaunchPeVM - Initiating PE/VM run number: %d\n", 224 CpuIndex, ** CID 1434836: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434836: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/SmiVmcallHandler.c: 1010 in SmiVmcallHandler() 1004 DEBUG ((EFI_D_ERROR, 1005 "%ld SmiVmcallHandler - GetSmiVmcallHandlerByIndex- Invalid API entry - %x!\n", 1006 Index, 1007 (UINTN)ReadUnaligned32 ((UINT32 *)&Reg->Rax))); 1008 Status = ERROR_INVALID_API; 1009 } else { >>> CID 1434836: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rcx" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 1010 AddressParameter = ReadUnaligned32 ((UINT32 *)&Reg->Rbx) + LShiftU64 (ReadUnaligned32 ((UINT32 *)&Reg->Rcx), 32); 1011 1012 Status = StmVmcallHandler (Index, AddressParameter); 1013 } 1014 1015 if (Status == STM_SUCCESS) { ** CID 1434835: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434835: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/SmmMsrHandler.c: 41 in SmmReadMsrHandler() 35 STM_SMM_CPU_STATE *SmmCpuState; 36 UINT32 VmType = SMI_HANDLER; 37 BOOLEAN Result; 38 39 SmmCpuState = mGuestContextCommonSmi.GuestContextPerCpu[Index].SmmCpuState; 40 Reg = &mGuestContextCommonSmm[VmType].GuestContextPerCpu[Index].Register; >>> CID 1434835: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rcx" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 41 MsrIndex = ReadUnaligned32 ((UINT32 *)&Reg->Rcx); 42 43 MsrDesc = GetStmResourceMsr (mHostContextCommon.MleProtectedResource.Base, MsrIndex); 44 if ((MsrDesc != NULL) && (MsrDesc->ReadMask != 0)) { 45 DEBUG ((EFI_D_ERROR, "RDMSR (%x) violation!\n", MsrIndex)); 46 AddEventLogForResource (EvtHandledProtectionException, (STM_RSC *)MsrDesc); ** CID 1434834: Incorrect expression (ASSERT_SIDE_EFFECT) /3rdparty/stm/Stm/StmPkg/Library/SimpleSynchronizationLib/SynchronizationGcc.c: 143 in AcquireSpinLockOrFail() ________________________________________________________________________________________________________ *** CID 1434834: Incorrect expression (ASSERT_SIDE_EFFECT) /3rdparty/stm/Stm/StmPkg/Library/SimpleSynchronizationLib/SynchronizationGcc.c: 143 in AcquireSpinLockOrFail() 137 SPIN_LOCK LockValue; 138 VOID *Result; 139 140 ASSERT (SpinLock != NULL); 141 142 LockValue = *SpinLock; >>> CID 1434834: Incorrect expression (ASSERT_SIDE_EFFECT) >>> Argument "LockValue" of ASSERT() has a side effect because the variable is volatile. The containing function might work differently in a non-debug build. 143 ASSERT (LockValue == SPIN_LOCK_ACQUIRED || LockValue == SPIN_LOCK_RELEASED); 144 145 _ReadWriteBarrier (); 146 Result = InterlockedCompareExchangePointer ( 147 (VOID**)SpinLock, 148 (VOID*)SPIN_LOCK_RELEASED, ** CID 1434833: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434833: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Init/StmInit.c: 1087 in CommonInit() 1081 AsmWriteCr4 (AsmReadCr4 () | CR4_OSFXSR | CR4_OSXMMEXCPT); 1082 if (IsXStateSupoprted()) { 1083 AsmWriteCr4 (AsmReadCr4 () | CR4_OSXSAVE); 1084 } 1085 1086 VmxMisc.Uint64 = AsmReadMsr64 (IA32_VMX_MISC_MSR_INDEX); >>> CID 1434833: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&mGuestContextCommonSmi.GuestContextPerCpu[Index].Register.Rdx" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 1087 RegEdx = ReadUnaligned32 ((UINT32 *)&mGuestContextCommonSmi.GuestContextPerCpu[Index].Register.Rdx); 1088 if ((RegEdx & STM_CONFIG_SMI_UNBLOCKING_BY_VMX_OFF) != 0) { 1089 if (VmxMisc.Bits.VmxOffUnblockSmiSupport != 0) { 1090 AsmWriteMsr64 (IA32_SMM_MONITOR_CTL_MSR_INDEX, AsmReadMsr64(IA32_SMM_MONITOR_CTL_MSR_INDEX) | IA32_SMM_MONITOR_SMI_UNBLOCKING_BY_VMX_OFF); 1091 } 1092 } ** CID 1434832: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434832: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeSmmMsrHandler.c: 111 in PeWriteMsrHandler() 105 106 SmmCpuState = mGuestContextCommonSmi.GuestContextPerCpu[Index].SmmCpuState; 107 108 Reg = &mGuestContextCommonSmm[VmType].GuestContextPerCpu[Index].Register; 109 MsrIndex = ReadUnaligned32 ((UINT32 *)&Reg->Rcx); 110 >>> CID 1434832: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rdx" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 111 Data64 = LShiftU64 ((UINT64)ReadUnaligned32 ((UINT32 *)&Reg->Rdx), 32) | (UINT64)ReadUnaligned32 ((UINT32 *)&Reg->Rax); 112 DEBUG ((EFI_D_INFO, "%ld PeWriteMsrHandler - 0x%llx 0x%llx\n", CpuIndex, MsrIndex, Data64)); 113 114 switch (MsrIndex) { 115 case IA32_EFER_MSR_INDEX: 116 #if 0 ** CID 1434831: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434831: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/SmmVmcallHandler.c: 435 in SmmVmcallHandler() 429 if (StmVmcallHandler == NULL) { 430 DEBUG((EFI_D_INFO, "%ld SmmVmcallHandler - GetSmmVmcallHandlerByIndex - %x!\n", Index, (UINTN)ReadUnaligned32 ((UINT32 *)&Reg->Rax))); 431 // Should not happen 432 CpuDeadLoop (); 433 Status = ERROR_INVALID_API; 434 } else { >>> CID 1434831: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rcx" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 435 AddressParameter = ReadUnaligned32 ((UINT32 *)&Reg->Rbx) + LShiftU64 (ReadUnaligned32 ((UINT32 *)&Reg->Rcx), 32); 436 Status = StmVmcallHandler (Index, AddressParameter); 437 } 438 439 WriteUnaligned32 ((UINT32 *)&Reg->Rax, Status); 440 if (Status == STM_SUCCESS) { ** CID 1434830: (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434830: (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Init/StmInit.c: 1237 in LaunchBack() 1231 1232 if(!IsResourceListValid ((STM_RSC *)(UINTN)mHostContextCommon.HostContextPerCpu[Index].TxtProcessorSmmDescriptor->BiosHwResourceRequirementsPtr, FALSE)) { 1233 DEBUG ((EFI_D_INFO, "%ld LaunchBack - ValidateBiosResourceList fail!\n", Index)); 1234 WriteUnaligned32 ((UINT32 *)&Reg->Rax, ERROR_STM_MALFORMED_RESOURCE_LIST); 1235 VmWriteN (VMCS_N_GUEST_RFLAGS_INDEX, VmReadN(VMCS_N_GUEST_RFLAGS_INDEX) | RFLAGS_CF); 1236 } else { >>> CID 1434830: (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rax" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 1237 WriteUnaligned32 ((UINT32 *)&Reg->Rax, STM_SUCCESS); 1238 VmWriteN (VMCS_N_GUEST_RFLAGS_INDEX, VmReadN(VMCS_N_GUEST_RFLAGS_INDEX) & ~RFLAGS_CF); 1239 } 1240 WriteUnaligned32 ((UINT32 *)&Reg->Rbx, 0); // Not support STM_RSC_BGM or STM_RSC_BGI or STM_RSC_MSR 1241 1242 DEBUG ((EFI_D_INFO, "%ld !!!LaunchBack!!!\n", (UINTN)Index)); /3rdparty/stm/Stm/StmPkg/Core/Init/StmInit.c: 1226 in LaunchBack() 1220 // 1221 if ((Index == 0) && (ReadUnaligned32 ((UINT32 *)&Reg->Rax) == STM_API_INITIALIZE_PROTECTION)) { 1222 DEBUG ((EFI_D_INFO, "BIOS resource:\n")); 1223 DumpStmResource ((STM_RSC *)(UINTN)mHostContextCommon.HostContextPerCpu[0].TxtProcessorSmmDescriptor->BiosHwResourceRequirementsPtr); 1224 } 1225 #endif >>> CID 1434830: (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rax" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 1226 if (ReadUnaligned32 ((UINT32 *)&Reg->Rax) == STM_API_START) { 1227 // We need do additional thing for STM_API_START 1228 mGuestContextCommonSmm[SMI_HANDLER].GuestContextPerCpu[Index].Actived = TRUE; 1229 SmmSetup (Index); 1230 } 1231 /3rdparty/stm/Stm/StmPkg/Core/Init/StmInit.c: 1234 in LaunchBack() 1228 mGuestContextCommonSmm[SMI_HANDLER].GuestContextPerCpu[Index].Actived = TRUE; 1229 SmmSetup (Index); 1230 } 1231 1232 if(!IsResourceListValid ((STM_RSC *)(UINTN)mHostContextCommon.HostContextPerCpu[Index].TxtProcessorSmmDescriptor->BiosHwResourceRequirementsPtr, FALSE)) { 1233 DEBUG ((EFI_D_INFO, "%ld LaunchBack - ValidateBiosResourceList fail!\n", Index)); >>> CID 1434830: (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rax" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 1234 WriteUnaligned32 ((UINT32 *)&Reg->Rax, ERROR_STM_MALFORMED_RESOURCE_LIST); 1235 VmWriteN (VMCS_N_GUEST_RFLAGS_INDEX, VmReadN(VMCS_N_GUEST_RFLAGS_INDEX) | RFLAGS_CF); 1236 } else { 1237 WriteUnaligned32 ((UINT32 *)&Reg->Rax, STM_SUCCESS); 1238 VmWriteN (VMCS_N_GUEST_RFLAGS_INDEX, VmReadN(VMCS_N_GUEST_RFLAGS_INDEX) & ~RFLAGS_CF); 1239 } ** CID 1434829: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434829: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/SmmCpuidHandler.c: 36 in SmmCpuidHandler() 30 X86_REGISTER *Reg; 31 UINT32 VmType = SMI_HANDLER; 32 33 Reg = &mGuestContextCommonSmm[VmType].GuestContextPerCpu[Index].Register; 34 35 AsmCpuidEx ( >>> CID 1434829: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rax" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 36 ReadUnaligned32 ((UINT32 *)&Reg->Rax), 37 ReadUnaligned32 ((UINT32 *)&Reg->Rcx), 38 (UINT32 *)&Reg->Rax, 39 (UINT32 *)&Reg->Rbx, 40 (UINT32 *)&Reg->Rcx, 41 (UINT32 *)&Reg->Rdx 42 ); 43 VmWriteN (VMCS_N_GUEST_RIP_INDEX, VmReadN(VMCS_N_GUEST_RIP_INDEX) + VmRead32(VMCS_32_RO_VMEXIT_INSTRUCTION_LENGTH_INDEX)); 44 return ; ** CID 1434828: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434828: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/SmiVmcallHandler.c: 1010 in SmiVmcallHandler() 1004 DEBUG ((EFI_D_ERROR, 1005 "%ld SmiVmcallHandler - GetSmiVmcallHandlerByIndex- Invalid API entry - %x!\n", 1006 Index, 1007 (UINTN)ReadUnaligned32 ((UINT32 *)&Reg->Rax))); 1008 Status = ERROR_INVALID_API; 1009 } else { >>> CID 1434828: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rbx" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 1010 AddressParameter = ReadUnaligned32 ((UINT32 *)&Reg->Rbx) + LShiftU64 (ReadUnaligned32 ((UINT32 *)&Reg->Rcx), 32); 1011 1012 Status = StmVmcallHandler (Index, AddressParameter); 1013 } 1014 1015 if (Status == STM_SUCCESS) { ** CID 1434827: (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434827: (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeSmmVmcallHandler.c: 309 in PeSmmVmcallHandler() 303 Status = ERROR_INVALID_API; 304 } else { 305 AddressParameter = ReadUnaligned32 ((UINT32 *)&Reg->Rbx) + LShiftU64 (ReadUnaligned32 ((UINT32 *)&Reg->Rcx), 32); 306 Status = StmVmcallHandler (Index, AddressParameter); 307 } 308 >>> CID 1434827: (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rax" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 309 WriteUnaligned32 ((UINT32 *)&Reg->Rax, Status); 310 if (Status == STM_SUCCESS) { 311 VmWriteN (VMCS_N_GUEST_RFLAGS_INDEX, VmReadN(VMCS_N_GUEST_RFLAGS_INDEX) & ~RFLAGS_CF); 312 } else { 313 VmWriteN (VMCS_N_GUEST_RFLAGS_INDEX, VmReadN(VMCS_N_GUEST_RFLAGS_INDEX) | RFLAGS_CF); 314 } /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeSmmVmcallHandler.c: 298 in PeSmmVmcallHandler() 292 293 //DEBUG((EFI_D_INFO, "%ld PeSmmVmcallHandler - start\n", Index)); 294 VmType = mHostContextCommon.HostContextPerCpu[Index].GuestVmType; 295 296 Reg = &mGuestContextCommonSmm[VmType].GuestContextPerCpu[0].Register; 297 >>> CID 1434827: (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rax" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 298 StmVmcallHandler = GetPeSmmVmcallHandlerByIndex (ReadUnaligned32 ((UINT32 *)&Reg->Rax)); 299 if (StmVmcallHandler == NULL) { 300 DEBUG ((EFI_D_ERROR, "%ld PeSmmVmcallHandler - GetPeSmmVmcallHandlerByIndex (no handler) - 0x%llx!\n", 301 Index, 302 ReadUnaligned32 ((UINT32 *)&Reg->Rax))); 303 Status = ERROR_INVALID_API; /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeSmmVmcallHandler.c: 300 in PeSmmVmcallHandler() 294 VmType = mHostContextCommon.HostContextPerCpu[Index].GuestVmType; 295 296 Reg = &mGuestContextCommonSmm[VmType].GuestContextPerCpu[0].Register; 297 298 StmVmcallHandler = GetPeSmmVmcallHandlerByIndex (ReadUnaligned32 ((UINT32 *)&Reg->Rax)); 299 if (StmVmcallHandler == NULL) { >>> CID 1434827: (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rax" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 300 DEBUG ((EFI_D_ERROR, "%ld PeSmmVmcallHandler - GetPeSmmVmcallHandlerByIndex (no handler) - 0x%llx!\n", 301 Index, 302 ReadUnaligned32 ((UINT32 *)&Reg->Rax))); 303 Status = ERROR_INVALID_API; 304 } else { 305 AddressParameter = ReadUnaligned32 ((UINT32 *)&Reg->Rbx) + LShiftU64 (ReadUnaligned32 ((UINT32 *)&Reg->Rcx), 32); ** CID 1434826: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434826: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/SmmCpuidHandler.c: 37 in SmmCpuidHandler() 31 UINT32 VmType = SMI_HANDLER; 32 33 Reg = &mGuestContextCommonSmm[VmType].GuestContextPerCpu[Index].Register; 34 35 AsmCpuidEx ( 36 ReadUnaligned32 ((UINT32 *)&Reg->Rax), >>> CID 1434826: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rcx" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 37 ReadUnaligned32 ((UINT32 *)&Reg->Rcx), 38 (UINT32 *)&Reg->Rax, 39 (UINT32 *)&Reg->Rbx, 40 (UINT32 *)&Reg->Rcx, 41 (UINT32 *)&Reg->Rdx 42 ); 43 VmWriteN (VMCS_N_GUEST_RIP_INDEX, VmReadN(VMCS_N_GUEST_RIP_INDEX) + VmRead32(VMCS_32_RO_VMEXIT_INSTRUCTION_LENGTH_INDEX)); 44 return ; ** CID 1434825: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434825: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/SmmMsrHandler.c: 139 in SmmWriteMsrHandler() 133 STM_SMM_CPU_STATE *SmmCpuState; 134 UINT32 VmType = SMI_HANDLER; 135 136 SmmCpuState = mGuestContextCommonSmi.GuestContextPerCpu[Index].SmmCpuState; 137 138 Reg = &mGuestContextCommonSmm[VmType].GuestContextPerCpu[Index].Register; >>> CID 1434825: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rcx" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 139 MsrIndex = ReadUnaligned32 ((UINT32 *)&Reg->Rcx); 140 141 MsrDesc = GetStmResourceMsr (mHostContextCommon.MleProtectedResource.Base, MsrIndex); 142 if ((MsrDesc != NULL) && (MsrDesc->WriteMask != 0)) { 143 DEBUG ((EFI_D_ERROR, "WRMSR (%x) violation!\n", MsrIndex)); 144 AddEventLogForResource (EvtHandledProtectionException, (STM_RSC *)MsrDesc); ** CID 1434824: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434824: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeSmmIoHandler.c: 64 in PeIoHandler() 58 59 if((PortNumber == 0x3D8)||(PortNumber == 0x3F8)) 60 { 61 UINT64 AddressSpaceStart = PeVmData[VmType].UserModule.AddressSpaceStart; 62 UINT64 AddressSpaceEnd = PeVmData[VmType].UserModule.AddressSpaceStart + PeVmData[VmType].UserModule.AddressSpaceSize; 63 GuestAddress = ReadUnaligned64((UINT64 *) &Reg->Rsi); // assume that DS Base is zero >>> CID 1434824: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rcx" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 64 DataSize = ReadUnaligned32((UINT32 *) &Reg->Rcx); 65 //DEBUG((EFI_D_INFO, "%ld PeIoHandler - GuestAddress: 0x%016llx DataSize: 0x%016llx \n", CpuIndex, GuestAddress, DataSize)); 66 GuestAddressEnd = GuestAddress + DataSize; 67 68 // make sure the GuestAddress fits in the block that is within 69 // SMRAM ** CID 1434823: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 1434823: Integer handling issues (INCOMPATIBLE_CAST) /3rdparty/stm/Stm/StmPkg/Core/Runtime/PeLoadVm.c: 631 in PostPeVmProc() 625 if(PeVmData[PeType].StartMode == PEVM_START_VMCALL) 626 { 627 // setup the return codes 628 629 Reg = &mGuestContextCommonSmi.GuestContextPerCpu[CpuIndex].Register; 630 >>> CID 1434823: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&Reg->Rax" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 631 WriteUnaligned32 ((UINT32 *)&Reg->Rax, rc); 632 if (rc == PE_SUCCESS) 633 { 634 VmWriteN (VMCS_N_GUEST_RFLAGS_INDEX, 635 VmReadN(VMCS_N_GUEST_RFLAGS_INDEX) & ~RFLAGS_CF); 636 } ** CID 1434822: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/stm/Stm/StmPkg/Core/StmResource.c: 308 in IsResourceNodeValid() ________________________________________________________________________________________________________ *** CID 1434822: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/stm/Stm/StmPkg/Core/StmResource.c: 308 in IsResourceNodeValid() 302 } 303 break; 304 case MEM_RANGE: 305 if (ResourceNode->Header.Length != sizeof(STM_RSC_MEM_DESC)) { 306 goto CheckFail; 307 } >>> CID 1434822: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "ResourceNode->Mem.RWXAttributes & -8 /* ~((1 | 2) | 4) */" is always 0 regardless of the values of its operands. This occurs as a value. 308 if ((ResourceNode->Mem.RWXAttributes & ~(STM_RSC_MEM_R | STM_RSC_MEM_W | STM_RSC_MEM_X)) != 0) { 309 goto CheckFail; 310 } 311 if (ResourceNode->Mem.Reserved != 0) { 312 goto CheckFail; 313 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Memory frequency issue with the T430 and 2133MHz RAM
by Lars Hochstetter 18 Oct '20

18 Oct '20

Hi everyone, I’m having an issue with the option “Ignore vendor programmed fuses that limit max. DRAM frequency”. When I enable said option my laptop will turn on but the screen stays black and “nothing” happens. The only option to recover the laptop is to install a 1600MHz stick, that will limit the other 2133MHz stick to 1600MHz and to reflash a coreboot build with above mentioned option turned off. My laptop is a Lenovo Thinkpad T430 without a dGPU (i.e. only Intel HD4000 iGPU). As far as I can recall the memory worked at its maximum frequency (2133MHz) fine when using the Lenovo OEM BIOS. I’m using coreboot v4.12 with SeaBIOS v1.13.0 and use libgfxinit. I also tried using the VGA option ROM but to no avail. I've appended the output of /dmidecode -t memory/ and /dmidecode -t processor/ and /uname -r/ below. Does anyone else has this issue? How do I debug this issue? Evgeny Zinoviev pointed me some time ago to the optional use of the mrc.bin for the X220 [1] and someone trying to use the mrc.bin for the T430 [2]. Could I somehow use the mrc.bin approach for the X220 in [2] in conjunction with [1] and [3] to allow the optional use of the mrc.bin for the T430? Kind regards lhochstetter [1] https://review.coreboot.org/c/coreboot/+/37153 [2] https://review.coreboot.org/c/coreboot/+/23489 [3] https://review.coreboot.org/c/coreboot/+/32500 --- /uname -r: /4.19.0-11-amd64 (Debian 4.19.146-1) // Here is the output of /dmidecode -t memory/ and /dmidecode -t processor/: # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. Handle 0x000A, DMI type 17, 40 bytes Memory Device Array Handle: 0x0000 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 8192 MB Form Factor: SODIMM Set: None Locator: Channel-0-DIMM-0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Speed: 800 MT/s Manufacturer: Kingston Serial Number: 4a2d6e3a Asset Tag: Not Specified Part Number: KHX2133C11S3L/8G Rank: 2 Configured Memory Speed: 800 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown Handle 0x000B, DMI type 17, 40 bytes Memory Device Array Handle: 0x0000 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 8192 MB Form Factor: SODIMM Set: None Locator: Channel-1-DIMM-0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Speed: 800 MT/s Manufacturer: Kingston Serial Number: 4b2d703a Asset Tag: Not Specified Part Number: KHX2133C11S3L/8G Rank: 2 Configured Memory Speed: 800 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown Handle 0x0004, DMI type 4, 42 bytes Processor Information Socket Designation: Not Specified Type: Central Processor Family: Pentium Pro Manufacturer: GenuineIntel ID: A9 06 03 00 FF FB EB BF Signature: Type 0, Family 6, Model 58, Stepping 9 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz Voltage: Unknown External Clock: Unknown Max Speed: Unknown Current Speed: Unknown Status: Unpopulated Upgrade: Unknown L1 Cache Handle: 0x0006 L2 Cache Handle: 0x0007 L3 Cache Handle: 0x0008 Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Core Count: 4 Core Enabled: 4 Characteristics: None

1 0

ASUS A88XM-E internal flashing
by mejim67741＠pastortips.com 16 Oct '20

16 Oct '20

The documentation says The main SPI flash can be accessed using flashrom, if the AmdSpiRomProtect modules have been deleted in the factory image previously. So what does that mean? How can i do that? I would like to flash it internal

4 3

How to debug open-source AGESA with serial console?
by Paul Menzel 16 Oct '20

16 Oct '20

Dear coreboot folks, To get PCI bridge 0:15.2 enabled for the network device on the Asus F2A85-M PRO, I want to debug the PCIe General Purpose Ports lane configuration of the FCH. I’d like to print some variables in src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c over the serial console. It looks like #include <console/console.h> and `printk(BIOS_DEBUG, …)` compiles, but the messages are not sent over serial console. Is that expected? Do I need to use AGESA’s Integrated Debug Services (IDS) [1], and enable the console in `src/mainboard/asus/f2a85-m/OptionsIds.h`? Kind regards, Paul [1]: https://www.coreboot.org/images/3/36/AGESA_Interface_Spec_for_Arch_2008_v3.…

6 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2020