From: "Benjamin Doron via groups.io" <benjamin.doron00=gmail.com@groups.io>
To: devel@edk2.groups.io
Cc: Guo Dong <guo.dong@intel.com>,
Sean Rhodes <sean@starlabs.systems>,
James Lu <james.lu@intel.com>,
linus.liu@intel.com, Gua Guo <gua.guo@intel.com>
Subject: [edk2-devel] UPL: UefiPayload depends on FIT FDT, but Platform Init has no reason to load it
Date: Mon, 9 Dec 2024 22:28:00 -0500 [thread overview]
Message-ID: <CAONYkK-HRxPcegMFBv4FJ-Zbq7ptPnvgncY0avAxLZyUrS4+UA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]
Hi,
In
https://github.com/tianocore/edk2/blob/a0ac7cf/UefiPayloadPkg/UefiPayloadEntry/FitUniversalPayloadEntry.c#L220,
UefiPayload parses its own UPL FIT's FDT to determine where the other FVs
can be found (if you follow the references backwards, you'll see that
gUniversalPayloadBaseGuid HOBs come from `upl-images@<addr>`. I don't love
this design, but the alternative is to have Platform Init copy in the
`images` node from the FIT FDT to the UPL FDT, which may not be any better.
The problem is that currently, Platform Init needs to have hardcoded logic
to load the entire .FIT file to where the entrypoint image points. See
below:
FDT dump of UPL FIT:
images {
tianocore {
description = "Uefi Universal Payload";
project = "tianocore";
arch = "x86";
type = "flat-binary";
producer = "intel";
data-offset = <0x00001000>;
data-size = <0x00016000>;
reloc-start = <0x00012000>;
entry-start = <0x00000000 0x00807c98>;
load = <0x00000000 0x00800000>;
};
// more images here
};
UefiPayloadPkg/UniversalPayloadBuild.py:
RunCommand (
"GenFw --rebase 0x{:02X} -o {} {} ".format (
fit_image_info_header.LoadAddr +
fit_image_info_header.DataOffset,
TargetRebaseFile,
TargetRebaseFile,
))
So, the entrypoint is supposed to be located 0x800000 + 0x1000, not
0x800000. The first 0x1000 is the FDT, but a Platform Init simply complying
with the FIT spec does not know that. We would have this problem in
coreboot.
To fix this issue, I propose we emit another 'image' into the FIT's FDT,
called "upl-fit-fdt". Then, we can shift the entrypoint's load value back
where it should be (0x1000 greater than it is now), and platform init will
copy it without needing hardcoded logic.
(I'm aware that a patch would be needed somewhere in UefiPayload - I
believe FitUniversalPayloadEntry but it might be FitParserLib - to make
sure that this image or this classification of images are not turned into
FV HOBs inside EDK2)
What do you think?
Best regards,
Benjamin
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120887): https://edk2.groups.io/g/devel/message/120887
Mute This Topic: https://groups.io/mt/110019777/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
[-- Attachment #2: Type: text/html, Size: 3722 bytes --]
next reply other threads:[~2024-12-10 3:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 3:28 Benjamin Doron via groups.io [this message]
2024-12-10 5:42 ` [edk2-devel] UPL: UefiPayload depends on FIT FDT, but Platform Init has no reason to load it Linus Liu via groups.io
2024-12-11 2:38 ` Linus Liu via groups.io
2024-12-11 5:57 ` Benjamin Doron via groups.io
2024-12-11 6:17 ` Chiu, Chasel via groups.io
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAONYkK-HRxPcegMFBv4FJ-Zbq7ptPnvgncY0avAxLZyUrS4+UA@mail.gmail.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox