From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 7BCCD9415FE for ; Sat, 24 Feb 2024 13:31:02 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=UOSMVPssKMIf6eNU0MtX2INVBwjM0WMcHMtS2aFb0dg=; c=relaxed/simple; d=groups.io; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:Feedback-ID:MIME-Version:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1708781461; v=1; b=MmAWhmAoZFbuGuiCzCClBTq5ko/jT0DxomNJNxceKgQ4YUDF791WmDjE/NinAdcvEMhUu0rC odlhRkuRTUs72RXTMjKdSwA/OLkMnBG7TSg3qQT7bCtZRzH/8MuF2T+/9qzKQRf516CQcK0s7cu CEDBQxWbf9fu4x1Sxy6BZ6o4= X-Received: by 127.0.0.2 with SMTP id nPbEYY7687511xcnNGYx9SYd; Sat, 24 Feb 2024 05:31:01 -0800 X-Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by mx.groups.io with SMTP id smtpd.web11.18844.1708781459855344166 for ; Sat, 24 Feb 2024 05:31:00 -0800 Date: Sat, 24 Feb 2024 13:30:44 +0000 To: "Desimone, Nathaniel L" From: "memristor2 via groups.io" Cc: "devel@edk2.groups.io" , "lersek@redhat.com" Subject: Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform Message-ID: In-Reply-To: References: <0600b231-8baf-645a-a287-8d623f692bd8@redhat.com> Feedback-ID: 99609138:user:proton MIME-Version: 1.0 Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,memristor2@proton.me List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: wVwjzAclBZAVq0mgxtGqbdHfx7686176AA= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=MmAWhmAo; dmarc=pass (policy=none) header.from=groups.io; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io Sent with Proton Mail secure email. On Saturday, February 24th, 2024 at 12:15 AM, Desimone, Nathaniel L wrote: > > -----Original Message----- > > From: memristor2 memristor2@proton.me > > Sent: Thursday, February 22, 2024 5:51 AM > > To: Desimone, Nathaniel L nathaniel.l.desimone@intel.com > > Cc: devel@edk2.groups.io; lersek@redhat.com > > Subject: RE: [edk2-devel] Peims are not gettting Dispatched in EagleStr= eam > > Platform > >=20 > > Thank you. Based on what you told me (memory corruption and and the > > unlikelihood of the stack pointer being NULL) my only suspicion would b= e 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. >=20 >=20 > 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. >=20 > > 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 o= f the > > concept of the microcode so I thought maybe I could use Whitley's micro= code. >=20 >=20 > Here is what microcode is in a nutshell. Every x86 processor designed sin= ce > ~1990 is actually a RISC-based CPU design internally. The microcode conta= ins a > lookup table that maps each CPU instruction into one or more sub-instruct= ions > (sometimes called micro-instructions or micro-OPs (=C2=B5OPs for short)) = which are > the instructions that the hidden RISC processor executes. This hidden RIS= C > processor has an unpublished instruction set that no one outside of the C= PU > vendor sees. >=20 > The initial purpose of RISC was to eliminate the need for microcode, as t= he > 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 executi= on 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 provide= s a > programmable instruction scheduler. >=20 > 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 wo= uld 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 f= actors > came together at once, and suddenly any CPU design that didn't use microc= ode was > obsolete by the year 2000. >=20 > Fast forward to today, the RISC vs. CISC argument is obsolete. Modern > high-performance CPUs require very complex microcode. The existence of th= at > microcode abstracts most of the differences between traditionally RISC IS= As like > ARM and traditionally CISC ISAs like x86. Thank you I just learned as much as I learned in my Advanced Computer Archi= tecture course. Your explanations are higly appreciated. =20 >=20 > > But now that EagleStream's microcode has been released I'll try with th= at 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. Pleas= e > > correct me if I am wrong on this matter. >=20 >=20 > You intuition that it is not a microcode issue is correct. There are a lo= t of > things in the BoardPkg that change with each platform design. For an exam= ple 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 PeimDispatc= hReadiness() routine calls IsPpiInstalled() it seems it doesn't find the Pp= is and I don't have any idea why >=20 > > On Thursday, February 22nd, 2024 at 3:42 AM, Desimone, Nathaniel L > > nathaniel.l.desimone@intel.com wrote: > >=20 > > > > -----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; memristor2@proton.me > > > > Subject: Re: [edk2-devel] Peims are not gettting Dispatched in > > > > EagleStream Platform > > > >=20 > > > > On 2/21/24 07:59, memristor2 via groups.io wrote: > > > >=20 > > > > > 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 !=3D &EvalStack[0]) { > > > > >=20 > > > > > DEBUG ((DEBUG_DISPATCH, " RESULT =3D FALSE (Underflow Error)\n"))= ; > > > > > return FALSE; } > > > > >=20 > > > > > DEBUG ((DEBUG_DISPATCH, " RESULT =3D %a\n", IsPpiInstalled > > > > > (PeiServices, StackPtr) ? "TRUE" : "FALSE")); > > > > >=20 > > > > > return IsPpiInstalled (PeiServices, StackPtr); ``` It seems that > > > > > when entering IsPpiInstalled StackPtr in always NULL. > > > > > Any thoughts on this? > > > >=20 > > > > 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). > > > >=20 > > > > Now, I can see two potential problems here: > > > >=20 > > > > - your depex is malformed (for whatever reason), and the eval stack > > > > is not torn down entirely before reachig EFI_DEP_END. The code seem= s > > > > to handle that correctly, by returning FALSE. > > > >=20 > > > > - 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= . > > > >=20 > > > > A NULL StackPtr value I cannot explain at all. > > >=20 > > > 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-platform= s > > > right now. I would recommend you wait for us to release our code as > > > opposed > > >=20 > > > > Laszlo > > > >=20 > > > >=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115904): https://edk2.groups.io/g/devel/message/115904 Mute This Topic: https://groups.io/mt/104498510/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-