Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upRelocate FVs to claim extra space from ME region. #26
Comments
|
Le 31/05/2018 à 11:42, persmule a écrit :
With me_cleaner, a lot of ROM space (several MiB) could be freed from
ME region and potentially used by BIOS region instead.
Is it possible to relocate FVs (especially the DXE FV) inside the
enlarged BIOS region to claim these space? And if possible, how to do
that?
I have investigated a lot about the build process of EDK2, only to
find there should be an FDF to record all the FVs' offset and size,
but failed to find how the FDF is built to binary and stored in the
resulted FD image.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#26>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABhW6b5qkF8uNl-f5QNBDBuXNU1Mp2tLks5t37rvgaJpZM4UUvHe>.
We did work on such exercise for a specific project. I don't think we
did publish the results yet, but it might be coming up soon. We wanted
to do the same thing than you did propose, but have faced strong issues,
where a lot of hardcoded address space (or offset) are standing into the
PEI and DXE code (PEI is not rellocatable, DXE is supposed to be).
So we decided to adopt a different strategy, as our rellocated image was
not working. We created a new FV which is using the empty space, and
added it to the Flash volume descriptor, without success (roughly the
original AMI BIOS was not mounting it and DXECore was not loading the
DXE drivers we were pushing into it).
Tram Hudson, wrote to address that case a special DXE driver which is
super small and can mostly fit into any current DXE FV. That DXE Driver
is called FvLoader, and is "mounting" our newly created Fv giving the
possibility to use the extra space.
I know this approach is a workaround but it has proven to be successfull
on at least one system, it is quite pretty. If you want to use the extra
space to make fit a big unitary blob, that approach won't work, but if
your intend is to add a couple of DXE drivers it could be suitable.
Just let us know !
vejmarie
|
|
@vejmarie Thank you very much, but I have a bit more questions:
|
|
Hi,
SeC Core ends most of the time by a jump into DXECore, and unfortunatly
or most of the time the jump is a direct address within memory space
(aka 4GB - xxxx) which is computed based on a physical offset into the
flash. So SeC Core is probably not using FD but all of this is
assumption made from reverse engineering
So roughly the answer to 0 is Yes if my assumption is good PEI must know
where DXE FV stands as to handover to DXECore.
Answer to 1, is probably more tricky. I don't think that PEI is knowing
anything regarding the FD, but I might be totally wrong. PCH is mapping
the flash, and chips boostrap on the vector contained into PEI area (4GB
- 16 if I am not wrong). FD first usage is probably at DXE level.
From what I learnt, I suspect that most of the stuff is "hard coded" or
deducted at compilation time.
vejmarie
Le 31/05/2018 à 13:43, persmule a écrit :
…
@vejmarie <https://github.com/vejmarie> Thank you very much, but I
have a bit more questions:
0. Does PEI already know where DXE FV should be when its own FV are
generated, or the FV layout is corrected when constructing FD?
1. Does FV layout used by PEI and/or DXE initially come from FDF? If
so, how is the layout coded into PEI and/or DXE modules? e.g. via
auto-generated source files containing global variables?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABhW6YIiHZvkFRrawdcgVeGvBEJ3v1nIks5t39d8gaJpZM4UUvHe>.
|
|
Jean-Marie is correct (with one minor correction -- I'm working on replacing the Linux BDS patch with a separate DXE module that does the minimum BDS stuff, as well as allowing us to add in new firmware volumes, remap the SPI flash as necessary and retrieve kernel command line parameters from the UEFI nvram store. https://github.com/osresearch/linuxboot/blob/bds/dxe/linuxboot.c |
|
I polished that work in here : #40 |
With me_cleaner, a lot of ROM space (several MiB) could be freed from ME region and potentially used by BIOS region instead.
Is it possible to relocate FVs (especially the DXE FV) inside the enlarged BIOS region to claim these space? And if possible, how to do that?
I have investigated a lot about the build process of EDK2, only to find there should be an FDF to record all the FVs' offset and size, but failed to find how the FDF is built to binary and stored in the resulted FD image.