Date   

Re: [EXTERNAL] Re: [edk2-discuss] failure in building unit test locally

Bret Barkelew
 

Thanks for your follow-up. This is a known limitation that we have worked to resolve but ran into some unknown/unexpected errors. We definitely want to support both traditional and simplified character sets (as well as any other character sets), but if I recall there were some ambiguous OS mechanisms at work.

We would appreciate any help or contributions to get these character sets supported, but I understand if you don’t have the time.

I thought we already had an issue open to track it, but I couldn’t find it so I created a new one here:
Support non-ASCII character sets in Stuart tools · Issue #267 · tianocore/edk2-pytool-extensions (github.com)<https://github.com/tianocore/edk2-pytool-extensions/issues/267>

We can mark it as a duplicate if I find the original report.

- Bret

From: wenyi,xie via groups.io<mailto:xiewenyi2=huawei.com@groups.io>
Sent: Monday, July 26, 2021 12:53 AM
To: Sean Brogan<mailto:spbrogan@outlook.com>; discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>
Subject: [EXTERNAL] Re: [edk2-discuss] failure in building unit test locally

Hi, everyone

I have found the root cause of failure, it's because the language in my windows is Chinese, and the software not support Unicode will use gbk as the coding format.
After I change the language, the problem is solved.

Thanks
Wenyi

On 2021/7/21 10:56, xiewenyi (A) wrote:
Hi,Sean

I have upload the log to github, link is like below.
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fleadsama%2FShowLog%2Fblob%2Fmain%2FREADME.md&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C990acd0e770447c7a28b08d9500a7dea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637628828276590927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cqhTkl5QFXsXwnq%2F0DYHfWieHhOiPsxTRgBKBkJhhsE%3D&amp;reserved=0

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

wenyi,xie
 

Hi, everyone

I have found the root cause of failure, it's because the language in my windows is Chinese, and the software not support Unicode will use gbk as the coding format.
After I change the language, the problem is solved.

Thanks
Wenyi

On 2021/7/21 10:56, xiewenyi (A) wrote:
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




.


how to use assert

wenyi,xie
 

Hi everyone

May I ask in what situation we can use assert, is there any rule.

thanks
Wenyi


Change GOP mode runtime

Konstantin Aladyshev
 

Hello!

I have written an UEFI shell application that can set a mode for GOP.
And I try to use this app to increase the resolution of a display on
OVMF under QEMU.
I connect to the QEMU via VNC.

By default resolution is 800x600 (mode 2): https://pasteboard.co/KcponHH.png

If I change it to something bigger (mode 6: 1024x786) the display
changes its size, but the text area doesn't really change:
https://pasteboard.co/KcpowA5.png

My guess it is because the text area is controlled by a different
protocol: EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL. I can see its modes via
internal `mode` command:
```
FS0:\> mode
Available modes for console output device.
Col 80 Row 25 *
Col 100 Row 31
```
But this protocol always has only two modes. So I can't really change
its mode to fill all the display with the bigger resolution.
It looks like both modes were calculated for the default 800x600
screen (with/without padding).

What driver is responsible for this protocol?
Is there a way to somehow recalculate available modes for a console
output device runtime?

Best regards,
Konstantin Aladyshev


Re: Functions for coversion strings to intergers

Konstantin Aladyshev
 

What I meant is there is no difference in the result between the "0"
string, and "hhh" string. Both would get translated to the number
zero.
And something like "16dfgdf" would get translated to 16.

But I think I've found a C library function, that is the base for
these StrDecimalToUintnS/StrDecimalToUint64S functions. It is
`strtol`.

And in the case of strtol it is a caller responsibility to check for
all the possible error cases via comparing first and second argument:
https://stackoverflow.com/questions/26080829/detecting-strtol-failure/26083517

```
CHAR16* End;
UINTN MyVar;
RETURN_STATUS Status = StrDecimalToUintnS(Argv[Index], &End, &MyVar);
if ((Status != RETURN_SUCCESS) || (Argv[Index] == End) || (*End != 0))
Print(L"Error! incorrect number\n");
}
```
So I think that clears my question.
Sorry to bother you.

Best regards,
Konstantin Aladyshev

On Wed, Jul 21, 2021 at 9:23 PM Andrew Fish <afish@apple.com> wrote:



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





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

1 - 20 of 805