[LinuxBIOS] (U)EFI payload for LinuxBIOS based on TianoCore- Current Status Report of GSoC

Xiong Yi xiongyi04 at gmail.com
Sun Jun 24 00:40:58 CEST 2007


Hi, All.

 

I am figuring out and developing (U)EFI payload for LB referring to the
TianoCore(https://www.tianocore.org/), which is one of the GSoC
ideas(http://code.google.com/soc/coresystems/appinfo.html?csaid=83B941F46A42
2F1A ).

 

I feel it's necessary to make you know what I've got till now and also get
some suggestions and feedbacks from you.

 

(1)   The EDK project of TianoCore includes the full (U)EFI implementation
for NT32 emulation, which can be debugged and tracked using VC 7.0. This
would be my top reference.

 

(2)   The EDK implements EFI as the following phases orderly: SEC(security),
PEI(Pre EFI Initialization), DXE(Driver eXecution Environment), BDS(Boot
Device Selection). The BDS phase indicates the EFI has already been boot up
and shows the interfaces to users. Actually, The SEC and PEI phases are not
the EFI implementation; they just do the basic platform preparation (check
the system memory, IO space, Boot Mode etc.) for the EFI execution. And the
DXE is the pure EFI implementation. All information gathered in the SEC and
PEI is formed into HOB (Hand-Off
Block:http://download.intel.com/technology/framework/docs/Hob.pdf) data
structure, which is only parameter to the DXE phase. The DXE phase parses
the HOB list for EFI running preparation.

 

(3)   The LinuxBIOS collects resource and platform information to LB table;
that is similar to what the SEC and PEI do (collect resource information to
HOB list). Thus the DXE phase would be the start point of my EFI payload.
There are two alternative solutions for this purpose: Firstly to parse the
LB table and transform to HOB format; then the DXE gets the HOB list
transformed by LB table. Secondly: to parse LB table directly for DXE use
and discard the HOB data structure from EDK. The former can reuse the EDK
source codes to more extent; the latter can thin the (U)EFI payload more. I
have not determined which solution to choose. Maybe you can give me some
suggestions.

 

(4)   Another issue is about the binary image. The binary of EDK follows its
special specifications, including 

            Firmware
Volume(http://download.intel.com/technology/framework/docs/Fv.pdf), 

            Firmware Volume
Block(http://download.intel.com/technology/framework/docs/FvBlock.pdf) and

            Firmware File system
(http://download.intel.com/technology/framework/docs/Ffs.pdf). The EDK
provides the tools (open source) to build and 

            parse its binary image (flash) in its source codes package. 

 

(5)   The solution to load (U)EFI payload from LB is needed although I have
not got the clear idea for this. Generally speaking, I may develop the
special tools to transfer (U)EFI payload binary to ELF that the LB can load(
just like the Linux kernel payload loading), or add the feature of loading
(U)EFI binary to LB source codes.

 

I am focusing on (3) this time; and I plan to finish parsing LB table for
DXE phase(my payload) use, and porting EFI special features in the SEC and
PEI phases(such as EFI image load/unload, EFI compression/decompression
interfaces) to the payload(DXE phase) before the mid-check(July, 9th) of
GSoc. The solution to load (U)EFI payload from LB will be the main point
after mid-check.

 

Any feedbacks or suggestions are appreciated very much.

 

Thanks & Best regards,

Xiong Yi

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070623/174e93f0/attachment.html>


More information about the coreboot mailing list