RE: [EDK DEV] I have this chicken, see, and this egg.

Subject: RE: [EDK DEV] I have this chicken, see, and this egg.

From: "Tian, Hot" <>

To: <>

Date: 2008-07-04 19:59:47

I think your solution is OK. Usually we should firstly link PeiMain and =
all PEIMs. Then use a tool to rebase these drivers for them to be run =
directly on ROM. The most important thing for PEI phase is to discover =
and prepare the memory for DXE phase. In PEI phase, when memory is =
ready, we can shadow some PEIMs into memory. The DxeIpl gPeiServices is =
only writable when DxeIpl is shadowed into memory:
      // The DxeIpl has been shadowed
      gPeiServices =3D PeiServices;
And if we add good dependency for some PEIMs to be dispatched after =
memory discovery, these drivers will be relocated to memory and executed =
in memory by PI PEI core (Edk\Foundation\Core\PiPei\Image). You can also =
compress these drivers for size reduction.


The content of this message is my personal opinion only and although I =
am an employee of Intel, the statements I make here in no way represent =
Intel's position on the issue, nor am I authorized to speak on behalf of =
Intel on this matter.

-----Original Message-----
From: Randy Thelen []=20
Sent: 2008=C4=EA7=D4=C24=C8=D5 3:14
Subject: [EDK DEV] I have this chicken, see, and this egg.

Folks --

On the one hand, I want a simple SEC phase.  And, I've accomplished =20
that.  I took the PeiMain code and linked its address into the ROM at =20
the address where it will be when PEI runs out of ROM.  The issue =20
here, in case you've missed my previous comments and questions on the =20
subject, is that PeiMain (along with all of the PeiModules) use global =20
variables for things like GUIDs and those addresses have to be =20
resolved (i.e., linked) so that the code can properly function.

OK, that's great.  I solved this problem by pre-linking my PeiMain and =20
various modules directly into my ROM.  I wrote Rebase.c and fixed bugs =20
in PeCoffRelocate() and things are mostly happy.

On the other hand, I had assumed that PeiMain and various modules did =20
NOT have any writable global variables.  Why is this important?  I'm =20
glad you asked.  Because the code is linked into an address in ROM, =20
there is no writable memory associated with the module.

However, DxeIpl contains a global variable.  And, it appears to be =20
important: gPeiServices.

I could solve this by including into the SEC phase a link/loader to =20
load and then link PeiMain.  Then, I could teach PeiMain to link/load =20
each of the modules.  But that is at once a lot of work and apparently =20
inconsistent with the current design.  Maybe I could just do the =20
latter, i.e., have PeiMain link/load PEI Modules.  But, why am -I- =20
bumping into this?  Am I the only one with this issue?

I therefore ask you, dear reader: What am I to do to resolve the issue =20
of linking and loading PeiMain and modules in order to create a =20
runtime environment for the PEI code?  The Nt32 code sample doesn't =20
help resolve this dilemma.  In fact, it completely skirts it by using =20
a link loader in the SEC phase.  Is that the only solution?

-- Randy

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail: