Date   

Loading second PCI driver on the same PCI device hangs the system.

UdayS
 

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.


Re: edk2 build failure due to long paths

rajesh.ravi@broadcom.com
 

Thanks a lot Laszlo.

Regards,
Rajesh

On Thu, Jan 28, 2021 at 09:50 AM, Laszlo Ersek wrote:


Laszlo


Re: 'PciIO->Map' is returning "EFI_OUT_OF_RESOURCES" on Intel CRB device

UdayS
 

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


Re: 回复: [edk2-discuss] edk2 build failure due to long paths

rajesh.ravi@broadcom.com
 

Thanks a lot gaoliming.

Regards,
Rajesh

On Thu, Jan 28, 2021 at 04:57 PM, gaoliming wrote:


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


Exposing new block IO handle to Platform BIOS

sanket.goswami@...
 

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


回复: [edk2-discuss] edk2 build failure due to long paths

gaoliming
 

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

Can you try the latest edk2?

-----邮件原件-----
发件人: bounce+34241+490+4905953+8764802@groups.io
<bounce+34241+490+4905953+8764802@groups.io> 代表 Laszlo Ersek
发送时间: 2021年1月29日 1:51
收件人: discuss@edk2.groups.io; rajesh.ravi@broadcom.com
主题: Re: [edk2-discuss] edk2 build failure due to long paths

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





Re: edk2 build failure due to long paths

Laszlo Ersek
 

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


edk2 build failure due to long paths

rajesh.ravi@broadcom.com
 

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


HTTP Requests from UEFI Shell are denied access to HTTP Server

huynhhai323@...
 

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


GDB server does not start.

joseph@...
 

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
==================================================


How to use TimerLib on X64?

vapciogaming@...
 

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?


Re: 'PciIO->Map' is returning "EFI_OUT_OF_RESOURCES" on Intel CRB device

Laszlo Ersek
 

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


Re: 'PciIO->Map' is returning "EFI_OUT_OF_RESOURCES" on Intel CRB device

UdayS
 

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


Re: 'PciIO->Map' is returning "EFI_OUT_OF_RESOURCES" on Intel CRB device

Laszlo Ersek
 

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


'PciIO->Map' is returning "EFI_OUT_OF_RESOURCES" on Intel CRB device

UdayS
 

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


Runtime Capsule Update Support

Mayur Gudmeti
 

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


Re: EDK2 CI and edk2-platforms

Sean
 

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 1/7/2021 10:00 AM, 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?
Thanks,
Jeff


Re: EDK2 CI and edk2-platforms

Laszlo Ersek
 

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


EDK2 CI and edk2-platforms

Jeff Brasen
 

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?

Thanks,
Jeff


Re: iPXE isnt able to get link status from my oprom driver, but PXE works.

Michael Brown
 

On 22/12/2020 08:33, udai sharma wrote:
Also I was able to break into shell using "ESC+B" as "CNTRL+B" wasn't working.
Then I tried to setup the interface ip using ifstat, it didn't work but dhcp succeeded.
"ifstat" is a command to display the status of interfaces, not to configure them.

How can I verify Tx/Rx big packets as ping also disabled/not present the default ipxe.efi.
As documented at https://ipxe.org/cmd/ping you will need to enable the option PING_CMD in config/general.h when building iPXE in order to have the "ping" command available.

Hope that helps,

Michael

401 - 420 of 889