Date   

Re: Functions for coversion strings to intergers

Andrew Fish
 

On Jul 21, 2021, at 10:01 AM, Konstantin Aladyshev <aladyshev22@gmail.com> wrote:

Are there any library functions that can convert a string with a
decimal number to a number, and tell if the conversion was successful?
What is your definition of successful?

I've found StrDecimalToUintnS and StrDecimalToUint64S functions in a
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/SafeString.c
But it looks like they always return `RETURN_SUCCESS`, no matter if
the passed string contains a number. In this case the function simply
fills the number value with a 0.

Also why aren't there any functions for conversion of signed numbers?
Something like StrDecimalToIntnS/StrDecimalToInt64S ?
Most of the library functions evolved from code duplication in the firmware. Thus we only pick functions that commonly got used.

Thanks,

Andrew Fish

Best regards,
Konstantin Aladyshev



Functions for coversion strings to intergers

Konstantin Aladyshev
 

Are there any library functions that can convert a string with a
decimal number to a number, and tell if the conversion was successful?

I've found StrDecimalToUintnS and StrDecimalToUint64S functions in a
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/SafeString.c
But it looks like they always return `RETURN_SUCCESS`, no matter if
the passed string contains a number. In this case the function simply
fills the number value with a 0.

Also why aren't there any functions for conversion of signed numbers?
Something like StrDecimalToIntnS/StrDecimalToInt64S ?

Best regards,
Konstantin Aladyshev


How to build edk2/ovmf with secure boot enabled as done in Fedora with "*CODE.secboot.fd" and "*VARS.secboot.fd" files?

Ks89
 

My env:
-centos8
-qemu 6.0.0

I'm trying to install windows 10 from .iso installation disk in QEMU 6.0.0 with secure boot enabled in UEFI.

If I pass edk2/ovmf files provided by Fedora, I can find the .secboot.fd versions. Passing those files to qemu with:
-global driver=cfi.pflash01,property=secure,value=on \
-drive if=pflash,format=raw,file=/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd,readonly=on \
-drive if=pflash,format=raw,file=./my-writable_OVMF_VARS.secboot.fd \

In this way I can see the option "secure boot" enabled in EUFI.

Ok, but now I want to download edk2/ovmf from sources using the latest stable tag:
git clone https://github.com/tianocore/edk2.git
cd edk2
git checkout edk2-stable202105
git submodule update --init

And finally I want to build it for x64 with secure boot:
./OvmfPkg/build.sh

I tried to use "./OvmfPkg/build.sh -DSECURE_BOOT_ENABLE" but when I run QEMU, the secure boot option in UEFI is disabled.

Which is the right procedure to build edk2/OVMF with secure boot?

Thank you.


Re: failure in building unit test locally

wenyi,xie
 

Hi,Sean

I have upload the log to github, link is like below.
https://github.com/leadsama/ShowLog/blob/main/README.md

Thanks
Wenyi

On 2021/7/20 23:26, Sean Brogan wrote:
In the workspace/build folder there should be some logs .
Can you look at those and/or send the CI Log?

Thanks
Sean



On 7/20/2021 2:08 AM, wenyi,xie via groups.io wrote:
Hello, everyone

I want to build unit test locally, my environment is win10, python 3.9.6, VS2019.
I excute the command according to steps in the ReadMe.
1. stuart_setup -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019
2. stuart_update -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019
3. stuart_ci_build -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019 -t NOOPT -p MdePkg

In step 3, the log is just stopped at "Running Build NOOPT", how do I know the cause of the build failure ?
SECTION - Init SDE
WARNING - Using Pip Tools based BaseTools
SECTION - Loading Plugins
SECTION - Start Invocable Tool
SECTION - Getting Environment
SECTION - Loading plugins
SECTION - Building MdePkg Package
PROGRESS - --Running MdePkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - Allowing Override for key TARGET_ARCH
PROGRESS - Start time: 2021-07-20 16:55:27.953832
PROGRESS - Setting up the Environment
PROGRESS - Running Pre Build
PROGRESS - Running Build NOOPT




.


Re: failure in building unit test locally

Sean
 

In the workspace/build folder there should be some logs .
Can you look at those and/or send the CI Log?

Thanks
Sean

On 7/20/2021 2:08 AM, wenyi,xie via groups.io wrote:
Hello, everyone
I want to build unit test locally, my environment is win10, python 3.9.6, VS2019.
I excute the command according to steps in the ReadMe.
1. stuart_setup -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019
2. stuart_update -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019
3. stuart_ci_build -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019 -t NOOPT -p MdePkg
In step 3, the log is just stopped at "Running Build NOOPT", how do I know the cause of the build failure ?
SECTION - Init SDE
WARNING - Using Pip Tools based BaseTools
SECTION - Loading Plugins
SECTION - Start Invocable Tool
SECTION - Getting Environment
SECTION - Loading plugins
SECTION - Building MdePkg Package
PROGRESS - --Running MdePkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - Allowing Override for key TARGET_ARCH
PROGRESS - Start time: 2021-07-20 16:55:27.953832
PROGRESS - Setting up the Environment
PROGRESS - Running Pre Build
PROGRESS - Running Build NOOPT


Re: How to get page break functionality in UEFI applications

Konstantin Aladyshev
 

I've managed to get the aforementioned functionality by using `EnablePageBreak` function from the EFI_SHELL_PROTOCOL:
```
EFI_SHELL_PROTOCOL* ShellProtocol;
Status = gBS->LocateProtocol(
&gEfiShellProtocolGuid,
NULL,
(VOID **)&ShellProtocol
);

if (EFI_ERROR(Status)) {
Print(L"Can't open EFI_SHELL_PROTOCOL: %r\n", Status);
return EFI_SUCCESS;
}

Print(L"PageBreak %s\n", (ShellProtocol->GetPageBreak()) ? L"enabled" : L"disabled");

ShellProtocol->EnablePageBreak();
```

But I still want to know, how to get automatic `-b` parameter parsing in your apps.

Also with this approach I've noticed that the `PageBreak` is always disabled at the start of an application. Why is this happening if `EFI_SHELL_PROTOCOL` is a global protocol? Why `PageBreak` is not enabled on the second launch of my application?


failure in building unit test locally

wenyi,xie
 

Hello, everyone

I want to build unit test locally, my environment is win10, python 3.9.6, VS2019.
I excute the command according to steps in the ReadMe.
1. stuart_setup -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019
2. stuart_update -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019
3. stuart_ci_build -c ./.pytool/CISettings.py TOOL_CHAIN_TAG=VS2019 -t NOOPT -p MdePkg

In step 3, the log is just stopped at "Running Build NOOPT", how do I know the cause of the build failure ?
SECTION - Init SDE
WARNING - Using Pip Tools based BaseTools
SECTION - Loading Plugins
SECTION - Start Invocable Tool
SECTION - Getting Environment
SECTION - Loading plugins
SECTION - Building MdePkg Package
PROGRESS - --Running MdePkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - Allowing Override for key TARGET_ARCH
PROGRESS - Start time: 2021-07-20 16:55:27.953832
PROGRESS - Setting up the Environment
PROGRESS - Running Pre Build
PROGRESS - Running Build NOOPT


How to get page break functionality in UEFI applications

Konstantin Aladyshev
 

All UEFI shell commands have page break functionality.
If the command is called with the "-b" argument and the output is too
long, output would be splitted to pages with this message after each
page:
```
Press ENTER to continue or 'Q' break:
```
How to get this functionality in your custom UEFI applications?

I've tried to use `ShellCEntryLib` as the entry point and have changed
all of my `Print(...)` statements to the `ShellPrintEx(-1,-1,...)` in
my UEFI application, but none of that have worked.

From the inspection of code I see that the aforementioned string is
defined in a file
https://github.com/tianocore/edk2/blob/master/ShellPkg/Application/Shell/Shell.uni
and used in a file
https://github.com/tianocore/edk2/blob/master/ShellPkg/Application/Shell/ConsoleLogger.c
in a `ConsoleLoggerPrintWithPageBreak` function.

`ConsoleLoggerPrintWithPageBreak` is called from the
`ConsoleLoggerOutputString` function, which itself is set to the
`(*ConsoleInfo)->OurConOut.OutputString`.

But in the same file I see:
`gST->ConOut = &(*ConsoleInfo)->OurConOut;`

As the `Print` function uses `gST->ConOut->OutputString` internally,
in the end it looks like it should call
`ConsoleLoggerPrintWithPageBreak`. But apparently this is not
happening? Why? What am I missing here?

ShellLib library class is included in my DSC file:
```
[LibraryClasses]
ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
```
As `-?` option produces some output, I guess command line argument
parsing is happening successfully:
```
FS0:\> GOPInfo.efi -?
No help could be found for command 'GOPInfo.efi'.
```

Best regards,
Konstantin Aladyshev


Re: EFI_PIXEL_BITMASK

Konstantin Aladyshev
 

Thanks for the explanation!

Here are my investigations to complete this conversation.

https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.dsc
```
DEFINE SOURCE_DEBUG_ENABLE = FALSE
...
!if $(SOURCE_DEBUG_ENABLE) == TRUE
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x17
!else
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
!endif
```

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/DebugLib.h
```
//
// Declare bits for PcdDebugPropertyMask
//
#define DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED 0x01
#define DEBUG_PROPERTY_DEBUG_PRINT_ENABLED 0x02
#define DEBUG_PROPERTY_DEBUG_CODE_ENABLED 0x04
#define DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED 0x08
#define DEBUG_PROPERTY_ASSERT_BREAKPOINT_ENABLED 0x10
#define DEBUG_PROPERTY_ASSERT_DEADLOOP_ENABLED 0x20
```
Therefore DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED is set when SOURCE_DEBUG_ENABLE
is FALSE.

With this knowledge I've tried to recompile OVMF:
```
build --platform=OvmfPkg/OvmfPkgX64.dsc --arch=X64 --buildtarget=RELEASE
--tagname=GCC5 -D SOURCE_DEBUG_ENABLE
```

And this indeed has changed bitmask values from 0xAF to some random garbage:
```
Pixel bitmask: R(0x00000005) G(0x00000000) B(0x07AC9000)
```

Best regards,
Konstantin Aladyshev

On Thu, Jul 15, 2021 at 11:15 PM Andrew Fish <afish@apple.com> wrote:



On Jul 15, 2021, at 12:36 PM, Konstantin Aladyshev <aladyshev22@gmail.com>
wrote:

Thanks Andrew!
I've missed that part in the spec.
In my case:
```
Pixel format: 1
```
So according to the

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/GraphicsOutput.h
my pixel format is `PixelBlueGreenRedReserved8BitPerColor`. You are
correct.
```
typedef enum {
PixelRedGreenBlueReserved8BitPerColor,
PixelBlueGreenRedReserved8BitPerColor,
PixelBitMask,
PixelBltOnly,
PixelFormatMax
} EFI_GRAPHICS_PIXEL_FORMAT;
```

When I used `dmem` in UEFI shell I've always wondered why all
uninitialized memory has this strange 0xAF value.
It's very interesting to know that it was named after you)
I've tried to find the exact commit to look at the commit message that
added this feature, but unfortunately it was before git. In the first
git commit this PCD is already present.

https://github.com/tianocore/edk2/commit/e053747a04ad7b8d71c7593b93e1575ba0057a91#diff-3de08afb0837cd4b0283b60925b72da84b616967cff4301d12929654946e75c8


Vincent added the 0xAF convention back in the early Itanium days so it
goes back to the original Intel EFI code base, so way back… Before edk2,
and before the original EDK. Ha Ha so it is actually older than git, that
is your problem :).

But I have to notice that both OVMF and my app were built in the RELEASE
mode



https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.dsc#L543
OvmfPkg/OvmfPkgX64.dsc
!if $(SOURCE_DEBUG_ENABLE) == TRUE
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x17
!else
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
!endif

Given:

https://github.com/tianocore/edk2/blob/master/MdePkg/MdePkg.dec#L2200
## The mask is used to control DebugLib behavior.<BR><BR>
# BIT0 - Enable Debug Assert.<BR>
# BIT1 - Enable Debug Print.<BR>
# BIT2 - Enable Debug Code.<BR>
# BIT3 - Enable Clear Memory.<BR>
# BIT4 - Enable BreakPoint as ASSERT.<BR>
# BIT5 - Enable DeadLoop as ASSERT.<BR>
# @Prompt Debug Property.
# @Expression 0x80000002 |
(gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask & 0xC0) == 0
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0|UINT8|0x00000005


So it looks like OVMF has the same settings for DEBUG and RELEASE builds.
That matches what you are seeing.


This is how the DebugLib hooks all this in.


https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/DebugLib.h#L543

#define DEBUG_CLEAR_MEMORY(Address, Length) \
do { \
if (DebugClearMemoryEnabled ()) { \
DebugClearMemory (Address, Length); \
} \
} while (FALSE)


https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/DebugLib.h#L252
/**
Returns TRUE if DEBUG_CLEAR_MEMORY() macro is enabled.
This function returns TRUE if the DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED bit
of
PcdDebugProperyMask is set. Otherwise, FALSE is returned.
@retval TRUE The DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED bit of
PcdDebugProperyMask is set.
@retval FALSE The DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED bit of
PcdDebugProperyMask is clear.
**/
BOOLEAN
EFIAPI
DebugClearMemoryEnabled (
VOID
);

If you search for DEBUG_CLEAR_MEMORY that is the code in the DXE Core (
MdeModulePkg/Core/Dxe/Mem/Pool.c) that is doing the clear on free.

Thanks,

Andrew Fish


Best regards,
Konstantin Aladyshev

On Thu, Jul 15, 2021 at 8:54 PM Andrew Fish <afish@apple.com> wrote:




On Jul 15, 2021, at 10:09 AM, Konstantin Aladyshev <aladyshev22@gmail.com>
wrote:

I've written an UEFI_APPLICATION that shows the current GOP mode
information.
This is example output from it, when it is run in the UEFI shell of
OVMF under QEMU:
```
FS0:\> GOPInfo.efi
Framebuffer base: 0000000080000000
Framebuffer size: 0000000000500000

Current mode: 14
Version: 0
Resolution: 1280x1024
Pixel format: 1
Pixel bitmask: R(0xAFAFAFAF) G(0xAFAFAFAF) B(0xAFAFAFAF)


Konstantin,

If you look more closely at the UEFI Spec you will see that
EFI_PIXEL_BITMASK (PixelInformation) is only valid if PixelFormat ==
PixelBlitMask. PixelRedGreenBlueReserved8BitPerColor and
PixelBlueGreenRedReserved8BitPerColor define a specific mapping for the
bits. So you should only display EFI_PIXEL_BITMASK if PixelFormat ==
PixelBitMask. Looks like in your case it is
PixelBlueGreenRedReserved8BitPerColor?


FYI 0xAF (my initials thanks to Vincent Zimmer) is the pattern for cleared
memory. The DEBUG_CLEAR_MEMORY() function is called by the DXE Core when
pool is freed. It is usually only enabled on a DEBUG build. The value comes
from PcdDebugClearMemoryValue

$ git grep PcdDebugClearMemoryValue -- *.dec
MdePkg/MdePkg.dec:2242:
gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF|UINT8|0x00000008

So the value never got initialized and it is a reused allocation thus the
malloc buffer in the QEMU graphics driver is full of 0xAF. This is also a
common patter on use after free bugs.

Thanks,

Andrew Fish

PixelsPerScanLine: 1280
```
My question is about the `Pixel bitmask` string. According to the UEFI
specification it is defined like this:
```
typedef struct {
UINT32 RedMask;
UINT32 GreenMask;
UINT32 BlueMask;
UINT32 ReservedMask;
} EFI_PIXEL_BITMASK;

If a bit is set in RedMask, GreenMask, or BlueMask then those bits of
the pixel represent the corresponding color. Bits in RedMask,
GreenMask, BlueMask, and ReserverdMask must not overlap bit positions.
The values for the red, green, and blue components in the bit mask
represent the color intensity. The color intensities must increase as
the color values for a each color mask increase with a minimum
intensity of all bits in a color mask clear to a maximum intensity of
all bits in a color mask set.
```

From this definition I was expecting something like this:
```
Pixel bitmask: R(0x00FF0000) G(0x0000FF00) B(0x000000FF)
```
But my program gives me this:
```
Pixel bitmask: R(0xAFAFAFAF) G(0xAFAFAFAF) B(0xAFAFAFAF)
```
What does it mean?

Just in case I did something silly here is a code of my simple app:
```
VOID PrintGOPModeInfo(EFI_GRAPHICS_OUTPUT_MODE_INFORMATION* GOPModeInfo)
{
Print(L"Version: %x\n", GOPModeInfo->Version);
Print(L"Resolution: %dx%d\n", GOPModeInfo->HorizontalResolution,
GOPModeInfo->VerticalResolution);
Print(L"Pixel format: %d\n", GOPModeInfo->PixelFormat);
Print(L"Pixel bitmask: R(0x%08x) G(0x%08x) B(0x%08x)\n",
GOPModeInfo->PixelInformation.RedMask,

GOPModeInfo->PixelInformation.GreenMask,

GOPModeInfo->PixelInformation.BlueMask);

Print(L"PixelsPerScanLine: %d\n", GOPModeInfo->PixelsPerScanLine);
}


EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_GRAPHICS_OUTPUT_PROTOCOL* GOP;

EFI_STATUS Status = gBS->LocateProtocol(
&gEfiGraphicsOutputProtocolGuid,
NULL,
(VOID **)&GOP);
if (EFI_ERROR(Status)) {
Print(L"Can't get GOP: %r\n", Status);
return Status;
}
Print(L"Framebuffer base: %016llx\n", GOP->Mode->FrameBufferBase);
Print(L"Framebuffer size: %016llx\n", GOP->Mode->FrameBufferSize);

Print(L"\n");
Print(L"Current mode: %d\n", GOP->Mode->Mode);
PrintGOPModeInfo(GOP->Mode->Info);
return EFI_SUCCESS;
}
```

Best regards,
Konstantin Aladyshev








Re: EFI_PIXEL_BITMASK

Andrew Fish
 

On Jul 15, 2021, at 12:36 PM, Konstantin Aladyshev <aladyshev22@gmail.com> wrote:

Thanks Andrew!
I've missed that part in the spec.
In my case:
```
Pixel format: 1
```
So according to the
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/GraphicsOutput.h
my pixel format is `PixelBlueGreenRedReserved8BitPerColor`. You are
correct.
```
typedef enum {
PixelRedGreenBlueReserved8BitPerColor,
PixelBlueGreenRedReserved8BitPerColor,
PixelBitMask,
PixelBltOnly,
PixelFormatMax
} EFI_GRAPHICS_PIXEL_FORMAT;
```

When I used `dmem` in UEFI shell I've always wondered why all
uninitialized memory has this strange 0xAF value.
It's very interesting to know that it was named after you)
I've tried to find the exact commit to look at the commit message that
added this feature, but unfortunately it was before git. In the first
git commit this PCD is already present.
https://github.com/tianocore/edk2/commit/e053747a04ad7b8d71c7593b93e1575ba0057a91#diff-3de08afb0837cd4b0283b60925b72da84b616967cff4301d12929654946e75c8
Vincent added the 0xAF convention back in the early Itanium days so it goes back to the original Intel EFI code base, so way back… Before edk2, and before the original EDK. Ha Ha so it is actually older than git, that is your problem :).

But I have to notice that both OVMF and my app were built in the RELEASE mode

https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.dsc#L543
OvmfPkg/OvmfPkgX64.dsc
!if $(SOURCE_DEBUG_ENABLE) == TRUE
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x17
!else
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
!endif

Given:

https://github.com/tianocore/edk2/blob/master/MdePkg/MdePkg.dec#L2200
## The mask is used to control DebugLib behavior.<BR><BR>
# BIT0 - Enable Debug Assert.<BR>
# BIT1 - Enable Debug Print.<BR>
# BIT2 - Enable Debug Code.<BR>
# BIT3 - Enable Clear Memory.<BR>
# BIT4 - Enable BreakPoint as ASSERT.<BR>
# BIT5 - Enable DeadLoop as ASSERT.<BR>
# @Prompt Debug Property.
# @Expression 0x80000002 | (gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask & 0xC0) == 0
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0|UINT8|0x00000005


So it looks like OVMF has the same settings for DEBUG and RELEASE builds. That matches what you are seeing.


This is how the DebugLib hooks all this in.

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/DebugLib.h#L543

#define DEBUG_CLEAR_MEMORY(Address, Length) \
do { \
if (DebugClearMemoryEnabled ()) { \
DebugClearMemory (Address, Length); \
} \
} while (FALSE)

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/DebugLib.h#L252
/**
Returns TRUE if DEBUG_CLEAR_MEMORY() macro is enabled.
This function returns TRUE if the DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED bit of
PcdDebugProperyMask is set. Otherwise, FALSE is returned.
@retval TRUE The DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED bit of PcdDebugProperyMask is set.
@retval FALSE The DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED bit of PcdDebugProperyMask is clear.
**/
BOOLEAN
EFIAPI
DebugClearMemoryEnabled (
VOID
);

If you search for DEBUG_CLEAR_MEMORY that is the code in the DXE Core (MdeModulePkg/Core/Dxe/Mem/Pool.c) that is doing the clear on free.

Thanks,

Andrew Fish


Best regards,
Konstantin Aladyshev

On Thu, Jul 15, 2021 at 8:54 PM Andrew Fish <afish@apple.com> wrote:



On Jul 15, 2021, at 10:09 AM, Konstantin Aladyshev <aladyshev22@gmail.com> wrote:

I've written an UEFI_APPLICATION that shows the current GOP mode information.
This is example output from it, when it is run in the UEFI shell of
OVMF under QEMU:
```
FS0:\> GOPInfo.efi
Framebuffer base: 0000000080000000
Framebuffer size: 0000000000500000

Current mode: 14
Version: 0
Resolution: 1280x1024
Pixel format: 1
Pixel bitmask: R(0xAFAFAFAF) G(0xAFAFAFAF) B(0xAFAFAFAF)


Konstantin,

If you look more closely at the UEFI Spec you will see that EFI_PIXEL_BITMASK (PixelInformation) is only valid if PixelFormat == PixelBlitMask. PixelRedGreenBlueReserved8BitPerColor and PixelBlueGreenRedReserved8BitPerColor define a specific mapping for the bits. So you should only display EFI_PIXEL_BITMASK if PixelFormat == PixelBitMask. Looks like in your case it is PixelBlueGreenRedReserved8BitPerColor?


FYI 0xAF (my initials thanks to Vincent Zimmer) is the pattern for cleared memory. The DEBUG_CLEAR_MEMORY() function is called by the DXE Core when pool is freed. It is usually only enabled on a DEBUG build. The value comes from PcdDebugClearMemoryValue

$ git grep PcdDebugClearMemoryValue -- *.dec
MdePkg/MdePkg.dec:2242: gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF|UINT8|0x00000008

So the value never got initialized and it is a reused allocation thus the malloc buffer in the QEMU graphics driver is full of 0xAF. This is also a common patter on use after free bugs.

Thanks,

Andrew Fish

PixelsPerScanLine: 1280
```
My question is about the `Pixel bitmask` string. According to the UEFI
specification it is defined like this:
```
typedef struct {
UINT32 RedMask;
UINT32 GreenMask;
UINT32 BlueMask;
UINT32 ReservedMask;
} EFI_PIXEL_BITMASK;

If a bit is set in RedMask, GreenMask, or BlueMask then those bits of
the pixel represent the corresponding color. Bits in RedMask,
GreenMask, BlueMask, and ReserverdMask must not overlap bit positions.
The values for the red, green, and blue components in the bit mask
represent the color intensity. The color intensities must increase as
the color values for a each color mask increase with a minimum
intensity of all bits in a color mask clear to a maximum intensity of
all bits in a color mask set.
```

From this definition I was expecting something like this:
```
Pixel bitmask: R(0x00FF0000) G(0x0000FF00) B(0x000000FF)
```
But my program gives me this:
```
Pixel bitmask: R(0xAFAFAFAF) G(0xAFAFAFAF) B(0xAFAFAFAF)
```
What does it mean?

Just in case I did something silly here is a code of my simple app:
```
VOID PrintGOPModeInfo(EFI_GRAPHICS_OUTPUT_MODE_INFORMATION* GOPModeInfo)
{
Print(L"Version: %x\n", GOPModeInfo->Version);
Print(L"Resolution: %dx%d\n", GOPModeInfo->HorizontalResolution,
GOPModeInfo->VerticalResolution);
Print(L"Pixel format: %d\n", GOPModeInfo->PixelFormat);
Print(L"Pixel bitmask: R(0x%08x) G(0x%08x) B(0x%08x)\n",
GOPModeInfo->PixelInformation.RedMask,

GOPModeInfo->PixelInformation.GreenMask,

GOPModeInfo->PixelInformation.BlueMask);

Print(L"PixelsPerScanLine: %d\n", GOPModeInfo->PixelsPerScanLine);
}


EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_GRAPHICS_OUTPUT_PROTOCOL* GOP;

EFI_STATUS Status = gBS->LocateProtocol(
&gEfiGraphicsOutputProtocolGuid,
NULL,
(VOID **)&GOP);
if (EFI_ERROR(Status)) {
Print(L"Can't get GOP: %r\n", Status);
return Status;
}
Print(L"Framebuffer base: %016llx\n", GOP->Mode->FrameBufferBase);
Print(L"Framebuffer size: %016llx\n", GOP->Mode->FrameBufferSize);

Print(L"\n");
Print(L"Current mode: %d\n", GOP->Mode->Mode);
PrintGOPModeInfo(GOP->Mode->Info);
return EFI_SUCCESS;
}
```

Best regards,
Konstantin Aladyshev






Re: EFI_PIXEL_BITMASK

Konstantin Aladyshev
 

Thanks Andrew!
I've missed that part in the spec.
In my case:
```
Pixel format: 1
```
So according to the
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/GraphicsOutput.h
my pixel format is `PixelBlueGreenRedReserved8BitPerColor`. You are
correct.
```
typedef enum {
PixelRedGreenBlueReserved8BitPerColor,
PixelBlueGreenRedReserved8BitPerColor,
PixelBitMask,
PixelBltOnly,
PixelFormatMax
} EFI_GRAPHICS_PIXEL_FORMAT;
```

When I used `dmem` in UEFI shell I've always wondered why all
uninitialized memory has this strange 0xAF value.
It's very interesting to know that it was named after you)
I've tried to find the exact commit to look at the commit message that
added this feature, but unfortunately it was before git. In the first
git commit this PCD is already present.
https://github.com/tianocore/edk2/commit/e053747a04ad7b8d71c7593b93e1575ba0057a91#diff-3de08afb0837cd4b0283b60925b72da84b616967cff4301d12929654946e75c8

But I have to notice that both OVMF and my app were built in the RELEASE mode


Best regards,
Konstantin Aladyshev

On Thu, Jul 15, 2021 at 8:54 PM Andrew Fish <afish@apple.com> wrote:



On Jul 15, 2021, at 10:09 AM, Konstantin Aladyshev <aladyshev22@gmail.com> wrote:

I've written an UEFI_APPLICATION that shows the current GOP mode information.
This is example output from it, when it is run in the UEFI shell of
OVMF under QEMU:
```
FS0:\> GOPInfo.efi
Framebuffer base: 0000000080000000
Framebuffer size: 0000000000500000

Current mode: 14
Version: 0
Resolution: 1280x1024
Pixel format: 1
Pixel bitmask: R(0xAFAFAFAF) G(0xAFAFAFAF) B(0xAFAFAFAF)


Konstantin,

If you look more closely at the UEFI Spec you will see that EFI_PIXEL_BITMASK (PixelInformation) is only valid if PixelFormat == PixelBlitMask. PixelRedGreenBlueReserved8BitPerColor and PixelBlueGreenRedReserved8BitPerColor define a specific mapping for the bits. So you should only display EFI_PIXEL_BITMASK if PixelFormat == PixelBitMask. Looks like in your case it is PixelBlueGreenRedReserved8BitPerColor?


FYI 0xAF (my initials thanks to Vincent Zimmer) is the pattern for cleared memory. The DEBUG_CLEAR_MEMORY() function is called by the DXE Core when pool is freed. It is usually only enabled on a DEBUG build. The value comes from PcdDebugClearMemoryValue

$ git grep PcdDebugClearMemoryValue -- *.dec
MdePkg/MdePkg.dec:2242: gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF|UINT8|0x00000008

So the value never got initialized and it is a reused allocation thus the malloc buffer in the QEMU graphics driver is full of 0xAF. This is also a common patter on use after free bugs.

Thanks,

Andrew Fish

PixelsPerScanLine: 1280
```
My question is about the `Pixel bitmask` string. According to the UEFI
specification it is defined like this:
```
typedef struct {
UINT32 RedMask;
UINT32 GreenMask;
UINT32 BlueMask;
UINT32 ReservedMask;
} EFI_PIXEL_BITMASK;

If a bit is set in RedMask, GreenMask, or BlueMask then those bits of
the pixel represent the corresponding color. Bits in RedMask,
GreenMask, BlueMask, and ReserverdMask must not overlap bit positions.
The values for the red, green, and blue components in the bit mask
represent the color intensity. The color intensities must increase as
the color values for a each color mask increase with a minimum
intensity of all bits in a color mask clear to a maximum intensity of
all bits in a color mask set.
```

From this definition I was expecting something like this:
```
Pixel bitmask: R(0x00FF0000) G(0x0000FF00) B(0x000000FF)
```
But my program gives me this:
```
Pixel bitmask: R(0xAFAFAFAF) G(0xAFAFAFAF) B(0xAFAFAFAF)
```
What does it mean?

Just in case I did something silly here is a code of my simple app:
```
VOID PrintGOPModeInfo(EFI_GRAPHICS_OUTPUT_MODE_INFORMATION* GOPModeInfo)
{
Print(L"Version: %x\n", GOPModeInfo->Version);
Print(L"Resolution: %dx%d\n", GOPModeInfo->HorizontalResolution,
GOPModeInfo->VerticalResolution);
Print(L"Pixel format: %d\n", GOPModeInfo->PixelFormat);
Print(L"Pixel bitmask: R(0x%08x) G(0x%08x) B(0x%08x)\n",
GOPModeInfo->PixelInformation.RedMask,

GOPModeInfo->PixelInformation.GreenMask,

GOPModeInfo->PixelInformation.BlueMask);

Print(L"PixelsPerScanLine: %d\n", GOPModeInfo->PixelsPerScanLine);
}


EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_GRAPHICS_OUTPUT_PROTOCOL* GOP;

EFI_STATUS Status = gBS->LocateProtocol(
&gEfiGraphicsOutputProtocolGuid,
NULL,
(VOID **)&GOP);
if (EFI_ERROR(Status)) {
Print(L"Can't get GOP: %r\n", Status);
return Status;
}
Print(L"Framebuffer base: %016llx\n", GOP->Mode->FrameBufferBase);
Print(L"Framebuffer size: %016llx\n", GOP->Mode->FrameBufferSize);

Print(L"\n");
Print(L"Current mode: %d\n", GOP->Mode->Mode);
PrintGOPModeInfo(GOP->Mode->Info);
return EFI_SUCCESS;
}
```

Best regards,
Konstantin Aladyshev






Re: EFI_PIXEL_BITMASK

Andrew Fish
 

On Jul 15, 2021, at 10:09 AM, Konstantin Aladyshev <aladyshev22@gmail.com> wrote:

I've written an UEFI_APPLICATION that shows the current GOP mode information.
This is example output from it, when it is run in the UEFI shell of
OVMF under QEMU:
```
FS0:\> GOPInfo.efi
Framebuffer base: 0000000080000000
Framebuffer size: 0000000000500000

Current mode: 14
Version: 0
Resolution: 1280x1024
Pixel format: 1
Pixel bitmask: R(0xAFAFAFAF) G(0xAFAFAFAF) B(0xAFAFAFAF)
Konstantin,

If you look more closely at the UEFI Spec you will see that EFI_PIXEL_BITMASK (PixelInformation) is only valid if PixelFormat == PixelBlitMask. PixelRedGreenBlueReserved8BitPerColor and PixelBlueGreenRedReserved8BitPerColor define a specific mapping for the bits. So you should only display EFI_PIXEL_BITMASK if PixelFormat == PixelBitMask. Looks like in your case it is PixelBlueGreenRedReserved8BitPerColor?


FYI 0xAF (my initials thanks to Vincent Zimmer) is the pattern for cleared memory. The DEBUG_CLEAR_MEMORY() function is called by the DXE Core when pool is freed. It is usually only enabled on a DEBUG build. The value comes from PcdDebugClearMemoryValue

$ git grep PcdDebugClearMemoryValue -- *.dec
MdePkg/MdePkg.dec:2242: gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF|UINT8|0x00000008

So the value never got initialized and it is a reused allocation thus the malloc buffer in the QEMU graphics driver is full of 0xAF. This is also a common patter on use after free bugs.

Thanks,

Andrew Fish

PixelsPerScanLine: 1280
```
My question is about the `Pixel bitmask` string. According to the UEFI
specification it is defined like this:
```
typedef struct {
UINT32 RedMask;
UINT32 GreenMask;
UINT32 BlueMask;
UINT32 ReservedMask;
} EFI_PIXEL_BITMASK;

If a bit is set in RedMask, GreenMask, or BlueMask then those bits of
the pixel represent the corresponding color. Bits in RedMask,
GreenMask, BlueMask, and ReserverdMask must not overlap bit positions.
The values for the red, green, and blue components in the bit mask
represent the color intensity. The color intensities must increase as
the color values for a each color mask increase with a minimum
intensity of all bits in a color mask clear to a maximum intensity of
all bits in a color mask set.
```

From this definition I was expecting something like this:
```
Pixel bitmask: R(0x00FF0000) G(0x0000FF00) B(0x000000FF)
```
But my program gives me this:
```
Pixel bitmask: R(0xAFAFAFAF) G(0xAFAFAFAF) B(0xAFAFAFAF)
```
What does it mean?

Just in case I did something silly here is a code of my simple app:
```
VOID PrintGOPModeInfo(EFI_GRAPHICS_OUTPUT_MODE_INFORMATION* GOPModeInfo)
{
Print(L"Version: %x\n", GOPModeInfo->Version);
Print(L"Resolution: %dx%d\n", GOPModeInfo->HorizontalResolution,
GOPModeInfo->VerticalResolution);
Print(L"Pixel format: %d\n", GOPModeInfo->PixelFormat);
Print(L"Pixel bitmask: R(0x%08x) G(0x%08x) B(0x%08x)\n",
GOPModeInfo->PixelInformation.RedMask,

GOPModeInfo->PixelInformation.GreenMask,

GOPModeInfo->PixelInformation.BlueMask);

Print(L"PixelsPerScanLine: %d\n", GOPModeInfo->PixelsPerScanLine);
}


EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_GRAPHICS_OUTPUT_PROTOCOL* GOP;

EFI_STATUS Status = gBS->LocateProtocol(
&gEfiGraphicsOutputProtocolGuid,
NULL,
(VOID **)&GOP);
if (EFI_ERROR(Status)) {
Print(L"Can't get GOP: %r\n", Status);
return Status;
}
Print(L"Framebuffer base: %016llx\n", GOP->Mode->FrameBufferBase);
Print(L"Framebuffer size: %016llx\n", GOP->Mode->FrameBufferSize);

Print(L"\n");
Print(L"Current mode: %d\n", GOP->Mode->Mode);
PrintGOPModeInfo(GOP->Mode->Info);
return EFI_SUCCESS;
}
```

Best regards,
Konstantin Aladyshev





EFI_PIXEL_BITMASK

Konstantin Aladyshev
 

I've written an UEFI_APPLICATION that shows the current GOP mode information.
This is example output from it, when it is run in the UEFI shell of
OVMF under QEMU:
```
FS0:\> GOPInfo.efi
Framebuffer base: 0000000080000000
Framebuffer size: 0000000000500000

Current mode: 14
Version: 0
Resolution: 1280x1024
Pixel format: 1
Pixel bitmask: R(0xAFAFAFAF) G(0xAFAFAFAF) B(0xAFAFAFAF)
PixelsPerScanLine: 1280
```
My question is about the `Pixel bitmask` string. According to the UEFI
specification it is defined like this:
```
typedef struct {
UINT32 RedMask;
UINT32 GreenMask;
UINT32 BlueMask;
UINT32 ReservedMask;
} EFI_PIXEL_BITMASK;

If a bit is set in RedMask, GreenMask, or BlueMask then those bits of
the pixel represent the corresponding color. Bits in RedMask,
GreenMask, BlueMask, and ReserverdMask must not overlap bit positions.
The values for the red, green, and blue components in the bit mask
represent the color intensity. The color intensities must increase as
the color values for a each color mask increase with a minimum
intensity of all bits in a color mask clear to a maximum intensity of
all bits in a color mask set.
```

From this definition I was expecting something like this:
```
Pixel bitmask: R(0x00FF0000) G(0x0000FF00) B(0x000000FF)
```
But my program gives me this:
```
Pixel bitmask: R(0xAFAFAFAF) G(0xAFAFAFAF) B(0xAFAFAFAF)
```
What does it mean?

Just in case I did something silly here is a code of my simple app:
```
VOID PrintGOPModeInfo(EFI_GRAPHICS_OUTPUT_MODE_INFORMATION* GOPModeInfo)
{
Print(L"Version: %x\n", GOPModeInfo->Version);
Print(L"Resolution: %dx%d\n", GOPModeInfo->HorizontalResolution,
GOPModeInfo->VerticalResolution);
Print(L"Pixel format: %d\n", GOPModeInfo->PixelFormat);
Print(L"Pixel bitmask: R(0x%08x) G(0x%08x) B(0x%08x)\n",
GOPModeInfo->PixelInformation.RedMask,

GOPModeInfo->PixelInformation.GreenMask,

GOPModeInfo->PixelInformation.BlueMask);

Print(L"PixelsPerScanLine: %d\n", GOPModeInfo->PixelsPerScanLine);
}


EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_GRAPHICS_OUTPUT_PROTOCOL* GOP;

EFI_STATUS Status = gBS->LocateProtocol(
&gEfiGraphicsOutputProtocolGuid,
NULL,
(VOID **)&GOP);
if (EFI_ERROR(Status)) {
Print(L"Can't get GOP: %r\n", Status);
return Status;
}
Print(L"Framebuffer base: %016llx\n", GOP->Mode->FrameBufferBase);
Print(L"Framebuffer size: %016llx\n", GOP->Mode->FrameBufferSize);

Print(L"\n");
Print(L"Current mode: %d\n", GOP->Mode->Mode);
PrintGOPModeInfo(GOP->Mode->Info);
return EFI_SUCCESS;
}
```

Best regards,
Konstantin Aladyshev


Re: State of the `edk2-libc` project

Rebecca Cran
 

I submitted a patch to fix it several weeks ago, but it never got committed.

Rebecca Cran

On Jul 14, 2021, at 11:36 AM, Konstantin Aladyshev <aladyshev22@gmail.com> wrote:

Hello!

What is the state of the `edk2-libc` project?

The last commit is dated Apr 29, 2019. I've tried to compile
`edk2-libc` with the master `edk2` and have come to some build issues.

For example this edk2 commit (13 Oct 2020 "MdePkg: Remove code wrapped
by DISABLE_NEW_DEPRECATED_INTERFACES"
https://github.com/tianocore/edk2/commit/9c1f455f5f0ee63ce080940bf974aac4fefe526b)
have dropped support for several functions, but these functions are
still used in `edk2-libs`:
- `StrCpy` and `StrCpy` functions are used in
https://github.com/tianocore/edk2-libc/blob/master/StdLib/LibC/Wchar/Copying.c
- `AsciiStrCat` and `AsciiStrnCat` functions are used in
https://github.com/tianocore/edk2-libc/blob/master/StdLib/LibC/String/Concatenation.c
In the modern `edk2` all these old functions are replaced with their
safe versions (StrCpyS, StrCpyS, AsciiStrCatS, AsciiStrnCatS).

My question is should these unsafe string functions be deprecated in
the `edk2-libc` as well? And more importantly does the tianocore
community have any plans for support of `edk2-libc` project or can it
be counted as obsolete?

Best regards,
Konstantin Aladyshev





State of the `edk2-libc` project

Konstantin Aladyshev
 

Hello!

What is the state of the `edk2-libc` project?

The last commit is dated Apr 29, 2019. I've tried to compile
`edk2-libc` with the master `edk2` and have come to some build issues.

For example this edk2 commit (13 Oct 2020 "MdePkg: Remove code wrapped
by DISABLE_NEW_DEPRECATED_INTERFACES"
https://github.com/tianocore/edk2/commit/9c1f455f5f0ee63ce080940bf974aac4fefe526b)
have dropped support for several functions, but these functions are
still used in `edk2-libs`:
- `StrCpy` and `StrCpy` functions are used in
https://github.com/tianocore/edk2-libc/blob/master/StdLib/LibC/Wchar/Copying.c
- `AsciiStrCat` and `AsciiStrnCat` functions are used in
https://github.com/tianocore/edk2-libc/blob/master/StdLib/LibC/String/Concatenation.c
In the modern `edk2` all these old functions are replaced with their
safe versions (StrCpyS, StrCpyS, AsciiStrCatS, AsciiStrnCatS).

My question is should these unsafe string functions be deprecated in
the `edk2-libc` as well? And more importantly does the tianocore
community have any plans for support of `edk2-libc` project or can it
be counted as obsolete?

Best regards,
Konstantin Aladyshev


Re: Should we keep 'EFI_KEY_DATA' argument after 'RegisterKeyNotify()' function call?

Andrew Fish
 

On Jul 13, 2021, at 10:13 AM, Konstantin Aladyshev <aladyshev22@gmail.com> wrote:

Hello!

According to the UEFI specification
`EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.RegisterKeyNotify()` function
registers a notification function for a particular keystroke for the
input device.

Its prototype is:
```
typedef
EFI_STATUS
(EFIAPI *EFI_REGISTER_KEYSTROKE_NOTIFY) (
IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This,
IN EFI_KEY_DATA *KeyData,
IN EFI_KEY_NOTIFY_FUNCTION KeyNotificationFunction,
OUT VOID **NotifyHandle
);
```

I want to use this function in my driver. My question is about the
`KeyData` argument. Do I need to keep it in memory after a
`RegisterKeyNotify` function call? For example, use allocate services
for `KeyData` memory, or simply declare it as a global variable. Or we
can create `KeyData` as a local function variable on stack?

The `KeyData` argument is passed by reference and it is unclear to me
whether it should be kept in memory or not.
I’d say it needs to be valid until you EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.UnregisterKeyNotify() and unhook your function.

Thanks,

Andrew Fish

Best regards,
Konstantin Aladyshev





gcc compile warning

wenyi,xie
 

After updating edk2 from 201903 to 202011, when using gcc to compile our platform(aarch64) code, we meet a warning
warning: '-x c' after last input file has no effect

We compare the code and find the root cause is that $(ASLCC_FLAGS) was added twice in section of [Acpi-Table-Code-File] in build_rule.template
So I wonder if it's a problem.


Should we keep 'EFI_KEY_DATA' argument after 'RegisterKeyNotify()' function call?

Konstantin Aladyshev
 

Hello!

According to the UEFI specification
`EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.RegisterKeyNotify()` function
registers a notification function for a particular keystroke for the
input device.

Its prototype is:
```
typedef
EFI_STATUS
(EFIAPI *EFI_REGISTER_KEYSTROKE_NOTIFY) (
IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This,
IN EFI_KEY_DATA *KeyData,
IN EFI_KEY_NOTIFY_FUNCTION KeyNotificationFunction,
OUT VOID **NotifyHandle
);
```

I want to use this function in my driver. My question is about the
`KeyData` argument. Do I need to keep it in memory after a
`RegisterKeyNotify` function call? For example, use allocate services
for `KeyData` memory, or simply declare it as a global variable. Or we
can create `KeyData` as a local function variable on stack?

The `KeyData` argument is passed by reference and it is unclear to me
whether it should be kept in memory or not.

Best regards,
Konstantin Aladyshev


Re: edk2toolext based build workspace question

Sean
 

Jeff,

All the stuart tools (edk2toolext) require a configuration file. For edk2 the file is

https://github.com/tianocore/edk2/blob/master/.pytool/CISettings.py

In this file you can see the workspace is controlled here:
https://github.com/tianocore/edk2/blob/master/.pytool/CISettings.py#L205
as well as the packages path here:
https://github.com/tianocore/edk2/blob/master/.pytool/CISettings.py#L202

The intent is for your repo you would have your own CISettings.py where you would configure your workspace and packages path.

The log files are created in <workspace>/Build/<filename>

<workspace>: is controlled by your CISettings as mentioned above.
<filename>: Invokable invoked controls the name. Example for CI build -
https://github.com/tianocore/edk2-pytool-extensions/blob/master/edk2toolext/invocables/edk2_ci_build.py#L46

The edk2 conf is created at <workspace>/Conf as you can see here:
https://github.com/tianocore/edk2-pytool-extensions/blob/9400bfd0162a0da40f14f7f7154ac6097de43302/edk2toolext/environment/uefi_build.py#L379

And build binary output is controlled by edk2 build process using the OUTPUT_DIRECTORY variable generally defined in your DSC:
https://github.com/tianocore/edk2-pytool-extensions/blob/9400bfd0162a0da40f14f7f7154ac6097de43302/edk2toolext/environment/uefi_build.py#L406

You could also set that in your command line.


Just for information:

I tried to do this with edk2 so I had a tree like

/test1 <workspace>
/edk2 <packages path>

I then updated edk2 CI settings to use test1 as the workspace root and edk2 as a packages path. This moved the output into /test1/Build and /test1/Conf but it doesn't completely work because if you are using git submodules (and stuart_setup) there is an assumption that the repo you are testing is the workspace. This makes sense because your repo is what is in your control. You can't control a folder above your repo. I have seen many projects setup that use a readme file to require you to configure a workspace differently but to be honest I don't think that is valid. That leads to a fragile repo configuration that doesn't scale and/or can't be included in other projects. pytools took the approach that repos can only control what is in them and not the larger environment they may be a part of.

So the above breaks that rule and doesn't work. Now I am confident that if you were building a platform and included edk2 in your repository as a submodule it would work fine. Also if you updated edk2 to have a new root folder and updated all the git submodules correctly the above change would work too. For platform building this mainly impacts "stuart_setup" because stuart_setup uses submodules. In stuart_ci_build I do see that some of the edk2 plugins (ecccheck and patchcheck) which try to use git commands fail. Again this is because the workspace is assumed to be the git repo root. If there is a desire to change the assumption between workspace being a repo root that would a new conversation but as mentioned above I don't think that is scalable design.

Anyway, lots of options. I am on the discord channel (https://discord.gg/WAzZbrF7) if you would like to have a faster back and forth discussion. If you find an issue or even a question in the pytools please file it here https://github.com/tianocore/edk2-pytool-extensions/issues but it sounds like you might have a solution.

Thanks
Sean

On 7/8/2021 11:32 AM, Jeff Brasen wrote:
Basically, the workspace directory that is used in the scripts seem to assume that there are files under there already, as opposed to just an out directory as we use it and use packages path to search everything. It seems to search for a bunch of things based on that prior to calling the edk2 build subsystem. I think we found another way to support that with our CI system so I think I can work with the current behavior.
Thanks,
Jeff
________________________________
From: discuss@edk2.groups.io <discuss@edk2.groups.io> on behalf of Sean via groups.io <spbrogan=outlook.com@groups.io>
Sent: Tuesday, July 6, 2021 8:55 PM
To: discuss@edk2.groups.io <discuss@edk2.groups.io>; Jeff Brasen <jbrasen@nvidia.com>
Subject: Re: [edk2-discuss] edk2toolext based build workspace question
External email: Use caution opening links or attachments
Can you elaborate more on what you have tried. What files are causing problems? The build output should be handled the same as any edk2 build
Thanks
Sean
________________________________
From: discuss@edk2.groups.io <discuss@edk2.groups.io> on behalf of Jeff Brasen <jbrasen@nvidia.com>
Sent: Tuesday, July 6, 2021 9:14:14 AM
To: discuss@edk2.groups.io <discuss@edk2.groups.io>
Subject: [edk2-discuss] edk2toolext based build workspace question
I am looking at converting our build from using a bunch of custom scripts/makefiles around the UEFI build process to the edk2toolext based python builder and am running into an Issue. Our overall build automation system whats to keep the source directory unchanged with all build output in another directory. I am supporting this currently by having WORKSPACE point to the specified out directory and PACKAGES_PATH pointing to our source. However if I have workspace point somewhere else with edk2toolext it seems like it requires the workspace to be with the sources. Is this something that can be done or is just a limitation/design feature of this build system?
Thanks,
Jeff


Re: edk2toolext based build workspace question

Jeff Brasen
 

Basically, the workspace directory that is used in the scripts seem to assume that there are files under there already, as opposed to just an out directory as we use it and use packages path to search everything. It seems to search for a bunch of things based on that prior to calling the edk2 build subsystem. I think we found another way to support that with our CI system so I think I can work with the current behavior.


Thanks,

Jeff

________________________________
From: discuss@edk2.groups.io <discuss@edk2.groups.io> on behalf of Sean via groups.io <spbrogan=outlook.com@groups.io>
Sent: Tuesday, July 6, 2021 8:55 PM
To: discuss@edk2.groups.io <discuss@edk2.groups.io>; Jeff Brasen <jbrasen@nvidia.com>
Subject: Re: [edk2-discuss] edk2toolext based build workspace question

External email: Use caution opening links or attachments


Can you elaborate more on what you have tried. What files are causing problems? The build output should be handled the same as any edk2 build

Thanks
Sean
________________________________
From: discuss@edk2.groups.io <discuss@edk2.groups.io> on behalf of Jeff Brasen <jbrasen@nvidia.com>
Sent: Tuesday, July 6, 2021 9:14:14 AM
To: discuss@edk2.groups.io <discuss@edk2.groups.io>
Subject: [edk2-discuss] edk2toolext based build workspace question

I am looking at converting our build from using a bunch of custom scripts/makefiles around the UEFI build process to the edk2toolext based python builder and am running into an Issue. Our overall build automation system whats to keep the source directory unchanged with all build output in another directory. I am supporting this currently by having WORKSPACE point to the specified out directory and PACKAGES_PATH pointing to our source. However if I have workspace point somewhere else with edk2toolext it seems like it requires the workspace to be with the sources. Is this something that can be done or is just a limitation/design feature of this build system?

Thanks,
Jeff

61 - 80 of 860