On 02/01/21 11:14, udai16787 via [] wrote:

Small Update:
I could fix the issue by moving the PCI->Map little early in the initialization but couldn't root cause it yet.

Could be that the portion of the address space that PciIo->Map() can
deal with gets fragmented in the part of code that you have now
eliminated, by moving the call earlier.

Laszlo

Hi all,
May I ask a question.
In what conditions will we update submodules. Will we update the sbumodule when it only fixes a vulnerability, or any other conditions should be meet before updating.

Hi,
I have two pci drivers (1) full driver with all functionality, (2) Driver which subset of (1).
Both drivers are working fine. Load/Unload at run time smoothly works when each of them are done independently.

Issue:
1. Load driver (1) and unload (1) now if I load driver (2), shell hangs.

I have verified loading/unloading of driver, multiple iterations, i.e. it cleanups all protocols installed.
But if I follow the issue procedure above, it hangs. I don't see error during initialization of second driver.

Need advise to debug this issue further.

Thank in advance.

Thanks a lot Laszlo.

Regards,
Rajesh

Small Update:
I could fix the issue by moving the PCI->Map little early in the initialization but couldn't root cause it yet.

Thanks a lot gaoliming.

Regards,
Rajesh

I'm working on a drivers for a storage controller. In it I install block IO protocol on each drive connected to the controller. Some of these drives may have OS in them.
These block IO handles are child handles of the controller handle.

In some scenarios I need to reinstall block IO protocol on the drives. This happens after boot when user changes the driver's configuration from BIOS menu.
Once I uninstall a block IO handle any driver using this block IO handle(e.g. Disk IO driver) with EFI_OPEN_PROTOCOL_BY_DRIVER attribute will be disconnected from this device.

1. when I install block IO again then Should I call boot service ConnectController to connect this block IO handle to all drivers in system?
I tried calling ConnectController service with recursive flag '-r' but it takes very long to complete the operation. So don't want to do it if it's not necessary.

2. If I want to do connect controller for only some specific drivers like disk IO driver, Is it ok to do it?
Because some drivers like partition driver use Disk IO handle to created child handle for each partition.
So if I connect to just Disk IO driver will the Partition driver and FAT system driver discover this new DiskIO handle and create partition handles and file system for it?

If I don't call connect controller service after reinstallation of Block IO protocol, the platform BIOS doesn't install partitions and file system on the bootable drive.

Thanks,
Sanket

BZ https://bugzilla.tianocore.org/show_bug.cgi?id=3032 has been fixed at 020ec963048340c9eaf9799471167d769239bcfc

Can you try the latest edk2?

On 01/28/21 10:29, rajesh.ravi@broadcom.com via groups.io wrote:

I 'm facing edk2 build issues on Linux build hosts when path length is long.

*Example scenarios*
Eg. A) manual/standalone builds: If edk2 code base is deep inside a
directory path instead of $HOME dir
B)Yocto builds: when SRCREV_FORMAT contains multiple components
making the uefi path very long.

*Source code*

It seems the following files are to support longer file paths and resolve
such issues.
*BaseTools/Source/Python/Common/LongFilePath*.py*

If so, please suggest how to enable longer file paths for edk2 builds on
Linux build host

You may have hit <https://bugzilla.tianocore.org/show_bug.cgi?id=3032>.

Thanks
Laszlo

I 'm facing edk2 build issues on Linux build hosts when path length is long.

*Example scenarios*
Eg. A) manual/standalone builds: If edk2 code base is deep inside a
directory path instead of $HOME dir
B)Yocto builds: when SRCREV_FORMAT contains multiple components
making the uefi path very long.

*Source code*

It seems the following files are to support longer file paths and resolve
such issues.
*BaseTools/Source/Python/Common/LongFilePath*.py*

If so, please suggest how to enable longer file paths for edk2 builds on
Linux build host
--
Regards,
Rajesh

Hi,

My name is Hayden. I am working on communications between a machine running only the UEFI Shell and an external server via HTTP Protocol. The Shell binary I am using is built from ShellPkg in the stable/202011 stable release. The issue I am facing is that both the http command binary (also built from ShellPkg in stable/202011) and HttpUtil program (source code attached with this post; written by me, based on the sample code on page 1548-1553 in the UEFI Spec 2.8B May 2020 document) were denied access to my HTTP server. Execution quitted whenever the Request function of the HttpProtocol instance was reached and a status of 15 (EFI_ACCESS_DENIED) is returned. Both machines are connected to the same network via the Catalyst 2960 Plus switch and they can ping each other seamlessly every time. I have also attached a zip containing files used to set up my simple HTTP server using NodeJS.

Any recommendations or advice would be greatly appreciated. And please do not hesitate to contact me if you need more information.

Best regards,
Hayden

It seems to be connected to DebugAgent, but the gdb server does not start.
I am using Hyper-V Generation 2.

==================================================
UEFI Shell:

disconnect (serial)
load -nc DebugAgentDxe.efi

Debug Agent: Initialized successfully!

Image 'FS1:\DebugAgentDxe.efi' loaded at F6C91000 - Success

==================================================
udk-gdb-server Log: (Can see also in https://pastebin.pl/view/ee5a1bc9 )

Intel(R) UEFI Development Kit Debugger Tool Version 1.5.1
Debugging through TCP (localhost:11001)
===Configuration===
Debug Port:
BaudRate =
Channel = TCP
Redirect Target output to TCP port (20715)
FlowControl =
Port = 11001
Server = localhost
Features:
TerminalRedirectionPort = 20715
Maintenance:
Trace = 0x1f
Target System:
ProcessorCount = 16
Send INIT break packet and try to connect the HOST (Intel(R) UDK Debugger Tool v1.5) ...
Received data [ fe 3f 06 00 59 ba ]
Request(3f) sequence (0)
Sent data [ fe 80 06 00 66 9f ]
ProcessAsyncCommand(): INIT_BREAK
Delay 0s before call HandleInitBreak()
HandleInitBreak() called
QueryRevision() called
Sent data [ fe 12 06 01 a0 87 ]
HOST connection is successful!
Timeout...
Recv timeout
Sent data [ fe 12 06 01 a0 87 ]
Received data [ fc 80 0a 01 d6 33 04 00 00 05 ]
Debug agent revision: 0.4
Sent data [ fe 80 06 01 57 ac ]
QueryRevision() returning : Revision = 4 Capability = 0
PutDebuggerSetting() called: Key = 2 Value = 1f
Sent data [ fe 11 08 02 33 92 02 1f ]
SendAckPacket: SequenceNo = 2
Sent data [ FE 80 06 02 04 F9 ]
Received data [ fe 80 06 02 04 f9 ]
PutDebuggerSetting() returning
PutDebuggerSetting() called: Key = 1 Value = 0
Sent data [ fe 11 08 03 e4 cb 01 00 ]
TARGET: Try to get command from HOST...
Timeout...
Recv timeout
Sent data [ fe 11 08 03 e4 cb 01 00 ]
Received data [ FE 11 08 03 00 00 01 00 ]
Processor[0]:Received one command(11)
SendAckPacket: SequenceNo = 3
Sent data [ FE 80 06 03 35 CA ]
Received data [ fe 80 06 03 35 ca ]
PutDebuggerSetting() returning
PutDebuggerSetting() called: Key = 3 Value = 0
Sent data [ fe 11 08 04 8b ba 03 00 ]
TARGET: Try to get command from HOST...
Timeout...
Recv timeout
Sent data [ fe 11 08 04 8b ba 03 00 ]
Received data [ FE 11 08 04 00 00 03 00 ]
Processor[0]:Received one command(11)
SendAckPacket: SequenceNo = 4
Sent data [ FE 80 06 04 A2 53 ]
Received data [ fe 80 06 04 a2 53 ]
PutDebuggerSetting() returning
IGetViewpoint() called
Sent data [ fe 15 06 05 49 1a ]
TARGET: Try to get command from HOST...
Timeout...
Recv timeout
Sent data [ fe 15 06 05 49 1a ]
Received data [ FE 15 06 05 00 00 ]
Processor[0]:Received one command(15)
Received data [ fc 80 09 05 76 9e 00 00 02 ]
Sent data [ fe 80 06 05 93 60 ]
IGetViewpoint() returning : TargetViewpoint = 0
MemoryReady() called
Sent data [ fe 3d 06 06 97 fd ]
Received data [ FE 80 06 05 00 00 ]
TARGET: Try to get command from HOST...
Timeout...
Recv timeout
Sent data [ fe 3d 06 06 97 fd ]
Received data [ FE 3D 06 06 00 00 ]
Processor[0]:Received one command(3D)
Sent data [ FE 80 07 06 42 D0 00 ]
Received data [ fe 80 07 06 42 d0 00 ]
Sent data [ fe 80 06 06 c0 35 ]
MemoryReady() returning : Ready = 0
Informing the happening of target event (reset)
Informed the happening of target event (reset)
IGo() called
Sent data [ fe 01 06 07 7d ad ]
Received data [ FE 80 06 06 00 00 ]
TARGET: Try to get command from HOST...
Timeout...
Recv timeout
Sent data [ fe 01 06 07 7d ad ]
Received data [ FE 01 06 07 00 00 ]
Processor[0]:Received one command(1)
SendAckPacket: SequenceNo = 7
Sent data [ FE 80 06 07 F1 06 ]
Received data [ fe 80 06 07 f1 06 ]
IGo() returning
HandleInitBreak() returning
Sent data [ FE 3D 06 01 00 64 ]
Received data [ fe 3d 06 01 00 64 ]
Request(3d) sequence (1)
Sent data [ fe 80 06 01 57 ac ]
Target memory is ready!
IGo() called
Sent data [ fe 01 06 08 43 bd ]
Received data [ FE 80 06 01 00 00 ]
TARGET: Try to get command from HOST...
Timeout...
Recv timeout
Sent data [ fe 01 06 08 43 bd ]
Received data [ FE 01 06 08 00 00 ]
Processor[0]:Received one command(1)
SendAckPacket: SequenceNo = 8
Sent data [ FE 80 06 08 CF 16 ]
Received data [ fe 80 06 08 cf 16 ]
IGo() returning
==================================================

Hello everyone, noob here.

I need an accurate timestamp counter for a UEFI_APPLICATION. currently i'm ussing MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf for the TimerLib but GetPerformanceCounter always returns 0. I read a bit about APIC and it seems that it needs to be initialized to work? What do I need to do to get GetPerformanceCounter to work?

On 01/15/21 06:33, udai16787 via [] wrote:

Hi Laszlo,
Thanks for replying.

(1) For BusMasterRead, you should not use AllocateBuffer. AllocateBuffer
is only needed for CommonBuffer operations.

Right. I have updated it now.

(2) PciIo->Map can run out of resources dependent on the IOMMU I guess,
as one reason. It can also run out of resources if you leak mappings
somewhere.

Prior to calling to above mentioned call, I do map two 16 bytes chunks for reading and current chunk where I get error is 128bytes long.

All systems need not react to such issues the same way.

What do you recommend how do I approach to this issue.

Ask your firmware vendor, or build your stuff upon open source software
that you can analyze yourself.

Thanks
Laszlo

Hi Laszlo,
Thanks for replying.

(1) For BusMasterRead, you should not use AllocateBuffer. AllocateBuffer
is only needed for CommonBuffer operations.

Right. I have updated it now.

(2) PciIo->Map can run out of resources dependent on the IOMMU I guess,
as one reason. It can also run out of resources if you leak mappings
somewhere.

Prior to calling to above mentioned call, I do map two 16 bytes chunks for reading and current chunk where I get error is 128bytes long.

All systems need not react to such issues the same way.

What do you recommend how do I approach to this issue.

-US

On 01/14/21 16:45, UdayS via groups.io wrote:

Hello Experts,
Need your help to understand why is PciIO->Map is returning "EFI_OUT_OF_RESOURCES" in my Intel CRB DQ57TM (v2.31) but same driver works in other SuperMicro system ( v2.31 and v2.4).
I understand it is specific to the IO mem allocated to the device, but I don't know how to find the memory map of the system and find the difference and the root cause of it.

Below is the code where I get error:
Status = PciIo->Map ( PciIo, // This
EfiPciIoOperationBusMasterRead, // Operation
(VOID *)RxBuffer, // HostAddress
(UINTN *)&RxSize, // NumberOfBytes
&DeviceAddress, // DeviceAddress
&RxBufferDMAMapping // Mapping
);
if (EFI_ERROR (Status)) {
AsciiPrint("\n PciIO->Map (RxBuffer[%d]): Status[%d]", RxSize, Status);
return CSIO_NOMEM;
}

And "RxBuffer", I have allocated using AllocateBuffer.

(1) For BusMasterRead, you should not use AllocateBuffer. AllocateBuffer
is only needed for CommonBuffer operations. For BusMasterRead and
BusMasterWrite, Map will handle bounce buffers internally.

(2) PciIo->Map can run out of resources dependent on the IOMMU I guess,
as one reason. It can also run out of resources if you leak mappings
somewhere. All systems need not react to such issues the same way.

Laszlo

Hello Experts,
Need your help to understand why is PciIO->Map is returning "EFI_OUT_OF_RESOURCES" in my Intel CRB DQ57TM (v2.31) but same driver works in other SuperMicro system ( v2.31 and v2.4).
I understand it is specific to the IO mem allocated to the device, but I don't know how to find the memory map of the system and find the difference and the root cause of it.

Below is the code where I get error:
Status = PciIo->Map ( PciIo, // This
EfiPciIoOperationBusMasterRead, // Operation
(VOID *)RxBuffer, // HostAddress
(UINTN *)&RxSize, // NumberOfBytes
&DeviceAddress, // DeviceAddress
&RxBufferDMAMapping // Mapping
);
if (EFI_ERROR (Status)) {
AsciiPrint("\n PciIO->Map (RxBuffer[%d]): Status[%d]", RxSize, Status);
return CSIO_NOMEM;
}

And "RxBuffer", I have allocated using AllocateBuffer.

Regards,
US

Hi,

I was wondering if can update the FMP capsule in storage with CapsuleInRamSupport enabled and without system reset. I was referring to this file https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c where gRT->UpdateCapsule is called when PcdCapsuleInRamSupport is enabled. In UpdateCapsule API, service which can be called by operating system too, checks whether CAPSULE_FLAGS_PERSIST_ACROSS_RESET and CAPSULE_FLAGS_INITIATE_RESET are set. If these flags are not set, then ProcessCapsuleImage is called which in turn calls ProcessThisCapsuleImage and then ProcessFmpCapsuleImage. ProcessFmpCapsuleImage calls a boot time service locate handle buffer through GetFmpHandleBufferByType. Now this is a runtime service calling a boottime service. Is this a possible bug or am I missing something here?

Thanks,
Mayur

There are a few challenges with the model of the edk2-platforms repo given that it doesn't have tracking of edk2 or any other dependency (submodule or otherwise). It also has no clear owner or anyone driving repository wide initiatives (like ci).

Ignoring that, the work to enable a "core ci" and "platform ci" in edk2-platforms would depend on the complexity of the build process of your platform but should be pretty small.

First you need to support the pytools based build process (https://github.com/tianocore/edk2-pytool-extensions). After that it just requires using the existing azurepipeline template files.


As an example see what is needed to enable "platform ci" for OVMF is here (and this includes additional work for automatic execution on qemu).
https://github.com/tianocore/edk2/tree/master/OvmfPkg/PlatformCI

To enable core CI
you need this per package: https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkg.ci.yaml

And some sort of very simple https://github.com/tianocore/edk2/blob/master/.pytool/CISettings.py

Another example is
EmulatorPkg here
https://github.com/tianocore/edk2/tree/master/EmulatorPkg/PlatformCI

A third example you can compare to for a platform that resides outside the edk2 tree is our Project Mu platform repo here:
https://github.com/microsoft/mu_tiano_platforms
but this is based on the Project Mu version of edk2 code and uses submodules to track dependencies.

Anyway, it has been talked about off and on, for the last few years but in my opinion the platform owners need to enable this.

Here is one effort Jeremiah Cox did to enable a more complicated Intel KBL based minplatform using pytools. (step 1 of getting platform ci) https://github.com/out0xb2/edk2-platforms/tree/feature/openkbl/galagopro3 It was presented at a edk2 community meeting in 2019 but was never picked up by the platform owners.


Thanks
Sean

On 01/07/21 19:00, Jeff Brasen wrote:

Hello,

Are there any plans on integrating the CI system (https://github.com/tianocore/edk2/tree/master/.pytool) to be able to test platform/silicon code hosted in the edk2-platforms repository? We are starting to develop some host based tests for our drivers and want to make sure we are supporting these in a way that will transfer well when we upstream in the future.

Would the .pytool be eventually mirrored into the edk2-platforms code or would the code in edk2 eventually expand to build things hosted in edk2-platforms?

I believe the idea has been floated before; unfortunately I don't
remember any specifics.

Laszlo