date:20241210

Re: [edk2-devel] UPL: UefiPayload depends on FIT FDT, but Platform Init has no reason to load it

2024-12-10 Thread Linus Liu via groups.io

Hi Benjamin
May I know what the problem in coreboot is?

Thanks

From: Liu, Linus
Sent: Tuesday, December 10, 2024 1:42 PM
To: Benjamin Doron ; devel@edk2.groups.io
Cc: Dong, Guo ; Rhodes, Sean ; Lu, 
James ; Guo, Gua ; Chiu, Chasel 

Subject: RE: UPL: UefiPayload depends on FIT FDT, but Platform Init has no 
reason to load it

Add Chasel.

From: Benjamin Doron 
mailto:benjamin.doro...@gmail.com>>
Sent: Tuesday, December 10, 2024 11:28 AM
To: devel@edk2.groups.io
Cc: Dong, Guo mailto:guo.d...@intel.com>>; Rhodes, Sean 
mailto:sean@starlabs.systems>>; Lu, James 
mailto:james...@intel.com>>; Liu, Linus 
mailto:linus@intel.com>>; Guo, Gua 
mailto:gua@intel.com>>
Subject: UPL: UefiPayload depends on FIT FDT, but Platform Init has no reason 
to load it

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@`. 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 = <0x1000>;
data-size = <0x00016000>;
reloc-start = <0x00012000>;
entry-start = <0x 0x00807c98>;
load = <0x 0x0080>;
};
// 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 0x80 + 0x1000, not 0x80. 
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 (#120893): https://edk2.groups.io/g/devel/message/120893
Mute This Topic: https://groups.io/mt/110019777/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Wednesday, December 11, 2024 #cal-cancelled

2024-12-10 Thread Group Notification

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCEL
REFRESH-INTERVAL;VALUE=DURATION:PT1H
X-PUBLISHED-TTL:PT1H
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
LAST-MODIFIED:20240422T053451Z
TZURL:https://www.tzurl.org/zoneinfo-outlook/America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Event:2493294 
UID:mlda.1580078539586725120.r...@groups.io
DTSTAMP:20241211T004251Z
ORGANIZER;CN=Liming Gao;SENT-BY="mailto:gaolim...@byosoft.com.cn":mailto:
 gaolim...@byosoft.com.cn
DTSTART:20241212T013000Z
DTEND:20241212T023000Z
SUMMARY:TianoCore Bug Triage - APAC / NAMO
DESCRIPTION:TianoCore Bug Triage - APAC / NAMO\n\nHosted by Liming Gao\n\
 n
 \n\nMicrosoft Teams meeting\n\n*Join on your computer or mobile a
 pp*\n\nClick here to join the meeting ( https://teams.microsoft.com/l/mee
 tup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40
 thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255
 d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d )\n\n*Jo
 in with a video conferencing device*\n\nte...@conf.intel.com\n\nVideo Con
 ference ID: 116 062 094 0\n\nAlternate VTC dialing instructions ( https:/
 /conf.intel.com/teams/?conf=1160620940&ivr=teams&d=conf.intel.com&test=te
 st_call )\n\n*Or call in (audio only)*\n\n+1 916-245-6934\,\,77463821# ( 
 tel:+19162456934\,\,77463821# ) United States\, Sacramento\n\nPhone Confe
 rence ID: 774 638 21#\n\nFind a local number ( https://dialin.teams.micro
 soft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821 ) | Reset PIN (
  https://mysettings.lync.com/pstnconferencing )\n\nLearn More ( https://a
 ka.ms/JoinTeamsMeeting ) | Meeting options ( https://teams.microsoft.com/
 meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e&tenantId
 =46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTUyZTg2NjgtNDh
 lNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2&messageId=0&language=en-US )
LOCATION:https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN
 2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%2
 2%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-
 1242-431b-9a51-92cd01a5df3c%22%7d
SEQUENCE:1
STATUS:CANCELLED
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] UPL: UefiPayload depends on FIT FDT, but Platform Init has no reason to load it

2024-12-10 Thread Benjamin Doron via groups.io

Ah, coreboot wants to load the images individually. And if you check the PE 
image base and entrypoint, there's a mismatch of 0x1000, so loading the 
tianocore image to where the "load" property says it should go won't work. In 
my email, you can see that the module is rebased to 8M + 4K, but "load" is set 
to 8M.

I've fixed this issue now, see 
https://github.com/tianocore/edk2/pull/6382/commits/90b718c9ba43100ff4dc045d4806683942934d8d.
 This will keep working for EDK2-based Platform Init, and allow us to support 
coreboot too.

The current plan, as discussed in the UPL meeting today, is to implement 
support for "/options/upl-images@/image" as defined in the spec in EDK2, 
which will tell us where the FVs are without parsing the FIT header. I've 
implemented and tested that on coreboot, and I'll push that patch in the 
morning.

Best regards,
Benjamin

On December 10, 2024 9:38:28 p.m. EST, "Liu, Linus"  wrote:
>Hi Benjamin
>May I know what the problem in coreboot is?
>
>Thanks
>
>
>From: Liu, Linus
>Sent: Tuesday, December 10, 2024 1:42 PM
>To: Benjamin Doron ; devel@edk2.groups.io
>Cc: Dong, Guo ; Rhodes, Sean ; Lu, 
>James ; Guo, Gua ; Chiu, Chasel 
>
>Subject: RE: UPL: UefiPayload depends on FIT FDT, but Platform Init has no 
>reason to load it
>
>Add Chasel.
>
>
>From: Benjamin Doron 
>mailto:benjamin.doro...@gmail.com>>
>Sent: Tuesday, December 10, 2024 11:28 AM
>To: devel@edk2.groups.io
>Cc: Dong, Guo mailto:guo.d...@intel.com>>; Rhodes, Sean 
>mailto:sean@starlabs.systems>>; Lu, James 
>mailto:james...@intel.com>>; Liu, Linus 
>mailto:linus@intel.com>>; Guo, Gua 
>mailto:gua@intel.com>>
>Subject: UPL: UefiPayload depends on FIT FDT, but Platform Init has no reason 
>to load it
>
>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@`. 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 = <0x1000>;
>data-size = <0x00016000>;
>reloc-start = <0x00012000>;
>entry-start = <0x 0x00807c98>;
>load = <0x 0x0080>;
>};
>// 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 0x80 + 0x1000, not 0x80. 
>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 (#120894): https://edk2.groups.io/g/devel/message/120894
Mute This Topic: https://groups.io/mt/110019777/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] UPL: UefiPayload depends on FIT FDT, but Platform Init has no reason to load it

2024-12-10 Thread Chiu, Chasel via groups.io


Hi Benjamin,

Thanks for clarifying and fixing the implementation issues. It might be good to 
split single huge PR into small PRs so we could merge some of the small fixes 
without blocking by other bigger changes. Like this load base address fix, we 
can merge it once we verified the edk2 use case still working. What do you 
think?

Thanks,
Chasel


From: Benjamin Doron 
Sent: Tuesday, December 10, 2024 9:58 PM
To: Liu, Linus ; devel@edk2.groups.io
Cc: Dong, Guo ; Rhodes, Sean ; Lu, 
James ; Guo, Gua ; Chiu, Chasel 

Subject: RE: UPL: UefiPayload depends on FIT FDT, but Platform Init has no 
reason to load it

Ah, coreboot wants to load the images individually. And if you check the PE 
image base and entrypoint, there's a mismatch of 0x1000, so loading the 
tianocore image to where the "load" property says it should go won't work. In 
my email, you can see that the module is rebased to 8M + 4K, but "load" is set 
to 8M.

I've fixed this issue now, see 
https://github.com/tianocore/edk2/pull/6382/commits/90b718c9ba43100ff4dc045d4806683942934d8d.
 This will keep working for EDK2-based Platform Init, and allow us to support 
coreboot too.

The current plan, as discussed in the UPL meeting today, is to implement 
support for "/options/upl-images@/image" as defined in the spec in EDK2, 
which will tell us where the FVs are without parsing the FIT header. I've 
implemented and tested that on coreboot, and I'll push that patch in the 
morning.

Best regards,
Benjamin

On December 10, 2024 9:38:28 p.m. EST, "Liu, Linus" 
mailto:linus@intel.com>> wrote:
Hi Benjamin
May I know what the problem in coreboot is?

Thanks


From: Liu, Linus
Sent: Tuesday, December 10, 2024 1:42 PM
To: Benjamin Doron 
mailto:benjamin.doro...@gmail.com>>; 
devel@edk2.groups.io
Cc: Dong, Guo mailto:guo.d...@intel.com>>; Rhodes, Sean 
mailto:sean@starlabs.systems>>; Lu, James 
mailto:james...@intel.com>>; Guo, Gua 
mailto:gua@intel.com>>; Chiu, Chasel 
mailto:chasel.c...@intel.com>>
Subject: RE: UPL: UefiPayload depends on FIT FDT, but Platform Init has no 
reason to load it

Add Chasel.


From: Benjamin Doron 
mailto:benjamin.doro...@gmail.com>>
Sent: Tuesday, December 10, 2024 11:28 AM
To: devel@edk2.groups.io
Cc: Dong, Guo mailto:guo.d...@intel.com>>; Rhodes, Sean 
mailto:sean@starlabs.systems>>; Lu, James 
mailto:james...@intel.com>>; Liu, Linus 
mailto:linus@intel.com>>; Guo, Gua 
mailto:gua@intel.com>>
Subject: UPL: UefiPayload depends on FIT FDT, but Platform Init has no reason 
to load it

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@`. 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 = <0x1000>;
data-size = <0x00016000>;
reloc-start = <0x00012000>;
entry-start = <0x 0x00807c98>;
load = <0x 0x0080>;
};
// 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 0x80 + 0x1000, not 0x80. 
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 (#120895): https://edk2.groups.io/g/devel/message/120895
Mute This Topic: https://groups.io/mt/110019777/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.grou

[edk2-devel] Static IP for PXE/HTTP boot

2024-12-10 Thread Mike Beaton via groups.io

I spotted that OVMF completely ignores the configured IPv4 static IP
settings, for PXE and HTTP boot, and just uses DHCP anyway. (Confirmed
on various versions from edk2-stable201905 to current master.)

When looking at the user-readable paths for PXE and HTTP boot options,
it seems likely that this is indeed the intended behaviour:

PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)

PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri()

Furthermore, PXE 2.1 spec (e.g. §2.2.1) gives no indication PXE boot
is supposed to work with static IP, and while it is less clear it
seems somewhat similar for HTTP boot in UEFI specification (e.g. v2.10
§24.7.4).

Hence to my questions, if anyone has time to answer:

1. Is it correct that the static IP settings available in OVMF are
intended to be ignored for PXE and HTTP boot?

2. Is there any (documented?) way to set a static IP for PXE or HTTP
boot? (With HTTP boot, in particular, we can already set the boot URI
in the path, so if we could set the IPv4 addr/mask/gateway/dns then we
could boot without DHCP.)

3. If it's not too general to ask, what types of application are the
IP settings intended for, if not PXE/HTTP boot? Just other IP-based
applications, in general, I guess?

Thanks in advance for any help!


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120891): https://edk2.groups.io/g/devel/message/120891
Mute This Topic: https://groups.io/mt/110033368/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] UPL: UefiPayload depends on FIT FDT, but Platform Init has no reason to load it

[edk2-devel] Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Wednesday, December 11, 2024 #cal-cancelled

Re: [edk2-devel] UPL: UefiPayload depends on FIT FDT, but Platform Init has no reason to load it

Re: [edk2-devel] UPL: UefiPayload depends on FIT FDT, but Platform Init has no reason to load it

[edk2-devel] Static IP for PXE/HTTP boot

5 matches

Site Navigation

Mail list logo

Footer information