discuss@edk2.groups.io

UiApp

Fabrice DECROP LONGET

#891

Hi,

This is my very first message on edk2, regarding UEFI software developpement.
Please, feel free to transfer my message to any other location if needed 😊

I’m currently working on a BIOS setup menu to integrate in the boot flow of my HW platform. I’m working on a reference design of ARM, was able to compile and execute edk2 UEFI boot.

Could someone answer to the following questions :

1/UiApp is started during the BDS phase.
Because it has been configured so in the EFI variable EfiGlobalVariable:Boot0000
Am I correct ?

2/Let us assume that there are Boot0000 to Boot0006 options on my platform.
How EDK2 fill the Boot#### options ? Is it pre-written in NVRAM, or is filled by EDK2 ?
If filled vy EDK2, could you please point me where it is done in source code

3/Is there a way to change this value parameter outside EDK2 and outside OS ?

4/Is there a way to add a boot option (BootNext) outside EDK2 (saying outise Bott Manager Menu), outside UEFI shell, and outside OS ?


Thanks in advance for your help,
Regards


Fabrice DECROP LONGET
SiPearl - Ingénieur BIOS/UEFI
Mobile: +33 6 44 12 09 85
https://www.sipearl.com

[Bug] While BootMenuApp build in UEFI payload, pcd in BootMenuApp will not be override.

Ning Feng

#890

While BootMenuApp build in UEFI payload, PcdBootManagerMenuFile used to get Uiapp file guid used in BootMenuApp will same with Universal payload pkg, platform can not override it.
we should add PlatformBootManagerLib for BootManagerMenuApp.inf in Edk2\UefiPayloadPkg\UefiPayloadPkg.dsc,after that we can override UiappGuid by platform side.

Inclusive Language Update RFC

Teng, Lynn L

#889

Hello all,

We have updated the Overview section of the Inclusive Language Guidelines to clarify two things.  
1. Which version (via date) of the [[UEFI Inclusive Language Implementation Guidelines|https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf]] we will be following so we do not have a moving target.  
2. Defining "_non-legacy_" and "_legacy_".  

***

## Overview
 
To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
In collaboration with UEFI, we will be following the same [[Inclusive Language Implementation Guidelines|https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf]] (as of Nov 1, 2021) as stated on [[UEFI.org|https://uefi.org/]].

In our plan below, we have steps for dealing with both "_non-legacy_" and "_legacy_".  For these terms we define "_non-legacy_" as UEFI BIOS/specifications and beyond, where as "_legacy_" is BIOS/specifications that predates UEFI.  There are references to legacy specifications not controlled by the TianoCore Community, and they may not follow these guidelines. In order to preserve compatibility for code that reads on legacy specifications, particularly where that specification is no longer under maintenance or development, language in this specification may appear out of sync with the guidelines. In these cases, the Community will work with other standards development bodies to eliminate such examples over time. In the meanwhile, by acknowledging and calling attention to this issue the hope is to promote discussion and action towards more complete use of Inclusive Language reflective of the diverse and innovative population of the technical community that works on standards.

 
 ## Plan
    
1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines  
2. Scrubbing of all comments, documentation, and Wiki pages  
3. Scrubbing of all non-legacy code  
4. Working with UEFI to scrub legacy code  
    
    
 ## Implementation Guidelines
    
 ### Master/Slave to not be used together nor alone.
 Alternatives:
 Master | Slave
 -------|-------
 Main | Secondary, Subordinate
 Primary | Secondary, Replica
 Host | Target
 Leader | Follower
 Orchestrator | Worker
 Initiator | Responder
 
 Or similar descriptive terminology
    
 ### Blacklist/Whitelist to not be used together nor alone.
 Alternatives:
 Blacklist | Whitelist
 ----------|----------
 Blocklist | Passlist
 Denylist | Allowlist
 Refused, Denied | Permitted
 
 Or similar descriptive terminology

***

Please provide any input you may have with regards to these changes by Nov 26th.

Thank you,  
Lynn Teng

Can EDK2 be compiled on Apple M1?

hnyrarara@...

#888

Hi,
I have a Mac using M1 chip, and try to use it build Edk2 project.
I followed by this tutorial: https://github.com/tianocore/tianocore.github.io/wiki/xcode
But the compilation encountered some unrecognized assembly statements(Please see in the attached file )
Could the project be compiled under M1?

edk2_build_on_apple_m1log.txt

Re: [edk2-devel] EDK2 doxygen documentation - adding docs for stable tags?

Rebecca Cran

#887

How easy it is to push changes to https://www.tianocore.org/ ? I had thought that given how infrequently it's updated it's rather difficult, but I agree that's the ideal location for the Doxygen pages. If it's easier than I think, I have other changes I'd like to make such as updating https://www.tianocore.org/news/ which hasn't been changed since 2018.

I agree it would be great if it could be a CI job somewhere: do we have any existing scheduled jobs in EDK2 already, or is it something that would need to be added?

Given that it was Stephano who originally said years ago that Doxygen generation should be in the cloud, and how nothing has changed since I'm skeptical about it, so for now I'll plan on setting up a scheduled job on my Gitlab instance (https://gitlab.bsdio.com) instead and continue publishing the pages on my site. But I'd be happy to help work towards putting it on tianocore.org as long as we don't lose any functionality in the process.

-- 
Rebecca Cran

Show quoted text

On 11/9/21 7:27 PM, Michael D Kinney wrote:
Hi Rebecca,

Yes.  They are useful.  I would be better if it could be a CI job on either Azure pipelines
or GitHub Actions could run the tool and publish the documents in TianoCore.  Perhaps an on
demand job against a specific tag.

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran
Sent: Tuesday, November 9, 2021 3:20 PM
To: devel@edk2.groups.io; discuss@edk2.groups.io
Subject: [edk2-devel] EDK2 doxygen documentation - adding docs for stable tags?

I've been hosting the Doxygen documentation for EDK2 at
https://bsdio.com/edk2/docs for a few years now. I previously had
versions for master, UDK2015, UDK2017, UDK2018 etc. but since migrating
my web server dropped everything except master.


I was wondering if people are finding it useful, and if so whether
they'd like me to generate documentation for each stable tag too?


Personally, _I_ find the web-based version (as opposed to a
locally-generated version) useful for the search feature -- being able
to quickly find the documentation for a certain function.


--

Rebecca Cran

EFI_IFR_DEFAULTSTORE

Konstantin Aladyshev

#886

Hello!

I was investigating output from the simplest VFR file:
```
#define HIISIMPLEFORM_FORMSET_GUID  {0xef2acc91, 0x7b50, 0x4ab9,
{0xab, 0x67, 0x2b, 0x4, 0xf8, 0xbc, 0x13, 0x5e}}

formset
  guid     = HIISIMPLEFORM_FORMSET_GUID,
  title    = STRING_TOKEN(HIISIMPLEFORM_FORMSET_TITLE),
  help     = STRING_TOKEN(HIISIMPLEFORM_FORMSET_HELP),
endformset;
```
This produces the following opcodes:
```
//
// All Opcode Record List
//
00000000: 0E A7 91 CC 2A EF 50 7B B9 4A AB 67 2B 04 F8 BC 13 5E 02 00 03 00 01 71 99 03 93 45 85 04 4B B4 5E 32 EB 83 26 04 0E
00000027: 5C 06 00 00 00 00
0000002D: 5C 06 00 00 01 00
00000033: 29 02```
Basically it is 4 IFR elements (one data string per element):
- EFI_IFR_FORM_SET
- EFI_IFR_DEFAULTSTORE
- EFI_IFR_DEFAULTSTORE
- EFI_IFR_END

My question is what is the purpose of the `EFI_IFR_DEFAULTSTORE`, and
why are there two such elements in the output?

Best regards,
Konstantin Aladyshev

Re: [edk2-devel] EDK2 doxygen documentation - adding docs for stable tags?

Michael D Kinney

#885

Hi Rebecca,

Yes.  They are useful.  I would be better if it could be a CI job on either Azure pipelines
or GitHub Actions could run the tool and publish the documents in TianoCore.  Perhaps an on
demand job against a specific tag.

Mike

Show quoted text

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran
Sent: Tuesday, November 9, 2021 3:20 PM
To: devel@edk2.groups.io; discuss@edk2.groups.io
Subject: [edk2-devel] EDK2 doxygen documentation - adding docs for stable tags?

I've been hosting the Doxygen documentation for EDK2 at
https://bsdio.com/edk2/docs for a few years now. I previously had
versions for master, UDK2015, UDK2017, UDK2018 etc. but since migrating
my web server dropped everything except master.

I was wondering if people are finding it useful, and if so whether
they'd like me to generate documentation for each stable tag too?

Personally, _I_ find the web-based version (as opposed to a
locally-generated version) useful for the search feature -- being able
to quickly find the documentation for a certain function.

--

Rebecca Cran

EDK2 doxygen documentation - adding docs for stable tags?

Rebecca Cran

#884

I've been hosting the Doxygen documentation for EDK2 at https://bsdio.com/edk2/docs for a few years now. I previously had versions for master, UDK2015, UDK2017, UDK2018 etc. but since migrating my web server dropped everything except master.

I was wondering if people are finding it useful, and if so whether they'd like me to generate documentation for each stable tag too?

Personally, _I_ find the web-based version (as opposed to a locally-generated version) useful for the search feature -- being able to quickly find the documentation for a certain function.

-- 

Rebecca Cran

Re: Adding another platform language

Konstantin Aladyshev

#883

It looks like L"PlatformLangCodes" is blocked by a variable policy
enforced to this variable in the BdsDxe:

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
```
///
/// The read-only variables defined in UEFI Spec.
///
CHAR16  *mReadOnlyVariables[] = {
  EFI_PLATFORM_LANG_CODES_VARIABLE_NAME,             //
L"PlatformLangCodes"  The language codes that the firmware supports
  EFI_LANG_CODES_VARIABLE_NAME,
  EFI_BOOT_OPTION_SUPPORT_VARIABLE_NAME,
  EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAME,
  EFI_OS_INDICATIONS_SUPPORT_VARIABLE_NAME
  };

...

  // Mark the read-only variables if the Variable Lock protocol exists
  //
  Status = gBS->LocateProtocol(&gEdkiiVariablePolicyProtocolGuid,
NULL, (VOID**)&VariablePolicy);
  DEBUG((DEBUG_INFO, "[BdsDxe] Locate Variable Policy protocol -
%r\n", Status));
  if (!EFI_ERROR (Status)) {
    for (Index = 0; Index < ARRAY_SIZE (mReadOnlyVariables); Index++) {
      Status = RegisterBasicVariablePolicy(
                 VariablePolicy,
                 &gEfiGlobalVariableGuid,
                 mReadOnlyVariables[Index],
                 VARIABLE_POLICY_NO_MIN_SIZE,
                 VARIABLE_POLICY_NO_MAX_SIZE,
                 VARIABLE_POLICY_NO_MUST_ATTR,
                 VARIABLE_POLICY_NO_CANT_ATTR,
                 VARIABLE_POLICY_TYPE_LOCK_NOW
                 );
      ASSERT_EFI_ERROR(Status);
    }
  }
```

In the end of DXE variable policy is locked in the
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c :
```
VOID
EFIAPI
OnEndOfDxe (
  EFI_EVENT Event,
  VOID *Context
)
{
  EFI_STATUS Status;
  DEBUG ((EFI_D_INFO, "[Variable]END_OF_DXE is signaled\n"));
   ...
  Status = LockVariablePolicy ();
   ...
}
```

So it looks like it is not possible to disable this policy at runtime
and modify L"PlatformLangCodes". Therefore it is not possible to add
another localization language at runtime.

I think this limitation comes from the fact that UEFI specification
marks this variable as read-only:
```
The PlatformLangCodes variable contains a null- terminated ASCII
string representing the language codes that the firmware can support.
At initialization time the firmware computes the supported languages
and creates this data variable. Since the firmware creates this value
on each initialization, its contents are not stored in nonvolatile
memory. This value is considered read-only
```
But what is the reason for such a limitation? Wouldn't it be good if
there would be a possibility to add new localization languages at
runtime?

Best regards,
Konstantin Aladyshev

On Sat, Oct 30, 2021 at 2:14 PM Konstantin Aladyshev
<aladyshev22@...> wrote:

Hello!

I was investigating the possibility of adding localization strings at
runtime. Is it possible to create another translation language at
runtime (UEFI Shell)?
From my understanding OVMF gets the list of supported languages from
the `PlatformLangCodes` variable.
So I've decided to create an UEFI shell application that would add
another language to this variable.
But it looks like it is not possible to modify this variable. I'm
getting `Write Protected` error.

Here is my code:
```
EFI_STATUS
EFIAPI
UefiMain (
  IN EFI_HANDLE        ImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  EFI_STATUS Status;
  CHAR8* LanguageString;

  Status = GetEfiGlobalVariable2(L"PlatformLangCodes",
(VOID**)&LanguageString, NULL);
  if (EFI_ERROR(Status)) {
    Print(L"Error! Can't perform GetEfiGlobalVariable2, status=%r\n", Status);
    return Status;
  }
  Print(L"Before: %a\n", LanguageString);

  CHAR8* NewLanguageString = AllocatePool(AsciiStrLen(LanguageString)
+ AsciiStrSize(";ru-RU"));
  if (NewLanguageString == NULL) {
    Print(L"Error! Can't allocate size for new PlatformLangCodes variable\n");
    FreePool(LanguageString);
    return EFI_OUT_OF_RESOURCES;
  }

  CopyMem(NewLanguageString, LanguageString, AsciiStrLen(LanguageString));
  CopyMem(&NewLanguageString[AsciiStrLen(LanguageString)], ";ru-RU",
AsciiStrSize(";ru-RU"));

  Print(L"After: %a\n", NewLanguageString);

  Status = gRT->SetVariable (
                L"PlatformLangCodes",
                &gEfiGlobalVariableGuid,
                EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,
                AsciiStrSize(NewLanguageString),
                NewLanguageString
                );
  if (EFI_ERROR(Status)) {
    Print(L"Error! Can't set PlatformLangCodes variable, status=%r\n", Status);
  }

  FreePool(NewLanguageString);
  FreePool(LanguageString);

  return EFI_SUCCESS;
}
```

And here is the output:
```
FS0:\> HIIAddLocalization.efi
Before: en;fr;en-US;fr-FR
After: en;fr;en-US;fr-FR;ru-RU
Error! Can't set PlatformLangCodes variable, status=Write Protected
```

I'm not sure, but I guess the limitation comes from the
`AutoUpdateLangVariable` function from the
https://github.com/tianocore/edk2/blob/1bc232aae32e812341f10c9b938350cd93308eee/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c#L1375
Am I correct?

Is it really impossible to add a new translation language at runtime?
What is the reason for blocking `PlatformLangCodes` variable from
modifying?

Best regards,
Konstantin Aladyshev

ISSUE ON LAPTOP SCREEN STUCK ON TIANOCORE LOGO

Wawa Roz <wafa.rozman98@...>

#882

Greetings,

As stated in the subject above, I have encountered an issue with my laptop, which the screen stucks on Tianocore logo and I couldn’t log in the Windows. The Tianocore logo kept on popping out on the screen and looping even I have plugged in the charger. I have tried many solutions as shown in Youtube and Google, unluckily there’s no improvement until now. I have attached an image of the problem below.

I have sent my laptop for repair but they are still trying to figure out the solution. I would like to ask for guidance/solution to remove the looping Tianocore logo since you are the owner of Tianocore. 

I would really appreciate your respond because I really need my laptop for assignment purposes as I am a college student. I’m looking forward to receiving feedback from you soon.
Thank you.

Regards,
Wafa Rozman.

(Attachment of image of the problem)

Re: [edk2-announce] Inclusive Language RFC

Teng, Lynn L

#881

Hello Sean,

You make a good point.  

I will remove both steps 3.1 and 4.1 from the plan for now so we can focus on the main proposal.
We can open a discussion later on to determine how best to maintain inclusive language once the codebase has been updated. 

Here is the updated proposal:

 ***
 
 ## Overview
 
 To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
 In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on UEFI.org](https://uefi.org/).
 
 
 ## Plan
    
1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines  
2. Scrubbing of all comments, documentation, and Wiki pages  
3. Scrubbing of all non-legacy code
4. Working with UEFI to scrub legacy code 
    
    
 ## Implementation Guidelines
    
 ### Master/Slave to not be used together nor alone.
 Alternatives:
 Master | Slave
 -------|-------
 Main | Secondary, Subordinate
 Primary | Secondary, Replica
 Host | Target
 Leader | Follower
 Orchestrator | Worker
 Initiator | Responder
 
 Or similar descriptive terminology
    
 ### Blacklist/Whitelist to not be used together nor alone.
 Alternatives:
 Blacklist | Whitelist
 ----------|----------
 Blocklist | Passlist
 Denylist | Allowlist
 Refused, Denied | Permitted
 
 Or similar descriptive terminology

Show quoted text

-----Original Message-----
From: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of Sean
Sent: Monday, November 1, 2021 1:16 PM
To: Teng, Lynn L <lynn.l.teng@...>; announce@edk2.groups.io
Subject: Re: [edk2-announce] Inclusive Language RFC

Content looks great except "Plan 4.1."
I don't see a commit hook as a solution that works for this community. 
I would think the plan would leverage pr-gate/ci to enforce this? 
Otherwise, it is yet another rule and place to cause code-review and contribution friction.

Thanks
Sean

On 10/25/2021 11:57 AM, Teng, Lynn L wrote:
Hello all,

Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05).  Thank you in advance for your contributions.

***

## Overview

To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).

## Plan

1. Announcement of intent, and all check-ins from here onwards will 
need to abide by Inclusive Language Implementation Guidelines 2. 
Scrubbing of all comments, documentation, and Wiki pages 3. Scrubbing 
all non-legacy code 3.1. Integrate open-source commit hook that will 
warn submitter of violations 4. Working with UEFI to scrub legacy code 
4.1. Update commit hook to block submissions with violations

## Implementation Guidelines

### Master/Slave to not be used together nor alone.
Alternatives:
Master | Slave
-------|-------
Main | Secondary, Subordinate
Primary | Secondary, Replica
Host | Target
Leader | Follower
Orchestrator | Worker
Initiator | Responder

Or similar descriptive terminology

### Blacklist/Whitelist to not be used together nor alone.
Alternatives:
Blacklist | Whitelist
----------|----------
Blocklist | Passlist
Denylist | Allowlist
Refused, Denied | Permitted

Or similar descriptive terminology

Re: .Vfr and .vfr

Konstantin Aladyshev

#880

Thanks for the answer.

I understand that it is possible, but is it good style?
I don't suggest dropping ".VFR" and ".Vfr" files parsing, but maybe
all the EDKII form files should be renamed to one style ''.vfr" for
consistency?
Honestly I've always used 'find ./ -name "*.vfr" ' to grep for form
files with no idea that they can be named differently. I wasn't even
thinking about the fact that they can be named ".Vfr" or ".VFR". Of
course I'm not a EDKII pro and I am investigating EDKII by myself, but
it is just a thing to think about.
Also for example it is also possible for the string files to have
different extensions: "UNI", "Uni" and "uni". But the EDKII codebase
has only "uni" files in itself. Which I think is a good consistency.
And I simply suggest doing the same with form files.

Best regards,
Konstantin Aladyshev

Show quoted text

On Mon, Nov 1, 2021 at 4:10 AM Feng, Bob C <bob.c.feng@...> wrote:

Both .vfr and .Vfr are supported by edk2 build tool. You can find the build rule in the edk2\BaseTools\Conf\build_rule.template.
Vfr, vfr, and VFR are all valid file ext and they apply the same build rule.

[Visual-Form-Representation-File]
    <InputFile>
        ?.vfr
        ?.Vfr
        ?.VFR

    <ExtraDependency>
        $(MAKE_FILE)

    <OutputFile>
        $(DEBUG_DIR)(+)${s_dir}(+)${s_base}.c

    <Command>
        "$(VFRPP)" $(DEPS_FLAGS) $(VFRPP_FLAGS) $(INC) ${src} > $(OUTPUT_DIR)(+)${s_base}.i
        "$(VFR)" $(VFR_FLAGS) --string-db $(OUTPUT_DIR)(+)$(MODULE_NAME)StrDefs.hpk --output-directory ${d_path} $(OUTPUT_DIR)(+)${s_base}.i



Thanks,
Bob

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Konstantin Aladyshev
Sent: Monday, November 1, 2021 2:28 AM
To: discuss <discuss@edk2.groups.io>
Subject: [edk2-discuss] .Vfr and .vfr

Hello!

I've noticed that edk2 uses two different styles for naming Visual Forms Representation files: "*.vfr" and "*.Vfr".
Is there any logic why some files have "*.Vfr" and some have "*.vfr" extension?
If there is no distinction, maybe it is better to use one style?

$ find ./ -name "*.vfr"
./EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefHii.vfr
./EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.vfr
./MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.vfr
./MdeModulePkg/Library/FileExplorerLib/FileExplorerVfr.vfr
./MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanup.vfr
./MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr
./MdeModulePkg/Universal/DriverSampleDxe/Inventory.vfr
./MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr
./MdeModulePkg/Universal/HiiResourcesSampleDxe/Sample.vfr
./MdeModulePkg/Universal/PlatformDriOverrideDxe/Vfr.vfr
./NetworkPkg/HttpBootDxe/HttpBootConfigVfr.vfr
./NetworkPkg/Ip4Dxe/Ip4Config2.vfr
./NetworkPkg/Ip6Dxe/Ip6Config.vfr
./NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr
./NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigVfr.vfr
./NetworkPkg/VlanConfigDxe/VlanConfig.vfr
./NetworkPkg/WifiConnectionManagerDxe/WifiConnectionManagerDxe.vfr
./OvmfPkg/PlatformDxe/PlatformForms.vfr
./SecurityPkg/HddPassword/HddPassword.vfr
./SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordForm.vfr
./SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr
./SecurityPkg/Tcg/TcgConfigDxe/TcgConfig.vfr
./SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr
./UefiLessonsPkg/HIIForm/Form.vfr
./UefiLessonsPkg/HiiMenu/bak.vfr
./UefiLessonsPkg/HiiMenu/HiiForm1Vfr.vfr

$ find ./ -name "*.Vfr"
./MdeModulePkg/Application/UiApp/FrontPageVfr.Vfr
./MdeModulePkg/Library/BootManagerUiLib/BootManagerVfr.Vfr
./MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerVfr.Vfr
./MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthConfigureVfr.Vfr
./MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerVfr.Vfr
./OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr

Best regards,
Konstantin Aladyshev

Re: .Vfr and .vfr

Bob Feng

#879

Both .vfr and .Vfr are supported by edk2 build tool. You can find the build rule in the edk2\BaseTools\Conf\build_rule.template.
Vfr, vfr, and VFR are all valid file ext and they apply the same build rule.

[Visual-Form-Representation-File]
    <InputFile>
        ?.vfr
        ?.Vfr
        ?.VFR

    <ExtraDependency>
        $(MAKE_FILE)

    <OutputFile>
        $(DEBUG_DIR)(+)${s_dir}(+)${s_base}.c

    <Command>
        "$(VFRPP)" $(DEPS_FLAGS) $(VFRPP_FLAGS) $(INC) ${src} > $(OUTPUT_DIR)(+)${s_base}.i
        "$(VFR)" $(VFR_FLAGS) --string-db $(OUTPUT_DIR)(+)$(MODULE_NAME)StrDefs.hpk --output-directory ${d_path} $(OUTPUT_DIR)(+)${s_base}.i



Thanks,
Bob

Show quoted text

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Konstantin Aladyshev
Sent: Monday, November 1, 2021 2:28 AM
To: discuss <discuss@edk2.groups.io>
Subject: [edk2-discuss] .Vfr and .vfr

Hello!

I've noticed that edk2 uses two different styles for naming Visual Forms Representation files: "*.vfr" and "*.Vfr".
Is there any logic why some files have "*.Vfr" and some have "*.vfr" extension?
If there is no distinction, maybe it is better to use one style?

$ find ./ -name "*.vfr"
./EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefHii.vfr
./EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.vfr
./MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.vfr
./MdeModulePkg/Library/FileExplorerLib/FileExplorerVfr.vfr
./MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanup.vfr
./MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr
./MdeModulePkg/Universal/DriverSampleDxe/Inventory.vfr
./MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr
./MdeModulePkg/Universal/HiiResourcesSampleDxe/Sample.vfr
./MdeModulePkg/Universal/PlatformDriOverrideDxe/Vfr.vfr
./NetworkPkg/HttpBootDxe/HttpBootConfigVfr.vfr
./NetworkPkg/Ip4Dxe/Ip4Config2.vfr
./NetworkPkg/Ip6Dxe/Ip6Config.vfr
./NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr
./NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigVfr.vfr
./NetworkPkg/VlanConfigDxe/VlanConfig.vfr
./NetworkPkg/WifiConnectionManagerDxe/WifiConnectionManagerDxe.vfr
./OvmfPkg/PlatformDxe/PlatformForms.vfr
./SecurityPkg/HddPassword/HddPassword.vfr
./SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordForm.vfr
./SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr
./SecurityPkg/Tcg/TcgConfigDxe/TcgConfig.vfr
./SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr
./UefiLessonsPkg/HIIForm/Form.vfr
./UefiLessonsPkg/HiiMenu/bak.vfr
./UefiLessonsPkg/HiiMenu/HiiForm1Vfr.vfr

$ find ./ -name "*.Vfr"
./MdeModulePkg/Application/UiApp/FrontPageVfr.Vfr
./MdeModulePkg/Library/BootManagerUiLib/BootManagerVfr.Vfr
./MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerVfr.Vfr
./MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthConfigureVfr.Vfr
./MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerVfr.Vfr
./OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr

Best regards,
Konstantin Aladyshev

.Vfr and .vfr

Konstantin Aladyshev

#878

Hello!

I've noticed that edk2 uses two different styles for naming Visual
Forms Representation files: "*.vfr" and "*.Vfr".
Is there any logic why some files have "*.Vfr" and some have "*.vfr" extension?
If there is no distinction, maybe it is better to use one style?

$ find ./ -name "*.vfr"
./EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefHii.vfr
./EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformHii.vfr
./MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.vfr
./MdeModulePkg/Library/FileExplorerLib/FileExplorerVfr.vfr
./MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanup.vfr
./MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr
./MdeModulePkg/Universal/DriverSampleDxe/Inventory.vfr
./MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr
./MdeModulePkg/Universal/HiiResourcesSampleDxe/Sample.vfr
./MdeModulePkg/Universal/PlatformDriOverrideDxe/Vfr.vfr
./NetworkPkg/HttpBootDxe/HttpBootConfigVfr.vfr
./NetworkPkg/Ip4Dxe/Ip4Config2.vfr
./NetworkPkg/Ip6Dxe/Ip6Config.vfr
./NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr
./NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigVfr.vfr
./NetworkPkg/VlanConfigDxe/VlanConfig.vfr
./NetworkPkg/WifiConnectionManagerDxe/WifiConnectionManagerDxe.vfr
./OvmfPkg/PlatformDxe/PlatformForms.vfr
./SecurityPkg/HddPassword/HddPassword.vfr
./SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordForm.vfr
./SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr
./SecurityPkg/Tcg/TcgConfigDxe/TcgConfig.vfr
./SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr
./UefiLessonsPkg/HIIForm/Form.vfr
./UefiLessonsPkg/HiiMenu/bak.vfr
./UefiLessonsPkg/HiiMenu/HiiForm1Vfr.vfr

$ find ./ -name "*.Vfr"
./MdeModulePkg/Application/UiApp/FrontPageVfr.Vfr
./MdeModulePkg/Library/BootManagerUiLib/BootManagerVfr.Vfr
./MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerVfr.Vfr
./MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthConfigureVfr.Vfr
./MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerVfr.Vfr
./OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr

Best regards,
Konstantin Aladyshev

Adding another platform language

Konstantin Aladyshev

#877

Hello!

I was investigating the possibility of adding localization strings at
runtime. Is it possible to create another translation language at
runtime (UEFI Shell)?
From my understanding OVMF gets the list of supported languages from
the `PlatformLangCodes` variable.
So I've decided to create an UEFI shell application that would add
another language to this variable.
But it looks like it is not possible to modify this variable. I'm
getting `Write Protected` error.

Here is my code:
```
EFI_STATUS
EFIAPI
UefiMain (
  IN EFI_HANDLE        ImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  EFI_STATUS Status;
  CHAR8* LanguageString;

  Status = GetEfiGlobalVariable2(L"PlatformLangCodes",
(VOID**)&LanguageString, NULL);
  if (EFI_ERROR(Status)) {
    Print(L"Error! Can't perform GetEfiGlobalVariable2, status=%r\n", Status);
    return Status;
  }
  Print(L"Before: %a\n", LanguageString);

  CHAR8* NewLanguageString = AllocatePool(AsciiStrLen(LanguageString)
+ AsciiStrSize(";ru-RU"));
  if (NewLanguageString == NULL) {
    Print(L"Error! Can't allocate size for new PlatformLangCodes variable\n");
    FreePool(LanguageString);
    return EFI_OUT_OF_RESOURCES;
  }

  CopyMem(NewLanguageString, LanguageString, AsciiStrLen(LanguageString));
  CopyMem(&NewLanguageString[AsciiStrLen(LanguageString)], ";ru-RU",
AsciiStrSize(";ru-RU"));

  Print(L"After: %a\n", NewLanguageString);

  Status = gRT->SetVariable (
                L"PlatformLangCodes",
                &gEfiGlobalVariableGuid,
                EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,
                AsciiStrSize(NewLanguageString),
                NewLanguageString
                );
  if (EFI_ERROR(Status)) {
    Print(L"Error! Can't set PlatformLangCodes variable, status=%r\n", Status);
  }

  FreePool(NewLanguageString);
  FreePool(LanguageString);

  return EFI_SUCCESS;
}
```

And here is the output:
```
FS0:\> HIIAddLocalization.efi
Before: en;fr;en-US;fr-FR
After: en;fr;en-US;fr-FR;ru-RU
Error! Can't set PlatformLangCodes variable, status=Write Protected
```

I'm not sure, but I guess the limitation comes from the
`AutoUpdateLangVariable` function from the
https://github.com/tianocore/edk2/blob/1bc232aae32e812341f10c9b938350cd93308eee/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c#L1375
Am I correct?

Is it really impossible to add a new translation language at runtime?
What is the reason for blocking `PlatformLangCodes` variable from
modifying?

Best regards,
Konstantin Aladyshev

Ways to add a string package of different language at runtime

Konstantin Aladyshev

#876

Hello!

I was investigating the possibility of adding localization strings at
runtime. I've noticed that
https://github.com/tianocore/edk2/blob/master/OvmfPkg/PlatformDxe/Platform.uni
has strings only for the `en-US` language. So I've decided to use it
as an example, and create an application that would add translations
for some other supported system language (in this case `fr-FR`):

```
EFI_STATUS
EFIAPI
UefiMain (
  IN EFI_HANDLE        ImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  EFI_STATUS Status;
  EFI_GUID PackageGuid = {0xD9DCC5DF, 0x4007, 0x435E, {0x90, 0x98,
0x89, 0x70, 0x93, 0x55, 0x04, 0xb2 }};
  EFI_HII_HANDLE* Handle = HiiGetHiiHandles(&PackageGuid);
  CHAR16* FrenchStrings[] = {
    L"Configuration de la OVMF plateforme",
    L"Modifier divers paramètres de la plateforme OVMF",
    L"Paramètres OVMF",
    L"Résolution préférée au prochain démarrage",
    ...
    L"2560x1600",
  };
  for (UINTN i=0; i<(sizeof(FrenchStrings)/sizeof(FrenchStrings[0])); i++) {
    EFI_STRING_ID StringId;
    if (i==0) {
      Status = gHiiString->NewString(gHiiString, *Handle, &StringId,
"fr-FR", L"French", L"", NULL);
      Print(L"Added ID=%d, Status = %r\n", StringId, Status);
    }
    StringId = i+2;
    Status = gHiiString->SetString(gHiiString, *Handle, StringId,
"fr-FR", FrenchStrings[i], NULL);
    Print(L"Added ID=%d, Status = %r\n", StringId, Status);
  }

  return EFI_SUCCESS;
}
```

This works well, but I'm a little concerned about the approach that
I've used to initially create the 'fr-FR' string package. Here I've
used:
```
gHiiString->NewString(gHiiString, *Handle, &StringId, "fr-FR",
L"French", L"", NULL);
```
Initially the `en-US` string package has 40 strings, so this code
would create a 'fr-FR' string package with one string of ID=41, which
has a "" value. Because of this hack in the end the 'en-US' package
would have 40 strings and the 'fr-FR' package would have 41 strings.
This is really not a problem of any kind, but maybe there is a library
function to create a string package of a different language?

Best regards,
Konstantin Aladyshev

Re: [edk2-rfc] Inclusive Language RFC

Teng, Lynn L

#875

Hello Marvin,

Your concerns have been heard, but providing a list of every alternative for every scenario and how/when to use them would be unreasonable.  
We would expect developers to use their understanding of each term and the context of how it is being used, and to find an appropriate alternative.  The lists provided are by no means exhaustive, and are not definitive in how they are combined.

Similar to [the UEFI guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf), [the Linux community](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst), and [IEEE](https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf), our intent is simply to inform the community that we are going to be moving towards using Inclusive Language and are providing the list of words that are no longer permitted and possible alternatives for those words.

Best regards,  
Lynn Teng

Show quoted text

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Marvin Häuser
Sent: Wednesday, October 27, 2021 12:42 AM
To: rfc@edk2.groups.io; Teng, Lynn L <lynn.l.teng@...>; devel@edk2.groups.io; discuss@edk2.groups.io
Subject: Re: [edk2-discuss] [edk2-rfc] Inclusive Language RFC

Hey,

On 25.10.21 20:47, Teng, Lynn L wrote:
Hello all,

Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05).  Thank you in advance for your contributions.

***

## Overview

To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).

## Plan

1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines
2. Scrubbing of all comments, documentation, and Wiki pages
3. Scrubbing all non-legacy code
3.1. Integrate open-source commit hook that will warn submitter of violations
4. Working with UEFI to scrub legacy code
4.1. Update commit hook to block submissions with violations

## Implementation Guidelines

### Master/Slave to not be used together nor alone.
Alternatives:
Master | Slave
-------|-------
Main | Secondary, Subordinate
Primary | Secondary, Replica
Host | Target
Leader | Follower
Orchestrator | Worker
Initiator | ResponderSome of these combinations sound very awkward because they are not 
strictly or strongly related language-wise. Examples:
- In my opinion, a replica can very well be a main, it just cannot be an 
original.
- "Responder" is very generic - "slave" conveys work, not just any sort 
of reaction
- "Primary" and "secondary" are clearly related, "main" and "secondary" 
are not.
...

The combination "leader"/"follower" could be interpreted politically if 
you just try hard enough, who knows what language revision proposals may 
look like in 10 years from now. Maybe drop it entirely. :)

Or similar descriptive terminology

### Blacklist/Whitelist to not be used together nor alone.
Alternatives:
Blacklist | Whitelist
----------|----------
Blocklist | Passlist
Denylist | Allowlist
Refused, Denied | PermittedI think this should be made stricter to "refused"/"permitted" and 
"granted"/"denied" to stay consistent with common usage.

My biggest issues with such proposals is they tell me which words to not 
use, but not which to use instead. Yes, there are plenty of alternatives 
given, but when do I use which? E.g. "host" / "target" already is a very 
common combination for debugging, but nobody would think of naming their 
main git branch "host". If you deprecate widely conventional 
terminology, in my opinion you should also provide clear and detailed 
guidelines for which sub-areas they are deprecated by which exact 
alternatives (e.g. "version control - main; debugging - host"). I don't 
think a terminology zoo where everybody picks their preference by gut 
feeling is in anyone's best interest.

Thanks!

Best regards,
Marvin

Or similar descriptive terminology

回复: [edk2-discuss] About how to submit a new architecture called LoongArch

gaoliming

#874

Chao:

 Here is wiki https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First-Process.

Thanks

Liming

发件人: discuss@edk2.groups.io <discuss@edk2.groups.io> 代表 kilaterlee@...
发送时间: 2021年10月26日 15:40
收件人: discuss@edk2.groups.io
主题: [edk2-discuss] About how to submit a new architecture called LoongArch

Dear All:

    I want to submit a new architecture called LoongArch on EDK2 and the USWG recommands us do "code first" because the UEFI specifitcation will easily accpet our arch.

    What can we do? Do I submit the part 1 code for new architecture on the "staging" branch? Hop you reply. :)

  _____  

Thanks,

LI Chao

About how to submit a new architecture called LoongArch

kilaterlee@...

#873

Dear All:

I want to submit a new architecture called LoongArch on EDK2 and the USWG recommands us do "code first" because the UEFI specifitcation will easily accpet our arch.

What can we do? Do I submit the part 1 code for new architecture on the "staging" branch? Hop you reply. :)

Thanks,

LI Chao

Inclusive Language RFC

Teng, Lynn L

#872

Hello all,

Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05).  Thank you in advance for your contributions.


***

## Overview

To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.   
In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).


## Plan  
  
1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines
2. Scrubbing of all comments, documentation, and Wiki pages  
3. Scrubbing all non-legacy code  
3.1. Integrate open-source commit hook that will warn submitter of violations  
4. Working with UEFI to scrub legacy code  
4.1. Update commit hook to block submissions with violations  
  
  
## Implementation Guidelines  
  
### Master/Slave to not be used together nor alone.  
Alternatives:  
Master | Slave
-------|-------
Main | Secondary, Subordinate  
Primary | Secondary, Replica
Host | Target  
Leader | Follower  
Orchestrator | Worker  
Initiator | Responder  

Or similar descriptive terminology  
  
### Blacklist/Whitelist to not be used together nor alone.  
Alternatives:
Blacklist | Whitelist
----------|----------
Blocklist | Passlist  
Denylist | Allowlist  
Refused, Denied | Permitted  

Or similar descriptive terminology