Date   

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


Re: EDK2 and building it on windows

Oram, Isaac W
 

There is some training material here: https://github.com/tianocore-training/Tianocore_Training_Contents/wiki.

If you look at BaseTools/Conf/tools_def.template you will see "Supported Tool Chains", which includes VS2019.

When you run edksetup script, it creates Conf/tools_def.txt based on the template. And it makes Conf/target.txt. If you change target.txt TOOL_CHAIN_TAG to VS2019, you should be able to build successfully. I haven't tried it personally, but all the pieces seem to be in place.


EDK2 and building it on windows

gomi odabaşıoğlu <gomidas95@...>
 

Hello,

I work on a UEFI project with Visual Studio 2019. When I first learnt that I can directly control computer with UEFI I was really excited. I got a sample project called GNU-EFI from osdev.org and started writing some code. I started handling keys and mouse events and drawing graphics using Graphics Output Protocol. However, GNU-EFI does not have a standard C library. I searched about it and found that EDK2 also provides a libc. I think I need C library as some hardware's like nvidia-cuda-gpus supports C language. I am not sure if this idea is correct. On github page I tried to understand how to build EDK2. I followed steps but documentation was for vs2015 and in the end I got not found error for build command. That was the step for building vs2015. I was using vs2019 so I tried to modify related value to vs2019 in related file and run command again still I got same error. I was not sure if I did all steps correcty. I was not even sure how to config vs2019 project for this properly. In the end I deleted everything including added system variables. This is the first time I tried something like this. I could not find any video documentation that shows all steps and building it for visual studio 2019. I am really enthusiastic to learn this, a detailed video documentation would be really helpful for starters.

Best Regards

Gomidas


Question: Bug 3106 - Issue: EFI partition contents/files (FS0:\) not visible to EFI shell (OVMF + QEMU)

matthew.giassa@...
 

Good day,

I have been setting up a sort of TPM2 developer environment with QEMU and OVMF, and have hit a snag (https://bugzilla.tianocore.org/show_bug.cgi?id=3106). In short, I can build OVMF and launch QEMU with it, but it gets stuck at the EFI shell, and is unable to see the contents of the EFI partition (which I can confirm manually by mounting my QCOW2 image file and confirming the expected files are indeed present). It seems that, no matter what I do, I can get FS0 to be visible from the EFI shell, but the pre-populated files I've put into the EFI partition are not visible from the EFI shell.

Has anyone encountered something like this in the past? I found a somewhat similar post on the automotive Linux forums (but not solution), so I'm wondering if there's some common error case that results in this kind of error case (i.e. misconfigured EFI partition or bad QEMU options)?

Thank you.


BootOrder recovery behavior

Li, Walon
 

Hi edk2 guys,

I have a question about BootOrder recovery behavior and want to consult with you. I found Boot0000 would be first place in BootOrder when system try to recover options. Please check steps as below.

1. Boot to OS and check BootOrder. In my case, it's "Boot0004, Boot0001, Boot0000, Boot0002, Boot0003".
2. Then, adjust BootOrder by efibootmgr, only set one boot option in order by "efibootmgr -o 0004". As screenshot, you can see 5 boot options, but only one(Boot0004) in BootOrder after changing.
[cid:image005.jpg@01D6CE5A.FCC36290]
3. Reboot system, will see Boot0000 be located at first place in BootOrder and others behind the specified option.
[cid:image006.jpg@01D6CE5A.FCC36290]

Ideally, BootOrder would be reconstruct again so it should be "Boot0004, Boot0000, Boot0001, Boot0002, Boot0003" as I thought. Is it any reason to put Boot0000 at first place? Or just a bug? I used edk2-stable202008 to reproduce that on OVMF.
By the way, Boot0000 is none-bootable so the boot flow still works good to boot Boot0004. But options behavior aren't consistent, and it might affect user scripts if the specified option is not first one in BootOrder.

Thanks,
Walon


USB Isochronous Transfer Type Support

jerry.yeh@...
 

Hi all,

Recently, I am studying a new feature that need to use camera in UEFI BIOS.
And I found that EDK2 do not support isochronous transfer. (please refer to attached)
But almost all webcams only support isochronous transfer for video streaming.
Does anyone has the experience to implement USB ISO type or use camera in UEFI?

Million thanks.

https://github.com/tianocore/edk2/blob/418aded9645d8cf1d3a3bdfa3db0815d91790705/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c


Re: SPCR / SSDT generation in the DynamicTablesPkg

Sami Mujawar <Sami.Mujawar@...>
 

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@...>
Sent: 18 November 2020 09:36 AM
To: discuss@edk2.groups.io; Irene Park <ipark@...>; Sami Mujawar <Sami.Mujawar@...>; Pierre Gondois <Pierre.Gondois@...>; Alexei Fedorov <Alexei.Fedorov@...>
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


From: Irene Park <ipark@...>
Sent: Wednesday, November 18, 2020 1:16:10 AM
To:
discuss@edk2.groups.io <discuss@edk2.groups.io>; Irene Park <ipark@...>; Sami.Mujawar@... <Sami.Mujawar@...>; pierre.gondois@... <pierre.gondois@...>; Alexei Fedorov <Alexei.Fedorov@...>; Jeff Brasen <jbrasen@...>
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 <discuss@edk2.groups.io> On Behalf Of Irene Park
Sent: Tuesday, November 17, 2020 3:28 AM
To: 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.


Re: redundant NULL pointer check

wenyi,xie
 

Hi Laszlo,

Thank you for your detailed explanation, I get it.
I will post a patch later.

Thanks
Wenyi

On 2020/11/25 6:56, Laszlo Ersek wrote:
On 11/24/20 12:05, xiewenyi (A) wrote:
Hi Laszlo,

So if (Info->VolumeLabel == NULL) will always evaluate to FALSE when Info != NULL. Can we just remove it.
Well, we can approach this on two levels.

The first level is whether the code transformation (the patch) that you
are describing above would be correct. Yes, removing the comparison in
question is correct. Please feel free to post the patch.

But the deeper (zeroth) level is more nuanced. Namely, it's not
specifically the *non-nullity* of "Info" that guarantees
(Info->VolumeLabel != NULL). Instead, that consequence originates from
the *validity* of Info (namely, that it points to an
EFI_FILE_SYSTEM_VOLUME_LABEL object), and from the fact that
"VolumeLabel" is an *array* in EFI_FILE_SYSTEM_VOLUME_LABEL. The address
of an array object (well, of any object) that *exists* can never be NULL.

I'm not sure if my depiction is understandable. Basically, if Info is
not NULL, then (Info->VolumeLabel != NULL) holds *exactly because*:

CHAR16 VolumeLabel[1];

ASSERT (&VolumeLabel[0] != NULL);

holds as well.

Anyway... feel free to post the patch.

Thanks!
Laszlo

On 2020/11/24 18:52, Laszlo Ersek wrote:
On 11/24/20 10:22, wenyi,xie via groups.io wrote:
Hi all,
When removing -Wno-tautological-compare, there's a warning.

MdeModulePkg/Library/FileExplorerLib/FileExplorer.c:850:19: warning: comparison of array 'Info->VolumeLabel' equal to a null pointer is always false [-Wtautological-pointer-compare]
Search "no-tautological-compare" (4904 hits in 1 file)

Since Info is a pointer of struct EFI_FILE_SYSTEM_VOLUME_LABEL, and this struct has only one member VolumeLabel. So Info and Info->VolumeLabel are point to the same place.
So if Info != NULL, is it necessary to check Info->VolumeLabel == NULL again ?
Assuming Info is a valid pointer, Info->VolumeLabel is an array object.

When evaluated, Info->VolumeLabel is converted to the address of its
first element.

The address of the first element of an array object can never be NULL.
And so (Info->VolumeLabel == NULL) will always evaluate to FALSE.

Thanks
Laszlo

.
.


Re: redundant NULL pointer check

Laszlo Ersek
 

On 11/24/20 12:05, xiewenyi (A) wrote:
Hi Laszlo,

So if (Info->VolumeLabel == NULL) will always evaluate to FALSE when Info != NULL. Can we just remove it.
Well, we can approach this on two levels.

The first level is whether the code transformation (the patch) that you
are describing above would be correct. Yes, removing the comparison in
question is correct. Please feel free to post the patch.

But the deeper (zeroth) level is more nuanced. Namely, it's not
specifically the *non-nullity* of "Info" that guarantees
(Info->VolumeLabel != NULL). Instead, that consequence originates from
the *validity* of Info (namely, that it points to an
EFI_FILE_SYSTEM_VOLUME_LABEL object), and from the fact that
"VolumeLabel" is an *array* in EFI_FILE_SYSTEM_VOLUME_LABEL. The address
of an array object (well, of any object) that *exists* can never be NULL.

I'm not sure if my depiction is understandable. Basically, if Info is
not NULL, then (Info->VolumeLabel != NULL) holds *exactly because*:

CHAR16 VolumeLabel[1];

ASSERT (&VolumeLabel[0] != NULL);

holds as well.

Anyway... feel free to post the patch.

Thanks!
Laszlo

On 2020/11/24 18:52, Laszlo Ersek wrote:
On 11/24/20 10:22, wenyi,xie via groups.io wrote:
Hi all,
When removing -Wno-tautological-compare, there's a warning.

MdeModulePkg/Library/FileExplorerLib/FileExplorer.c:850:19: warning: comparison of array 'Info->VolumeLabel' equal to a null pointer is always false [-Wtautological-pointer-compare]
Search "no-tautological-compare" (4904 hits in 1 file)

Since Info is a pointer of struct EFI_FILE_SYSTEM_VOLUME_LABEL, and this struct has only one member VolumeLabel. So Info and Info->VolumeLabel are point to the same place.
So if Info != NULL, is it necessary to check Info->VolumeLabel == NULL again ?
Assuming Info is a valid pointer, Info->VolumeLabel is an array object.

When evaluated, Info->VolumeLabel is converted to the address of its
first element.

The address of the first element of an array object can never be NULL.
And so (Info->VolumeLabel == NULL) will always evaluate to FALSE.

Thanks
Laszlo

.


Re: redundant NULL pointer check

wenyi,xie
 

Hi Laszlo,

So if (Info->VolumeLabel == NULL) will always evaluate to FALSE when Info != NULL. Can we just remove it.

Thanks
Wenyi

On 2020/11/24 18:52, Laszlo Ersek wrote:
On 11/24/20 10:22, wenyi,xie via groups.io wrote:
Hi all,
When removing -Wno-tautological-compare, there's a warning.

MdeModulePkg/Library/FileExplorerLib/FileExplorer.c:850:19: warning: comparison of array 'Info->VolumeLabel' equal to a null pointer is always false [-Wtautological-pointer-compare]
Search "no-tautological-compare" (4904 hits in 1 file)

Since Info is a pointer of struct EFI_FILE_SYSTEM_VOLUME_LABEL, and this struct has only one member VolumeLabel. So Info and Info->VolumeLabel are point to the same place.
So if Info != NULL, is it necessary to check Info->VolumeLabel == NULL again ?
Assuming Info is a valid pointer, Info->VolumeLabel is an array object.

When evaluated, Info->VolumeLabel is converted to the address of its
first element.

The address of the first element of an array object can never be NULL.
And so (Info->VolumeLabel == NULL) will always evaluate to FALSE.

Thanks
Laszlo

.


Re: redundant NULL pointer check

Laszlo Ersek
 

On 11/24/20 10:22, wenyi,xie via groups.io wrote:
Hi all,
When removing -Wno-tautological-compare, there's a warning.

MdeModulePkg/Library/FileExplorerLib/FileExplorer.c:850:19: warning: comparison of array 'Info->VolumeLabel' equal to a null pointer is always false [-Wtautological-pointer-compare]
Search "no-tautological-compare" (4904 hits in 1 file)

Since Info is a pointer of struct EFI_FILE_SYSTEM_VOLUME_LABEL, and this struct has only one member VolumeLabel. So Info and Info->VolumeLabel are point to the same place.
So if Info != NULL, is it necessary to check Info->VolumeLabel == NULL again ?
Assuming Info is a valid pointer, Info->VolumeLabel is an array object.

When evaluated, Info->VolumeLabel is converted to the address of its
first element.

The address of the first element of an array object can never be NULL.
And so (Info->VolumeLabel == NULL) will always evaluate to FALSE.

Thanks
Laszlo

421 - 440 of 889