Date   

Re: Redfish Host Interface

Russell Peterson
 

Thanks for the response Laszlo and Abner. Very much appreciated.

Do I understand correctly that if I have a BMC with the proper schema for my system UEFI, when the system boots it (UEFI) will fetch data from the BMC via the Redfish host interface and that data would in effect, "take priority" over the data stored in the UPVS? I mean not only for boot order but also any other configuration data?

I assume UEFI has some type of discovery mechanism and authentication mechanism to find and use the BMC Redfish data. From what I have read this seems to be the case.

--Russ

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Abner Chang via groups.io
Sent: Sunday, March 14, 2021 9:24 PM
To: Laszlo Ersek <lersek@redhat.com>; Russell Peterson <russell@nvidia.com>
Cc: discuss@edk2.groups.io; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>
Subject: Re: [edk2-discuss] Redfish Host Interface



-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Saturday, March 13, 2021 6:11 AM
To: russell@nvidia.com
Cc: discuss@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
<abner.chang@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>
Subject: Re: [edk2-discuss] Redfish Host Interface

Hi Russell,

On 03/11/21 22:02, Russell Peterson wrote:
Hello,

I am interested in a UEFI Redfish Host Interface that does not require an OS.
Redfish Host Interface is built for OS to communicate with Redfish service on either BMC or out-of-band service (I donโ€™t see this use case yet). UEFI use case is similar to how OS communicates with Redfish service through Redfish HI.

That is, the Redfish service would be provided by UEFI itself (via an
IP interface)... or perhaps an EFI application.
This is interesting , however you will need edk2 web server and the implementation of Redfish service on edk2 as well. Not sure how this use case works for OS <-> in-band Redfish service on edk2. Or you just would like to build up an stand along Redfish service on edk2 and other Redfish clients can connect to it?

For example, if a BMC wanted to access EFI variables directly from
UEFI via
an IP interface with no functional OS present.
Redfish HI just provides the Redfish information to Redfish clients, the majority users are OS and firmware. Client sends the request to service for the property through HTTP. Rare use cases that service asks client for something on its own initiative, Redfish event service is one of the service-to-client action however client has to registers even first.
So BMC accesses to EFI variable through Redfish HI seems to me not an use case of generic Redfish services.


Is this crazy for me to think this? Already exists? Under
development? An
idea... but I would need to do some work?

At least the following TianoCore bugzilla
<https://bugzilla.tianocore.org/> tickets relate to RedFish, one way
or
another:
Laszlo, thanks for providing below information.
Abner

2337
2906
2910
2911
2912
2913
2918
2919
2930
2931
2932
2933
2934
2936
3102
3173
3174

At least the following USWG Mantis tickets relate to RedFish:

0001221
0001834
0001853
0001920
0001925
0001935
0001941
0002000
0002009
0002172

In UEFI v2.8B, there is a chapter called "31 - EFI Redfish Service Support".

A top-level RedfishPkg exists in edk2, and it seems like EmulatorPkg
has received some enablement. Not sure about the state in
edk2-platforms (or in other out-of-tree platforms).

Adding Abner and Nickle to the CC list (per "Maintainers.txt");
hopefully they can summarize the status for you.

Thanks
Laszlo


Re: Redfish Host Interface

Abner Chang
 

-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Saturday, March 13, 2021 6:11 AM
To: russell@nvidia.com
Cc: discuss@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
<abner.chang@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>
Subject: Re: [edk2-discuss] Redfish Host Interface

Hi Russell,

On 03/11/21 22:02, Russell Peterson wrote:
Hello,

I am interested in a UEFI Redfish Host Interface that does not require an OS.
Redfish Host Interface is built for OS to communicate with Redfish service on either BMC or out-of-band service (I donโ€™t see this use case yet). UEFI use case is similar to how OS communicates with Redfish service through Redfish HI.

That is, the Redfish service would be provided by UEFI itself (via an IP
interface)... or perhaps an EFI application.
This is interesting , however you will need edk2 web server and the implementation of Redfish service on edk2 as well. Not sure how this use case works for OS <-> in-band Redfish service on edk2. Or you just would like to build up an stand along Redfish service on edk2 and other Redfish clients can connect to it?

For example, if a BMC wanted to access EFI variables directly from UEFI via
an IP interface with no functional OS present.
Redfish HI just provides the Redfish information to Redfish clients, the majority users are OS and firmware. Client sends the request to service for the property through HTTP. Rare use cases that service asks client for something on its own initiative, Redfish event service is one of the service-to-client action however client has to registers even first.
So BMC accesses to EFI variable through Redfish HI seems to me not an use case of generic Redfish services.


Is this crazy for me to think this? Already exists? Under development? An
idea... but I would need to do some work?

At least the following TianoCore bugzilla <https://bugzilla.tianocore.org/>
tickets relate to RedFish, one way or
another:
Laszlo, thanks for providing below information.
Abner

2337
2906
2910
2911
2912
2913
2918
2919
2930
2931
2932
2933
2934
2936
3102
3173
3174

At least the following USWG Mantis tickets relate to RedFish:

0001221
0001834
0001853
0001920
0001925
0001935
0001941
0002000
0002009
0002172

In UEFI v2.8B, there is a chapter called "31 - EFI Redfish Service Support".

A top-level RedfishPkg exists in edk2, and it seems like EmulatorPkg has
received some enablement. Not sure about the state in edk2-platforms (or
in other out-of-tree platforms).

Adding Abner and Nickle to the CC list (per "Maintainers.txt"); hopefully they
can summarize the status for you.

Thanks
Laszlo


Re: Google Summer of Code Interested Student

Nate DeSimone
 

Hi Laszlo,

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Laszlo Ersek
Sent: Friday, March 12, 2021 10:51 AM
To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>;
cadenkline9@gmail.com
Cc: discuss@edk2.groups.io; devel@edk2.groups.io
Subject: Re: [edk2-discuss] Google Summer of Code Interested Student

As far as I can remember, the terminal type has always been hard-coded in
OVMF like this -- I believe it's not a regression (old or recent). I guess I
haven't seen a good PlatformBootManagerLib example on this topic.
Yeah specifically on the topic of properly setting the terminal type, I don't think I've seen a completely correct implementation of PlatformBootManagerLib either. Agreed it is probably not a regression, but I still think it would be a great contribution to get this sorted out properly.


Thanks
Laszlo





Re: Google Summer of Code Interested Student

Nate DeSimone
 

I've created a new wiki page for this task with all the information I have gathered thus far. I've done some more experimentation and found that there are several newer terminal emulators that don't support DEC Special Graphics so I've reduced the number of modes where DEC Special Graphics should be preferred. Laszlo, if you could take a look at the terminal type matrix I created that would be very helpful.

https://github.com/tianocore/tianocore.github.io/wiki/Tasks-Terminal-driver-improvements

Thanks,
Nate

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Nate
DeSimone
Sent: Thursday, March 11, 2021 9:46 PM
To: cadenkline9@gmail.com
Cc: Laszlo Ersek <lersek@redhat.com>; discuss@edk2.groups.io;
devel@edk2.groups.io
Subject: Re: [edk2-discuss] Google Summer of Code Interested Student

Hi Caden,

Great to meet you and welcome to the TianoCore project! Glad you hear you
are interested! Sorry it has taken me a while to get back to you, researching
the topics you are interested in ended up being somewhat involved ๐Ÿ˜Š.

I went back and did some investigation of current state of the terminal
driver, and some of the work has already been done. However, there are
some things missing and some odd bugs that need attention. To give you a
little more detail, the Terminal driver is located at
https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Universal
/Console/TerminalDxe

The most prevalent use case for the terminal driver is to display the BIOS
setup menu on headless server systems using a PC style serial port
connected to a laptop via null modem. This allows administrators to adjust
BIOS settings on rack mounted systems without needing to connect a
monitor and keyboard.

Historically, the BIOS setup menu would be rendered using the IBM PC VGA
text mode, which encoded text using code page 437 (CP437). This was
important for box-drawing characters, such as โ”Œ , โ”€ , and โ” , which VGA text
mode encodes as 0xDA, 0xC4, and 0xBF respectively. However, most
terminal emulators assume text to be encoded in UTF-8. Unicode defines
these box drawing characters as 0x250C, 0x2500, and 0x2510. In UTF-8
encoding, these characters translate into 3 byte sequences of (0xE2, 0x94,
0x8C), (0xE2, 0x94, 0x80), and (0xE2, 0x94, 0x90) respectively. The VGA
encodings of these box characters will end up generating errors if one
attempts to decode them as strict UTF-8, though most terminals assume that
the intended characters to be drawn are รš, ร„, and ยฟ, which have the Unicode
character codes 0xDA, 0xC4, and 0xBF. The end result is the BIOS setup menu
looks like this:

รšร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„
ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ยฟ
ยณ Device Manager ยณ
ร€ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„
ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร™

Devices List List all the Driver
> Driver Health Manager Health instances to
> RAM Disk Configuration manage
> OVMF Platform Configuration
> iSCSI Configuration
> Network Device List


Press ESC to exit.


รšร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„
ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ยฟ
ยณ ยณ
ยณ ^v=Move Highlight <Enter>=Select Entry Esc=Exit ยณ
ร€ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„
ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร™

Instead of like this:

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ Device Manager โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Devices List List all the Driver
> Driver Health Manager Health instances to
> RAM Disk Configuration manage
> OVMF Platform Configuration
> iSCSI Configuration
> Network Device List


Press ESC to exit.


โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ โ”‚
โ”‚ ^v=Move Highlight <Enter>=Select Entry Esc=Exit โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

The terminal driver has fully supported both the legacy CP437 encoding and
the UTF-8 encoding for more than 10 years now. Which mode to use is part
of the configuration settings given to the terminal driver at start up.
However, those configuration settings need to come from somewhere. For
example, OVMF has the following page in its setup menu for configuring the
serial terminal:

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ Set COM Attributes โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Set COM Baud Rate <115200> Set COM Baud Rate
Set COM Data Bits <8>
Set COM Parity <None>
Set COM Stop Bits <One>
Set COM Terminal Type <PC_ANSI>
Set COM Flow Control <None>

Commit Changes and Exit
Discard Changes and Exit


โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ F9=Reset to Defaults F10=Save โ”‚
โ”‚ ^v=Move Highlight <Enter>=Select Entry Esc=Exit โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

The default terminal type is PC_ANSI, which uses CP437. In this day and age
that is probably not the right default anymore, though one could argue
whether PC_ANSI being the default is a "bug". Here is the list of supported
terminal types:

- PC_ANSI
- VT_100
- VT_100_PLUS
- VT_UTF8
- TTY_TERM
- LINUX
- XTERM_R6
- VT_400
- SCO

Now, here is the first unquestionable bug. All of these terminal types except
for VT_UTF8 output the box drawing characters using CP437. The VT-100 did
not use CP437 for box drawing characters. On the VT-100, the terminal driver
should output the escape sequence "ESC ( 0" to switch the character set
from ASCII to "DEC Special Graphics". Then, while in DEC Special Graphics
mode, โ”Œ , โ”€ , and โ” , are encoded as 0x6C, 0x71, and 0x6B respectively. After
outputting the box drawing characters, the terminal driver should switch
back to ASCII using the escape sequence "ESC ( B". Implementing this will
introduce the interesting problem of optimizing display performance by
limiting the number of character mode switches.

For all the modes listed above, the VT-100 method should be used for
drawing box characters (and other characters in the DEC special graphics
character set) with the exception of PC_ANSI and VT_UTF8, which should
use CP437 and UTF-8 respectively. In general, DEC special graphics has been
around for such a long time that all terminal emulators support it, so it should
be the preferred method of outputting characters outside the initial 0-127
basic ASCII codes, with UTF-8 as a fallback if the character can't be encoded
by either basic ASCII or DEC special graphics. The difference between
VT_UTF8 and the other modes is that DEC special graphics should never be
used. PC_ANSI mode should never use DEC special graphics either.

Now, here is the second bug. That BIOS setup menu page that OVMF has for
configuring the serial port has a field for setting the terminal type. But,
changing the value in that field doesn't actually change the configuration data
that is sent to the terminal driver. So the terminal driver always ends up using
PC_ANSI mode even if the user changes that setting. This isnโ€™t a bug in the
terminal driver really, itโ€™s a bug in OVMF's setup menu implementation. But it
does create the appearance of a problem in the terminal driver and should
be fixed as part of this GSoC project. This should be fixed in both he OVMF
implementation and the MinPlatform implementation.

I'm not sure if the terminal driver improvements would absorb the entire 10
week coding window. If you had time left, you could consider spending it
writing unit tests.

Looking at your experience, it seems like you have more experience with
Python coding than with C coding. Both the terminal driver improvements
and unit tests would be written in C. Another option you could consider is we
have a lot of Python code in TianoCore as well. The two major pieces of
Python code are BaseTools and EdkRepo. BaseTools provides the build
system for TianoCore and implements the logic necessary to compile a BIOS
ROM file from source. EdkRepo is the multi-repository tool for EDK II.
EdkRepo automates common developer workflows for projects that use
more than one git repository (many TianoCore projects do). We would gladly
accept project proposals for either BaseTools or EdkRepo. If either of those
interest you I can point you to some places where they can be improved and
give you some project ideas.

The most important outcome from GSoC in our view is that our students
learn something, get some exposure, and have a great experience that they
will remember fondly for years to come. We want you to be successful.
Gauge your comfort level and pick a project that you feel you can achieve in
the 10 week period. Sorry for the long email, but I hope it helps. Finally I'd
like to reiterate... Welcome to the project!

With Best Regards,
Nate

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Wednesday, March 10, 2021 8:17 AM
To: discuss@edk2.groups.io
Cc: cadenkline9@gmail.com; Desimone, Nathaniel L
<nathaniel.l.desimone@intel.com>
Subject: Re: [edk2-discuss] Google Summer of Code Interested Student

adding Nate

On 03/10/21 03:10, mailto:cadenkline9@gmail.com wrote:
Hello, My name is Caden Kline. I am a freshmen Computer Science major in
the US. I intend to specialize in Systems or Security or both. The main two
tasks I am hoping to apply for are "Terminal driver improvements" and
"Writing Unit Tests". However, I am primarily interested in any system level
work and willing to work on anything. I am concerned about the difficulty in
completing these tasks so I'm going to list my experience.

My relevant experience for C programming language is a one semester
introduction to C and Unix class I am currently taking. Outside of formal
experience, I have primarily interacted with C and assembly with capture the
flag/wargame binary exploitation challenges, and unfinished projects such as
a chip8 emulator. My primary programming experience is Java and Python
thanks to my high school and college classes. I have participated in several
past google code-ins. My github profile is https://github.com/Pokemod97 .

Is there anything I can do to improve my chances to be selected or any
other feedback? Thank you for taking the time to read this message.








Re: Redfish Host Interface

Laszlo Ersek
 

Hi Russell,

On 03/11/21 22:02, Russell Peterson wrote:
Hello,

I am interested in a UEFI Redfish Host Interface that does not require an OS. That is, the Redfish service would be provided by UEFI itself (via an IP interface)... or perhaps an EFI application.
For example, if a BMC wanted to access EFI variables directly from UEFI via an IP interface with no functional OS present.

Is this crazy for me to think this? Already exists? Under development? An idea... but I would need to do some work?
At least the following TianoCore bugzilla
<https://bugzilla.tianocore.org/> tickets relate to RedFish, one way or
another:

2337
2906
2910
2911
2912
2913
2918
2919
2930
2931
2932
2933
2934
2936
3102
3173
3174

At least the following USWG Mantis tickets relate to RedFish:

0001221
0001834
0001853
0001920
0001925
0001935
0001941
0002000
0002009
0002172

In UEFI v2.8B, there is a chapter called "31 - EFI Redfish Service Support".

A top-level RedfishPkg exists in edk2, and it seems like EmulatorPkg has
received some enablement. Not sure about the state in edk2-platforms (or
in other out-of-tree platforms).

Adding Abner and Nickle to the CC list (per "Maintainers.txt");
hopefully they can summarize the status for you.

Thanks
Laszlo


Redfish Host Interface

Russell Peterson
 

Hello,

I am interested in a UEFI Redfish Host Interface that does not require an OS. That is, the Redfish service would be provided by UEFI itself (via an IP interface)... or perhaps an EFI application.
For example, if a BMC wanted to access EFI variables directly from UEFI via an IP interface with no functional OS present.

Is this crazy for me to think this? Already exists? Under development? An idea... but I would need to do some work?

Any advice much appreciated.

Regards,

Russell


Re: Google Summer of Code Interested Student

Laszlo Ersek
 

On 03/12/21 06:45, Desimone, Nathaniel L wrote:

Now, here is the second bug. That BIOS setup menu page that OVMF has
for configuring the serial port has a field for setting the terminal
type. But, changing the value in that field doesn't actually change
the configuration data that is sent to the terminal driver. So the
terminal driver always ends up using PC_ANSI mode even if the user
changes that setting. This isnโ€™t a bug in the terminal driver really,
itโ€™s a bug in OVMF's setup menu implementation. But it does create
the appearance of a problem in the terminal driver and should be
fixed as part of this GSoC project. This should be fixed in both he
OVMF implementation and the MinPlatform implementation.
It's a shortcoming of OVMF's PlatformBootManagerLib.

A solution would be nice where, if a (non-volatile) terminal type
setting existed, that would take effect, but if no such setting existed,
then we'd still automatically add the serial port(s) -- with some
default terminal type -- to the console I/O variables.

ArmVirtQemu's PlatformBootManagerLib works somewhat differently (see the
build-time feature test macro TTY_TERMINAL). I'm not up-to-date on
whether that PlatformBootManagerLib instance handles the Setup TUI-based
terminal type setting correctly.

As far as I can remember, the terminal type has always been hard-coded
in OVMF like this -- I believe it's not a regression (old or recent). I
guess I haven't seen a good PlatformBootManagerLib example on this topic.

Thanks
Laszlo


Re: [EXTERNAL] Re: [edk2-discuss] ๅ›žๅค: [edk2-discuss] edk2 build error

Bret Barkelew
 

Apologies. I was out of the office yesterday.

My guess is that you have multiple installs that may be confusing the โ€œvswhereโ€ utility. As such, you may have correctly configured your Buildtools 2019 install, but vswhere is finding an incorrectly configured install.

Itโ€™s hard to test this theory via email. Our team has a Discord server set up for UEFI and EDK2 community conversations. It would be easier for things like screenshare and quick back and forth. Any interest in joining me there? Iโ€™ll be on all day today (3/12) in case you want to drop by.
https://discord.gg/qy6CcUrr

- Bret

From: Mohammad Younas Khan Pathan <pmdyounaskhan786@gmail.com>
Sent: Friday, March 12, 2021 10:33:10 AM
To: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: discuss@edk2.groups.io <discuss@edk2.groups.io>; Sean Brogan <spbrogan@outlook.com>; Feng, Bob C <bob.c.feng@intel.com>; alexgdi@outlook.com <alexgdi@outlook.com>
Subject: Re: [EXTERNAL] Re: [edk2-discuss] ๅ›žๅค: [edk2-discuss] edk2 build error

Hi Bret & others,
Do you have any comments on this??

On Wed, Mar 10, 2021, 12:20 PM Mohammad Younas Khan Pathan <pmdyounaskhan786@gmail.com<mailto:pmdyounaskhan786@gmail.com>> wrote:
Hi Bret,
I have installed using vs_buildtools.exe cmd in shared link (https://microsoft.github.io/mu/CodeDevelopment/prerequisites/#visual-studio-2019-preferred<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23visual-studio-2019-preferred&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C66cd35ea9ef043a8df6708d8e585514e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637511708056659265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MSzF3lw6zstn9MTpXZxs37Z639ACa2xlkgRKswhlsU4%3D&reserved=0>)

Still I am facing the same build error:
ERROR - We were not able to find on the keys requested from vcvarsall.
ERROR - We didn't find: ['WINDOWSSDKVERSION', 'WINDOWSSDKDIR', 'UNIVERSALCRTSDKDIR', 'EXTENSIONSDKDIR', 'WINDOWSLIBPATH', 'WINDOWSSDKVERBINPATH', 'VCTOOLSINSTALLDIR', 'PATH', 'WINDOWSSDKBINPATH']

Then I tried to manually set these env vars as follows, but still I am getting the same build errors.

set WINDOWSSDKVERSION=10.0.17763.0
set WINDOWSSDKDIR=C:\Program Files (x86)\Windows Kits\10\
set EXTENSIONSDKDIR=C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\
set WINDOWSLIBPATH=References\CommonConfiguration\Neutral\
set WINDOWSSDKVERBINPATH=C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\
set VCTOOLSINSTALLDIR=C:\BuildTools\VC\Tools\MSVC\14.28.29910\
set WINDOWSSDKBINPATH=C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\
set UCRTVERSION=10.0.17763.0
set PATH=%Path%

The build errors are due to paths in environment vars are not set appropriately.
Is there any other way to set these variables? or can you share your reference variables, so that I can set and check?

Thank you,
Younas.

On Mon, 8 Mar 2021 at 21:48, Bret Barkelew <Bret.Barkelew@microsoft.com<mailto:Bret.Barkelew@microsoft.com>> wrote:

Updated (below)โ€ฆ



- Bret



From: Bret Barkelew via groups.io<mailto:bret.barkelew=microsoft.com@groups.io>
Sent: Monday, March 8, 2021 8:09 AM
To: Mohammad Younas Khan Pathan<mailto:pmdyounaskhan786@gmail.com>
Cc: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>; Sean Brogan<mailto:spbrogan@outlook.com>; Feng, Bob C<mailto:bob.c.feng@intel.com>; alexgdi@outlook.com<mailto:alexgdi@outlook.com>
Subject: Re: [EXTERNAL] Re: [edk2-discuss] ๅ›žๅค: [edk2-discuss] edk2 build error



Younas,

Can you try making sure that you have all the following subcomponents of VS Buildtools installed:
Microsoft.VisualStudio.Component.VC.CoreBuildTools
Microsoft.VisualStudio.Component.VC.Tools.x86.x64
Microsoft.VisualStudio.Component.Windows10SDK.17763

While this isnโ€™t official EDK2 documentation, this is our (MSCoreUEFI) recommended way to install buildtools:
Tools and Prerequisite - Project Mu (microsoft.github.io<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmicrosoft.github.io%2F&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C66cd35ea9ef043a8df6708d8e585514e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637511708056659265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=371ScXPitDC0gmVWwE9teb6mxsm2FcCfD6mdEtnPXwo%3D&reserved=0>)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23visual-studio-2019-preferred&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743119026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=X1E2BLWjvErQpq6nRbI8BbSuqbrjjmZ9tJX3btyrxmg%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23visual-studio-2019-preferred&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C66cd35ea9ef043a8df6708d8e585514e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637511708056669219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cKaDMQ29la12bc0jhJ3jE363HJoyivTlO54Bg%2B4Yf98%3D&reserved=0>>

- Bret

From: Mohammad Younas Khan Pathan<mailto:pmdyounaskhan786@gmail.com>
Sent: Sunday, March 7, 2021 11:30 PM
To: Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
Cc: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io><mailto:discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>>; Sean Brogan<mailto:spbrogan@outlook.com>; Feng, Bob C<mailto:bob.c.feng@intel.com>; alexgdi@outlook.com<mailto:alexgdi@outlook.com><mailto:alexgdi@outlook.com>
Subject: Re: [EXTERNAL] Re: [edk2-discuss] ๅ›žๅค: [edk2-discuss] edk2 build error

Bret,
I selected default install from VS buildtools from below link:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvisualstudio.microsoft.com%2Fdownloads%2F%23build-tools-for-visual-studio-2019&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743119026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=cPCr9rYcre5fxpAM6YTcWuKQPiPuoY9eMArye5B0q20%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvisualstudio.microsoft.com%2Fdownloads%2F%23build-tools-for-visual-studio-2019&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743119026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=cPCr9rYcre5fxpAM6YTcWuKQPiPuoY9eMArye5B0q20%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvisualstudio.microsoft.com%2Fdownloads%2F%23build-tools-for-visual-studio-2019&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C66cd35ea9ef043a8df6708d8e585514e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637511708056669219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vTTe5mX7UI3GRsovr5OUtsPVUaV8Cops3mChmqlECxM%3D&reserved=0>>

Please find the log:
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build>vcvarsall.bat AMD64
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.9.0
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build>

Thank you,
Younas.

On Fri, 5 Mar 2021 at 22:52, Bret Barkelew <Bret.Barkelew@microsoft.com<mailto:Bret.Barkelew@microsoft.com><mailto:Bret.Barkelew@microsoft.com<mailto:Bret.Barkelew@microsoft.com>>> wrote:
Can you send the output of:
โ€œC:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvarsall.bat AMD64โ€

When you installed VS2019, did you select any additional packages or just a default install?

- Bret

From: Mohammad Younas Khan Pathan via groups.io<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroups.io%2F&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C66cd35ea9ef043a8df6708d8e585514e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637511708056679174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DPyQJFxaEKOL0yBalEjhHgqOfM7yHAbEhPgh1DHsgJ4%3D&reserved=0><mailto:pmdyounaskhan786=gmail.com@groups.io>
Sent: Thursday, March 4, 2021 10:16 PM
To: Sean Brogan<mailto:spbrogan@outlook.com>
Cc: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io><mailto:discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>>; Feng, Bob C<mailto:bob.c.feng@intel.com>; alexgdi@outlook.com<mailto:alexgdi@outlook.com><mailto:alexgdi@outlook.com>
Subject: [EXTERNAL] Re: [edk2-discuss] ๅ›žๅค: [edk2-discuss] edk2 build error

Hi Bret/others,
I have installed WinSDK & VS2019 in my system.
Please find the attached build log for building EmulatorPkg.
And help me out on this.

Thank you,
Younas.

On Fri, 5 Mar 2021 at 09:49, Sean Brogan <spbrogan@outlook.com<mailto:spbrogan@outlook.com><mailto:spbrogan@outlook.com<mailto:spbrogan@outlook.com>>> wrote:

EmulatorPkg on Windows is a Windows application and thus you need all
the tools/libs to support building a windows application.

I would suggest making sure you have VS2019 and WinSdk as listed here:


https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23visual-studio-2019-preferred&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743119026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=X1E2BLWjvErQpq6nRbI8BbSuqbrjjmZ9tJX3btyrxmg%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23visual-studio-2019-preferred&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=deUr%2BQCYJ4srUuHZJGbovx8tion%2FqUrBk75UtYGNyBw%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23visual-studio-2019-preferred&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C66cd35ea9ef043a8df6708d8e585514e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637511708056679174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ra%2BLlALTa6ndPsJNviW9yBPBlITmNTM9rzEtyHL%2Fgx0%3D&reserved=0>>


https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23optional-windows-driver-kit&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6%2BOIGR0lcVz0z%2F1ykiHOwZuSEGPylHf2kex8PECZcsk%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23optional-windows-driver-kit&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6%2BOIGR0lcVz0z%2F1ykiHOwZuSEGPylHf2kex8PECZcsk%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23optional-windows-driver-kit&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C66cd35ea9ef043a8df6708d8e585514e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637511708056689133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ApfFP0XnrlyNPRBflB2e4woS22dzFKJ6aVgTTjNXaY4%3D&reserved=0>>

Thanks
Sean


On 3/4/2021 6:23 AM, Mohammad Younas Khan Pathan wrote:
The mu_nasm dependency issue is resolved with below cmd:

stuart_update -c .pytool/CISettings.py


I am facing another error if I try stuart_build (for EmulatorPkg) or
running BaseTools/Edk2ToolsBuild.py for VS2019:

*ERROR - We were not able to find on the keys requested from vcvarsall.*
* ValueError: Missing keys when querying vcvarsall:
['WINDOWSSDKVERSION',
'WINDOWSSDKBINPATH', 'UNIVERSALCRTSDKDIR', 'WINDOWSLIBPATH', 'PATH',
'VCTOOLSINSTALLDIR', 'EXTENSIONSDKDIR', 'UCRTVERSION',
'WINDOWSSDKVERBINPATH', 'WINDOWSSDKDIR']*

Do we need to do any setup for these variables?

Thank you,
Younas.

On Thu, 4 Mar 2021 at 19:24, Feng, Bob C <bob.c.feng@intel.com<mailto:bob.c.feng@intel.com><mailto:bob.c.feng@intel.com<mailto:bob.c.feng@intel.com>>> wrote:

OvmfPkg\Platform\ReadMe.md describes the instruction of using Pytools to
build OvmfPkg in details. Those instruction can also apply to
EmulatorPkg
Build.

This command is to init and update the edk2 submodules
stuart_setup -c OvmfPkg/PlatformCI/PlatformBuild.py
TOOL_CHAIN_TAG=<TOOL_CHAIN_TAG> -a <TARGET_ARCH>

This command is to install the nasm and iasl
stuart_update -c OvmfPkg/PlatformCI/PlatformBuild.py
TOOL_CHAIN_TAG=<TOOL_CHAIN_TAG> -a <TARGET_ARCH>

This command is to build BaseTools C tools and set the necessary
environment variable
python BaseTools/Edk2ToolsBuild.py -t <ToolChainTag>

This command is to OvmfPkg
stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py -a IA32
TOOL_CHAIN_TAG=<TOOL_CHAIN_TAG>


Thanks,
Bob

-----Original Message-----
From: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io><mailto:discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>> <discuss@edk2.groups.io<mailto:discuss@edk2.groups.io><mailto:discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>>> On Behalf Of
Mohammad Younas Khan Pathan
Sent: Thursday, March 4, 2021 7:07 PM
To: alexgdi@outlook.com<mailto:alexgdi@outlook.com><mailto:alexgdi@outlook.com>
Cc: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io><mailto:discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>>
Subject: Re: [edk2-discuss] ๅ›žๅค: [edk2-discuss] edk2 build error

Alex,
I tried that cmd, but it gives below error: NASM is installed and kept
with NASM_PREFIX env variable.

ERROR - Dependency 'mu_nasm' is not met!
Traceback (most recent call last):
File "c:\python\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "c:\python\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Python\Scripts\stuart_build.exe\__main__.py", line 7, in
<module>
File

"c:\python\lib\site-packages\edk2toolext\invocables\edk2_platform_build.py",
line 113, in main
Edk2PlatformBuild().Invoke()
File
"c:\python\lib\site-packages\edk2toolext\base_abstract_invocable.py",
line
122, in Invoke
raise RuntimeError("SDE is not current. Please update your env
before
running this tool.")
RuntimeError: SDE is not current. Please update your env before running
this tool.

Have you got any errors like this?

Thank you,
Younas.

On Thu, 4 Mar 2021 at 16:06, <alexgdi@outlook.com<mailto:alexgdi@outlook.com><mailto:alexgdi@outlook.com<mailto:alexgdi@outlook.com>>> wrote:

On Thu, Mar 4, 2021 at 02:27 AM, Mohammad Younas Khan Pathan wrote:


cmd: python BaseTools/Edk2ToolsBuild.py -t <ToolChainTag> #
ToolChainTag
It is not necessary to compile BaseTools. If you want to build
EmulatorPkg try this instruction
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FEmulatorPkg%2FPlatformCI%2FR&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2FeHjU8zhs%2B7xV0uHb4mwHGasM89rkHicgiNqojwll9s%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FEmulatorPkg%2FPlatformCI%2FR&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2FeHjU8zhs%2B7xV0uHb4mwHGasM89rkHicgiNqojwll9s%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FEmulatorPkg%2FPlatformCI%2FR&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C66cd35ea9ef043a8df6708d8e585514e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637511708056699090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=53C30DsAjs1YWIjLjW6ptfOF6rUffBzAKBne2qwF8jA%3D&reserved=0>>
eadMe.md
and use MSVC 2019 compiler

for example

stuart_build -c EmulatorPkg/PlatformCI/PlatformBuild.py
TOOL_CHAIN_TAG=VS2019 -a X64

...












Re: ๅ›žๅค: Non-reproducible binaries generated by GenFw

Laszlo Ersek
 

On 03/11/21 20:37, Ross Burton wrote:
On Thu, 11 Mar 2021 at 17:30, Laszlo Ersek <lersek@redhat.com> wrote:
Ross -- can you please confirm? Does Liming's suggestion work for you?
If I manually call GenFw with -z then it does in fact work. Proof via
diffoscope:

https://try.diffoscope.org/takcczugyxzr.html

I'm failing at making this actually stick in the makefiles though...
Can you provide your platform DSC file?

What is your exact "build" command line? (I'm looking for the "-a",
"-b", "-t" options.)

Thanks
Laszlo


Re: ๅ›žๅค: [edk2-discuss] ๅ›žๅค: Non-reproducible binaries generated by GenFw

Laszlo Ersek
 

On 03/12/21 06:31, gaoliming wrote:
Laszlo:
I verify the below three commands. The first generated EFI image includes DEBUG entry. Other EFI images have no DEBUG entry. Yes, DEBUG entry is added by GenFw tool. -z option can be used to remove it.

GenFw -e PEI_CORE -o test.efi PeiCore.dll
GenFw -e PEI_CORE -o test2.efi -z PeiCore.dll
GenFw -e PEI_CORE -o test3.efi --zero PeiCore.dll
Thanks, I must have messed up my testing then.

... Does it matter if we add "--zero" directly after "GenFw", as very
first option? Probably not. I'll update the BZ (state that my testing
was wrong).

Thanks
Laszlo




Thanks
Liming
-----้‚ฎไปถๅŽŸไปถ-----
ๅ‘ไปถไบบ: discuss@edk2.groups.io <discuss@edk2.groups.io> ไปฃ่กจ Laszlo
Ersek
ๅ‘้€ๆ—ถ้—ด: 2021ๅนด3ๆœˆ12ๆ—ฅ 1:30
ๆ”ถไปถไบบ: discuss@edk2.groups.io; gaoliming@byosoft.com.cn; 'Ross Burton'
<ross@burtonini.com>
ๆŠ„้€: bob.c.feng@intel.com; yuwei.chen@intel.com
ไธป้ข˜: Re: [edk2-discuss] ๅ›žๅค: Non-reproducible binaries generated by
GenFw

Hi Liming,

On 03/11/21 05:44, gaoliming wrote:
Ross:
I verify -z option. It can remove DEBUG entry and make sure the
generated image be reproduced.

I tried the "--zero" option myself (as seen in the BZ), but it didn't
work. What I did was the following: in the original run of the "build"
utility, I redirected the standard output and the standard error to a
log file. Then, I located the "GenFw" invocation that produced the
"Shell.efi" binary from the "Shell.dll" file. I also checked that the
"Shell.dll" file did not contain the full pathname, embedded -- so it
was GenFw that embedded the full file path indeed.

Then, I re-run the GenFw utility myself, interactively, and added the
"--zero" flag to the command line. The output did not change,
"Shell.efi" still contained the full pathname embedded. I also couldn't
find a spot in the GenFw source code where "--zero" would have prevented
a call to WriteDebug64(), or otherwise eliminated the NB10 entry.

... So at this point I'm not sure if I simply messed up my testing. :(

Ross -- can you please confirm? Does Liming's suggestion work for you?

Thanks,
Laszlo


PlatformPkg.dsc:

[BuildOptions]
RELEASE_*_*_GENFW_FLAGS = -z

Thanks
Liming
-----้‚ฎไปถๅŽŸไปถ-----
ๅ‘ไปถไบบ: Ross Burton <ross@burtonini.com>
ๅ‘้€ๆ—ถ้—ด: 2021ๅนด3ๆœˆ11ๆ—ฅ 3:36
ๆ”ถไปถไบบ: discuss@edk2.groups.io
ๆŠ„้€: bob.c.feng@intel.com; gaoliming@byosoft.com.cn;
yuwei.chen@intel.com
ไธป้ข˜: Non-reproducible binaries generated by GenFw

Hi,

As per https://bugzilla.tianocore.org/show_bug.cgi?id=3256, GenFw
writes non-reproducible binaries by embedding a build path. In fact in
a build of ovmf with embedded shell, this one path is the sole source
of non-determinism.

WriteDebug64() is always called in GenFw on output and that embeds
into the NB10 entry the input filename. As build paths change this is
a source of non-determinism. There already exists a --zero option to
wipe out debug paths but this is in release builds so I'm not sure
what the best solution is. I can see several options:

1) Release builds should not call WriteDebug64() at all
2) --zero should wipe the NB10 entry, and release builds should pass that
3) GenFw should support path remapping (like gcc's -ffile-prefix-map)
to turn build paths into something consistent.

Any suggestions?

Cheers,
Ross










Re: [EXTERNAL] Re: [edk2-discuss] ๅ›žๅค: [edk2-discuss] edk2 build error

Mohammad Younas Khan Pathan
 

Hi Bret & others,
Do you have any comments on this??

On Wed, Mar 10, 2021, 12:20 PM Mohammad Younas Khan Pathan <
pmdyounaskhan786@gmail.com> wrote:

Hi Bret,
I have installed using vs_buildtools.exe cmd in shared link (
https://microsoft.github.io/mu/CodeDevelopment/prerequisites/#visual-studio-2019-preferred
)

Still I am facing the same build error:
ERROR - We were not able to find on the keys requested from vcvarsall.
ERROR - We didn't find: ['WINDOWSSDKVERSION', 'WINDOWSSDKDIR',
'UNIVERSALCRTSDKDIR', 'EXTENSIONSDKDIR', 'WINDOWSLIBPATH',
'WINDOWSSDKVERBINPATH', 'VCTOOLSINSTALLDIR', 'PATH', 'WINDOWSSDKBINPATH']

Then I tried to manually set these env vars as follows, but still I am
getting the same build errors.

set WINDOWSSDKVERSION=10.0.17763.0
set WINDOWSSDKDIR=C:\Program Files (x86)\Windows Kits\10\
set EXTENSIONSDKDIR=C:\Program Files (x86)\Microsoft SDKs\Windows
Kits\10\ExtensionSDKs\
set WINDOWSLIBPATH=References\CommonConfiguration\Neutral\
set WINDOWSSDKVERBINPATH=C:\Program Files (x86)\Windows
Kits\10\bin\10.0.17763.0\x64\
set VCTOOLSINSTALLDIR=C:\BuildTools\VC\Tools\MSVC\14.28.29910\
set WINDOWSSDKBINPATH=C:\Program Files (x86)\Windows
Kits\10\bin\10.0.17763.0\x64\
set UCRTVERSION=10.0.17763.0
set PATH=%Path%

The build errors are due to paths in environment vars are not set
appropriately.
Is there any other way to set these variables? or can you share your
reference variables, so that I can set and check?

Thank you,
Younas.

On Mon, 8 Mar 2021 at 21:48, Bret Barkelew <Bret.Barkelew@microsoft.com>
wrote:

Updated (below)โ€ฆ



- Bret



*From: *Bret Barkelew via groups.io
<bret.barkelew=microsoft.com@groups.io>
*Sent: *Monday, March 8, 2021 8:09 AM
*To: *Mohammad Younas Khan Pathan <pmdyounaskhan786@gmail.com>
*Cc: *discuss@edk2.groups.io; Sean Brogan <spbrogan@outlook.com>; Feng,
Bob C <bob.c.feng@intel.com>; alexgdi@outlook.com
*Subject: *Re: [EXTERNAL] Re: [edk2-discuss] ๅ›žๅค: [edk2-discuss] edk2
build error



Younas,

Can you try making sure that you have all the following subcomponents of
VS Buildtools installed:
Microsoft.VisualStudio.Component.VC.CoreBuildTools
Microsoft.VisualStudio.Component.VC.Tools.x86.x64
Microsoft.VisualStudio.Component.Windows10SDK.17763

While this isnโ€™t official EDK2 documentation, this is our (MSCoreUEFI)
recommended way to install buildtools:
Tools and Prerequisite - Project Mu (microsoft.github.io)<
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23visual-studio-2019-preferred&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743119026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=X1E2BLWjvErQpq6nRbI8BbSuqbrjjmZ9tJX3btyrxmg%3D&amp;reserved=0
- Bret

From: Mohammad Younas Khan Pathan<mailto:pmdyounaskhan786@gmail.com
<pmdyounaskhan786@gmail.com>>
Sent: Sunday, March 7, 2021 11:30 PM
To: Bret Barkelew<mailto:Bret.Barkelew@microsoft.com
<Bret.Barkelew@microsoft.com>>
Cc: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>; Sean Brogan<
mailto:spbrogan@outlook.com <spbrogan@outlook.com>>; Feng, Bob C<
mailto:bob.c.feng@intel.com <bob.c.feng@intel.com>>; alexgdi@outlook.com<
mailto:alexgdi@outlook.com <alexgdi@outlook.com>>
Subject: Re: [EXTERNAL] Re: [edk2-discuss] ๅ›žๅค: [edk2-discuss] edk2 build
error

Bret,
I selected default install from VS buildtools from below link:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvisualstudio.microsoft.com%2Fdownloads%2F%23build-tools-for-visual-studio-2019&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743119026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=cPCr9rYcre5fxpAM6YTcWuKQPiPuoY9eMArye5B0q20%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvisualstudio.microsoft.com%2Fdownloads%2F%23build-tools-for-visual-studio-2019&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743119026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=cPCr9rYcre5fxpAM6YTcWuKQPiPuoY9eMArye5B0q20%3D&amp;reserved=0
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvisualstudio.microsoft.com%2Fdownloads%2F%23build-tools-for-visual-studio-2019&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743119026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=cPCr9rYcre5fxpAM6YTcWuKQPiPuoY9eMArye5B0q20%3D&amp;reserved=0%3chttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvisualstudio.microsoft.com%2Fdownloads%2F%23build-tools-for-visual-studio-2019&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743119026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=cPCr9rYcre5fxpAM6YTcWuKQPiPuoY9eMArye5B0q20%3D&amp;reserved=0>
Please find the log:
C:\Program Files (x86)\Microsoft Visual
Studio\2019\BuildTools\VC\Auxiliary\Build>vcvarsall.bat AMD64
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.9.0
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

C:\Program Files (x86)\Microsoft Visual
Studio\2019\BuildTools\VC\Auxiliary\Build>

Thank you,
Younas.

On Fri, 5 Mar 2021 at 22:52, Bret Barkelew <Bret.Barkelew@microsoft.com
<mailto:Bret.Barkelew@microsoft.com>> wrote:
Can you send the output of:
โ€œC:\Program Files (x86)\Microsoft Visual
Studio\2019\BuildTools\VC\Auxiliary\Build\vcvarsall.bat AMD64โ€

When you installed VS2019, did you select any additional packages or just
a default install?

- Bret

From: Mohammad Younas Khan Pathan via groups.io<
mailto:pmdyounaskhan786=gmail.com@groups.io
<pmdyounaskhan786=gmail.com@groups.io>>
Sent: Thursday, March 4, 2021 10:16 PM
To: Sean Brogan<mailto:spbrogan@outlook.com <spbrogan@outlook.com>>
Cc: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>; Feng, Bob C<
mailto:bob.c.feng@intel.com <bob.c.feng@intel.com>>; alexgdi@outlook.com<
mailto:alexgdi@outlook.com <alexgdi@outlook.com>>
Subject: [EXTERNAL] Re: [edk2-discuss] ๅ›žๅค: [edk2-discuss] edk2 build
error

Hi Bret/others,
I have installed WinSDK & VS2019 in my system.
Please find the attached build log for building EmulatorPkg.
And help me out on this.

Thank you,
Younas.

On Fri, 5 Mar 2021 at 09:49, Sean Brogan <spbrogan@outlook.com<mailto:
spbrogan@outlook.com>> wrote:

EmulatorPkg on Windows is a Windows application and thus you need all
the tools/libs to support building a windows application.

I would suggest making sure you have VS2019 and WinSdk as listed here:


https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23visual-studio-2019-preferred&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743119026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=X1E2BLWjvErQpq6nRbI8BbSuqbrjjmZ9tJX3btyrxmg%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23visual-studio-2019-preferred&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=deUr%2BQCYJ4srUuHZJGbovx8tion%2FqUrBk75UtYGNyBw%3D&amp;reserved=0
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23visual-studio-2019-preferred&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743119026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=X1E2BLWjvErQpq6nRbI8BbSuqbrjjmZ9tJX3btyrxmg%3D&amp;reserved=0%3chttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23visual-studio-2019-preferred&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=deUr%2BQCYJ4srUuHZJGbovx8tion%2FqUrBk75UtYGNyBw%3D&amp;reserved=0>



https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23optional-windows-driver-kit&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6%2BOIGR0lcVz0z%2F1ykiHOwZuSEGPylHf2kex8PECZcsk%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23optional-windows-driver-kit&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6%2BOIGR0lcVz0z%2F1ykiHOwZuSEGPylHf2kex8PECZcsk%3D&amp;reserved=0
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23optional-windows-driver-kit&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6%2BOIGR0lcVz0z%2F1ykiHOwZuSEGPylHf2kex8PECZcsk%3D&amp;reserved=0%3chttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicrosoft.github.io%2Fmu%2FCodeDevelopment%2Fprerequisites%2F%23optional-windows-driver-kit&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6%2BOIGR0lcVz0z%2F1ykiHOwZuSEGPylHf2kex8PECZcsk%3D&amp;reserved=0>


Thanks
Sean


On 3/4/2021 6:23 AM, Mohammad Younas Khan Pathan wrote:
The mu_nasm dependency issue is resolved with below cmd:

stuart_update -c .pytool/CISettings.py


I am facing another error if I try stuart_build (for EmulatorPkg) or
running BaseTools/Edk2ToolsBuild.py for VS2019:

*ERROR - We were not able to find on the keys requested from
vcvarsall.*
* ValueError: Missing keys when querying vcvarsall:
['WINDOWSSDKVERSION',
'WINDOWSSDKBINPATH', 'UNIVERSALCRTSDKDIR', 'WINDOWSLIBPATH', 'PATH',
'VCTOOLSINSTALLDIR', 'EXTENSIONSDKDIR', 'UCRTVERSION',
'WINDOWSSDKVERBINPATH', 'WINDOWSSDKDIR']*

Do we need to do any setup for these variables?

Thank you,
Younas.

On Thu, 4 Mar 2021 at 19:24, Feng, Bob C <bob.c.feng@intel.com
<mailto:bob.c.feng@intel.com>> wrote:

OvmfPkg\Platform\ReadMe.md describes the instruction of using
Pytools to
build OvmfPkg in details. Those instruction can also apply to
EmulatorPkg
Build.

This command is to init and update the edk2 submodules
stuart_setup -c OvmfPkg/PlatformCI/PlatformBuild.py
TOOL_CHAIN_TAG=<TOOL_CHAIN_TAG> -a <TARGET_ARCH>

This command is to install the nasm and iasl
stuart_update -c OvmfPkg/PlatformCI/PlatformBuild.py
TOOL_CHAIN_TAG=<TOOL_CHAIN_TAG> -a <TARGET_ARCH>

This command is to build BaseTools C tools and set the necessary
environment variable
python BaseTools/Edk2ToolsBuild.py -t <ToolChainTag>

This command is to OvmfPkg
stuart_build -c OvmfPkg/PlatformCI/PlatformBuild.py -a IA32
TOOL_CHAIN_TAG=<TOOL_CHAIN_TAG>


Thanks,
Bob

-----Original Message-----
From: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io> <
discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>> On Behalf Of
Mohammad Younas Khan Pathan
Sent: Thursday, March 4, 2021 7:07 PM
To: alexgdi@outlook.com<mailto:alexgdi@outlook.com
<alexgdi@outlook.com>>
Cc: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>
Subject: Re: [edk2-discuss] ๅ›žๅค: [edk2-discuss] edk2 build error

Alex,
I tried that cmd, but it gives below error: NASM is installed and
kept
with NASM_PREFIX env variable.

ERROR - Dependency 'mu_nasm' is not met!
Traceback (most recent call last):
File "c:\python\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "c:\python\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Python\Scripts\stuart_build.exe\__main__.py", line 7, in
<module>
File

"c:\python\lib\site-packages\edk2toolext\invocables\edk2_platform_build.py",
line 113, in main
Edk2PlatformBuild().Invoke()
File
"c:\python\lib\site-packages\edk2toolext\base_abstract_invocable.py",
line
122, in Invoke
raise RuntimeError("SDE is not current. Please update your env
before
running this tool.")
RuntimeError: SDE is not current. Please update your env before
running
this tool.

Have you got any errors like this?

Thank you,
Younas.

On Thu, 4 Mar 2021 at 16:06, <alexgdi@outlook.com<mailto:
alexgdi@outlook.com>> wrote:

On Thu, Mar 4, 2021 at 02:27 AM, Mohammad Younas Khan Pathan wrote:


cmd: python BaseTools/Edk2ToolsBuild.py -t <ToolChainTag> #
ToolChainTag
It is not necessary to compile BaseTools. If you want to build
EmulatorPkg try this instruction
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FEmulatorPkg%2FPlatformCI%2FR&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2FeHjU8zhs%2B7xV0uHb4mwHGasM89rkHicgiNqojwll9s%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FEmulatorPkg%2FPlatformCI%2FR&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2FeHjU8zhs%2B7xV0uHb4mwHGasM89rkHicgiNqojwll9s%3D&amp;reserved=0
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FEmulatorPkg%2FPlatformCI%2FR&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2FeHjU8zhs%2B7xV0uHb4mwHGasM89rkHicgiNqojwll9s%3D&amp;reserved=0%3chttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FEmulatorPkg%2FPlatformCI%2FR&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cd3e80d6eabc04679f11108d8e24c52a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508165743128985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2FeHjU8zhs%2B7xV0uHb4mwHGasM89rkHicgiNqojwll9s%3D&amp;reserved=0>

eadMe.md
and use MSVC 2019 compiler

for example

stuart_build -c EmulatorPkg/PlatformCI/PlatformBuild.py
TOOL_CHAIN_TAG=VS2019 -a X64

...





















Re: Non-reproducible binaries generated by GenFw

Ross Burton
 

On Fri, 12 Mar 2021 at 05:37, gaoliming <gaoliming@byosoft.com.cn> wrote:

RELEASE_*_*_GENFW_FLAGS = -z means this option is applied on RELEASE build.
So where would I put that statement? I tried dropping it into
ShellPkg.dsc but it wasn't respected.

Ross


Re: Google Summer of Code Interested Student

Nate DeSimone
 

Hi Caden,

Great to meet you and welcome to the TianoCore project! Glad you hear you are interested! Sorry it has taken me a while to get back to you, researching the topics you are interested in ended up being somewhat involved ๐Ÿ˜Š.

I went back and did some investigation of current state of the terminal driver, and some of the work has already been done. However, there are some things missing and some odd bugs that need attention. To give you a little more detail, the Terminal driver is located at https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Universal/Console/TerminalDxe

The most prevalent use case for the terminal driver is to display the BIOS setup menu on headless server systems using a PC style serial port connected to a laptop via null modem. This allows administrators to adjust BIOS settings on rack mounted systems without needing to connect a monitor and keyboard.

Historically, the BIOS setup menu would be rendered using the IBM PC VGA text mode, which encoded text using code page 437 (CP437). This was important for box-drawing characters, such as โ”Œ , โ”€ , and โ” , which VGA text mode encodes as 0xDA, 0xC4, and 0xBF respectively. However, most terminal emulators assume text to be encoded in UTF-8. Unicode defines these box drawing characters as 0x250C, 0x2500, and 0x2510. In UTF-8 encoding, these characters translate into 3 byte sequences of (0xE2, 0x94, 0x8C), (0xE2, 0x94, 0x80), and (0xE2, 0x94, 0x90) respectively. The VGA encodings of these box characters will end up generating errors if one attempts to decode them as strict UTF-8, though most terminals assume that the intended characters to be drawn are รš, ร„, and ยฟ, which have the Unicode character codes 0xDA, 0xC4, and 0xBF. The end result is the BIOS setup menu looks like this:

รšร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ยฟ
ยณ Device Manager ยณ
ร€ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร™

Devices List List all the Driver
> Driver Health Manager Health instances to
> RAM Disk Configuration manage
> OVMF Platform Configuration
> iSCSI Configuration
> Network Device List


Press ESC to exit.


รšร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ยฟ
ยณ ยณ
ยณ ^v=Move Highlight <Enter>=Select Entry Esc=Exit ยณ
ร€ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร„ร™

Instead of like this:

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ Device Manager โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Devices List List all the Driver
> Driver Health Manager Health instances to
> RAM Disk Configuration manage
> OVMF Platform Configuration
> iSCSI Configuration
> Network Device List


Press ESC to exit.


โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ โ”‚
โ”‚ ^v=Move Highlight <Enter>=Select Entry Esc=Exit โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

The terminal driver has fully supported both the legacy CP437 encoding and the UTF-8 encoding for more than 10 years now. Which mode to use is part of the configuration settings given to the terminal driver at start up. However, those configuration settings need to come from somewhere. For example, OVMF has the following page in its setup menu for configuring the serial terminal:

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ Set COM Attributes โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Set COM Baud Rate <115200> Set COM Baud Rate
Set COM Data Bits <8>
Set COM Parity <None>
Set COM Stop Bits <One>
Set COM Terminal Type <PC_ANSI>
Set COM Flow Control <None>

Commit Changes and Exit
Discard Changes and Exit


โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ F9=Reset to Defaults F10=Save โ”‚
โ”‚ ^v=Move Highlight <Enter>=Select Entry Esc=Exit โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

The default terminal type is PC_ANSI, which uses CP437. In this day and age that is probably not the right default anymore, though one could argue whether PC_ANSI being the default is a "bug". Here is the list of supported terminal types:

- PC_ANSI
- VT_100
- VT_100_PLUS
- VT_UTF8
- TTY_TERM
- LINUX
- XTERM_R6
- VT_400
- SCO

Now, here is the first unquestionable bug. All of these terminal types except for VT_UTF8 output the box drawing characters using CP437. The VT-100 did not use CP437 for box drawing characters. On the VT-100, the terminal driver should output the escape sequence "ESC ( 0" to switch the character set from ASCII to "DEC Special Graphics". Then, while in DEC Special Graphics mode, โ”Œ , โ”€ , and โ” , are encoded as 0x6C, 0x71, and 0x6B respectively. After outputting the box drawing characters, the terminal driver should switch back to ASCII using the escape sequence "ESC ( B". Implementing this will introduce the interesting problem of optimizing display performance by limiting the number of character mode switches.

For all the modes listed above, the VT-100 method should be used for drawing box characters (and other characters in the DEC special graphics character set) with the exception of PC_ANSI and VT_UTF8, which should use CP437 and UTF-8 respectively. In general, DEC special graphics has been around for such a long time that all terminal emulators support it, so it should be the preferred method of outputting characters outside the initial 0-127 basic ASCII codes, with UTF-8 as a fallback if the character can't be encoded by either basic ASCII or DEC special graphics. The difference between VT_UTF8 and the other modes is that DEC special graphics should never be used. PC_ANSI mode should never use DEC special graphics either.

Now, here is the second bug. That BIOS setup menu page that OVMF has for configuring the serial port has a field for setting the terminal type. But, changing the value in that field doesn't actually change the configuration data that is sent to the terminal driver. So the terminal driver always ends up using PC_ANSI mode even if the user changes that setting. This isnโ€™t a bug in the terminal driver really, itโ€™s a bug in OVMF's setup menu implementation. But it does create the appearance of a problem in the terminal driver and should be fixed as part of this GSoC project. This should be fixed in both he OVMF implementation and the MinPlatform implementation.

I'm not sure if the terminal driver improvements would absorb the entire 10 week coding window. If you had time left, you could consider spending it writing unit tests.

Looking at your experience, it seems like you have more experience with Python coding than with C coding. Both the terminal driver improvements and unit tests would be written in C. Another option you could consider is we have a lot of Python code in TianoCore as well. The two major pieces of Python code are BaseTools and EdkRepo. BaseTools provides the build system for TianoCore and implements the logic necessary to compile a BIOS ROM file from source. EdkRepo is the multi-repository tool for EDK II. EdkRepo automates common developer workflows for projects that use more than one git repository (many TianoCore projects do). We would gladly accept project proposals for either BaseTools or EdkRepo. If either of those interest you I can point you to some places where they can be improved and give you some project ideas.

The most important outcome from GSoC in our view is that our students learn something, get some exposure, and have a great experience that they will remember fondly for years to come. We want you to be successful. Gauge your comfort level and pick a project that you feel you can achieve in the 10 week period. Sorry for the long email, but I hope it helps. Finally I'd like to reiterate... Welcome to the project!

With Best Regards,
Nate

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Wednesday, March 10, 2021 8:17 AM
To: discuss@edk2.groups.io
Cc: cadenkline9@gmail.com; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Subject: Re: [edk2-discuss] Google Summer of Code Interested Student

adding Nate

On 03/10/21 03:10, mailto:cadenkline9@gmail.com wrote:
Hello, My name is Caden Kline. I am a freshmen Computer Science major in the US. I intend to specialize in Systems or Security or both. The main two tasks I am hoping to apply for are "Terminal driver improvements" and "Writing Unit Tests". However, I am primarily interested in any system level work and willing to work on anything. I am concerned about the difficulty in completing these tasks so I'm going to list my experience.

My relevant experience for C programming language is a one semester introduction to C and Unix class I am currently taking. Outside of formal experience, I have primarily interacted with C and assembly with capture the flag/wargame binary exploitation challenges, and unfinished projects such as a chip8 emulator. My primary programming experience is Java and Python thanks to my high school and college classes. I have participated in several past google code-ins. My github profile is https://github.com/Pokemod97 .

Is there anything I can do to improve my chances to be selected or any other feedback? Thank you for taking the time to read this message.





ๅ›žๅค: Non-reproducible binaries generated by GenFw

gaoliming
 

RELEASE_*_*_GENFW_FLAGS = -z means this option is applied on RELEASE build.

*_*_*_GANFW_FLAGS = -z can apply this option to all target builds.

When you build, you can build -j build.log. Then, build log will dump into build.log file. You can search GenFw command in build.log and check whether GenFw has -e option.

Thanks
Liming

-----้‚ฎไปถๅŽŸไปถ-----
ๅ‘ไปถไบบ: Ross Burton <ross@burtonini.com>
ๅ‘้€ๆ—ถ้—ด: 2021ๅนด3ๆœˆ12ๆ—ฅ 0:16
ๆ”ถไปถไบบ: gaoliming <gaoliming@byosoft.com.cn>
ๆŠ„้€: discuss@edk2.groups.io; bob.c.feng@intel.com; yuwei.chen@intel.com
ไธป้ข˜: Re: Non-reproducible binaries generated by GenFw

On Thu, 11 Mar 2021 at 04:44, gaoliming <gaoliming@byosoft.com.cn> wrote:

Ross:
I verify -z option. It can remove DEBUG entry and make sure the
generated image be reproduced.

PlatformPkg.dsc:

[BuildOptions]
RELEASE_*_*_GENFW_FLAGS = -z
I tried adding that to ShellPkg.dsc but I can't seem to make the value
actually get into the build. Is there anything else I need to do
apart from:

+++ b/ShellPkg/ShellPkg.dsc
@@ -154,3 +154,4 @@
[BuildOptions]
*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
+ RELEASE_*_*_GENFW_FLAGS = -z

Thanks,
Ross


ๅ›žๅค: [edk2-discuss] ๅ›žๅค: Non-reproducible binaries generated by GenFw

gaoliming
 

Laszlo:
I verify the below three commands. The first generated EFI image includes DEBUG entry. Other EFI images have no DEBUG entry. Yes, DEBUG entry is added by GenFw tool. -z option can be used to remove it.

GenFw -e PEI_CORE -o test.efi PeiCore.dll
GenFw -e PEI_CORE -o test2.efi -z PeiCore.dll
GenFw -e PEI_CORE -o test3.efi --zero PeiCore.dll

Thanks
Liming

-----้‚ฎไปถๅŽŸไปถ-----
ๅ‘ไปถไบบ: discuss@edk2.groups.io <discuss@edk2.groups.io> ไปฃ่กจ Laszlo
Ersek
ๅ‘้€ๆ—ถ้—ด: 2021ๅนด3ๆœˆ12ๆ—ฅ 1:30
ๆ”ถไปถไบบ: discuss@edk2.groups.io; gaoliming@byosoft.com.cn; 'Ross Burton'
<ross@burtonini.com>
ๆŠ„้€: bob.c.feng@intel.com; yuwei.chen@intel.com
ไธป้ข˜: Re: [edk2-discuss] ๅ›žๅค: Non-reproducible binaries generated by
GenFw

Hi Liming,

On 03/11/21 05:44, gaoliming wrote:
Ross:
I verify -z option. It can remove DEBUG entry and make sure the
generated image be reproduced.

I tried the "--zero" option myself (as seen in the BZ), but it didn't
work. What I did was the following: in the original run of the "build"
utility, I redirected the standard output and the standard error to a
log file. Then, I located the "GenFw" invocation that produced the
"Shell.efi" binary from the "Shell.dll" file. I also checked that the
"Shell.dll" file did not contain the full pathname, embedded -- so it
was GenFw that embedded the full file path indeed.

Then, I re-run the GenFw utility myself, interactively, and added the
"--zero" flag to the command line. The output did not change,
"Shell.efi" still contained the full pathname embedded. I also couldn't
find a spot in the GenFw source code where "--zero" would have prevented
a call to WriteDebug64(), or otherwise eliminated the NB10 entry.

... So at this point I'm not sure if I simply messed up my testing. :(

Ross -- can you please confirm? Does Liming's suggestion work for you?

Thanks,
Laszlo


PlatformPkg.dsc:

[BuildOptions]
RELEASE_*_*_GENFW_FLAGS = -z

Thanks
Liming
-----้‚ฎไปถๅŽŸไปถ-----
ๅ‘ไปถไบบ: Ross Burton <ross@burtonini.com>
ๅ‘้€ๆ—ถ้—ด: 2021ๅนด3ๆœˆ11ๆ—ฅ 3:36
ๆ”ถไปถไบบ: discuss@edk2.groups.io
ๆŠ„้€: bob.c.feng@intel.com; gaoliming@byosoft.com.cn;
yuwei.chen@intel.com
ไธป้ข˜: Non-reproducible binaries generated by GenFw

Hi,

As per https://bugzilla.tianocore.org/show_bug.cgi?id=3256, GenFw
writes non-reproducible binaries by embedding a build path. In fact in
a build of ovmf with embedded shell, this one path is the sole source
of non-determinism.

WriteDebug64() is always called in GenFw on output and that embeds
into the NB10 entry the input filename. As build paths change this is
a source of non-determinism. There already exists a --zero option to
wipe out debug paths but this is in release builds so I'm not sure
what the best solution is. I can see several options:

1) Release builds should not call WriteDebug64() at all
2) --zero should wipe the NB10 entry, and release builds should pass that
3) GenFw should support path remapping (like gcc's -ffile-prefix-map)
to turn build paths into something consistent.

Any suggestions?

Cheers,
Ross









Re: ๅ›žๅค: Non-reproducible binaries generated by GenFw

Ross Burton
 

On Thu, 11 Mar 2021 at 17:30, Laszlo Ersek <lersek@redhat.com> wrote:
Ross -- can you please confirm? Does Liming's suggestion work for you?
If I manually call GenFw with -z then it does in fact work. Proof via
diffoscope:

https://try.diffoscope.org/takcczugyxzr.html

I'm failing at making this actually stick in the makefiles though...

Ross


Re: Non-reproducible binaries generated by GenFw

Ross Burton
 

On Thu, 11 Mar 2021 at 04:44, gaoliming <gaoliming@byosoft.com.cn> wrote:

Ross:
I verify -z option. It can remove DEBUG entry and make sure the generated image be reproduced.

PlatformPkg.dsc:

[BuildOptions]
RELEASE_*_*_GENFW_FLAGS = -z
I tried adding that to ShellPkg.dsc but I can't seem to make the value
actually get into the build. Is there anything else I need to do
apart from:

+++ b/ShellPkg/ShellPkg.dsc
@@ -154,3 +154,4 @@
[BuildOptions]
*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
+ RELEASE_*_*_GENFW_FLAGS = -z

Thanks,
Ross


Non-reproducible binaries generated by GenFw

Ross Burton
 

Hi,

As per https://bugzilla.tianocore.org/show_bug.cgi?id=3256, GenFw
writes non-reproducible binaries by embedding a build path. In fact in
a build of ovmf with embedded shell, this one path is the sole source
of non-determinism.

WriteDebug64() is always called in GenFw on output and that embeds
into the NB10 entry the input filename. As build paths change this is
a source of non-determinism. There already exists a --zero option to
wipe out debug paths but this is in release builds so I'm not sure
what the best solution is. I can see several options:

1) Release builds should not call WriteDebug64() at all
2) --zero should wipe the NB10 entry, and release builds should pass that
3) GenFw should support path remapping (like gcc's -ffile-prefix-map)
to turn build paths into something consistent.

Any suggestions?

Cheers,
Ross


Re: ๅ›žๅค: Non-reproducible binaries generated by GenFw

Laszlo Ersek
 

Hi Liming,

On 03/11/21 05:44, gaoliming wrote:
Ross:
I verify -z option. It can remove DEBUG entry and make sure the generated image be reproduced.
I tried the "--zero" option myself (as seen in the BZ), but it didn't
work. What I did was the following: in the original run of the "build"
utility, I redirected the standard output and the standard error to a
log file. Then, I located the "GenFw" invocation that produced the
"Shell.efi" binary from the "Shell.dll" file. I also checked that the
"Shell.dll" file did not contain the full pathname, embedded -- so it
was GenFw that embedded the full file path indeed.

Then, I re-run the GenFw utility myself, interactively, and added the
"--zero" flag to the command line. The output did not change,
"Shell.efi" still contained the full pathname embedded. I also couldn't
find a spot in the GenFw source code where "--zero" would have prevented
a call to WriteDebug64(), or otherwise eliminated the NB10 entry.

... So at this point I'm not sure if I simply messed up my testing. :(

Ross -- can you please confirm? Does Liming's suggestion work for you?

Thanks,
Laszlo


PlatformPkg.dsc:

[BuildOptions]
RELEASE_*_*_GENFW_FLAGS = -z

Thanks
Liming
-----้‚ฎไปถๅŽŸไปถ-----
ๅ‘ไปถไบบ: Ross Burton <ross@burtonini.com>
ๅ‘้€ๆ—ถ้—ด: 2021ๅนด3ๆœˆ11ๆ—ฅ 3:36
ๆ”ถไปถไบบ: discuss@edk2.groups.io
ๆŠ„้€: bob.c.feng@intel.com; gaoliming@byosoft.com.cn;
yuwei.chen@intel.com
ไธป้ข˜: Non-reproducible binaries generated by GenFw

Hi,

As per https://bugzilla.tianocore.org/show_bug.cgi?id=3256, GenFw
writes non-reproducible binaries by embedding a build path. In fact in
a build of ovmf with embedded shell, this one path is the sole source
of non-determinism.

WriteDebug64() is always called in GenFw on output and that embeds
into the NB10 entry the input filename. As build paths change this is
a source of non-determinism. There already exists a --zero option to
wipe out debug paths but this is in release builds so I'm not sure
what the best solution is. I can see several options:

1) Release builds should not call WriteDebug64() at all
2) --zero should wipe the NB10 entry, and release builds should pass that
3) GenFw should support path remapping (like gcc's -ffile-prefix-map)
to turn build paths into something consistent.

Any suggestions?

Cheers,
Ross






ๅ›žๅค: Non-reproducible binaries generated by GenFw

gaoliming
 

Ross:
I verify -z option. It can remove DEBUG entry and make sure the generated image be reproduced.

PlatformPkg.dsc:

[BuildOptions]
RELEASE_*_*_GENFW_FLAGS = -z

Thanks
Liming

-----้‚ฎไปถๅŽŸไปถ-----
ๅ‘ไปถไบบ: Ross Burton <ross@burtonini.com>
ๅ‘้€ๆ—ถ้—ด: 2021ๅนด3ๆœˆ11ๆ—ฅ 3:36
ๆ”ถไปถไบบ: discuss@edk2.groups.io
ๆŠ„้€: bob.c.feng@intel.com; gaoliming@byosoft.com.cn;
yuwei.chen@intel.com
ไธป้ข˜: Non-reproducible binaries generated by GenFw

Hi,

As per https://bugzilla.tianocore.org/show_bug.cgi?id=3256, GenFw
writes non-reproducible binaries by embedding a build path. In fact in
a build of ovmf with embedded shell, this one path is the sole source
of non-determinism.

WriteDebug64() is always called in GenFw on output and that embeds
into the NB10 entry the input filename. As build paths change this is
a source of non-determinism. There already exists a --zero option to
wipe out debug paths but this is in release builds so I'm not sure
what the best solution is. I can see several options:

1) Release builds should not call WriteDebug64() at all
2) --zero should wipe the NB10 entry, and release builds should pass that
3) GenFw should support path remapping (like gcc's -ffile-prefix-map)
to turn build paths into something consistent.

Any suggestions?

Cheers,
Ross

221 - 240 of 834