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

[Xiong Yi]

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

[Peter Stuge]

On Sat, Jun 23, 2007 at 03:40:58PM -0700, Xiong Yi wrote:
> 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.

I think we can benefit from providing (U)EFI what it wants. I say let
your (U)EFI loader payload prepare the HOB using the LB table.
> (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.

Right, either write a new efiboot that would replace elfboot,
or make an ELF wrapper for (U)EFI. I for one prefer the latter
solution just because that's how the other payloads work.
> Any feedbacks or suggestions are appreciated very much.

Nice to hear from you! Seems like you are making good progress! :)

//Peter