search for: biosism

On 05-08-15 12:05, Gene Cumm wrote: > > I recompiled with this in mk/devel.mk <http://devel.mk>: > > GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 > > 0x2f8 is a BIOSism. Is this a problem? The example in the comments said 0x3f8 which is COM1.

On 05-08-15 15:28, Gene Cumm wrote: >>> 0x2f8 is a BIOSism. > >> Is this a problem? The example in the comments said 0x3f8 which is COM1. > > It means that a BIOS IO port for a UART won't work for EFI. No value > for DEBUG_PORT will do anything unless someone's got some translation > "glue" to take the attempts to op...

...gt; 5 files changed, 1192 deletions(-) > delete mode 100644 core/syslinux.ld > delete mode 100644 core/x86_64/syslinux.ld > delete mode 100644 efi/syslinux.ld > delete mode 100644 mbr/mbr.ld > delete mode 100644 memdisk/memdisk.ld Removing mbr/mbr.ld makes 0 sense. MBRs are a BIOSism that won't be present on UEFI IA32 (aka i386) and X64 (aka x86-64 IA32-64 EM64T AMD64). I feel it makes more sense to remove the architecture-specific scripts. A MEMDISK-like system for UEFI would probably need to be implemented as a UEFI driver. As a result, it's questionable if it'...

Hi, I have browsed through your syslinux archives and see that the issue of an UEFI compliant version of the pxechn-module has come up several times: http://www.syslinux.org/archives/2014-August/022611.html http://www.syslinux.org/archives/2015-March/023320.html http://www.syslinux.org/archives/2015-September/024231.html Now the issue as I understand it is that the original pxechn-module

...chn-module in specific. We have a setup at my workplace that are dependant upon this working and right now the only solution is to use legacy BIOS PXE-boot. > > > Is there any fix for this in the recently mentioned 6.04 pre-release (soon to become release?)? No, I removed all modules with BIOSisms from UEFI builds like pxechn.c32. More importantly, Syslinux can't load arbitrary UEFI images yet. -- -Gene

...c. We have a setup at my workplace that are dependant upon this working and right now the only solution is to use legacy BIOS PXE-boot. >> >> >> Is there any fix for this in the recently mentioned 6.04 pre-release (soon to become release?)? > > No, I removed all modules with BIOSisms from UEFI builds like pxechn.c32. > > More importantly, Syslinux can't load arbitrary UEFI images yet. > > -- > -Gene

...PM, "Oscar Roozen via Syslinux" <syslinux at zytor.com> wrote: > Still miss the printf output, though, so error messages from the shared code don't reach the user. > > I recompiled with this in mk/devel.mk: > GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 0x2f8 is a BIOSism. --Gene

...2015 at 8:06 AM, Oscar Roozen <oscar.roozen at brightcomputing.com> wrote: > On 05-08-15 12:05, Gene Cumm wrote: >> >> > I recompiled with this in mk/devel.mk <http://devel.mk>: >> > GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 >> >> 0x2f8 is a BIOSism. > Is this a problem? The example in the comments said 0x3f8 which is COM1. It means that a BIOS IO port for a UART won't work for EFI. No value for DEBUG_PORT will do anything unless someone's got some translation "glue" to take the attempts to open the UART and use an EFI...

...chn-module in specific. We have a setup at my workplace that are dependant upon this working and right now the only solution is to use legacy BIOS PXE-boot. > > > Is there any fix for this in the recently mentioned 6.04 pre-release (soon to become release?)? No, I removed all modules with BIOSisms from UEFI builds like pxechn.c32. More importantly, Syslinux can't load arbitrary UEFI images yet. -- -Gene

...letions(-) >> delete mode 100644 core/syslinux.ld >> delete mode 100644 core/x86_64/syslinux.ld >> delete mode 100644 efi/syslinux.ld >> delete mode 100644 mbr/mbr.ld >> delete mode 100644 memdisk/memdisk.ld > > Removing mbr/mbr.ld makes 0 sense. MBRs are a BIOSism that won't be > present on UEFI IA32 (aka i386) and X64 (aka x86-64 IA32-64 EM64T > AMD64). I feel it makes more sense to remove the > architecture-specific scripts. As the commit line say, it removes unused linker scripts. This commit intended to be really dumb: unused = delete. And...

On 04-08-15 17:38, Oscar Roozen wrote: > Okay, the code in efi/ uses Print() from gnu_efi, but generic code from > core/ like core/elflink/load_env32.c prints their messages and debugging > stuff using printf(). These messages end up nowhere. This may explain > why I never saw anything beyond a certain point, even with debugging > turned on. I was busy adding some code to dprintf.h

>>> > On 05-08-15 12:05, Gene Cumm wrote: >> >>? > I recompiled with this in mk/devel.mk <http://devel.mk>: >>? >? GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 >> >> 0x2f8 is a BIOSism. > Is this a problem? The example in the comments said 0x3f8 which is COM1. It means that a BIOS IO port for a UART won't work for EFI.? No value for DEBUG_PORT will do anything unless someone's got some translation "glue" to take the attempts to open the UART and use...

...c. We have a setup at my workplace that are dependant upon this working and right now the only solution is to use legacy BIOS PXE-boot. >> >> >> Is there any fix for this in the recently mentioned 6.04 pre-release (soon to become release?)? > > No, I removed all modules with BIOSisms from UEFI builds like pxechn.c32. > > More importantly, Syslinux can't load arbitrary UEFI images yet. > > -- > -Gene

...> boot: hdtl > Undef symbol FAIL: exp > Failed to load libgpl.c32 > Failed to load COM32 file hdt.c32 > boot: I'm not sure this is a problem with Debian's package; it is more probable that the problem is in upstream's HDT code. I do know that HDT has several "BIOSisms". If it is even possible to run hdt.c32 in UEFI mode at all, then perhaps some developer might be capable of solving this particular hang. Everyone is free to wish and hope. > I was surprised that SYSLX64.CFG was found when it was in / and no cfg > in EFI/BOOT The _cfg_ file sho...

...t my workplace that are dependant upon this working and right now the only solution is to use legacy BIOS PXE-boot. >>> >>> >>> Is there any fix for this in the recently mentioned 6.04 pre-release (soon to become release?)? >> >> No, I removed all modules with BIOSisms from UEFI builds like pxechn.c32. >> >> More importantly, Syslinux can't load arbitrary UEFI images yet. >> >> -- >> -Gene

...l FAIL: exp > > Failed to load libgpl.c32 > > Failed to load COM32 file hdt.c32 > > boot: > > > I'm not sure this is a problem with Debian's package; it is more > probable that the problem is in upstream's HDT code. I do know that HDT > has several "BIOSisms". If it is even possible to run hdt.c32 in UEFI > mode at all, then perhaps some developer might be capable of solving > this particular hang. Everyone is free to wish and hope. This may be something I don't care about. > > > > I was surprised that SYSLX64.CFG was foun...

On Fri, Dec 7, 2018 at 11:16 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote: > > > > If this is the best we can do, I'm ok with that. > > It's _not_ the best we can do. The question is... what exactly is this > "we"? We have both made some contributions to my little goal. you certainly share in the credit. > > After some testing (which I

From: Sylvain Gault <sylvain.gault at gmail.com> These patches basically remove unused linker scripts and port a change that was made to an unused script. Those are to be applied on top of the gcc 5 bug fixes as they would conflict otherwise. Sylvain Gault (4): diag/mbr: fix dependency to linker script Remove unused linker scripts core: Make symbols defined in linker script HIDDEN