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 82FD5D81164 for ; Thu, 29 Feb 2024 12:08:05 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=MAuDh2cl0nIn/1XX8Que2D5wiNB+EPDr24cnwQdDQ8A=; 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=1709208484; v=1; b=Ustv/cATZyADG2uf5PdecVBBLE3KNikQpg2QPxBLXA9P3p4C6JkmiNQ0Y2M86OmU+E9U3+vd b+Rhs7fW3kZEW1q/NoEgvnKcl6D/PKq4n7of/BfocWTER5yGcG2BQfc3v/y+wNOaSK9rQNEdm7e cb+ZfRcD0yfzM4Gb7ZikjU7A= X-Received: by 127.0.0.2 with SMTP id mLs6YY7687511xf2lT0LdJ43; Thu, 29 Feb 2024 04:08:04 -0800 X-Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by mx.groups.io with SMTP id smtpd.web10.23187.1709208482605738707 for ; Thu, 29 Feb 2024 04:08:03 -0800 Date: Thu, 29 Feb 2024 12:07:49 +0000 To: devel@edk2.groups.io From: "memristor2 via groups.io" Cc: "Desimone, Nathaniel L" , "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> <17B6CFAF57BD7756.3842@groups.io> 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: yaptFkiYcXper53tI8lsWpaqx7686176AA= 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="Ustv/cAT"; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=pass (policy=none) header.from=groups.io 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=20 Sent with Proton Mail secure email. On Saturday, February 24th, 2024 at 5:41 PM, memristor2 wrote: >=20 >=20 >=20 >=20 >=20 > Sent with Proton Mail secure email. >=20 >=20 > On Saturday, February 24th, 2024 at 5:00 PM, memristor2 via groups.io mem= ristor2=3Dproton.me@groups.io wrote: >=20 > > Sent with Proton Mail secure email. > >=20 > > On Saturday, February 24th, 2024 at 12:15 AM, Desimone, Nathaniel L nat= haniel.l.desimone@intel.com wrote: > >=20 > > > > -----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 Eagl= eStream > > > > 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 wou= ld be the > > > > microcode I am using, since the only platform dependent parts up un= til 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 > > > Having correct microcode is absolutely essential for sure. But microc= ode & 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 h= adn't been > > > > released yet). To be honest I still don't have a proper comprehensi= on of the > > > > concept of the microcode so I thought maybe I could use Whitley's m= icrocode. > > >=20 > > > Here is what microcode is in a nutshell. Every x86 processor designed= since > > > ~1990 is actually a RISC-based CPU design internally. The microcode c= ontains a > > > lookup table that maps each CPU instruction into one or more sub-inst= ructions > > > (sometimes called micro-instructions or micro-OPs (=C2=B5OPs for shor= t)) which are > > > the instructions that the hidden RISC processor executes. This hidden= RISC > > > processor has an unpublished instruction set that no one outside of t= he CPU > > > vendor sees. > > >=20 > > > 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 technol= ogy came > > > along called out-of-order execution. The idea behind out-of-order exe= cution is > > > that we can expand the purpose of microcode to be more than just a lo= okup 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 pro= vides a > > > programmable instruction scheduler. > > >=20 > > > The use of out-of-order execution was made possible by Moore's law. M= oore's law > > > drove rapidly increasing transistor counts during the 1990s. No longe= r 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 the= se factors > > > came together at once, and suddenly any CPU design that didn't use mi= crocode 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 o= f that > > > microcode abstracts most of the differences between traditionally RIS= C ISAs like > > > ARM and traditionally CISC ISAs like x86. > >=20 > > Thank you I just learned as much as I learned in my Advanced Computer A= rchitecture course. Your explanations are higly appreciated. > >=20 > > > > But now that EagleStream's microcode has been released I'll try wit= h that and > > > > let you know whether it works or not. Yet I am still skeptical abou= t it being > > > > a microcode issue because my thought is that the microcode is proco= sser > > > > architecture-based code rather than it being platform-based code. P= lease > > > > correct me if I am wrong on this matter. > > >=20 > > > 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. >=20 > I forgot to mention one thing. The microcode released for EagleStream has= two issues: > 1. It was "EaglestreamSiliconBinPkg" instead of "EagleStreamSiliconBinPkg= ". > 2. There was no .inf file defined for it > So I added the .INF file but as we both thought it didn't change the outc= ome, but I for sure could say each tick became shorter resulting in preform= ance improvement >=20 > > 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 thin= g is that all of the Peims are found inside the FV but whenever the PeimDis= patchReadiness() routine calls IsPpiInstalled() it seems it doesn't find th= e Ppis 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 La= szlo > > > > > > 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. I= f > > > > > > > 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 t= hat > > > > > > > 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 s= tack > > > > > > is not torn down entirely before reachig EFI_DEP_END. The code = seems > > > > > > 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 &EvalSta= ck[0]. > > > > > > That decrement invokes undefined behavior. However, I assume in > > > > > > practice the behavior will be the same as in the previous parag= raph. > > > > > >=20 > > > > > > A NULL StackPtr value I cannot explain at all. > > > > >=20 > > > > > Agreed with Laszlo here... the only thing that I could think of i= s > > > > > memory corruption. Several people at Intel (myself included) as > > > > > working on getting an EaglestreamOpenBoardPkg posted to edk2-plat= forms > > > > > 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 (#116162): https://edk2.groups.io/g/devel/message/116162 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-