[edk2-devel] Peims are not gettting Dispatched in EagleStream Platform
Hi,
I am trying to build edk2-platforms for EagleStream Platform. The problem I am
facing now is that the Peims are not getting dispatched when The PeiMain
routine calls PeiDispatcher().
After digging deeper into it it seems that the DepexSatisfied() routine is
always returning false. So I also checked this and realized that the place that
is returning false is inside the PeimDispatchReadiness
function:
```
case (EFI_DEP_END): DEBUG ((DEBUG_DISPATCH, " END\n"));
StackPtr--;
//
// Check to make sure EvalStack is balanced. If not, then there is
// an error in the dependency grammar, so return EFI_INVALID_PARAMETER.
//
if (StackPtr != &EvalStack[0]) {
DEBUG ((DEBUG_DISPATCH, " RESULT = FALSE (Underflow Error)\n"));
return FALSE;
}
DEBUG ((DEBUG_DISPATCH, " RESULT = %a\n", IsPpiInstalled (PeiServices,
StackPtr) ? "TRUE" : "FALSE"));
return IsPpiInstalled (PeiServices, StackPtr);
```
It seems that when entering IsPpiInstalled StackPtr in always NULL.
Any thoughts on this?
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115748): https://edk2.groups.io/g/devel/message/115748
Mute This Topic: https://groups.io/mt/104498510/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Peims are not gettting Dispatched in EagleStream Platform
Hi,
I am trying to build edk2-platforms for EagleStream Platform. The problem I am
facing now is that the Peims are not getting dispatched when The PeiMain
routine calls PeiDispatcher().
After digging deeper into it it seems that the DepexSatisfied() routine is
always returning false. So I also checked this and realized that the place that
is returning false is inside the PeimDispatchReadiness
function:
```
case (EFI_DEP_END): DEBUG ((DEBUG_DISPATCH, " END\n"));
StackPtr--;
//
// Check to make sure EvalStack is balanced. If not, then there is
// an error in the dependency grammar, so return EFI_INVALID_PARAMETER.
//
if (StackPtr != &EvalStack[0]) {
DEBUG ((DEBUG_DISPATCH, " RESULT = FALSE (Underflow Error)\n"));
return FALSE;
}
DEBUG ((DEBUG_DISPATCH, " RESULT = %a\n", IsPpiInstalled (PeiServices,
StackPtr) ? "TRUE" : "FALSE"));
return IsPpiInstalled (PeiServices, StackPtr);
```
It seems that when entering IsPpiInstalled StackPtr in always NULL.Any thoughts
on this?
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115749): https://edk2.groups.io/g/devel/message/115749
Mute This Topic: https://groups.io/mt/104498510/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform
Thank you. Based on what you told me (memory corruption and and the
unlikelihood of the stack pointer being NULL) my only suspicion would be the
microcode I am using, since the only platform dependent parts up until this
part would be the microcode and the FSP-T and since I am using the FSP for
EagleStream only the microcode would be left to change. Up until now I was
using Whitley's microcode (since EagleStream's hadn't been released yet). To be
honest I still don't have a proper comprehension of the concept of the
microcode so I thought maybe I could use Whitley's microcode. But now that
EagleStream's microcode has been released I'll try with that and let you know
whether it works or not. Yet I am still skeptical about it being a microcode
issue because my thought is that the microcode is procosser architecture-based
code rather than it being platform-based code. Please correct me if I am wrong
on this matter.
On Thursday, February 22nd, 2024 at 3:42 AM, Desimone, Nathaniel L
wrote:
> > -Original Message-
> > From: devel@edk2.groups.io devel@edk2.groups.io On Behalf Of Laszlo
> > Ersek
> > Sent: Wednesday, February 21, 2024 3:59 PM
> > To: devel@edk2.groups.io; memrist...@proton.me
> > Subject: Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream
> > Platform
> >
> > On 2/21/24 07:59, memristor2 via groups.io wrote:
> >
> > > Hi,
> > > I am trying to build edk2-platforms for EagleStream Platform. The
> > > problem I am facing now is that the Peims are not getting dispatched
> > > when The PeiMain routine calls PeiDispatcher().
> > > After digging deeper into it it seems that the DepexSatisfied()
> > > routine is always returning false. So I also checked this and realized
> > > that the place that is returning false is inside the
> > > PeimDispatchReadiness
> > > function:
> > > ||```
> > > case (EFI_DEP_END): DEBUG ((DEBUG_DISPATCH, " END\n"));
> > > StackPtr--;
> > > //
> > > // Check to make sure EvalStack is balanced. If not, then
> > > there is
> > > // an error in the dependency grammar, so return
> > > EFI_INVALID_PARAMETER.
> > > //
> > > if (StackPtr != &EvalStack[0]) {
> > >
> > > DEBUG ((DEBUG_DISPATCH, " RESULT = FALSE (Underflow
> > > Error)\n"));
> > > return FALSE;
> > > }
> > >
> > > DEBUG ((DEBUG_DISPATCH, " RESULT = %a\n", IsPpiInstalled
> > > (PeiServices, StackPtr) ? "TRUE" : "FALSE"));
> > >
> > > return IsPpiInstalled (PeiServices, StackPtr); ``` It seems
> > > that when entering IsPpiInstalled StackPtr in always NULL.
> > > Any thoughts on this?
> >
> > StackPtr being NULL seems extremely unlikely; it is supposed to point to
> > elements of the EvalStack local array (or I guess one past the last
> > element).
> >
> > Now, I can see two potential problems here:
> >
> > - your depex is malformed (for whatever reason), and the eval stack is not
> > torn
> > down entirely before reachig EFI_DEP_END. The code seems to handle that
> > correctly, by returning FALSE.
> >
> > - your depex is malformed such that it immediately starts with an
> > EFI_DEP_END. The code is actually buggy for that case, because it decrements
> > StackPtr first, before comparing it against &EvalStack[0].
> > That decrement invokes undefined behavior. However, I assume in practice the
> > behavior will be the same as in the previous paragraph.
> >
> > A NULL StackPtr value I cannot explain at all.
>
>
> Agreed with Laszlo here... the only thing that I could think of is memory
> corruption. Several people at Intel (myself included) as working on getting
> an EaglestreamOpenBoardPkg posted to edk2-platforms right now. I would
> recommend you wait for us to release our code as opposed
>
> > Laszlo
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115816): https://edk2.groups.io/g/devel/message/115816
Mute This Topic: https://groups.io/mt/104498510/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform
Sent with Proton Mail secure email. On Saturday, February 24th, 2024 at 12:15 AM, Desimone, Nathaniel L wrote: > > -Original Message- > > From: memristor2 memrist...@proton.me > > Sent: Thursday, February 22, 2024 5:51 AM > > To: Desimone, Nathaniel L nathaniel.l.desim...@intel.com > > Cc: devel@edk2.groups.io; ler...@redhat.com > > Subject: RE: [edk2-devel] Peims are not gettting Dispatched in EagleStream > > Platform > > > > Thank you. Based on what you told me (memory corruption and and the > > unlikelihood of the stack pointer being NULL) my only suspicion would be the > > microcode I am using, since the only platform dependent parts up until this > > part would be the microcode and the FSP-T and since I am using the FSP for > > EagleStream only the microcode would be left to change. > > > Having correct microcode is absolutely essential for sure. But microcode & FSP > are not the only platform dependent components. Any code contained in a > *BoardPkg is considered to be platform dependent in some way. I would be > surprised if simply adding the microcode will fix this problem. > > > Up until now I was using Whitley's microcode (since EagleStream's hadn't > > been > > released yet). To be honest I still don't have a proper comprehension of the > > concept of the microcode so I thought maybe I could use Whitley's microcode. > > > Here is what microcode is in a nutshell. Every x86 processor designed since > ~1990 is actually a RISC-based CPU design internally. The microcode contains a > lookup table that maps each CPU instruction into one or more sub-instructions > (sometimes called micro-instructions or micro-OPs (µOPs for short)) which are > the instructions that the hidden RISC processor executes. This hidden RISC > processor has an unpublished instruction set that no one outside of the CPU > vendor sees. > > The initial purpose of RISC was to eliminate the need for microcode, as the > complex decode engine and ROM consumed transistors that could instead be used > for things like a wider ALU. But then in the mid-1990s, a new technology came > along called out-of-order execution. The idea behind out-of-order execution is > that we can expand the purpose of microcode to be more than just a lookup > table, > it can actually change the sequence of micro-OPs so that the program runs > faster. So now, microcode is not only a lookup table, but it also provides a > programmable instruction scheduler. > > The use of out-of-order execution was made possible by Moore's law. Moore's > law > drove rapidly increasing transistor counts during the 1990s. No longer would > you > need to decide whether to use your transistor budget for microcode or for a > wider ALU... you had plenty of transistors so you could do both! Both of them > together yields the fastest CPU designs by a large margin. All of these > factors > came together at once, and suddenly any CPU design that didn't use microcode > was > obsolete by the year 2000. > > Fast forward to today, the RISC vs. CISC argument is obsolete. Modern > high-performance CPUs require very complex microcode. The existence of that > microcode abstracts most of the differences between traditionally RISC ISAs > like > ARM and traditionally CISC ISAs like x86. Thank you I just learned as much as I learned in my Advanced Computer Architecture course. Your explanations are higly appreciated. > > > But now that EagleStream's microcode has been released I'll try with that > > and > > let you know whether it works or not. Yet I am still skeptical about it > > being > > a microcode issue because my thought is that the microcode is procosser > > architecture-based code rather than it being platform-based code. Please > > correct me if I am wrong on this matter. > > > You intuition that it is not a microcode issue is correct. There are a lot of > things in the BoardPkg that change with each platform design. For an example > of > that, try diff'ing KabylakeOpenBoardPkg with AlderlakeOpenBoardPkg. So I must take back my first thought that the StackPtr was NULL now it wasn't. StackPtr->Operator is always NULL, Which is another issue. The thing is that all of the Peims are found inside the FV but whenever the PeimDispatchReadiness() routine calls IsPpiInstalled() it seems it doesn't find the Ppis and I don't have any idea why > > > On Thursday, February 22nd, 2024 at 3:42 AM, Desimone, Nathaniel L > > nathaniel.l.desim...@intel.com wrote: > > > > > > -Original Message- > > > > From: devel@edk2.groups.io devel@e
Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform
Sent with Proton Mail secure email. On Saturday, February 24th, 2024 at 5:00 PM, memristor2 via groups.io wrote: > > > > > > Sent with Proton Mail secure email. > > > On Saturday, February 24th, 2024 at 12:15 AM, Desimone, Nathaniel L > nathaniel.l.desim...@intel.com wrote: > > > > -Original Message- > > > From: memristor2 memrist...@proton.me > > > Sent: Thursday, February 22, 2024 5:51 AM > > > To: Desimone, Nathaniel L nathaniel.l.desim...@intel.com > > > Cc: devel@edk2.groups.io; ler...@redhat.com > > > Subject: RE: [edk2-devel] Peims are not gettting Dispatched in EagleStream > > > Platform > > > > > > Thank you. Based on what you told me (memory corruption and and the > > > unlikelihood of the stack pointer being NULL) my only suspicion would be > > > the > > > microcode I am using, since the only platform dependent parts up until > > > this > > > part would be the microcode and the FSP-T and since I am using the FSP for > > > EagleStream only the microcode would be left to change. > > > > Having correct microcode is absolutely essential for sure. But microcode & > > FSP > > are not the only platform dependent components. Any code contained in a > > *BoardPkg is considered to be platform dependent in some way. I would be > > surprised if simply adding the microcode will fix this problem. > > > > > Up until now I was using Whitley's microcode (since EagleStream's hadn't > > > been > > > released yet). To be honest I still don't have a proper comprehension of > > > the > > > concept of the microcode so I thought maybe I could use Whitley's > > > microcode. > > > > Here is what microcode is in a nutshell. Every x86 processor designed since > > ~1990 is actually a RISC-based CPU design internally. The microcode > > contains a > > lookup table that maps each CPU instruction into one or more > > sub-instructions > > (sometimes called micro-instructions or micro-OPs (µOPs for short)) which > > are > > the instructions that the hidden RISC processor executes. This hidden RISC > > processor has an unpublished instruction set that no one outside of the CPU > > vendor sees. > > > > The initial purpose of RISC was to eliminate the need for microcode, as the > > complex decode engine and ROM consumed transistors that could instead be > > used > > for things like a wider ALU. But then in the mid-1990s, a new technology > > came > > along called out-of-order execution. The idea behind out-of-order execution > > is > > that we can expand the purpose of microcode to be more than just a lookup > > table, > > it can actually change the sequence of micro-OPs so that the program runs > > faster. So now, microcode is not only a lookup table, but it also provides a > > programmable instruction scheduler. > > > > The use of out-of-order execution was made possible by Moore's law. Moore's > > law > > drove rapidly increasing transistor counts during the 1990s. No longer > > would you > > need to decide whether to use your transistor budget for microcode or for a > > wider ALU... you had plenty of transistors so you could do both! Both of > > them > > together yields the fastest CPU designs by a large margin. All of these > > factors > > came together at once, and suddenly any CPU design that didn't use > > microcode was > > obsolete by the year 2000. > > > > Fast forward to today, the RISC vs. CISC argument is obsolete. Modern > > high-performance CPUs require very complex microcode. The existence of that > > microcode abstracts most of the differences between traditionally RISC ISAs > > like > > ARM and traditionally CISC ISAs like x86. > > Thank you I just learned as much as I learned in my Advanced Computer > Architecture course. Your explanations are higly appreciated. > > > > But now that EagleStream's microcode has been released I'll try with that > > > and > > > let you know whether it works or not. Yet I am still skeptical about it > > > being > > > a microcode issue because my thought is that the microcode is procosser > > > architecture-based code rather than it being platform-based code. Please > > > correct me if I am wrong on this matter. > > > > You intuition that it is not a microcode issue is correct. There are a lot > > of > > things in the BoardPkg that change with each platform design
Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform
I solved my issue it seems that I fo got to add the crucial PcdPei.inf peim (yes all this fuss for a simple mistake) to my fdf file thank you for your help Sent with Proton Mail secure email. On Saturday, February 24th, 2024 at 5:41 PM, memristor2 wrote: > > > > > > Sent with Proton Mail secure email. > > > On Saturday, February 24th, 2024 at 5:00 PM, memristor2 via groups.io > memristor2=proton...@groups.io wrote: > > > Sent with Proton Mail secure email. > > > > On Saturday, February 24th, 2024 at 12:15 AM, Desimone, Nathaniel L > > nathaniel.l.desim...@intel.com wrote: > > > > > > -Original Message- > > > > From: memristor2 memrist...@proton.me > > > > Sent: Thursday, February 22, 2024 5:51 AM > > > > To: Desimone, Nathaniel L nathaniel.l.desim...@intel.com > > > > Cc: devel@edk2.groups.io; ler...@redhat.com > > > > Subject: RE: [edk2-devel] Peims are not gettting Dispatched in > > > > EagleStream > > > > Platform > > > > > > > > Thank you. Based on what you told me (memory corruption and and the > > > > unlikelihood of the stack pointer being NULL) my only suspicion would > > > > be the > > > > microcode I am using, since the only platform dependent parts up until > > > > this > > > > part would be the microcode and the FSP-T and since I am using the FSP > > > > for > > > > EagleStream only the microcode would be left to change. > > > > > > Having correct microcode is absolutely essential for sure. But microcode > > > & FSP > > > are not the only platform dependent components. Any code contained in a > > > *BoardPkg is considered to be platform dependent in some way. I would be > > > surprised if simply adding the microcode will fix this problem. > > > > > > > Up until now I was using Whitley's microcode (since EagleStream's > > > > hadn't been > > > > released yet). To be honest I still don't have a proper comprehension > > > > of the > > > > concept of the microcode so I thought maybe I could use Whitley's > > > > microcode. > > > > > > Here is what microcode is in a nutshell. Every x86 processor designed > > > since > > > ~1990 is actually a RISC-based CPU design internally. The microcode > > > contains a > > > lookup table that maps each CPU instruction into one or more > > > sub-instructions > > > (sometimes called micro-instructions or micro-OPs (µOPs for short)) which > > > are > > > the instructions that the hidden RISC processor executes. This hidden RISC > > > processor has an unpublished instruction set that no one outside of the > > > CPU > > > vendor sees. > > > > > > The initial purpose of RISC was to eliminate the need for microcode, as > > > the > > > complex decode engine and ROM consumed transistors that could instead be > > > used > > > for things like a wider ALU. But then in the mid-1990s, a new technology > > > came > > > along called out-of-order execution. The idea behind out-of-order > > > execution is > > > that we can expand the purpose of microcode to be more than just a lookup > > > table, > > > it can actually change the sequence of micro-OPs so that the program runs > > > faster. So now, microcode is not only a lookup table, but it also > > > provides a > > > programmable instruction scheduler. > > > > > > The use of out-of-order execution was made possible by Moore's law. > > > Moore's law > > > drove rapidly increasing transistor counts during the 1990s. No longer > > > would you > > > need to decide whether to use your transistor budget for microcode or for > > > a > > > wider ALU... you had plenty of transistors so you could do both! Both of > > > them > > > together yields the fastest CPU designs by a large margin. All of these > > > factors > > > came together at once, and suddenly any CPU design that didn't use > > > microcode was > > > obsolete by the year 2000. > > > > > > Fast forward to today, the RISC vs. CISC argument is obsolete. Modern > > > high-performance CPUs require very complex microcode. The existence of > > > that > > > microcode abstracts most of the differences between traditionally RISC > > > ISAs like > > >
[edk2-devel] DxeSmmReadyToLockProtocol interface doesn't get installed
Hello everyone, I am developing a platform based on MinPlatformPkg everything works fine up until the BDS phase. To be more specific what's happening is that inside the BdsDxe module when the BdsEntry function calls the platform-dependent "PlatformBootManagerBeforeConsole" function (Inside MinPlatformPkg) and eventually the ExitPmAuth() function, the execution seems to get stuck on this part of the code: Handle = NULL; Status = gBS->InstallProtocolInterface ( &Handle, &gEfiDxeSmmReadyToLockProtocolGuid, EFI_NATIVE_INTERFACE, NULL ); I do not have a single clue why this is happening especially since it doesn't return and simply hangs. The only thing that would come to my mind would be that its dependencies aren't met which is not true in this case since other drivers also have this depex and get dispatched with no problem and if this was the case the module wouldn't even execute at the first place. Any ideas are extremely appreciated. Thanks, Memristor -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117879): https://edk2.groups.io/g/devel/message/117879 Mute This Topic: https://groups.io/mt/10635/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] ASSERT(FALSE) at the end of a void function "PciHostBridgeResourceConflict" from "MinPlatformPkg"
Hello everyone,
I was trying to get my platform running and since I used MinPlatformPkg as my
base platform I used the
Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.inf
for the library of the
MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf component. the thing
was that my platform would execute through PciEnumerator then
PciHostBridgeResourceAllocator then would get stuck when calling the
NotifyPhase (PciResAlloc, EfiPciHostBridgeAllocateResources); So I checked the
switch case routine looking for the EfiPciHostBridgeAllocateResources literal
and I realized the "PciHostBridgeResourceConflict" is as following:
VOID
EFIAPI
PciHostBridgeResourceConflict (
EFI_HANDLE HostBridgeHandle,
VOID *Configuration
)
{
EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor;
UINTN RootBridgeIndex;
DEBUG ((DEBUG_ERROR, "PciHostBridge: Resource conflict happens!\n"));
RootBridgeIndex = 0;
Descriptor = (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *) Configuration;
while (Descriptor->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR) {
DEBUG ((DEBUG_ERROR, "RootBridge[%d]:\n", RootBridgeIndex++));
for (; Descriptor->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR; Descriptor++) {
ASSERT (Descriptor->ResType <
sizeof (mPciHostBridgeLibAcpiAddressSpaceTypeStr) / sizeof
(mPciHostBridgeLibAcpiAddressSpaceTypeStr[0])
);
DEBUG ((DEBUG_ERROR, " %s: Length/Alignment = 0x%lx / 0x%lx\n",
mPciHostBridgeLibAcpiAddressSpaceTypeStr[Descriptor->ResType],
Descriptor->AddrLen, Descriptor->AddrRangeMax));
if (Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) {
DEBUG ((DEBUG_ERROR, " Granularity/SpecificFlag = %ld / %02x%s\n",
Descriptor->AddrSpaceGranularity, Descriptor->SpecificFlag,
((Descriptor->SpecificFlag &
EFI_ACPI_MEMORY_RESOURCE_SPECIFIC_FLAG_CACHEABLE_PREFETCHABLE) != 0) ? L"
(Prefetchable)" : L""
));
}
}
//
// Skip the END descriptor for root bridge
//
ASSERT (Descriptor->Desc == ACPI_END_TAG_DESCRIPTOR);
Descriptor = (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *)
((EFI_ACPI_END_TAG_DESCRIPTOR *) Descriptor + 1);
}
ASSERT (FALSE);}
So my question is what is going on with this line "ASSERT(FALSE)" must it stop
the platform from executing further? if so, why other libraries which define
this function don't have this line? I could simply comment it out but I would
rather get a sense of what's going on
Sent with [Proton Mail](https://proton.me/) secure email.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118097): https://edk2.groups.io/g/devel/message/118097
Mute This Topic: https://groups.io/mt/105670505/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [Question] What is the propose of BME DMA mitigation
Hello everyone, I was scrolling through the UEFI HII and encountered an option which i failed to find any proper explanation about it. Could you please explain point of mitigating DMA access for PCI.Thanks --- Forwarded Message --- From: memristor2 Date: On Tuesday, June 18th, 2024 at 4:56 PM Subject: [Question] What is the propose of BME DMA mitigation To: disc...@edk2.groups.io > Hello everyone, > I was scrolling through the UEFI HII and encountered an option which i failed > to find any proper explanation about it. > Could you please explain point of mitigating DMA access for PCI. > Thanks -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119629): https://edk2.groups.io/g/devel/message/119629 Mute This Topic: https://groups.io/mt/106756522/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Serial Debug not working in JunctionCity Whitley Platform
Hello everyone, I'm trying to get the serial debug working on my platform but I don't know why i can't see the debug logs. This is the library use3d for SerialPortLIb inside the platform's dsc: SerialPortLib|WhitleyPkg/Library/SerialPortLib/SerialPortLib.inf Also these are the values of the debug Pcds: gEfiMdePkgTokenSpaceGuid.PcdFixedDebugPrintErrorLevel|0x802A00C7 gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07 gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUEgEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2 I don't know why I cant see the debug logs. Even though I'm sure the SerialPortInitialize function and all of its subroutines (this path SerialPortLib|WhitleyPkg/Library/SerialPortLib/SerialPortLib.inf ) are getting executed. I suspected that the ast2500 configuration isn't right (inside InitializeSio) but I double-checked it with the datasheet and everything seemed aligned to it. This is getting frustrating since I need the debug for further development. Any help is highly appreciated. Memristor -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119730): https://edk2.groups.io/g/devel/message/119730 Mute This Topic: https://groups.io/mt/106956967/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Serial Debug not working in JunctionCity Whitley Platform
Any thoughts on this? On Sunday, June 30th, 2024 at 10:58 AM, memristor2 via groups.io wrote: > Hello everyone, > I'm trying to get the serial debug working on my platform but I don't know > why i can't see the debug logs. > This is the library use3d for SerialPortLIb inside the platform's dsc: > SerialPortLib|WhitleyPkg/Library/SerialPortLib/SerialPortLib.inf > Also these are the values of the debug Pcds: > gEfiMdePkgTokenSpaceGuid.PcdFixedDebugPrintErrorLevel|0x802A00C7 > gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F > > gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07 > gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUEgEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2 > I don't know why I cant see the debug logs. Even though I'm sure the > SerialPortInitialize function and all of its subroutines (this path > SerialPortLib|WhitleyPkg/Library/SerialPortLib/SerialPortLib.inf ) are > getting executed. I suspected that the ast2500 configuration isn't right > (inside InitializeSio) but I double-checked it with the datasheet and > everything seemed aligned to it. > This is getting frustrating since I need the debug for further development. > Any help is highly appreciated. > Memristor > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119997): https://edk2.groups.io/g/devel/message/119997 Mute This Topic: https://groups.io/mt/106956967/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Serial Debug not working in JunctionCity Whitley Platform
It seemed that the InitializeSio routine was incomplete and the AST2500 wasn't being programmed properly for serial logging. I have fixed this issue by completing the the SIO initialization. Sent with [Proton Mail](https://proton.me/) secure email. On Sunday, July 21st, 2024 at 12:01 PM, memristor2 wrote: > Any thoughts on this? > > On Sunday, June 30th, 2024 at 10:58 AM, memristor2 via groups.io > wrote: > >> Hello everyone, >> I'm trying to get the serial debug working on my platform but I don't know >> why i can't see the debug logs. >> This is the library use3d for SerialPortLIb inside the platform's dsc: >> SerialPortLib|WhitleyPkg/Library/SerialPortLib/SerialPortLib.inf >> Also these are the values of the debug Pcds: >> gEfiMdePkgTokenSpaceGuid.PcdFixedDebugPrintErrorLevel|0x802A00C7 >> gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F >> >> gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07 >> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUEgEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2 >> I don't know why I cant see the debug logs. Even though I'm sure the >> SerialPortInitialize function and all of its subroutines (this path >> SerialPortLib|WhitleyPkg/Library/SerialPortLib/SerialPortLib.inf ) are >> getting executed. I suspected that the ast2500 configuration isn't right >> (inside InitializeSio) but I double-checked it with the datasheet and >> everything seemed aligned to it. >> This is getting frustrating since I need the debug for further development. >> Any help is highly appreciated. >> Memristor >> >> -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120363): https://edk2.groups.io/g/devel/message/120363 Mute This Topic: https://groups.io/mt/106956967/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Redfishlib: How does it work?
Hello everyone, I am trying to develop Redfish on my platform. I got a few questions about the development process of Redfish. - Studying the libraries I see this RedfishLib which provides some API's but there isn't much specification on how to implement these APIs. My guess is I should start with the RedfishCreateService? But this needs a REDFISH_CONFIG_SERVICE_INFORMATION structure to have its RedfishServiceRestExHandle initialized. How is this going to work? My guess is by using OpenProtocol? - Since i was trying to use the provided Redfishlib I realized I need to call the RedfishConfigHandlerDriver driver to call a callback function whenever the gEdkIIRedfishConfigHandlerProtocolGuid gets installed and then execute the RedfishConfigHandlerInitialization and then I would have the gRedfishConfigData.RedfishServiceInfo filled out with the instance so I could eventually use this function RedfishCreateService (this is my assumption even though I highly doubt it would be correct). But the problem is that there are NO drivers installing the gEdkIIRedfishConfigHandlerProtocolGuid protocol. In fact the function registered to this protocol tries to locate it. What driver is going to install this protocol? I know the callback function gets called even if no driver installs the protocol but what is the point if there is no drivers installing that protocol? Thanks, Memristor Sent with [Proton Mail](https://proton.me/) secure email. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120365): https://edk2.groups.io/g/devel/message/120365 Mute This Topic: https://groups.io/mt/107978990/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Redfishlib: How does it work?
Hi Nickle, Didn't knew there was a separate repo on this matter. Thanks for the quick response, Ill dive into it. Sent with [Proton Mail](https://proton.me/) secure email. On Monday, August 19th, 2024 at 5:13 PM, Nickle Wang wrote: > 1. We are moving from RedfishLib to Redfish http protocol > (gEdkIIRedfishHttpProtocolGuid). I would recommend you to use Redfish http > protocol for Redfish communication. > > 2. Redfish config handler protocol is installed by Redfish application. It > will be called by RedfishConfigHandler driver when Redfish service is > discovered. Please check the example code here: > https://github.com/tianocore/edk2-redfish-client/blob/a09fd42735fb9f98915b1c7fa1a15d14c688d706/RedfishClientPkg/Features/Bios/v1_0_9/Dxe/BiosDxe.c#L783 > > And I hope the information here can help you understand how it works: > https://github.com/tianocore/edk2-redfish-client/tree/main/RedfishClientPkg#edk2-redfish-client-feature-driver > > Regards, > > Nickle > > From: devel@edk2.groups.io On Behalf Of memristor2 via > groups.io > Sent: Monday, August 19, 2024 8:05 PM > To: devel@edk2.groups.io > Subject: [edk2-devel] Redfishlib: How does it work? > > External email: Use caution opening links or attachments > > Hello everyone, > > I am trying to develop Redfish on my platform. I got a few questions about > the development process of Redfish. > > - Studying the libraries I see this RedfishLib which provides some API's but > there isn't much specification on how to implement these APIs. My guess is I > should start with the RedfishCreateService? But this needs a > REDFISH_CONFIG_SERVICE_INFORMATION structure to have its > RedfishServiceRestExHandle initialized. How is this going to work? My guess > is by using OpenProtocol? > - Since i was trying to use the provided Redfishlib I realized I need to > call the RedfishConfigHandlerDriver driver to call a callback function > whenever the gEdkIIRedfishConfigHandlerProtocolGuid gets installed and then > execute the RedfishConfigHandlerInitialization and then I would have the > gRedfishConfigData.RedfishServiceInfo filled out with the instance so I could > eventually use this function RedfishCreateService (this is my assumption even > though I highly doubt it would be correct). But the problem is that there are > NO drivers installing the gEdkIIRedfishConfigHandlerProtocolGuid protocol. In > fact the function registered to this protocol tries to locate it. What driver > is going to install this protocol? I know the callback function gets called > even if no driver installs the protocol but what is the point if there is no > drivers installing that protocol? > > Thanks, > > Memristor > > Sent with [Proton Mail](https://proton.me/) secure email. > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120374): https://edk2.groups.io/g/devel/message/120374 Mute This Topic: https://groups.io/mt/107978990/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] IpmiLib is a NULL instance
Hello, I was building the IpmifeaturePkg from the OutOfBandManagementPkg in edk2-platforms and saw the the components were not working in Run-time. I checkout out the instances in the edk2-platforms/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/IpmiFeature.dsc and realized that this instance was used for all modules using IpmiLib: IpmiLib|MdeModulePkg/Library/BaseIpmiLibNull/BaseIpmiLibNull.inf which meant all the the drivers using the IpmiSubmitCommand routine would simply calling a NULL routine. shouldn't it be like this?: [LibraryClasses.common.PEI_CORE,LibraryClasses.common.PEIM] ... IpmiLib|MdeModulePkg/Library/PeiIpmiLibIpmiPpi/PeiIpmiLibIpmiPpi.inf [LibraryClasses.common.DXE_DRIVER,LibraryClasses.common.UEFI_DRIVER] ... IpmiLib|MdeModulePkg/Library/DxeIpmiLibIpmiProtocol/DxeIpmiLibIpmiProtocol.inf [LibraryClasses.common.DXE_SMM_DRIVER] ... IpmiLib|MdeModulePkg/Library/SmmIpmiLibSmmIpmiProtocol/SmmIpmiLibSmmIpmiProtocol.inf Sent with [Proton Mail](https://proton.me/) secure email. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120401): https://edk2.groups.io/g/devel/message/120401 Mute This Topic: https://groups.io/mt/108071920/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 0/2] Ampere: Add BMC Configuration Screen
Hello, I looked into this driver and saw it was platform-independent. Why not add this into to the features directory? I wrote this driver from scratch and saw this patch later in my emails. it would facilitated my development if I saw it sooner if it were inside a directory that was platform-independent. Thanks, Memristor Sent with [Proton Mail](https://proton.me/) secure email. On Thursday, August 29th, 2024 at 10:46 AM, Nhi Pham via groups.io wrote: > Pushed as 9d8eda62..146cb5322498 > > Thanks, > Nhi > > --- > > From: devel@edk2.groups.io on behalf of Nhi Pham via > groups.io > Sent: Friday, August 23, 2024 9:51 AM > To: Chuong Tran OS ; devel@edk2.groups.io > > Cc: quic_llind...@quicinc.com ; Chuong Tran OS > ; Rebecca Cran OS > > Subject: Re: [edk2-devel] [PATCH 0/2] Ampere: Add BMC Configuration Screen > > Thanks for the review. I will push after the IPMI SSIF support is merged. > > -Nhi > > --- > > From: Chuong Tran OS > Sent: Thursday, August 22, 2024 3:22 PM > To: Nhi Pham OS ; devel@edk2.groups.io > > Cc: quic_llind...@quicinc.com ; Chuong Tran OS > ; Rebecca Cran OS > > Subject: Re: [PATCH 0/2] Ampere: Add BMC Configuration Screen > > Reviewed-by: Chuong Tran > > Thanks, > Chuong > > On 8/14/2024 10:18 AM, Nhi Pham wrote: >> This implements BMC Configuration Screen and supports on Ampere Mt. Jade >> platform. >> >> Nhi Pham (2): >> AmpereSiliconPkg: Implement BMC Configuration screen >> JadePkg: Add BmcConfigDxe >> >> Silicon/Ampere/AmpereSiliconPkg/AmpereSiliconPkg.dec | 8 +- >> Platform/Ampere/JadePkg/Jade.dsc | 1 + >> Platform/Ampere/JadePkg/Jade.fdf | 1 + >> Silicon/Ampere/AmpereSiliconPkg/Drivers/BmcConfigDxe/BmcConfigDxe.inf | 44 >> +++ >> Silicon/Ampere/AmpereSiliconPkg/Drivers/BmcConfigDxe/BmcConfigDxe.h | 35 +++ >> Silicon/Ampere/AmpereSiliconPkg/Include/Guid/BmcConfigHii.h | 19 ++ >> Silicon/Ampere/AmpereSiliconPkg/Drivers/BmcConfigDxe/BmcConfigVfr.vfr | 42 >> +++ >> Silicon/Ampere/AmpereSiliconPkg/Drivers/BmcConfigDxe/BmcConfigDxe.c | 326 >> >> Silicon/Ampere/AmpereSiliconPkg/Drivers/BmcConfigDxe/BmcConfigDxe.uni | 18 ++ >> 9 files changed, 493 insertions(+), 1 deletion(-) >> create mode 100644 >> Silicon/Ampere/AmpereSiliconPkg/Drivers/BmcConfigDxe/BmcConfigDxe.inf >> create mode 100644 >> Silicon/Ampere/AmpereSiliconPkg/Drivers/BmcConfigDxe/BmcConfigDxe.h >> create mode 100644 >> Silicon/Ampere/AmpereSiliconPkg/Include/Guid/BmcConfigHii.h >> create mode 100644 >> Silicon/Ampere/AmpereSiliconPkg/Drivers/BmcConfigDxe/BmcConfigVfr.vfr >> create mode 100644 >> Silicon/Ampere/AmpereSiliconPkg/Drivers/BmcConfigDxe/BmcConfigDxe.c >> create mode 100644 >> Silicon/Ampere/AmpereSiliconPkg/Drivers/BmcConfigDxe/BmcConfigDxe.uni >> >> -- >> 2.25.1 >> > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120460): https://edk2.groups.io/g/devel/message/120460 Mute This Topic: https://groups.io/mt/107889120/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] FSP-T gets stuck on postcode 0x4
Hello everyone, I am trying to build a UEFI image for BirchStream Platform, my problem is the boot execution doesn't go any further than the 0x04 POST code. Since i don't have access to the FSP's source code and there is no integration guide , I don't know what the problem is. Any hints on this is appreciated. I also should mention that this FSP works fine with the vendor's UEFI and exits TempRamInitExit perfectly fine since it shows the 0x7F post code. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120962): https://edk2.groups.io/g/devel/message/120962 Mute This Topic: https://groups.io/mt/110456457/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] FSP-T gets stuck on postcode 0x4
I should mention that I am using the IA32 MinPlatformPkg's PlatformSeclib (SecEntry.nasm) I also pass zero for the FsptUpdDataPtr paramter which is then passed to the TempRamInitApi. On Monday, January 6th, 2025 at 5:06 PM, memristor2 via groups.io wrote: > Hello everyone, > I am trying to build a UEFI image for BirchStream Platform, my problem is the > boot execution doesn't go any further than the 0x04 POST code. Since i don't > have access to the FSP's source code and there is no integration guide , I > don't know what the problem is. Any hints on this is appreciated. I also > should mention that this FSP works fine with the vendor's UEFI and exits > TempRamInitExit perfectly fine since it shows the 0x7F post code. > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120963): https://edk2.groups.io/g/devel/message/120963 Mute This Topic: https://groups.io/mt/110456457/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Execution of TempRamInitApi doesn't return.
So I figured this out and it was a microcode issue. I extracted another set of microcode mcbs for the target platform and added them to the FV, execution returned from TempInitRamApi. I was stuck on this since I didn't have any access to the FSP-T source code and there was no other debugging approaches in this phase. I suspected the issue would be caused by one of the following: - Fsp-T parameter's pointer being passed to the TempRamInitApi - the temporary RAM base wasn't correct - there would be a problem in the microcode I was using, since there wouldn't be any reason for the execution to not return if no.1 and 2 were the issues my suspicions made me focus on No. 3 since a buggy microcode would highly likely crash the processor. I must mention the first set of microcode mcbs used were meant for this platform but somehow they didn't work right. Turns out I guessed it right. On Monday, December 30th, 2024 at 5:11 PM, memristor2 via groups.io wrote: > Any thoughts on this? > even the smallest hints would be highly appreciated. > > Sent with [Proton Mail](https://proton.me/mail/home) secure email. > > On Tuesday, December 24th, 2024 at 6:12 PM, memristor2 via groups.io > wrote: > >> Hello everyone, >> I am trying to build an Intel platform's customized UEFI. >> I have extracted the microcode and FSP binaries from the vendors UEFI image >> successfully. I also changed the PlatformPkg and FspFlashOffset FDF files. >> Execution goes on fine up until the last line of this subroutine: >> >> FspHeaderFound: >> ; Get the fsp TempRamInit Api address >> mov eax, dword [edi + FSP_HEADER_IMAGEBASE_OFFSET] >> add eax, dword [edi + FSP_HEADER_TEMPRAMINIT_OFFSET] >> ; Setup the hardcode stack >> mov esp, TempRamInitStack >> ; Call the fsp TempRamInit Api jmp eax >> >> I have checked the address of TempRamInit Entry which matched the address >> inside the FSP header. >> but somehow it doesn't return to the TempRamInitDone subroutine. I have no >> idea why this happens. I also changed the UPD parameters to match the >> signature of the target platform. >> Any thoughts on this? > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120941): https://edk2.groups.io/g/devel/message/120941 Mute This Topic: https://groups.io/mt/110272463/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Execution of TempRamInitApi doesn't return.
Hello everyone, I am trying to build an Intel platform's customized UEFI. I have extracted the microcode and FSP binaries from the vendors UEFI image successfully. I also changed the PlatformPkg and FspFlashOffset FDF files. Execution goes on fine up until the last line of this subroutine: FspHeaderFound: ; Get the fsp TempRamInit Api address mov eax, dword [edi + FSP_HEADER_IMAGEBASE_OFFSET] add eax, dword [edi + FSP_HEADER_TEMPRAMINIT_OFFSET] ; Setup the hardcode stack mov esp, TempRamInitStack ; Call the fsp TempRamInit Api jmp eax I have checked the address of TempRamInit Entry which matched the address inside the FSP header. but somehow it doesn't return to the TempRamInitDone subroutine. I have no idea why this happens. I also changed the UPD parameters to match the signature of the target platform. Any thoughts on this? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120933): https://edk2.groups.io/g/devel/message/120933 Mute This Topic: https://groups.io/mt/110272463/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Generating FSP Bin File from .bsf File
Hello Kuldeep, FSP binaries are proprietary resources provided by Intel you can access them by signing a CNDA with Intel or by using the publicized FSP binaries in the Intel FSP's GitHub repo at gitHub.com/Intel/fsp. Have in mind not all Intel platforms have their FSPs publicized. Also the bsf files do not generate FSP binaries they are just a means for patching the FSP configuration regions inside those binaries. The IntelFsp2Pkg in the edk2 repo is just a sample package for the APIs used in the FSP binaries which has to be ported for each platform differently which also needs proprietary resources, about the silicon, provided by Intel. For further information please refer to the "Intel® Firmware Support Package External Architecture Specification" and "A Tour Beyond BIOS Using the Intel® Firmware Support Package" Sent with Proton Mail secure email. On Friday, December 27th, 2024 at 9:08 AM, Kuldeep Rana via groups.io wrote: > Hello! > > We are currently working on a project where we need to create an FSP > (Firmware Support Package) using EDK2. We have the corresponding .bsf > file, and we would like to know how to generate the FSP bin file from > it. Once the FSP bin is created, we intend to integrate it into our > project. > > Could you kindly provide guidance or references on how to generate the > FSP bin file from the .bsf file? If you need any additional > information from our side, please don't hesitate to ask. > > Thank you in advance for your help! > > > > Best Regards, > Kuldeep Singh Rana > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120936): https://edk2.groups.io/g/devel/message/120936 Mute This Topic: https://groups.io/mt/110301666/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Execution of TempRamInitApi doesn't return.
Any thoughts on this? even the smallest hints would be highly appreciated. Sent with [Proton Mail](https://proton.me/mail/home) secure email. On Tuesday, December 24th, 2024 at 6:12 PM, memristor2 via groups.io wrote: > Hello everyone, > I am trying to build an Intel platform's customized UEFI. > I have extracted the microcode and FSP binaries from the vendors UEFI image > successfully. I also changed the PlatformPkg and FspFlashOffset FDF files. > Execution goes on fine up until the last line of this subroutine: > > FspHeaderFound: > ; Get the fsp TempRamInit Api address > mov eax, dword [edi + FSP_HEADER_IMAGEBASE_OFFSET] > add eax, dword [edi + FSP_HEADER_TEMPRAMINIT_OFFSET] > ; Setup the hardcode stack > mov esp, TempRamInitStack > ; Call the fsp TempRamInit Api jmp eax > > I have checked the address of TempRamInit Entry which matched the address > inside the FSP header. > but somehow it doesn't return to the TempRamInitDone subroutine. I have no > idea why this happens. I also changed the UPD parameters to match the > signature of the target platform. > Any thoughts on this? > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120939): https://edk2.groups.io/g/devel/message/120939 Mute This Topic: https://groups.io/mt/110272463/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] UefiPayload hangs when grub tries to call OS
Hello Everyone, I have already asked this question but I am sending it again since I found more info on this matter. I have built coreboot with UEFIpayload and Universal Payload but either way grub can't load the OS. I the OS I am trying to boot is Ubuntu 24.02 and it shows the grub menu but hangs when linux kernel is tried to call. below is part of the log I got from the BIOS: FSOpen: Open '\efi\rufus\ntfs_x64.efi' Success [Security] 3rd party image[0] can be loaded after EndOfDxe: PciRoot(0x1F)/Pci(0x7,0x0)/Pci(0x0,0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/USB(0x1,0x0)/USB(0x1,0x0)/HD(2,MBR,0x1B2B42E0,0x39D17A5,0x81F)/\efi\rufus\ntfs_x64.efi. CcMeasurementProtocol is not installed. - Not Found Tcg2Protocol is not installed. - Not Found None of Tcg2Protocol/CcMeasurementProtocol is installed. InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 605533C0 Loading driver at 0x0006052F000 EntryPoint=0x0006054488B ntfs.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 60350218 ProtectUefiImageCommon - 0x605533C0 - 0x6052F000 - 0x00023180 [CoreStartImage], started - memristor. [CoreStartImage], ImageInfo loaded - memristor. [CoreStartImage], before preformance measurement - memristor. [CoreStartImage], After preformance measurement - memristor. [CoreStartImage], Before allocating pool - memristor. [CoreStartImage], Before Aligning pointer - memristor. [CoreStartImage], Before setting jump - memristor. [CoreStartImage], set jump is zero - memristor. [CoreStartImage], about to call image entry point - memristor. [FindVariableEx],started-memristor. [FindVariableEx],started-memristor. InstallProtocolInterface: F4ED18CA-CDFB-40CA-97EC-322A8B014E5F 60551FB0 InstallProtocolInterface: 18A031AB-B443-4D1A-A5C0-0C09261E9F71 60551D60 InstallProtocolInterface: 107A772C-D5E1-11D4-9A46-0090273FC14D 60551D10 InstallProtocolInterface: 6A7A5CFF-E8D9-4F70-BADA-75AB3025CE14 60551CE0 [CoreStartImage], image has returned - memristor. InstallProtocolInterface: 964E5B22-6459-11D2-8E39-00A0C969723B 605537A8 [Security] 3rd party image[0] can be loaded after EndOfDxe: PciRoot(0x1F)/Pci(0x7,0x0)/Pci(0x0,0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/USB(0x1,0x0)/USB(0x1,0x0)/HD(1,MBR,0x1B2B42E0,0x800,0x39D0F80)/\EFI\boot\bootx64.efi. CcMeasurementProtocol is not installed. - Not Found Tcg2Protocol is not installed. - Not Found None of Tcg2Protocol/CcMeasurementProtocol is installed. InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 6031E7C0 Loading driver at 0x0005FD48000 EntryPoint=0x0005FD6B000 InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 60312D18 ProtectUefiImageCommon - 0x6031E7C0 - 0x5FD48000 - 0x000D7000 ValidateSetVariable - Variable (605DAB50-E046-4300-ABB6-3DD810DD8B23:SbatLevel) returning Success. ValidateSetVariable - Variable (605DAB50-E046-4300-ABB6-3DD810DD8B23:MokListRT) returning Success. ValidateSetVariable - Variable (605DAB50-E046-4300-ABB6-3DD810DD8B23:MokListXRT) returning Success. ValidateSetVariable - Variable (605DAB50-E046-4300-ABB6-3DD810DD8B23:MokListTrustedRT) returning Success. MemoryAttributesTable: Version - 0x0002 NumberOfEntries - 0x0013 DescriptorSize - 0x0030 Entry (0x5FF0C6A8) Type - 0x5 PhysicalStart - 0x63253000 VirtualStart - 0x NumberOfPages - 0x00C8 Attribute - 0x8000 Entry (0x5FF0C6D8) Type - 0x5 PhysicalStart - 0x6331B000 VirtualStart - 0x NumberOfPages - 0x0001 Attribute - 0x80004000 Entry (0x5FF0C708) Type - 0x5 PhysicalStart - 0x6331C000 VirtualStart - 0x NumberOfPages - 0x0004 Attribute - 0x8002 Entry (0x5FF0C738) Type - 0x5 PhysicalStart - 0x6332 VirtualStart - 0x NumberOfPages - 0x0002 Attribute - 0x80004000 Entry (0x5FF0C768) Type - 0x5 PhysicalStart - 0x63322000 VirtualStart - 0x NumberOfPages - 0x0003 Attribute - 0x8002 Entry (0x5FF0C798) Type - 0x5 PhysicalStart - 0x63325000 VirtualStart - 0x NumberOfPages - 0x0003 Attribute - 0x80004000 Entry (0x5FF0C7C8) Type - 0x5 PhysicalStart - 0x63328000 VirtualStart - 0x NumberOfPages - 0x0002 Attribute - 0x8002 Entry (0x5FF0C7F8) Type - 0x5 PhysicalStart - 0x6332A000 VirtualStart - 0x NumberOfPages - 0x0002 Attribute - 0x80004000 Entry (0x5FF0C828) Type - 0x5 PhysicalStart - 0x6332C000 VirtualStart - 0x NumberOfPages - 0x0003 Attribute - 0x8002 Entry (0x5FF0C858) Type - 0x5 PhysicalStart - 0x6332F000 VirtualStart - 0x NumberOfPages - 0x0002 Attribute - 0x80004000 Entry (0x5FF0C888) Type - 0x5 PhysicalStart - 0x63331000 VirtualStart - 0x NumberOfPages - 0x000E Attri
