>>>> It does contain a Net but there are 2 issues with SNP: > 1) The interface is different than UDPv4/TCPv4 protocols; this imply lot of code. Not as much as you may think.? We already have lwIP implemented into lpxelinux.0.? It's more a matter of using more glue. > 2) SNP has its non-blocking transmit issues ; see "Flaws in the design" at > https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/UEFI_Network_Driver#Flaws_in_the_design certainly gives some things to think about. As a side note, I'd expect anything that used SNP should be able to shut everything else off and have to implement enough of a TCP/IP stack to be proper for its uses (ie no need to implement TCP or respond to TCP if it doesn't use TCP yet should respond to ARP requests).>>>OK, at the moment the updated code should be able to deal with cases #2 and #3 Let's put a pin on SNP for case #1 and see what the multi-NIC users report from the current patch. What do you think?>>>> > So far I've seen MNPSb is only available when the rest of SBs are also present then > it makes no sense embracing a new MNP protocol when UDPv4Sb and TCPv4Sb are also > available. Correct, MNPSb is the parent.? We'd only use it if we wanted to create a new protocol like a TCP replacement which I expect is out of scope. My point is that unless the rule was set early, I'd expect to eventually find an oddball client where UDPSb and TCPSb live on different EFI_HANDLEs (but presumably still under an MNPSb). <<< The current code either looks for UDPSb handles (or TCPSb depending on the received bgiud), then it really does not matter if UDPSb and TCPSb are created under different handles. As soon as I get the array of UDPSb (or TCPSb ) handles I parse their associated Path Protocol looking for the matching MAC.>>>> I also wonder if UEFI firmware w/o SB protocols is really UEFI compliant... > i.e the Elitebook 8460p is an early 2011 model that probably should receive a firmware update > including the missing SB protocols... What firmware version is loaded?? Available? <<< The last one; F.60 Rev.A(31 Mar 2015)>>> For absolute hilarity, Google "8460p firmware EFI". Your forum post was on top for me. <<<Yes; I know... HP silence says it all; they know they're guilty ;-) http://h30434.www3.hp.com/t5/Notebook-Operating-Systems-and-Software/EFI-firmware-bug-on-HP-EliteBook-2560p-8460p/td-p/4931486>>> > I thought of it but I do not know if there's really much to get here;> i.e. in a 4 NIC PC the parsing only involves 4 UDPv4Sb (or TCPv4Sb) handles. > Anyway it can definitely be done if necessary. It's also a question of how fast the firmware bothers to be. Considering our rate, this in theory shouldn't matter. <<< agreed>>>Oh how fun. UEFI Specifications version 2.0 states "An EFI_PXE_BASE_CODE_PROTOCOL will be layered on top of an EFI_SIMPLE_NETWORK_PROTOCOL protocol in order to perform packet level transactions." while version 2.1 states "An EFI_PXE_BASE_CODE_PROTOCOL will be layered on top of an EFI_MANAGED_NETWORK_PROTOCOL protocol in order to perform packet level transactions.">>>Could this be the reason why in the past Pxebc and the SBs where attached to different handles?? mmhhh I have to admit; UEFI development is a bit messy... Best, Patrick
On Fri, Jul 10, 2015 at 5:00 AM, Patrick Masotta <masottaus at yahoo.com> wrote:>>>> > Oh how fun. UEFI Specifications version 2.0 states "An > EFI_PXE_BASE_CODE_PROTOCOL will be layered on top of an > EFI_SIMPLE_NETWORK_PROTOCOL protocol in order to perform packet level > transactions." while version 2.1 states "An EFI_PXE_BASE_CODE_PROTOCOL > will be layered on top of an EFI_MANAGED_NETWORK_PROTOCOL protocol in > order to perform packet level transactions." >>>> > > Could this be the reason why in the past Pxebc and the SBs where attached to different handles?? mmhhh > I have to admit; UEFI development is a bit messy...I'd suspect possibly. I also have yet to see evidence your HP EliteBook 2560p is not UEFI-2.0 compliant. It's safe to assume the 2560p and 2570p are not 2.1 compliant as the Pxebc appears backed by a Net not an MNPSb. -- -Gene
Hey everyone, sorry for the delay in replying. First off, thanks for all the help, effort and support so far! == build =I built and used syslinux from https://github.com/ppatpat/syslinux (latest commit 43f5efa2db4a7880c7a2c6485d8fd8a64f0f33c3). On top of that I had to patch main.c. This had to be done to mitigate the following error when trying to 'make all': main.c:(.text+0x3b9): undefined reference to `BSWAP_64' More specifically I made this change: diff ../syslinux_ppatpat_orig/efi/main.c efi/main.c 13a14> #include <byteswap.h>178c179 < BSWAP_64(*(uint64_t*)&bguid->Data4), --->This build of syslinux works on my HP ProLiant DL380 Gen9 server while netbooting from nic1 (not nic0) :-) == output booting pxe =Don't know if it is useful, but I saw this output when booting from pxe over IPv4: ... NBP file downloaded successfully. Booting from: Acpi(PNP0A3,0)/Pci(1C|4)/Pci(0|1)/Mac(XXXXXXXXXXXX)/IPv4(not-done) Getting cached packet ... == output page-fault =Sometimes (rarely) I get a Page-Fault Exception (red text). I haven't been able to track this issue down. Might be unrelated, but wanted to post it for completeness. X64 Exception Type 0E - Page-Fault Exception ... CALL ImageBase ImageName+Offset 00h 0000000077283000 No Image Information Best regards, Sebastian On Sun, Jul 12, 2015 at 3:35 AM, Gene Cumm via Syslinux <syslinux at zytor.com> wrote:> On Fri, Jul 10, 2015 at 5:00 AM, Patrick Masotta <masottaus at yahoo.com> > wrote: > > >>>> > > Oh how fun. UEFI Specifications version 2.0 states "An > > EFI_PXE_BASE_CODE_PROTOCOL will be layered on top of an > > EFI_SIMPLE_NETWORK_PROTOCOL protocol in order to perform packet level > > transactions." while version 2.1 states "An EFI_PXE_BASE_CODE_PROTOCOL > > will be layered on top of an EFI_MANAGED_NETWORK_PROTOCOL protocol in > > order to perform packet level transactions." > >>>> > > > > Could this be the reason why in the past Pxebc and the SBs where > attached to different handles?? mmhhh > > I have to admit; UEFI development is a bit messy... > > I'd suspect possibly. I also have yet to see evidence your HP > EliteBook 2560p is not UEFI-2.0 compliant. It's safe to assume the > 2560p and 2570p are not 2.1 compliant as the Pxebc appears backed by a > Net not an MNPSb. > > -- > -Gene > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
>>>I'd suspect possibly.? I also have yet to see evidence your HP EliteBook 2560p is not UEFI-2.0 compliant.? It's safe to assume the 2560p and 2570p are not 2.1 compliant as the Pxebc appears backed by a Net not an MNPSb. -- -Gene <<< It's really weird The 2560p Device Handle includes Net but it does not include MNPSb The 2570p Device Handle includes both ! let's see what kind of feedback we get. Best, Patrick