Re: [edk2] EDK II Network Stack Issue
On 1/22/19 6:34 PM, Laszlo Ersek wrote: Okay, summary: - forget the MdePkg and StdLib DSC files, build only AppPkg (or whatever platform DSC it is that produces your UEFI application) - make sure PcdDebugPropertyMask has bitmask 0x06 set when you build AppPkg (or the appropriate platform DSC in question); either modify the same DSC for this, or use the --pcd command line switch - make sure PcdDebugPrintErrorLevel has all the DEBUG_* bits set from "StdLib/EfiSocketLib/Socket.h" that you care about; the methods for setting this PCD are identical to those seen in the previous point. Hope this helps, Laszlo Hello Laszlo, debug prints are working now - thanks for your advice! Greetings, Karin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EDK II Network Stack Issue
Adding the list back in -- I can't really justify spending an hour or more on emails like this if I don't send them to the list. More importantly, I could be wrong about some details, and keeping the discussion on-list gives others a chance to correct me. Comments below: On 01/22/19 09:56, Karin Willers wrote: > On 2019-01-16 17:51, Laszlo Ersek wrote: > >>> >>> Could please someone shed some light on how to enable debug prints >>> using UefiDebugLibConOut in EfiSocketLib/Socket.c. Enabling debug >>> prints is, IMHO, not very intuitive in edk2 ... >> >> Can you build your platform and/or application with the --log and >> --report-file options, and share the outputs? The following could all >> matter: > > See attached ZIP-File. > >> >> - what you pass to "build" with "-b" (NOOPT/DEBUG/RELEASE), > > DEBUG is selected in target.txt > >> - gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask, >> - gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel, >> - gEfiMdePkgTokenSpaceGuid.PcdFixedDebugPrintErrorLevel, > > In StdLib.dsc I have: > > # > # Debug output control > # > DEFINE DEBUG_ENABLE_OUTPUT = TRUE# Set to TRUE to enable > debug output > # DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x8000 # Flags to control > amount of debug output > DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x # Flags to control > amount of debug output > DEFINE DEBUG_PROPERTY_MASK = 0x0f > > [PcdsFeatureFlag] > > [PcdsFixedAtBuild] > gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|$(DEBUG_PROPERTY_MASK) > > gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|$(DEBUG_PRINT_ERROR_LEVEL) > > This enables UefiDebugLibConOut.inf (in StdLib.dsc) as follows: > > !if $(DEBUG_ENABLE_OUTPUT) > DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf > > DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf > > !else ## DEBUG_ENABLE_OUTPUT > DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf > !endif ## DEBUG_ENABLE_OUTPUT > > Just to be sure (don't know whether this is really necessary) in > MdePkg.dsc I have: > gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x > >> - what lib instance you resolve the DebugLib class to, > > In 'StdLib.inc' (included from 'StdLib.dsc') I inserted: > DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf # > Debugging Support > >> - whether you apply the above just to your application, or all other >> DXE > > I suppose, just my application?! > >> components in your platform. > > I compile the parts (which I think I need) individually: > > o MdePkg > o StdLib > o AppPkg > > and then copy everything to a folder for use with OVMF. > > The packages were built in this exact order: > > build --log MdePkg-log.txt --report-file MdePkg-report-file.txt > build --log StdLib-log.txt --report-file StdLib-report-file.txt > build --log AppPkg-log.txt --report-file AppPkg-report-file.txt > > When running qemu on the OVMF image (built previously) using the files > just generated, > I do not see any debug prints. My qemu sequence is as follows: > > #!/bin/sh > > set -x > > qemu-system-x86_64 -L . --bios ./OVMF.fd \ > -hda fat:rw:hda-contents \ > -global e1000.romfile="" \ > -netdev tap,id=hostnet0,ifname=tap0,script=no,downscript=no \ > -device e1000,netdev=hostnet0,mac=52:54:00:56:34:12 > >> >> Thanks >> Laszlo > > The next thing is to try another network driver - the e1000 driver is > only available as a binary from Intel > and not in source form. > > Thanks in advance for your help! In "AppPkg-report-file.txt", the "RawIp4Tx" module's section lists the following library instances (reformatted for readability): DebugPrintErrorLevelLib --> MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf PcdLib --> MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf DebugLib--> MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf EfiSocketLib--> StdLib/EfiSocketLib/EfiSocketLib.inf The report file also confirms that the build target was DEBUG. This means that DEBUG macro invocations in StdLib/EfiSocketLib code will be resolved to MdePkg/Library/UefiDebugLibConOut, in the final "RawIp4Tx.efi" binary. The PcdLib class resolution means that dynamic PCDs won't work; all the relevant PCDs have to be patched-in-module, or fixed-at-build. This is actually good (see details below). The chosen DebugLib instance depends on PcdDebugPropertyMask and PcdFixedDebugPrintErrorLevel. The former PCD is relevant here for DebugPrintEnabled() and DebugCodeEnabled(), the latter is relevant for DebugPrintLevelEnabled(). In addition, the chosen DebugPrintErrorLevelLib instance consumes PcdDebugPrintErrorLevel, via GetDebugPrintErrorLevel(). Now, assume that the DEBUG() function-like macro is invoked within a DEBUG_CODE() section in StdLib/EfiSocketLib. This is what happens, after the macros are all expanded: - DebugCodeEnabled() is called first.
Re: [edk2] EDK II Network Stack Issue
On 01/16/19 13:57, Karin Willers wrote: > On 2019-01-10 13:40, Karin Willers wrote: >> On 2019-01-07 20:27, Laszlo Ersek wrote: >>> On 01/04/19 15:02, Karin Willers wrote: G'Day! I'm trying to get networking under edk2 up and running. I tried AppPkg/Applications/Sockets/RawIp4Tx under OVMF. The raw packet is sent out on the network, but the application never returns from the socket close routine. I'm currently using UDK2017 with the latest security patches (downloaded December 18 2018). The network driver under OVMF is the e1000 driver. The effect that the socket close never returns is also visible when running RawIp4Tx on real hardware, so I think the behavior has nothing to do with OVMF or the UEFI itself. Does anyone see similar effects? Any hints on setting up networking under edk2 correctly? >>> >>> The socket (= libc-level networking) APIs are not the most robust ones >>> in edk2, in my -- admittedly limited -- experience. I'd suggest using >>> applications and shell commands that use UEFI protocols instead, for >>> networking. (I understand that could be a challenge if you are porting a >>> standard C program to UEFI.) >>> >>> Thanks >>> Laszlo >> >> The reason for this undertaking initially was to compile a Python.efi >> that >> supports sockets. We wanted that to be able to run the Chipsec suite with >> external network test partners under UEFI. The Chipsec guys do provide >> pre-compiled Pyhon executables, but these do not include the network >> stack. >> >> I think, I have to debug the issue myself ... >> >> Greetings, Karin > > Could please someone shed some light on how to enable debug prints using > UefiDebugLibConOut > in EfiSocketLib/Socket.c. Enabling debug prints is, IMHO, not very > intuitive in edk2 ... Can you build your platform and/or application with the --log and --report-file options, and share the outputs? The following could all matter: - what you pass to "build" with "-b" (NOOPT/DEBUG/RELEASE), - gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask, - gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel, - gEfiMdePkgTokenSpaceGuid.PcdFixedDebugPrintErrorLevel, - what lib instance you resolve the DebugLib class to, - whether you apply the above just to your application, or all other DXE components in your platform. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EDK II Network Stack Issue
On 2019-01-10 13:40, Karin Willers wrote: On 2019-01-07 20:27, Laszlo Ersek wrote: On 01/04/19 15:02, Karin Willers wrote: G'Day! I'm trying to get networking under edk2 up and running. I tried AppPkg/Applications/Sockets/RawIp4Tx under OVMF. The raw packet is sent out on the network, but the application never returns from the socket close routine. I'm currently using UDK2017 with the latest security patches (downloaded December 18 2018). The network driver under OVMF is the e1000 driver. The effect that the socket close never returns is also visible when running RawIp4Tx on real hardware, so I think the behavior has nothing to do with OVMF or the UEFI itself. Does anyone see similar effects? Any hints on setting up networking under edk2 correctly? The socket (= libc-level networking) APIs are not the most robust ones in edk2, in my -- admittedly limited -- experience. I'd suggest using applications and shell commands that use UEFI protocols instead, for networking. (I understand that could be a challenge if you are porting a standard C program to UEFI.) Thanks Laszlo The reason for this undertaking initially was to compile a Python.efi that supports sockets. We wanted that to be able to run the Chipsec suite with external network test partners under UEFI. The Chipsec guys do provide pre-compiled Pyhon executables, but these do not include the network stack. I think, I have to debug the issue myself ... Greetings, Karin Could please someone shed some light on how to enable debug prints using UefiDebugLibConOut in EfiSocketLib/Socket.c. Enabling debug prints is, IMHO, not very intuitive in edk2 ... Thanks, Karin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EDK II Network Stack Issue
On 2019-01-07 20:27, Laszlo Ersek wrote: On 01/04/19 15:02, Karin Willers wrote: G'Day! I'm trying to get networking under edk2 up and running. I tried AppPkg/Applications/Sockets/RawIp4Tx under OVMF. The raw packet is sent out on the network, but the application never returns from the socket close routine. I'm currently using UDK2017 with the latest security patches (downloaded December 18 2018). The network driver under OVMF is the e1000 driver. The effect that the socket close never returns is also visible when running RawIp4Tx on real hardware, so I think the behavior has nothing to do with OVMF or the UEFI itself. Does anyone see similar effects? Any hints on setting up networking under edk2 correctly? The socket (= libc-level networking) APIs are not the most robust ones in edk2, in my -- admittedly limited -- experience. I'd suggest using applications and shell commands that use UEFI protocols instead, for networking. (I understand that could be a challenge if you are porting a standard C program to UEFI.) Thanks Laszlo The reason for this undertaking initially was to compile a Python.efi that supports sockets. We wanted that to be able to run the Chipsec suite with external network test partners under UEFI. The Chipsec guys do provide pre-compiled Pyhon executables, but these do not include the network stack. I think, I have to debug the issue myself ... Greetings, Karin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EDK II Network Stack Issue
On 01/04/19 15:02, Karin Willers wrote: > G'Day! > > I'm trying to get networking under edk2 up and running. I tried > AppPkg/Applications/Sockets/RawIp4Tx > under OVMF. The raw packet is sent out on the network, but the > application never returns from the > socket close routine. > > I'm currently using UDK2017 with the latest security patches (downloaded > December 18 2018). The network > driver under OVMF is the e1000 driver. > > The effect that the socket close never returns is also visible when > running RawIp4Tx on real hardware, > so I think the behavior has nothing to do with OVMF or the UEFI itself. > > Does anyone see similar effects? Any hints on setting up networking > under edk2 correctly? The socket (= libc-level networking) APIs are not the most robust ones in edk2, in my -- admittedly limited -- experience. I'd suggest using applications and shell commands that use UEFI protocols instead, for networking. (I understand that could be a challenge if you are porting a standard C program to UEFI.) Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] EDK II Network Stack Issue
G'Day! I'm trying to get networking under edk2 up and running. I tried AppPkg/Applications/Sockets/RawIp4Tx under OVMF. The raw packet is sent out on the network, but the application never returns from the socket close routine. I'm currently using UDK2017 with the latest security patches (downloaded December 18 2018). The network driver under OVMF is the e1000 driver. The effect that the socket close never returns is also visible when running RawIp4Tx on real hardware, so I think the behavior has nothing to do with OVMF or the UEFI itself. Does anyone see similar effects? Any hints on setting up networking under edk2 correctly? Thanks, Karin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
