Date   

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


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

UdayS
 

Hi Michael,
I hope you are doing well. Sorry for the delay in reply.


So: there is no problem with the link state, and the fact that you were
able to obtain a DHCPv4 address and download something from your HTTP
server indicates that the link is very definitely up and functional.


The error that you are experiencing is described on the error page shown
in your error message:

http://ipxe.org/0f0a6095

As you will see from that page, this error indicates a TCP RST being
sent from your web server.

Since this appears to coincide with your first attempt to download
anything larger than a single network packet, my first guess would be
that you have a problem receiving full-sized packets.

iPXE will use the MTU as reported by your driver via
PXE_OPCODE_GET_INIT_INFO. The values in FrameDataLen and MediaHeaderLen
will be added together to create the receive buffer length as used by
iPXE. This buffer length will be provided to your driver as BufferLen
for subsequent calls to PXE_OPCODE_RECEIVE.
iPXE will also use the MTU to calculate the TCP MSS sent as part of the
TCP SYN packet.

The DHCP server is allowed to override the MTU, up to the maximum
supported by the hardware (which, in this case, is the value provided
via PXE_OPCODE_GET_INIT_INFO).

My UNDI driver is setting the same parameters in "UNDI_GetInitInfo" in the below driver.
https://github.com/tianocore/edk2-platforms/blob/master/Drivers/OptionRomPkg/UndiRuntimeDxe/Decode.c
For Underlying PHY, MTU is set to 1500.


You may want to check these various values. You may also want to check
that the MTU is configured correctly on your HTTP server, if your
network is using any kind of jumbo frames.

Also I captured the packet on server. And I see MSS value set to 1460.
Frame 1: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Dec 22, 2020 13:13:51.093371000 India Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1608623031.093371000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 78 bytes (624 bits)
Capture Length: 78 bytes (624 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:tcp]
[Coloring Rule Name: HTTP]
[Coloring Rule String: http || tcp.port == 80 || http2]
Ethernet II, Src: ChelsioC_29:46:40 (00:07:43:29:46:40), Dst: ChelsioC_40:7c:60 (00:07:43:40:7c:60)
Destination: ChelsioC_40:7c:60 (00:07:43:40:7c:60)
Source: ChelsioC_29:46:40 (00:07:43:29:46:40)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 102.90.90.96, Dst: 102.90.90.48
Transmission Control Protocol, Src Port: 26442, Dst Port: 80, Seq: 0, Len: 0
Source Port: 26442
Destination Port: 80
[Stream index: 0]
[TCP Segment Len: 0]
Sequence number: 0 (relative sequence number)
[Next sequence number: 0 (relative sequence number)]
Acknowledgment number: 0
1011 .... = Header Length: 44 bytes (11)
Flags: 0x002 (SYN)
Window size value: 65532
[Calculated window size: 65532]
Checksum: 0xf4f1 [unverified]
[Checksum Status: Unverified]
Urgent pointer: 0
Options: (24 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps, No-Operation (NOP), No-
Operation (NOP), SACK permitted, No-Operation (NOP), Window scale, Maximum segment size
TCP Option - No-Operation (NOP)
TCP Option - No-Operation (NOP)
TCP Option - Timestamps: TSval 191936, TSecr 0
TCP Option - No-Operation (NOP)
TCP Option - No-Operation (NOP)
TCP Option - SACK permitted
TCP Option - No-Operation (NOP)
TCP Option - Window scale: 9 (multiply by 512)
TCP Option - Maximum segment size: 1460 bytes


Arm Secondary Core Startup - question

Kurt Kennett <kurt_kennett@...>
 

My understanding of ARM secondary core startup is that the stacks for all the cores live at the top of UEFI memory.
The secondary core stacks sit at the top, with the primary core stack just under them.
The PrePi code for ARM runs on those stacks, and the cores enter a WFI loop waiting to be released to do useful work.
The problem I have seen is that the UEFI stacks are set at EfiBootServicesData memory type.
This memory is reclaimed by the OS from the EFI memory map when it starts.
This is a problem because the secondary cores will execute code ON THOSE STACKS when they are released. This means they
1) can corrupt that (physical) memory by writing to it before they jump to the OS entry point for those cores
or
2) crash because of stack contents for their local variables being garbage.

Can anyone confirm this is a problem? If it isn't i want to know what i'm missing.

Is the OS-specific bootloader expected to release those cores and put them into an OS wait loop on 'safe' stack memory and code prior to launching the OS?

Thanks,


Re: SPCR / SSDT generation in the DynamicTablesPkg

Samer El-Haj-Mahmoud
 

I did a quick look in edk2-platforms, and found similar cases at least with a couple of other systems: Marvell Armada and OctenTx. Both of these use a _HID of "MRVL0001" (with its own clock-frequency _DSD) and a _CID of "HISI0031" to pickup tty/serial/8250/8250_dw.c, while publishing an SPCR indicating 16550 InterfaceType. See for example https://github.com/tianocore/edk2-platforms/tree/master/Silicon/Marvell/Armada7k8k/AcpiTables and https://github.com/tianocore/edk2-platforms/tree/master/Silicon/Marvell/OcteonTx/AcpiTables/T91

Other systems like the Socionext SynQuacer and the Hisilicon systems picks 8250_dw.c as well for one of the UART controllers, using CID of "HISI0031". However, the UART used in SPCR is another controller, which is a standard ARM PL011 UART ("ARMH0011") : https://github.com/tianocore/edk2-platforms/tree/master/Silicon/Socionext/SynQuacer/AcpiTables


Given the variations in the hardware implementations (and Linux 8250 drivers), and the fact they are not all strictly 16550 compatible, maybe SsdtSerialPortFixupLib can be flexible to allow platforms to select their own "16550" HID/CID (via PCDs for example)? This can be done while still defaulting to PNP0501/ PNP0500 for 16550 compatible UARTs.



From: Sami Mujawar <Sami.Mujawar@arm.com>
Sent: Thursday, December 17, 2020 1:04 PM
To: Jeff Brasen (jbrasen@nvidia.com) <jbrasen@nvidia.com>; discuss@edk2.groups.io; Irene Park <ipark@nvidia.com>; Pierre Gondois <Pierre.Gondois@arm.com>; Alexei Fedorov <Alexei.Fedorov@arm.com>; nd <nd@arm.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Thanu Rangarajan <Thanu.Rangarajan@arm.com>
Subject: RE: [edk2-discuss] SPCR / SSDT generation in the DynamicTablesPkg

+Samer

From: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>
Sent: 19 November 2020 10:17 PM
To: Sami Mujawar <Sami.Mujawar@arm.com<mailto:Sami.Mujawar@arm.com>>; discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>; Irene Park <ipark@nvidia.com<mailto:ipark@nvidia.com>>; Pierre Gondois <Pierre.Gondois@arm.com<mailto:Pierre.Gondois@arm.com>>; Alexei Fedorov <Alexei.Fedorov@arm.com<mailto:Alexei.Fedorov@arm.com>>; nd <nd@arm.com<mailto:nd@arm.com>>
Cc: Thanu Rangarajan <Thanu.Rangarajan@arm.com<mailto:Thanu.Rangarajan@arm.com>>
Subject: Re: [edk2-discuss] SPCR / SSDT generation in the DynamicTablesPkg

Yes, that is the issue we are seeing.

Our COM acpi node has a different HID NVDA0100 which uses drivers\tty\serial\8250\8250_tegra.c in linux. It also has a _DSD node to expose the configured clock rate as that driver needs that as with device tree based bindings it gets that from the clock subsystem.

I did just test a forked copy of SsdtSerialPortFixupLib for our platfrom and it did work, but it seems like there would be an issue if someone wanted to use what is in DynamicPkg as the SPCR is marked as 4-byte access but the linux driver would use 1-byte accesses. Of course if we change the SPCR generation to be 1-byte that would break our systems table.


Thanks,

Jeff

________________________________
From: Sami Mujawar <Sami.Mujawar@arm.com<mailto:Sami.Mujawar@arm.com>>
Sent: Thursday, November 19, 2020 10:31 AM
To: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; discuss@edk2.groups.io<mailto:discuss@edk2.groups.io> <discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>>; Irene Park <ipark@nvidia.com<mailto:ipark@nvidia.com>>; Pierre Gondois <Pierre.Gondois@arm.com<mailto:Pierre.Gondois@arm.com>>; Alexei Fedorov <Alexei.Fedorov@arm.com<mailto:Alexei.Fedorov@arm.com>>; nd <nd@arm.com<mailto:nd@arm.com>>
Cc: Thanu Rangarajan <Thanu.Rangarajan@arm.com<mailto:Thanu.Rangarajan@arm.com>>
Subject: RE: [edk2-discuss] SPCR / SSDT generation in the DynamicTablesPkg

External email: Use caution opening links or attachments


Hi Irene, Jeff,



If I understand correctly, when the HID is PNP0501 the Linux driver 'drivers\tty\serial\8250\8250_pnp.c' is setting 'uart.port.iotype = UPIO_MEM;'

This results in the read/write access size being 1 byte. Is this the problem you are seeing?



If so, are you intending to change the HID in your serial port SSDT? Or you are defining a property to specify the access size?



Please let me know. I am thinking if this problem can be solved more generically.



With regards to SSDT generation I can see a few options here:

1. Implement a SsdtSerialPortFixupLib for your platform.

This would mean implementing the interfaces in https://github.com/tianocore/edk2/blob/master/DynamicTablesPkg/Include/Library/SsdtSerialPortFixupLib.h



2. A Feature PCD DisableUartSsdtGeneration could be introduced with the default value being FALSE.



I would prefer Option 1 as it would keep the Dynamic Tables Core code SBBR compliant.



Regards,



Sami Mujawar



From: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>
Sent: 18 November 2020 09:36 AM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>; Irene Park <ipark@nvidia.com<mailto:ipark@nvidia.com>>; Sami Mujawar <Sami.Mujawar@arm.com<mailto:Sami.Mujawar@arm.com>>; Pierre Gondois <Pierre.Gondois@arm.com<mailto:Pierre.Gondois@arm.com>>; Alexei Fedorov <Alexei.Fedorov@arm.com<mailto:Alexei.Fedorov@arm.com>>
Subject: Re: [edk2-discuss] SPCR / SSDT generation in the DynamicTablesPkg



To add a little more detail on what we were seeing our 16550 based serial has 4 byte spacing which the SPCR table is generated with correctly but then the dynamic table code creates a SSDT with the standard pnp hid/cid in the ssdt table which at least from my reading of the Linux driver looks like that only uses 1 byte spacing between registers. It is possible I missed something though.

Thanks,

Jeff

Get Outlook for Android<https://aka.ms/ghei36>



________________________________

From: Irene Park <ipark@nvidia.com<mailto:ipark@nvidia.com>>
Sent: Wednesday, November 18, 2020 1:16:10 AM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io> <discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>>; Irene Park <ipark@nvidia.com<mailto:ipark@nvidia.com>>; Sami.Mujawar@arm.com<mailto:Sami.Mujawar@arm.com> <Sami.Mujawar@arm.com<mailto:Sami.Mujawar@arm.com>>; pierre.gondois@arm.com<mailto:pierre.gondois@arm.com> <pierre.gondois@arm.com<mailto:pierre.gondois@arm.com>>; Alexei Fedorov <Alexei.Fedorov@arm.com<mailto:Alexei.Fedorov@arm.com>>; Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>
Subject: RE: [edk2-discuss] SPCR / SSDT generation in the DynamicTablesPkg



Hi Sami, Pierre, Alexei,
I wonder your thought about this topic.
Thank you,
Irene

-----Original Message-----
From: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io> <discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>> On Behalf Of Irene Park
Sent: Tuesday, November 17, 2020 3:28 AM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>
Subject: [edk2-discuss] SPCR / SSDT generation in the DynamicTablesPkg

External email: Use caution opening links or attachments


The latest patches to the DynamicTablesPkg help an SSDT generated to meet the SBBR requirement when an SPCR generation is desired.
But the auto-generated SSDT might be unable to describe the compatible but custom 16550 device on the non-SBBR compliant platform.
I wonder if an SSDT generation would be manageable when a user doesn't want to.

Thank you,
Irene



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: SPCR / SSDT generation in the DynamicTablesPkg

Sami Mujawar
 

+Samer

From: Jeff Brasen <jbrasen@nvidia.com>
Sent: 19 November 2020 10:17 PM
To: Sami Mujawar <Sami.Mujawar@arm.com>; discuss@edk2.groups.io; Irene Park <ipark@nvidia.com>; Pierre Gondois <Pierre.Gondois@arm.com>; Alexei Fedorov <Alexei.Fedorov@arm.com>; nd <nd@arm.com>
Cc: Thanu Rangarajan <Thanu.Rangarajan@arm.com>
Subject: Re: [edk2-discuss] SPCR / SSDT generation in the DynamicTablesPkg

Yes, that is the issue we are seeing.

Our COM acpi node has a different HID NVDA0100 which uses drivers\tty\serial\8250\8250_tegra.c in linux. It also has a _DSD node to expose the configured clock rate as that driver needs that as with device tree based bindings it gets that from the clock subsystem.

I did just test a forked copy of SsdtSerialPortFixupLib for our platfrom and it did work, but it seems like there would be an issue if someone wanted to use what is in DynamicPkg as the SPCR is marked as 4-byte access but the linux driver would use 1-byte accesses. Of course if we change the SPCR generation to be 1-byte that would break our systems table.


Thanks,

Jeff

________________________________
From: Sami Mujawar <Sami.Mujawar@arm.com<mailto:Sami.Mujawar@arm.com>>
Sent: Thursday, November 19, 2020 10:31 AM
To: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; discuss@edk2.groups.io<mailto:discuss@edk2.groups.io> <discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>>; Irene Park <ipark@nvidia.com<mailto:ipark@nvidia.com>>; Pierre Gondois <Pierre.Gondois@arm.com<mailto:Pierre.Gondois@arm.com>>; Alexei Fedorov <Alexei.Fedorov@arm.com<mailto:Alexei.Fedorov@arm.com>>; nd <nd@arm.com<mailto:nd@arm.com>>
Cc: Thanu Rangarajan <Thanu.Rangarajan@arm.com<mailto:Thanu.Rangarajan@arm.com>>
Subject: RE: [edk2-discuss] SPCR / SSDT generation in the DynamicTablesPkg

External email: Use caution opening links or attachments


Hi Irene, Jeff,



If I understand correctly, when the HID is PNP0501 the Linux driver 'drivers\tty\serial\8250\8250_pnp.c' is setting 'uart.port.iotype = UPIO_MEM;'

This results in the read/write access size being 1 byte. Is this the problem you are seeing?



If so, are you intending to change the HID in your serial port SSDT? Or you are defining a property to specify the access size?



Please let me know. I am thinking if this problem can be solved more generically.



With regards to SSDT generation I can see a few options here:

1. Implement a SsdtSerialPortFixupLib for your platform.

This would mean implementing the interfaces in https://github.com/tianocore/edk2/blob/master/DynamicTablesPkg/Include/Library/SsdtSerialPortFixupLib.h



2. A Feature PCD DisableUartSsdtGeneration could be introduced with the default value being FALSE.



I would prefer Option 1 as it would keep the Dynamic Tables Core code SBBR compliant.



Regards,



Sami Mujawar



From: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>
Sent: 18 November 2020 09:36 AM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>; Irene Park <ipark@nvidia.com<mailto:ipark@nvidia.com>>; Sami Mujawar <Sami.Mujawar@arm.com<mailto:Sami.Mujawar@arm.com>>; Pierre Gondois <Pierre.Gondois@arm.com<mailto:Pierre.Gondois@arm.com>>; Alexei Fedorov <Alexei.Fedorov@arm.com<mailto:Alexei.Fedorov@arm.com>>
Subject: Re: [edk2-discuss] SPCR / SSDT generation in the DynamicTablesPkg



To add a little more detail on what we were seeing our 16550 based serial has 4 byte spacing which the SPCR table is generated with correctly but then the dynamic table code creates a SSDT with the standard pnp hid/cid in the ssdt table which at least from my reading of the Linux driver looks like that only uses 1 byte spacing between registers. It is possible I missed something though.

Thanks,

Jeff

Get Outlook for Android<https://aka.ms/ghei36>



________________________________

From: Irene Park <ipark@nvidia.com<mailto:ipark@nvidia.com>>
Sent: Wednesday, November 18, 2020 1:16:10 AM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io> <discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>>; Irene Park <ipark@nvidia.com<mailto:ipark@nvidia.com>>; Sami.Mujawar@arm.com<mailto:Sami.Mujawar@arm.com> <Sami.Mujawar@arm.com<mailto:Sami.Mujawar@arm.com>>; pierre.gondois@arm.com<mailto:pierre.gondois@arm.com> <pierre.gondois@arm.com<mailto:pierre.gondois@arm.com>>; Alexei Fedorov <Alexei.Fedorov@arm.com<mailto:Alexei.Fedorov@arm.com>>; Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>
Subject: RE: [edk2-discuss] SPCR / SSDT generation in the DynamicTablesPkg



Hi Sami, Pierre, Alexei,
I wonder your thought about this topic.
Thank you,
Irene

-----Original Message-----
From: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io> <discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>> On Behalf Of Irene Park
Sent: Tuesday, November 17, 2020 3:28 AM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>
Subject: [edk2-discuss] SPCR / SSDT generation in the DynamicTablesPkg

External email: Use caution opening links or attachments


The latest patches to the DynamicTablesPkg help an SSDT generated to meet the SBBR requirement when an SPCR generation is desired.
But the auto-generated SSDT might be unable to describe the compatible but custom 16550 device on the non-SBBR compliant platform.
I wonder if an SSDT generation would be manageable when a user doesn't want to.

Thank you,
Irene



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Quest for your website and who can I go for information about the shell I have.

honzo right <righthonzo@...>
 

Hey I have your firmware installed in my aser Chromebooks bios files, and I'm not quite sure if I need it for my destro to boot through and run the desktop I want. But I'm just confused as to what this is and if it is configured correctly or if I have to configure it for that display I always see when I search up UEFI. Please let me know, and I will be looking at your website.


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

Michael Brown <mcb30@...>
 

On 15/12/2020 06:48, udai sharma wrote:
net2: 00:07:43:29:46:40 using NII on NII-0000:02:00.0 (open)
This shows that you are using iPXE's "NII" driver, which uses the UEFI UNDI API. (Possible alternatives were the "SNP" driver which uses the UEFI SNP API, or a native PCI driver.)

[Link:down, TX:0 TXE:0 RX:0 RXE:0]
[Link status: Unknown (http://ipxe.org/1a086194)]
The link is reported as down in this initial banner because the UEFI UNDI API does not provide any way to retrieve the link state until after the interface has been opened. However...

Configuring (net2 00:07:43:29:46:40)............. ok
... the link is successfully up at this point, otherwise you would be seeing a "Waiting for link-up on net2" message from iPXE.

net0: fe80::ec4:7aff:fe6c:623e/64 (inaccessible)
net1: fe80::ec4:7aff:fe6c:623f/64 (inaccessible)
net2: 102.90.90.96/255.255.255.0 gw 102.90.90.1
net2: fe80::207:43ff:fe29:4640/64
net3: fe80::207:43ff:fe29:4658/64 (inaccessible)
Next server: 102.90.90.48
Filename: http://102.90.90.48/real_boot_script.php
http://102.90.90.48/real_boot_script.php.... [connecting].. ok
real_boot_script.php : 208 bytes [script]
http://102.90.90.48/iPXE/initrd.img...... 0%
Connection reset (http://ipxe.org/0f0a6095)
Could not boot image: Connection reset (http://ipxe.org/0f0a6095)
No more network devices
As you can see it is able to fetch 'real_boot_script.php' from http server, but Link remains Down.
So: there is no problem with the link state, and the fact that you were able to obtain a DHCPv4 address and download something from your HTTP server indicates that the link is very definitely up and functional.

The error that you are experiencing is described on the error page shown in your error message:

http://ipxe.org/0f0a6095

As you will see from that page, this error indicates a TCP RST being sent from your web server.

Since this appears to coincide with your first attempt to download anything larger than a single network packet, my first guess would be that you have a problem receiving full-sized packets.

iPXE will use the MTU as reported by your driver via PXE_OPCODE_GET_INIT_INFO. The values in FrameDataLen and MediaHeaderLen will be added together to create the receive buffer length as used by iPXE. This buffer length will be provided to your driver as BufferLen for subsequent calls to PXE_OPCODE_RECEIVE.

iPXE will also use the MTU to calculate the TCP MSS sent as part of the TCP SYN packet.

The DHCP server is allowed to override the MTU, up to the maximum supported by the hardware (which, in this case, is the value provided via PXE_OPCODE_GET_INIT_INFO).

You may want to check these various values. You may also want to check that the MTU is configured correctly on your HTTP server, if your network is using any kind of jumbo frames.

Thanks,

Michael


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

udai sharma <udai16787@...>
 

Hi Michael,
I am unable to break into iPXE shell (using Ctrl+B).

I could capture the below log from the serial console.

>Checking Media Presence......
>>Media Present......
>>Start PXE over IPv4.
Station IP address is 102.90.90.195

Server IP address is 102.90.90.48
NBP filename is ipxe.efi
NBP filesize is 987744 Bytes
>>Checking Media Presence......
>>Media Present......
Downloading NBP file...

Succeed to download NBP file.
iPXE initialising devices...ok



iPXE 1.20.1+ (gb6e2e) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DNS HTTP iSCSI TFTP SRP AoE EFI Menu

Press Ctrl-B for the iPXE command line...
net2: 00:07:43:29:46:40 using NII on NII-0000:02:00.0 (open)
[Link:down, TX:0 TXE:0 RX:0 RXE:0]
[Link status: Unknown (http://ipxe.org/1a086194)]
Configuring (net2 00:07:43:29:46:40)............. ok
net0: fe80::ec4:7aff:fe6c:623e/64 (inaccessible)
net1: fe80::ec4:7aff:fe6c:623f/64 (inaccessible)
net2: 102.90.90.96/255.255.255.0 gw 102.90.90.1
net2: fe80::207:43ff:fe29:4640/64
net3: fe80::207:43ff:fe29:4658/64 (inaccessible)
Next server: 102.90.90.48
Filename: http://102.90.90.48/real_boot_script.php
http://102.90.90.48/real_boot_script.php.... [connecting].. ok
real_boot_script.php : 208 bytes [script]
http://102.90.90.48/iPXE/initrd.img...... 0%
Connection reset (http://ipxe.org/0f0a6095)
Could not boot image: Connection reset (http://ipxe.org/0f0a6095)
No more network devices


As you can see it is able to fetch 'real_boot_script.php' from http server, but Link remains Down.

I cloned 'git clone git://git.ipxe.org/ipxe.git' recently and created image using 'make bin-x86_64-
efi/ipxe.efi'.

Thanks.



On Tue, 15 Dec 2020 06:31:45 +0530 Michael Brown wrote
>On 14/12/2020 19:00, Laszlo Ersek wrote:

> On 12/14/20 18:44, udai sharma wrote:

>> Hello Community,

>>

>> My OptionRom driver works with PXE but it fails to get/report link

>> status in iPXE.

>>

>> I had setup iPXE.efi in dhcp.conf to load it from DHCP-PXE server.

>> I see it gets loaded properly.

>>

>> But when iPXE ifconfig tries to look for link status, it always

>> fails to get the link status.

>>

>> I need to understand is there something with my oprom driver or the

>> driver in iPXE.efi has to be looked into.

>>

>> Thanks in advance.

>

> no clue, but I'm adding Michael.



Thanks for the heads-up!



Udai: which driver is iPXE using? You can find out via the "ifstat"

command in the iPXE shell.



Thanks,



Michael



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

Michael Brown <mcb30@...>
 

On 14/12/2020 19:00, Laszlo Ersek wrote:
On 12/14/20 18:44, udai sharma wrote:
Hello Community,
My OptionRom driver works with PXE but it fails to get/report link
status in iPXE.
I had setup iPXE.efi in dhcp.conf to load it from DHCP-PXE server.
I see it gets loaded properly.
But when iPXE ifconfig tries to look for link status, it always
fails to get the link status.
I need to understand is there something with my oprom driver or the
driver in iPXE.efi has to be looked into.
Thanks in advance.
no clue, but I'm adding Michael.
Thanks for the heads-up!

Udai: which driver is iPXE using? You can find out via the "ifstat" command in the iPXE shell.

Thanks,

Michael


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

udai sharma <udai16787@...>
 

Hello Community,
My OptionRom driver works with PXE but it fails to get/report link status in iPXE.

I had setup iPXE.efi in dhcp.conf to load it from DHCP-PXE server. I see it gets loaded properly.
But when iPXE ifconfig tries to look for link status, it always fails to get the link status.
I need to understand is there something with my oprom driver or the driver in iPXE.efi has to be looked
into.

Thanks in advance.
US


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

Laszlo Ersek
 

Hi,

On 12/14/20 18:44, udai sharma wrote:
Hello Community,

My OptionRom driver works with PXE but it fails to get/report link status in iPXE.



I had setup iPXE.efi in dhcp.conf to load it from DHCP-PXE server. I see it gets loaded properly.

But when iPXE ifconfig tries to look for link status, it always fails to get the link status.

I need to understand is there something with my oprom driver or the driver in iPXE.efi has to be looked

into.



Thanks in advance.
no clue, but I'm adding Michael.

Thanks
Laszlo

381 - 400 of 859