search for: devicehandl

>>> I'm just debating what's the best algorithm here.? It would seem if the LoadeImage's DeviceHandle provides UDPv4Sb, use it as it's guaranteed to be the same interface.? Otherwise, we need a MNPSb (EFI_MANAGED_NETWORK_SERVICE_BINDING) that provides UDPv4Sb across the same interface.? Presumably it should also provide TCPv4Sb (rather than being on a separate handle). -- -Gene <&l...

...to MAC-based searching, saving all 3 handles, the image handle, Pxebc handle, and ServiceBinding handle.? Presumably the UDP and TCP handles _should_ be the same... -- -Gene <<< OK now it works. Everything is done within efi_create_binding(EFI_GUID *bguid, EFI_GUID *pguid) from image_DeviceHandle I get the right DevPath handle, I parse it and I get the MAC address. Next I LibLocateHandle(ByProtocol, bguid, NULL, &nr_handles, &handles) what gives me all the handles that include the Service Binding Protocol "bguid". For each of this handles I get the DevPath handle and I pa...

...nd out that my EFI shell on VMware VMs can also handle output redirection like: guid > fs0:\efi-guid.txt dh > fs0:\efi-dh.txt dh bd >> fs0:\efi-dh.txt fs0 being the EFI boot partition on the hard drive of the VM. > 2) SB protocols are loaded under a different that LoadeImage's DeviceHandle, > while Pxebc is loaded under the LoadeImage's DeviceHandle. (Elitebook 8470p/2570p) a) Hunt for a Sb. b) use Net > 3) SB protocols and Pxebc are loaded under the LoadeImage's DeviceHandle (VMware Workstation 10). a) use Sb on Pxebc handle b) use Net > About MNPSb; even when...

...dh.txt fs0 being the EFI boot partition on the hard drive of the VM. <<< Yes, but I use empty virtual clients when testing Syslinux PXE then I prefer redirecting console commands to a USB pendrive >>> > 2) SB protocols are loaded under a different that LoadeImage's DeviceHandle, > while Pxebc is loaded under the LoadeImage's DeviceHandle. (Elitebook 8470p/2570p) a) Hunt for a Sb. b) use Net <<< I do a hunt for either UDPv4Sb or TCPv4Sb >>> > 3) SB protocols and Pxebc are loaded under the LoadeImage's DeviceHandle (VMware Workstat...

...erything 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). > >>> > > 2) SB protocols are loaded under a different that LoadeImage's DeviceHandle, > > while Pxebc is loaded under the LoadeImage's DeviceHandle. (Elitebook 8470p/2570p) > > a) Hunt for a Sb. > b) use Net > <<< > > I do a hunt for either UDPv4Sb or TCPv4Sb Just summarizing choices. >>>> > > 3) SB protocols and Pxebc a...

...hub.com/ppatpat/syslinux/ > > a) a missing return; on an error condition at efi/pxe.c\net_parse_dhcp() > b) you close a protocol before creating its child at efi/main.c\efi_create_binding() Rewrote the commit messages and it's in at commit ID 5186539 > 2.2) I think "image_DeviceHandle" instead of "pxe_DeviceHandle" produces a code easier to follow; > specially when we end up using that handle to create a TCP4 or UDP4 child... Not all handles are devices but all usable devices have handles. The image_handle is a type EFI_LOADED_IMAGE_PROTOCOL, not a device. p...

...0.0.0.0:0) (Remote IP: 0.0.0.0:0) (Protocol: 0) (Source IP: DHCP) AsStr: 'PciRoot(0x0)/Pci(0x19,0x0)/MAC(FC15B4E81CAC,0x0)/IPv4(0.0.0.0,UDP,DHCP,0.0.0.0)' Load (72284728) Net (730C5020) Pxebc (722B0110) The booting syslinux.efi receives DeviceHandle = 19D (IPv4); this handle has also attached to it the Pxebc Protocol but it does not have attached the Service Binding Protocol UDPv4Sb (in this case under the handle 172 instead). The HP 2570p is not really an old PC (~2013) then I can think if we continue using the "same handle" meth...

...fo); > +if(status != EFI_SUCCESS) > + { > + uefi_call_wrapper(BS->UnloadImage,1, Child_image_handle ); > + action=szHandleProtocol; > + goto bail; > + } > + > + > + > +Child_image_info->ParentHandle = image_info; > +Child_image_info->DeviceHandle = image_info->DeviceHandle; > +Child_image_info->LoadOptionsSize = (UINT32)cmdlineSize; > +if(cmdline!=NULL && cmdlineSize != 0) > + Child_image_info->LoadOptions = (VOID *)cmdline; > +else > + Child_image_info->LoadOptions = (VOID *)w_emptyCmdLine; > +...

...k (IPv4 or IPv6). <<< Yes it is the handle of the device (NIC) that loaded syslinux plus IP stack (as you said) but also all the attached Service Binding Protocols, PXE Protocol, and some more. All of them sharing the same device handle. >>> > 2.2) > I think "image_DeviceHandle" instead of > "pxe_DeviceHandle" produces a code easier to follow; > specially when we end up using > that handle to create a TCP4 or UDP4 child... Not all handles are devices but all usable devices have handles.? The image_handle is a type EFI_LOADED_IMAGE_PROTOCOL, no...

...handles, the image handle, Pxebc handle, and ServiceBinding handle. > Presumably the UDP and TCP handles _should_ be the same... > -- > -Gene > <<< > > OK now it works. > Everything is done within efi_create_binding(EFI_GUID *bguid, EFI_GUID *pguid) > from image_DeviceHandle I get the right DevPath handle, I parse it and I get the MAC address. > Next I LibLocateHandle(ByProtocol, bguid, NULL, &nr_handles, &handles) > what gives me all the handles that include the Service Binding Protocol "bguid". > For each of this handles I get the DevPath...

....0.0.0:0) > (Protocol: 0) > (Source IP: DHCP) > AsStr: 'PciRoot(0x0)/Pci(0x19,0x0)/MAC(FC15B4E81CAC,0x0)/IPv4(0.0.0.0,UDP,DHCP,0.0.0.0)' > Load (72284728) > Net (730C5020) > Pxebc (722B0110) > > The booting syslinux.efi receives DeviceHandle = 19D (IPv4); this handle has also attached to it the Pxebc Protocol > but it does not have attached the Service Binding Protocol UDPv4Sb (in this case under the handle 172 instead). > > The HP 2570p is not really an old PC (~2013) then I can think if we continue using the "same hand...

..._handle, + &LoadedImageProtocol,(void**)&Child_image_info); +if(status != EFI_SUCCESS) + { + uefi_call_wrapper(BS->UnloadImage,1, Child_image_handle ); + action=szHandleProtocol; + goto bail; + } + + + +Child_image_info->ParentHandle = image_info; +Child_image_info->DeviceHandle = image_info->DeviceHandle; +Child_image_info->LoadOptionsSize = (UINT32)cmdlineSize; +if(cmdline!=NULL && cmdlineSize != 0) + Child_image_info->LoadOptions = (VOID *)cmdline; +else + Child_image_info->LoadOptions = (VOID *)w_emptyCmdLine; + + + + +status = uefi_c...

On Tue, Feb 17, 2015 at 12:57:32PM +0100, Jur van der Burg via Syslinux wrote: > We have been using syslinux (V4.05) in our product for years without a problem. > Since we encounter more and more systems that do a UEFI boot by default > we want to support that too. So I've been using syslinux V6.03 to create > usb sticks and harddisks to allow both bios and uefi boot which works

...4 round_up(UINT64 x, UINT64 y) > { > @@ -1295,6 +1286,7 @@ EFI_STATUS efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *table) > } else { > efi_derivative(SYSLINUX_FS_PXELINUX); > ops[0] = &pxe_fs_ops; > + pxe_handle = info->DeviceHandle; > } > > /* setup timer for boot menu system support */ > diff --git a/efi/pxe.c b/efi/pxe.c > index 443ab47..82cdee4 100644 > --- a/efi/pxe.c > +++ b/efi/pxe.c > @@ -93,20 +93,13 @@ void net_parse_dhcp(void) > EFI_PXE_BASE_CODE *bc; > unsign...

We have been using syslinux (V4.05) in our product for years without a problem. Since we encounter more and more systems that do a UEFI boot by default we want to support that too. So I've been using syslinux V6.03 to create usb sticks and harddisks to allow both bios and uefi boot which works fine. The problem I run into now is that it is not possible to create a dvd that is capable of

So last week I was wondering if XFS was still working -- even with its last on-disk structure changes -- and it _suprisingly_ worked as expected. Right, now I can finally get rid of GRUB and use Syslinux to boot my Linux on EFI from a rootfs with xfs. Shit, I have two partitions (the first one being the required ESP) so there is no way to access the other partitions since because Syslinux does not