Date   

Re: MM communication buffer access denied or leading to an unhandled exception

Thomas Abraham
 

Hi Fabrice,

On Wed, Apr 6, 2022 at 12:25 AM, Fabrice DECROP LONGET wrote:


Hi,

I'm currently working on implemting the secure partition manager in EDK2. My
platform is based on reference design DANIEL. But I'm facing several issues,
that makes me very confused, and don't know what to do now for implenting
this feature.
Couple of questions to understand this better -

1. Is the reference design DANIEL platform you work on downloaded from https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps? If yes, what is the version number of the FVP?

2. Is the software you are using same as described in https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/blob/master/docs/infra/rdv1/readme.rst. If yes, what is the release tag being used?

Thanks,
Thomas.


MM communication buffer access denied or leading to an unhandled exception

Fabrice DECROP LONGET
 

Hi,

I'm currently working on implemting the secure partition manager in EDK2. My platform is based on reference design DANIEL. But I'm facing several issues, that makes me very confused, and don't know what to do now for implenting this feature.

First, I enable the SPM flag in ARM-TF firmware. I'm sure that this feature is enabled. MM communication buffer is (should be) correctly configured in mapping of this firmware. I say _correctly_ because, to my understanding, SPM_MM flag is correctly set in compilation and arm-tf firmware generation. To my understanding, it should be enough for EDK2 BIOS to have RW access to MM communication buffer.

Second, in EDK2, I enable the StandaloneMmPkg in EDK2 compilation. I also add the VariableInfo application, to test the communication between the Normal and Secure world.

Then, here are descriptions of the several issues I'm facing :

1-After the later configuration of arm-tf and EDK2 (SPM_MM enabled and StandaloneMmPkg addition), boot od EDK2 is leading to an hundandled exception.
I must also mention that MM communication buffer (@FF60000) access is not possible through armds in EL2 (typing EL2:FF600000 in the memory section debugger). Memory view is not not show any content, and is colored in pink.

2-I assume that I have to add MM communication memory zone (@FF600000) in the Mmu configuration. That'as what I saw in the StandaloneAARCH64 branch of EDK2 (in edk2-staging)
To achieve this addition, I added a call to BuidRessourceDescriptorHob() in MemoryPeim() of ArmPlatformPkg. Of course, this call has PcdMmBufferBase (=0xFF600000) in input parameter.
With this addition, former hundandled exception is corrected.
But : MM communication memory zone is still pink in the memory section of ArmDs. And MmCommunicationDxe driver failed to ubstall protocol interface (gEfiCommunication2ProtocolGuid)
So, my test application VariableInfo failed to communicate with secure world.


Could someone point me what I'm doing wrong ?
Is there some configuration to do in Mmu in EDK2 to enable communication ? If so, what should it be ?
Is it normal to have no access at the output of Arm-TF (and at the very beginning of BL33 = UEFI EDK2 normal world) trough ArmDS in its memory section.


Many thanks for your help.


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


Re: Device path for the HII Form drivers

Tomas Pilar (tpilar)
 

I've tried to debug OVMF code and have found out that the RouteConfig
call fails because the DevicePath is not present in the ConfigResp
string:
https://github.com/tianocore/edk2/blob/7c0ad2c33810ead45b7919f8f8d0e282dae52e71/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c#L5486

I think this implementation guards against the possibility that you might have two similar devices that install the same third-party driver. Now the two drivers will install two HII forms with the same GUID so the RouteConfig has to distinguish between then somehow.

Cheers,
Tom


Re: `varstore` vs `efivarstore`

Tomas Pilar (tpilar)
 

I understand that the `varstore` gives you more flexibility as you can
control the behaviour of save/load (=route/extract) functions. But
what can you achieve with this?
For example, writing a third-party driver (optionROM for a PCIe card). Using a varstore allows you to control how the configuration is stored and where it is stored - likely you have a config flash partition on your device. Storing config on your device means the physical device carries its config to a new server when you move it.

Moreover, your device has to be compatible with many different builds of bioses in different servers. While we have UEFI standards and EDK2 libraries, there are nevertheless 'behavioural quirks' with many (especially older) implementations of UEFI in various servers. As a driver developer I was very cautious about letting the server handle the storage of my variables.

Cheers,
Tom


Re: Automatic number to bool conversion in VFR

Tomas Pilar (tpilar)
 

But when I've tried to create more complicated expressions I have
found out some strange things:
```
suppressif (1 AND 0); - present
suppressif (1 AND 1); - present (???)
suppressif (0 OR 0); - present
suppressif (1 OR 0); - present (???)
suppressif (TRUE OR 0); - present (???)
```
It looks like for correct behaviour explicit cast is needed:
```
suppressif ((BOOLEAN)1 AND (BOOLEAN)1); - not present
suppressif ((BOOLEAN)1 OR (BOOLEAN)0); - not present
suppressif (TRUE OR (BOOLEAN)0); - not present
```

Can someone explain to me the logic when the cast statement is not present?
Hi Konstantin,

I could be wrong, but this is my understading of the situation. The process of building and using HII includes transpiling a file written in VFR into IFR bytecode. This transpilation is custom for edk2 and therefore the transpiler is likely to be more 'quirky' than what you'd expect of your mainstream compiler. Especially for less-utilised syntax structures, where it had far less user testing. I've usually limited myself to well-worn paths when writing up a VFR file for a driver.

Cheers,
Tom


`varstore` vs `efivarstore`

Konstantin Aladyshev
 

Hello!

Can someone explain to me, what is a typical reason for using
`varstore` instead of `efivarstore` for HII storage?

I understand that the `varstore` gives you more flexibility as you can
control the behaviour of save/load (=route/extract) functions. But
what can you achieve with this?

EDKII has several drivers with `varstore`, can you give me some
examples, why do they need exactly this type of storage?

./MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.vfr
./MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanup.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/TcgConfigDxe/TcgConfig.vfr
./SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr
./OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr

Best regards,
Konstantin Aladyshev


Automatic number to bool conversion in VFR

Konstantin Aladyshev
 

Hello!

I was experimenting with conditions under the `suppressif` statement:
```
suppressif TRUE; - element is not present
suppressif FALSE; - element is present
```
From the C language I'm used to the fact that 0 is FALSE, and every
other number is TRUE. And at first glance it looks like VFR has the
same cast:
```
suppressif 2; - not present
suppressif 1; - not present
suppressif 0; - present
```
But when I've tried to create more complicated expressions I have
found out some strange things:
```
suppressif (1 AND 0); - present
suppressif (1 AND 1); - present (???)
suppressif (0 OR 0); - present
suppressif (1 OR 0); - present (???)
suppressif (TRUE OR 0); - present (???)
```
It looks like for correct behaviour explicit cast is needed:
```
suppressif ((BOOLEAN)1 AND (BOOLEAN)1); - not present
suppressif ((BOOLEAN)1 OR (BOOLEAN)0); - not present
suppressif (TRUE OR (BOOLEAN)0); - not present
```

Can someone explain to me the logic when the cast statement is not present?

Best regards,
Konstantin Aladyshev


How to use VFR string MULTI_LINE flag?

Konstantin Aladyshev
 

Hello!

According to the
https://edk2-docs.gitbook.io/edk-ii-vfr-specification/2_vfr_description_in_bnf/211_vfr_form_definition#2.11.6.7.1-vfr-string-statement-definition
it is possible to add `MULTI_LINE` flag to the VFR string element.

For example:
```
string
varid = FormData.StringValue,
prompt = STRING_TOKEN(STRING_PROMPT),
help = STRING_TOKEN(STRING_HELP),
flags = MULTI_LINE,
minsize = 5,
maxsize = 10,
endstring;
```
But how does it work? How to type `new line` in the HII? Because when
I type `enter` it simply changes the current value.

Best regards,
Konstantin Aladyshev


Which VFR elements can use 'namevaluevarstore' storage?

Konstantin Aladyshev
 

Hello!

There is only one usage example of the 'namevaluevarstore' storage in
the edk2 codebase
(https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr).
And in this driver this storage is used only by the `numeric` VFR elements.
Is it possible to use `namevaluevarstore` storage with other VFR elements?
I've tried to use it with the `checkbox` element, but in this case
build fails with an error:
```
ERROR 12288: CheckBox varid doesn't support array
```

Best regards,
Konstantin Aladyshev


Device path for the HII Form drivers

Konstantin Aladyshev
 

Hello!

Why form storage does not work if HII resources were published without
a DevicePath?

I'm trying to create a minimal example of a checkbox form:
```
formset
guid = FORMSET_GUID,
title = STRING_TOKEN(FORMSET_TITLE),
help = STRING_TOKEN(FORMSET_HELP),

efivarstore UINT8,
attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE,
name = MyVar,
guid = FORMSET_GUID;

form
formid = 1,
title = STRING_TOKEN(FORMID1_TITLE);

checkbox
varid = MyVar,
prompt = STRING_TOKEN(CHECKBOX_PROMPT),
help = STRING_TOKEN(CHECKBOX_HELP),
endcheckbox;
endform;
endformset;
```

Initially I've tried this code:
```
EFI_STATUS Status;

EFI_GUID Guid = FORMSET_GUID;

UINTN BufferSize;
UINT8 EfiVarstore;
BufferSize = sizeof(UINT8);
Status = gRT->GetVariable(
L"HIIFormCheckboxEfiVarstore",
&Guid,
NULL,
&BufferSize,
&EfiVarstore);
if (EFI_ERROR(Status)) {
ZeroMem(&EfiVarstore, sizeof(EfiVarstore));
Status = gRT->SetVariable(
L"HIIFormCheckboxEfiVarstore",
&Guid,
EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS,
sizeof(EfiVarstore),
&EfiVarstore);
}

mHiiHandle = HiiAddPackages(
&gEfiCallerIdGuid,
NULL,
HIIFormCheckboxStrings,
FormBin,
NULL
);
```

With this code form successfully loads but fails to save any data.

I've tried to debug OVMF code and have found out that the RouteConfig
call fails because the DevicePath is not present in the ConfigResp
string:
https://github.com/tianocore/edk2/blob/7c0ad2c33810ead45b7919f8f8d0e282dae52e71/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c#L5486

So I've added:
```
HII_VENDOR_DEVICE_PATH mHiiVendorDevicePath = {
{
{
HARDWARE_DEVICE_PATH,
HW_VENDOR_DP,
{
(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
}
},
FORMSET_GUID
},
{
END_DEVICE_PATH_TYPE,
END_ENTIRE_DEVICE_PATH_SUBTYPE,
{
(UINT8) (END_DEVICE_PATH_LENGTH),
(UINT8) ((END_DEVICE_PATH_LENGTH) >> 8)
}
}
};

...

Status = gBS->InstallProtocolInterface (
&mDriverHandle,
&gEfiDevicePathProtocolGuid,
EFI_NATIVE_INTERFACE,
&mHiiVendorDevicePath
);

...

mHiiHandle = HiiAddPackages(
&gEfiCallerIdGuid,
mDriverHandle,
HIIFormCheckboxStrings,
FormBin,
NULL
);
```

And now the storage works successfully.

But I still don't understand, why is the DevicePath mandatory?
efivarstore has GUID and name for the UEFI variable, and their values
are present in the ConfigResp string. Why do we need something more
for the system to work?

Best regards,
Konstantin Aladyshev


Re: Uefi

Nate DeSimone
 

Hi Wolf,

We have support for two older Clevo models, the N130WU/N131WU and the N140WU/N141WU. You can compile images for those systems using the “GalagoPro3” build target. Please see here for more information: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel

Thanks,
Nate

From: <discuss@edk2.groups.io> on behalf of wolf wolf <wolfw2140@...>
Reply-To: "discuss@edk2.groups.io" <discuss@edk2.groups.io>, "wolfw2140@..." <wolfw2140@...>
Date: Wednesday, February 16, 2022 at 7:50 AM
To: "discuss@edk2.groups.io" <discuss@edk2.groups.io>
Subject: [edk2-discuss] Uefi

hello, can I flash my clevo laptop with your uef?


How to start contributing?

Joursoir
 

Hello everyone,

I would like to take part in the development of TianoCore projects. I'm familiar with UEFI and PI specifications, have written some drivers and applications at my work. At free time, I write file manager with text-based UI for UEFI Shell (link below). Unfortunately, I have no experience with contributing to open source projects. Also I am interested to become a GSoC contibutor.

What can I do now to understand the development and communication process? Try to fix some bug from the bug tracker?

Link to file manager: http://git.joursoir.net/ufm/about (https://github.com/Joursoir/ufm). I would appreciate any feedback. If sharing a link to any project to the mailing list is rude, please, let me know

--
Joursoir


PCIe RS232 card in UEFI Shell

Gelip <mrgelip@...>
 

I have a motherboard with an integrated COM port. This port works in UEFI Shell after loading the drivers:
load TerminalDxe.efi PciSioSerialDxe.efi

Drivers unpacked from edk2.git-ovmf-x64-0-20211216.122.gc9b7c6e0cc.noarch.rpm\.\usr\share\edk2.git\ovmf-x64\OVMF-pure-efi.fd

I have a second PC connected with a null-modem cable and after loading the drivers UEFI Shell automatically appears in Putty.

I have another motherboard that does not have an integrated RS232 port. I connected PCIe card with serial port (SER5427A) but after loading the drivers .efi port does not work.
How to enable port on this card under UEFI Shell?


Uefi

wolf wolf <wolfw2140@...>
 

hello, can I flash my clevo laptop with your uef?


Is it necessary to support capital letter in DER/PEM-encoded certificate suffix

wenyi,xie
 

Hi, all

Now only lowercase letter is valid in DER/PEM-encoded certificate suffix in function IsDerPemEncodeCertificate(). Is it necaeeary to also support capital letter.

Thanks
Wenyi


Runtime service SetVariable does not call Reclaim() on linux

tinhn@...
 

Hi,

On OS (like Linux), the runtime service Setvariable() will return EFI_OUT_OF_RESOURCE when the variable store is almost full.
Why does it not call Reclaim to free up space?

I found this code block:
MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c

if (AtRuntime ()) {
if (IsCommonUserVariable && ((VarSize + mVariableModuleGlobal->CommonUserVariableTotalSize) > mVariableModuleGlobal->CommonMaxUserVariableSpace)) {
RecordVarErrorFlag (VAR_ERROR_FLAG_USER_ERROR, VariableName, VendorGuid, Attributes, VarSize);
}
if (IsCommonVariable && ((VarSize + mVariableModuleGlobal->CommonVariableTotalSize) > mVariableModuleGlobal->CommonRuntimeVariableSpace)) {
RecordVarErrorFlag (VAR_ERROR_FLAG_SYSTEM_ERROR, VariableName, VendorGuid, Attributes, VarSize);
}
Status = EFI_OUT_OF_RESOURCES;
goto Done;
}
//
// Perform garbage collection & reclaim operation, and integrate the new variable at the same time.
//

Status = Reclaim (
mVariableModuleGlobal->VariableGlobal.NonVolatileVariableBase,
&mVariableModuleGlobal->NonVolatileLastVariableOffset,
FALSE,
Variable,
NextVariable,
HEADER_ALIGN (VarSize)
);

Please help me out.

Many thanks,


Re: UEFI shell output to console

Andrew Fish
 

Konstantin,

There is a virtual console device called the ConSplitter that aggregates physical console. You can dump out the Console Output devices in the UEFI Shell via `dh -p SimpleTextOut`. The handles that have a DevicePath are the physical console devices, and the ones without are part of the Conspliter. The Console published by UEFI is the ConSpliter handle.

If Grub is not working that that would imply Grub is not doing it the UEFI way, but the Grub way. Maybe Grub is drawing directly to the graphics screen? Or maybe Grub pick a physical console to use. I’d investigate this from the Grub config point of view.

Thanks,

Andrew Fish

On Feb 6, 2022, at 2:51 AM, Konstantin Aladyshev <aladyshev22@...> wrote:

Hello!

The UEFI firmware on my motherboard has an option "Console
Redirection". When it is enabled, the BIOS menu can be redirected to
the serial port that is connected to the BMC controller on the board.
Basically that means that with the help of the Serial-over-LAN IPMI
feature it is possible to see the BIOS menu over LAN.
Initially I thought that this is purely a BIOS menu feature, but I've
noticed that if I boot to the UEFI shell all its output would be
redirected as well, and moreover wrapped to 80x24 IPMI terminal
nicely. But if I boot to the GRUB menu, nothing would be printed.
What can be the reason for such different behaviour? What protocols
UEFI shell uses when it prints characters to the screen?

Best regards,
Konstantin Aladyshev





UEFI shell output to console

Konstantin Aladyshev
 

Hello!

The UEFI firmware on my motherboard has an option "Console
Redirection". When it is enabled, the BIOS menu can be redirected to
the serial port that is connected to the BMC controller on the board.
Basically that means that with the help of the Serial-over-LAN IPMI
feature it is possible to see the BIOS menu over LAN.
Initially I thought that this is purely a BIOS menu feature, but I've
noticed that if I boot to the UEFI shell all its output would be
redirected as well, and moreover wrapped to 80x24 IPMI terminal
nicely. But if I boot to the GRUB menu, nothing would be printed.
What can be the reason for such different behaviour? What protocols
UEFI shell uses when it prints characters to the screen?

Best regards,
Konstantin Aladyshev


Re: edk2 app size

Roman Bacik
 

Hi Andrew,

That is great, you are right, overriding flags in the dsc file sounds like
a better way.
Thank you very much for your help,

Roman

On Thu, Jan 27, 2022 at 12:26 PM Andrew Fish <afish@...> wrote:

I forgot to mention you can also override the flags per driver/app in the
DSC. You can use <BuldOptions>. I don’t see an example of that. Here is an
example that overrides <LibraryClasses>. The syntax in the block would be
the same as the global [LibraryClasses] block.


https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.dsc#L745

MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
}
Thanks,

Andrew Fish

On Jan 27, 2022, at 12:19 PM, Roman Bacik <roman.bacik@...>
wrote:

Hi Andrew,


Yes, that is correct, our efi app is 25MB or so.
Thanks,


Roman


*From:* Andrew Fish <afish@...>
*Sent:* Thursday, January 27, 2022 12:18 PM
*To:* discuss <discuss@edk2.groups.io>; Roman Bacik <
roman.bacik@...>
*Cc:* Ard Biesheuvel <ard.biesheuvel@...>; Vladimir Olovyannikov <
vladimir.olovyannikov@...>
*Subject:* Re: [edk2-discuss] edk2 app size


Roman,


I assume your issue is due to your driver being larger? So you expect the
tiny model to not work?


https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
-mcmodel=tiny
Generate code for the tiny code model. The program and its statically
defined symbols must be within 1MB of each other. Programs can be
statically or dynamically linked.
-mcmodel=small
Generate code for the small code model. The program and its statically
defined symbols must be within 4GB of each other. Programs can be
statically or dynamically linked. This is the default code model.
-mcmodel=large
Generate code for the large code model. This makes no assumptions about
addresses and sizes of sections. Programs can be statically linked only.
The -mcmodel=large option is incompatible with -mabi=ilp32, -fpic and
-fPIC.




If you want a solution that does not require you to override the default
compiler settings you could try to set the flag in your DSC file. Usually
with the compiler the last version of a flag wins so you could try to
overload to -mcmodel=small in the DSC.


Here is an example. If you don’t want to restrict to a specific module
type you can just use [BuildOptions]


https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.dsc#L98
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
XCODE:*_*_*_DLINK_FLAGS = -seg1addr 0x1000 -segalign 0x1000
XCODE:*_*_*_MTOC_FLAGS = -align 0x1000
CLANGPDB:*_*_*_DLINK_FLAGS = /ALIGN:4096


You can also replace the * with something that better matches the compiler
version you are using if you want to be more targeted, and be portable with
other compilers.


Thanks,


Andrew Fish


On Jan 25, 2022, at 8:31 AM, Roman Bacik via groups.io <
roman.bacik@...> wrote:


Hi Andrew,

We use gcc-linaro-5.5.0-2017.10-x86_64_aarch64-linux-gnu. This is the
settings of the flags:

DEBUG_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) -O0 -mcmodel=small
DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z
common-page-size=0x1000
DEBUG_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20

RELEASE_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) -flto
-Wno-unused-but-set-variable -mcmodel=tiny -fomit-frame-pointer
RELEASE_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -flto -Os
-L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64
-Wl,-plugin-opt=-pass-through=-llto-aarch64

NOOPT_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) -O0 -mcmodel=small
NOOPT_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z
common-page-size=0x1000 -O0
NOOPT_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20 -O0

Based on your comment, we have made the following change to the RELEASE
flags settings, which seems to work:

RELEASE_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) -flto
-Wno-unused-but-set-variable -mcmodel=small -fomit-frame-pointer
RELEASE_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -flto -Os
-L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64
-Wl,-plugin-opt=-pass-through=-llto-aarch64 -z common-page-size=0x1000
RELEASE_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20

Thank you very much for your help,

Roman


On Mon, Jan 24, 2022 at 7:32 PM Andrew Fish <afish@...> wrote:



On Jan 24, 2022, at 4:13 PM, Roman Bacik <roman.bacik@...> wrote:

We have created bnxtmt.efi app running in edk2 shell. It builds and runs
ok when created with NOOPT and DEBUG options. But it fails to link when
using RELEASE option.
The errors we see:

...
/local/ldk/netxtreme/main/Cumulus/util/bnxt-mt/src/bnxtmt/tcl/dos/tclAppIn
it.c:224:(.text.Tcl_AppInit+0x50): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against `.rodata.str1.1'
bnxtmt.dll.ltrans0.ltrans.o: In function `init_efi':
/local/ldk/netxtreme/main/Cumulus/util/bnxt-mt/src/bnxtmt/os_util/uefi/os_
uefi.c:363:(.text.Tcl_AppInit+0x60): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against symbol `NX2_BootServices' defined in
.bss.NX2_BootServices section in bnxtmt.dll.ltrans22.ltrans.o
bnxtmt.dll.ltrans0.ltrans.o: In function `tcl_al_diag_init':
/local/ldk/netxtreme/main/Cumulus/util/bnxt-mt/src/common/tcl_al/tcl_al.c:
367:(.text.Tcl_AppInit+0x68): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against `.rodata.str1.1'
bnxtmt.dll.ltrans0.ltrans.o: In function `dg_get_no_pci_flag':
/local/ldk/netxtreme/main/Cumulus/util/bnxt-mt/src/common/diag_manager/dg_
init.c:231:(.text.Tcl_AppInit+0x78): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against symbol `no_pci_flag.lto_priv.844' defined
in .bss.no_pci_flag.lto_priv.844 section in bnxtmt.dll.ltrans9.ltrans.o
bnxtmt.dll.ltrans0.ltrans.o: In function `console_init':
/local/ldk/netxtreme/main/Cumulus/util/bnxt-mt/src/common/util/debug.c:64:
(.text.Tcl_AppInit+0x88): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against `.bss.console_buffer.lto_priv.1155'
...

Do you have any suggestions on how to fix it?
Thanks,


Roman,

Which toolchain are you using?

If you look in Conf/tools_def.txt (it was copied
from BaseTools/Conf/tools_def.template [1]) it should show you the compiler
and linker flags.

So you could take a quick look to see if something is unique about the
RELEASE build.
<build type or * for all>_<compiler>_AARCH64_CC_FLAGS
<build type or * for all>_<compiler_AARCH64_DLINK_FLAGS

You can change the Conf/tools_def.txt locally to test things out, but it
will get copied back over from the template file on a new build.

It looks like these are likely 32-bit relocations that don’t resolve. So
the other thing to look for is does you RELEASE build add any large global
data structures?


[1]

https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template

Thanks,

Andrew Fish


Roman

--
This electronic communication and the information and any files
transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may
contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.



--
This electronic communication and the information and any files transmitted

with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain

information that is confidential, legally privileged, protected by privacy

laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.






This electronic communication and the information and any files
transmitted with it, or attached to it, are confidential and are intended
solely for the use of the individual or entity to whom it is addressed and
may contain information that is confidential, legally privileged, protected
by privacy laws, or otherwise restricted from disclosure to anyone else. If
you are not the intended recipient or the person responsible for delivering
the e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.


--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.


Re: edk2 app size

Andrew Fish
 

I forgot to mention you can also override the flags per driver/app in the DSC. You can use <BuldOptions>. I don’t see an example of that. Here is an example that overrides <LibraryClasses>. The syntax in the block would be the same as the global [LibraryClasses] block.


https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.dsc#L745

MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
}
Thanks,

Andrew Fish

On Jan 27, 2022, at 12:19 PM, Roman Bacik <roman.bacik@...> wrote:

Hi Andrew,

Yes, that is correct, our efi app is 25MB or so.
Thanks,

Roman

From: Andrew Fish <afish@... <mailto:afish@...>>
Sent: Thursday, January 27, 2022 12:18 PM
To: discuss <discuss@edk2.groups.io <mailto:discuss@edk2.groups.io>>; Roman Bacik <roman.bacik@... <mailto:roman.bacik@...>>
Cc: Ard Biesheuvel <ard.biesheuvel@... <mailto:ard.biesheuvel@...>>; Vladimir Olovyannikov <vladimir.olovyannikov@... <mailto:vladimir.olovyannikov@...>>
Subject: Re: [edk2-discuss] edk2 app size

Roman,

I assume your issue is due to your driver being larger? So you expect the tiny model to not work?

https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
-mcmodel=tiny
<>Generate code for the tiny code model. The program and its statically defined symbols must be within 1MB of each other. Programs can be statically or dynamically linked.
-mcmodel=small
<>Generate code for the small code model. The program and its statically defined symbols must be within 4GB of each other. Programs can be statically or dynamically linked. This is the default code model.
-mcmodel=large
<>Generate code for the large code model. This makes no assumptions about addresses and sizes of sections. Programs can be statically linked only. The -mcmodel=large option is incompatible with -mabi=ilp32, -fpic and -fPIC.


If you want a solution that does not require you to override the default compiler settings you could try to set the flag in your DSC file. Usually with the compiler the last version of a flag wins so you could try to overload to -mcmodel=small in the DSC.

Here is an example. If you don’t want to restrict to a specific module type you can just use [BuildOptions]

https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.dsc#L98
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
XCODE:*_*_*_DLINK_FLAGS = -seg1addr 0x1000 -segalign 0x1000
XCODE:*_*_*_MTOC_FLAGS = -align 0x1000
CLANGPDB:*_*_*_DLINK_FLAGS = /ALIGN:4096

You can also replace the * with something that better matches the compiler version you are using if you want to be more targeted, and be portable with other compilers.

Thanks,

Andrew Fish


On Jan 25, 2022, at 8:31 AM, Roman Bacik via groups.io <http://groups.io/> <roman.bacik@... <mailto:roman.bacik@...>> wrote:

Hi Andrew,

We use gcc-linaro-5.5.0-2017.10-x86_64_aarch64-linux-gnu. This is the
settings of the flags:

DEBUG_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) -O0 -mcmodel=small
DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z
common-page-size=0x1000
DEBUG_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20

RELEASE_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) -flto
-Wno-unused-but-set-variable -mcmodel=tiny -fomit-frame-pointer
RELEASE_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -flto -Os
-L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64
-Wl,-plugin-opt=-pass-through=-llto-aarch64

NOOPT_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) -O0 -mcmodel=small
NOOPT_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z
common-page-size=0x1000 -O0
NOOPT_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20 -O0

Based on your comment, we have made the following change to the RELEASE
flags settings, which seems to work:

RELEASE_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) -flto
-Wno-unused-but-set-variable -mcmodel=small -fomit-frame-pointer
RELEASE_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -flto -Os
-L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64
-Wl,-plugin-opt=-pass-through=-llto-aarch64 -z common-page-size=0x1000
RELEASE_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20

Thank you very much for your help,

Roman


On Mon, Jan 24, 2022 at 7:32 PM Andrew Fish <afish@... <mailto:afish@...>> wrote:



On Jan 24, 2022, at 4:13 PM, Roman Bacik <roman.bacik@... <mailto:roman.bacik@...>> wrote:

We have created bnxtmt.efi app running in edk2 shell. It builds and runs
ok when created with NOOPT and DEBUG options. But it fails to link when
using RELEASE option.
The errors we see:

...
/local/ldk/netxtreme/main/Cumulus/util/bnxt-mt/src/bnxtmt/tcl/dos/tclAppIn
it.c:224:(.text.Tcl_AppInit+0x50): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against `.rodata.str1.1'
bnxtmt.dll.ltrans0.ltrans.o: In function `init_efi':
/local/ldk/netxtreme/main/Cumulus/util/bnxt-mt/src/bnxtmt/os_util/uefi/os_
uefi.c:363:(.text.Tcl_AppInit+0x60): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against symbol `NX2_BootServices' defined in
.bss.NX2_BootServices section in bnxtmt.dll.ltrans22.ltrans.o
bnxtmt.dll.ltrans0.ltrans.o: In function `tcl_al_diag_init':
/local/ldk/netxtreme/main/Cumulus/util/bnxt-mt/src/common/tcl_al/tcl_al.c:
367:(.text.Tcl_AppInit+0x68): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against `.rodata.str1.1'
bnxtmt.dll.ltrans0.ltrans.o: In function `dg_get_no_pci_flag':
/local/ldk/netxtreme/main/Cumulus/util/bnxt-mt/src/common/diag_manager/dg_
init.c:231:(.text.Tcl_AppInit+0x78): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against symbol `no_pci_flag.lto_priv.844' defined
in .bss.no_pci_flag.lto_priv.844 section in bnxtmt.dll.ltrans9.ltrans.o
bnxtmt.dll.ltrans0.ltrans.o: In function `console_init':
/local/ldk/netxtreme/main/Cumulus/util/bnxt-mt/src/common/util/debug.c:64:
(.text.Tcl_AppInit+0x88): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against `.bss.console_buffer.lto_priv.1155'
...

Do you have any suggestions on how to fix it?
Thanks,


Roman,

Which toolchain are you using?

If you look in Conf/tools_def.txt (it was copied
from BaseTools/Conf/tools_def.template [1]) it should show you the compiler
and linker flags.

So you could take a quick look to see if something is unique about the
RELEASE build.
<build type or * for all>_<compiler>_AARCH64_CC_FLAGS
<build type or * for all>_<compiler_AARCH64_DLINK_FLAGS

You can change the Conf/tools_def.txt locally to test things out, but it
will get copied back over from the template file on a new build.

It looks like these are likely 32-bit relocations that don’t resolve. So
the other thing to look for is does you RELEASE build add any large global
data structures?


[1]
https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template

Thanks,

Andrew Fish


Roman

--
This electronic communication and the information and any files
transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may
contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.


--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.






This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.