search for: efi_handle

...+++------------------------ > efi/pxe.c | 16 ++++++---------- > 3 files changed, 23 insertions(+), 35 deletions(-) > > diff --git a/efi/efi.h b/efi/efi.h > index ef5bacb..1416488 100644 > --- a/efi/efi.h > +++ b/efi/efi.h > @@ -42,7 +42,7 @@ struct efi_binding { > EFI_HANDLE this; > }; > > -extern EFI_HANDLE image_handle; > +extern EFI_HANDLE image_handle, pxe_handle; > > struct screen_info; > extern void setup_screen(struct screen_info *); > diff --git a/efi/main.c b/efi/main.c > index 208fee4..6e43f79 100644 > --- a/efi/main.c > ++...

...64. Is there a way we can enable > some debug somehow to see why the request for ldlinux.e64 includes > the tsize option? Or even disable the tsize option (as it appears it > may be causing the UEFI to hang)? > --- a/efi/main.c +++ b/efi/main.c @@ -1371,7 +1371,9 @@ EFI_STATUS efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *table) */ efi_setcwd(DevicePathToStr(info->FilePath)); + Print(L"fs_init start\n"); fs_init(ops, (void *)&priv); + Print(L"fs_init done.\n"); /* * There may be pending user input that wasn&...

...ient always booted correctly from the NIC that received the full set of PXE parameters. It seems to work. It would be really interesting if the HP guys having this issue can give it a try... Please see the new code at https://github.com/ppatpat/syslinux/blob/master/efi/main.c Patched: efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *table) {} efi_create_binding(EFI_GUID *bguid, EFI_GUID *pguid) {} Best, Patrick

...dle b) use Net > About MNPSb; even when it presents the same interface than all the Service Binding protocols > remember we have to create a child of the particular matching protocol and those do not have > the same interface. Correct, different interface but it seems dominantly the same EFI_HANDLE. > I kept testing my patch and so far it proved to work in a multi-NIC environment: > I've set a VMware EFI client with 2 NICs connected to the same network, > using the VMware DHCP server and Serva as proxyDHCP. > Setting a MAC filter in Serva I forced the client not receiving PX...

...t; > some debug somehow to see why the request for ldlinux.e64 includes > > the tsize option? Or even disable the tsize option (as it appears it > > may be causing the UEFI to hang)? > > > --- a/efi/main.c > +++ b/efi/main.c > @@ -1371,7 +1371,9 @@ EFI_STATUS efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *table) > */ > efi_setcwd(DevicePathToStr(info->FilePath)); > > + Print(L"fs_init start\n"); > fs_init(ops, (void *)&priv); > + Print(L"fs_init done.\n"); > > /* >...

On 05/10/2013 06:27 AM, syslinux-bot for Matt Fleming wrote: > > diff --git a/efi/main.c b/efi/main.c > index 31f0bff..27e7f8f 100644 > --- a/efi/main.c > +++ b/efi/main.c > @@ -1177,13 +1177,10 @@ static void efi_setcwd(CHAR16 *dp) > > EFI_STATUS efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *table) > { > + EFI_PXE_BASE_CODE *pxe; > EFI_LOADED_IMAGE *info; > EFI_STATUS status = EFI_SUCCESS; > -#if 0 > - const struct fs_ops *ops[] = { &vfat_fs_ops, NULL }; > -#else > - const struct fs_ops *ops[] = { &pxe_fs_ops, NULL }; > -...

...t;>> > About MNPSb; even when it presents the same interface than all the Service Binding protocols > remember we have to create a child of the particular matching protocol and those do not have > the same interface. Correct, different interface but it seems dominantly the same EFI_HANDLE. <<< 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. >>> > I kept testing my patch and so far it proved to work in a multi-NIC environment:...

...; enable some debug somehow to see why the request for ldlinux.e64 > > includes the tsize option? Or even disable the tsize option (as it > > appears it may be causing the UEFI to hang)? > > > --- a/efi/main.c > +++ b/efi/main.c > @@ -1371,7 +1371,9 @@ EFI_STATUS efi_main(EFI_HANDLE image, > EFI_SYSTEM_TABLE *table) > */ > efi_setcwd(DevicePathToStr(info->FilePath)); > > + Print(L"fs_init start\n"); > fs_init(ops, (void *)&priv); > + Print(L"fs_init done.\n"); > > /* >...

...image_handle, sb_handle, EFI_OPEN_PROTOCOL_GET_PROTOCOL); if (status == EFI_SUCCESS) { mnpsb_handle = sb_handle; break; } } } } if (status != EFI_SUCCESS) goto free_binding; child = NULL; status = uefi_call_wrapper(sbp->CreateChild, 2, sbp, (EFI_HANDLE *)&child); <<<< Potential crash here ! ... I think these changes would solve the thing. ... -EFI_SERVICE_BINDING *sbp; +EFI_SERVICE_BINDING *sbp =NULL; ... - if (status != EFI_SUCCESS) + if (status != EFI_SUCCESS || sbp != NULL) goto free_binding; ... Please tak...

...bout MNPSb; even when it presents the same interface than all the Service Binding protocols > > remember we have to create a child of the particular matching protocol and those do not have > > the same interface. > > Correct, different interface but it seems dominantly the same EFI_HANDLE. > <<< > > 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 n...

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

...st 6.03; the issue is still present in 6.04 as per e466d2498604c8eea055a8e98284d65311073b39 Best Regards, Olli --- syslinux-6.03/efi/main.c.orig 2015-08-15 12:31:33.987766223 +0200 +++ syslinux-6.03/efi/main.c 2015-08-15 12:31:44.427993051 +0200 @@ -1324,7 +1324,7 @@ EFI_STATUS efi_main(EFI_HANDLE image, EF in = ST->ConIn; do { status = uefi_call_wrapper(in->ReadKeyStroke, 2, in, &key); - } while (status != EFI_NOT_READY); + } while (status == EFI_SUCCESS); if (!setjmp(load_error_buf)) load_env32(NULL);

...// 0=> no timeout + status = uefi_call_wrapper(in->ReadKeyStroke, 2, in, &key); // get the char + + if (!key.ScanCode) + return (char)key.UnicodeChar; + + /* + * We currently only handle scan codes that fit in 8 bits. + */ + if(hi) + *hi = (char)key.ScanCode; + + return 0; + +} + +EFI_HANDLE image = NULL; +EFI_SYSTEM_TABLE* systab = NULL; + +int doTheJob(void) +{ + + + image = (EFI_HANDLE) firmware->image; + systab = (EFI_SYSTEM_TABLE*) firmware->table; + + InitializeLib(image, systab); + + //Clear screen + uefi_call_wrapper(ST->ConOut->ClearScreen, 1, ST->ConOu...

> On Wed, Oct 07, 2015 at 05:06:41PM -0500, Clements, James via Syslinux > wrote: > > > On Wed, Oct 07, 2015 at 06:01:30PM +0200, Geert Stappers via Syslinux > wrote: > > > is for BIOS, not for EFI. So that suggestion can be scraped. > > > > > > Which makes > > > * text which is on the screen of the netbooting (virtual) machine > > >

..._efi(void *kernel_buf, size_t kernel_size, + char *cmdline, int cmdlineSize) +{ + +char* szLoadImage = "LoadImage()"; +char* szHandleProtocol = "HandleProtocol()"; +char* szStartImage = "StartImage()"; + +char* action = NULL; + +EFI_LOADED_IMAGE * image_info = NULL; +EFI_HANDLE Child_image_handle; +EFI_LOADED_IMAGE * Child_image_info = NULL; +EFI_STATUS status; + +CHAR16 w_emptyCmdLine [4]={0,0,0,0}; + + + +status = uefi_call_wrapper(BS->HandleProtocol, 3, image_handle, + &LoadedImageProtocol,(void**)&image_info); +if(status != EFI_SUCCESS) + { + acti...

...mnpsb_handle = sb_handle; > break; > } > } > > } > > } > if (status != EFI_SUCCESS) > goto free_binding; > > child = NULL; > > status = uefi_call_wrapper(sbp->CreateChild, 2, sbp, (EFI_HANDLE *)&child); <<<< Potential crash here ! > > ... > > > I think these changes would solve the thing. > > ... > -EFI_SERVICE_BINDING *sbp; > +EFI_SERVICE_BINDING *sbp =NULL; > ... > > - if (status != EFI_SUCCESS) > + if (status != EFI_SUCCES...

Signed-off-by: Beno?t Allard <benoit.allard at greenbone.net> --- efi/fio.h | 9 --------- 1 file changed, 9 deletions(-) diff --git a/efi/fio.h b/efi/fio.h index 65fff8d..a1bfe68 100644 --- a/efi/fio.h +++ b/efi/fio.h @@ -11,15 +11,6 @@ #define MAX_EFI_ARGS 64 #define WS(c16) (c16 == L' ' || c16 == CHAR_TAB) -/* VPrint is not in export declarations in gnu-efi lib yet

...now applied this fix to the 'master' branch. Thanks for the report! protocol.h | 13 ------------- 1 files changed, 0 insertions(+), 13 deletions(-) diff --git a/protocol.h b/protocol.h index 88b4a7b..6881d70 100644 --- a/protocol.h +++ b/protocol.h @@ -51,19 +51,6 @@ handle_protocol(EFI_HANDLE handle, EFI_GUID *protocol, void **interface) } /** - * locate_protocol - Returns the first protocol instance for @protocol - * @protocol: the protocol to search for - * @registration: optional registration key - * @interface: used to return a pointer to the first matching interface - */ -stati...

...+ +/** + * @file disk.c + * + * Deal with disks and partitions + */ + +#include <core.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> + +#include <efi.h> +#include <efilib.h> + +#include <syslinux/disk.h> + +#define DISKS_MAX 0x80 + +static EFI_HANDLE disk_dev_handles[DISKS_MAX] = { NULL, }; + +/* Find all device handles that support EFI_BLOCK_IO_PROTOCOL */ +static EFI_STATUS find_all_block_devs(EFI_HANDLE **bdevs, + unsigned long *bdevsno) +{ + EFI_STATUS status; + unsigned long len = 0; + + *bdevs...

>>> Lovely, the ServiceBindings are on a handle that resembles the NIC while the Pxebc is IP-type specific.? Looks like we should try to do a ServiceBinding based on Pxebc but fall back 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