search for: efi_main

...ldlinux.e64. 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...

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, NUL...

...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"); > > /* &g...

>>> The key is that the handle _itself_ is the proper link between the EFI_PXE_BASE_CODE_PROTOCOL and EFI_UDP4_SERVICE_BINDING_PROTOCOL. _IT_ is the piece that must be stored and reused. I found this thanks to a Google search "EFI_PXE_BASE_CODE_PROTOCOL EFI_MANAGED_NETWORK_PROTOCOL" and http://sourceforge.net/p/edk2/mailman/message/31604654/ where Laszlo Ersek showed the

...> > 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"); > > /* &...

...is against 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(N...

> 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 > > >

...2; the client 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

This patch adds to Com32 modules the capabilities of accessing the EFI environment The idea is simple, the EFI parameters "image" and "table" received by syslinux.efi's efi_main() are stored in the "firmware" structure, next they are retrieved from the Com32 module which is linked against the gnu-efi static library. The Com32 module can use the EFI environment after calling InitializeLib(image, systab); With this patch coding i.e. pxechn.c32 able to run on EFI...

...you mean; > "I think" the handle of the running image (our code) has a "path" telling us where > was laded from. That would solve this thing. I just found we already found the handle before in a more reliable manner and we already found it in the beginning of execution in efi_main(). -- -Gene

...ork. This sounds positive for cases 2&3 but still leaves #1 high and dry. > 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) {} Debating if this hunting should be more persistent so we don't go hunting at every binding. It shouldn't affect large files but could affect lots of tiny files if we're hunting e...

...think" the handle of the running image (our code) has a "path" telling us where >> was laded from. That would solve this thing. > > I just found we already found the handle before in a more reliable > manner and we already found it in the beginning of execution in > efi_main(). > > -- > -Gene Commit 23b2707 should resolve this. Please let me know if you need test binaries -- -Gene

...desc? may result in an unaligned pointer value [-Waddress-of-packed-member] 907 | status = emalloc(gdt.limit, __SIZEOF_POINTER__ , (EFI_PHYSICAL_ADDRESS *)&gdt.base); | ^~~~~~~~~ syslinux/efi/main.c: In function ?efi_main?: syslinux/efi/main.c:1390:7: warning: implicit declaration of function ?setjmp? [-Wimplicit-function-declaration] 1390 | if (!setjmp(&load_error_buf)) | ^~~~~~ make[3]: *** [syslinux/mk/efi.mk:63: main.o] Error 1 This is due to gnu-efi commit 486ba3c3bdd147b7d98159b9e650be60bce0...

>>> 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

Hi Rui, A quick question: Does lld-link only work with clang-cl with windows-msvc option? Can lld-link work with clang with linux-gnu option? Thanks Steven Shi Intel\SSG\FID\Firmware Infrastructure From: Shi, Steven Sent: Tuesday, January 29, 2019 1:32 PM To: 'Rui Ueyama' <ruiu at google.com> Cc: llvm-dev at lists.llvm.org Subject: RE: lld write wrong symbol value in .data

...long memmap, UINTN desc_sz, int i) > return (EFI_MEMORY_DESCRIPTOR *)(memmap + (i * desc_sz)); > } > > -EFI_HANDLE image_handle; > +EFI_HANDLE image_handle, pxe_handle; > > static inline UINT64 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 su...

This patch adds to the core EFI image booting capabilities. It was tested on VMware EFI clients and HP Elitebook EFI notebooks, only on PXE environments but it should work on non-PXE scenarios as well. Feedback appreciated. Best, Patrick Signed-off-by: Patrick Masotta <masottaus at yahoo.com> --- diff -uprN a/com32/elflink/ldlinux/execute.c b/com32/elflink/ldlinux/execute.c ---

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