search for: biosisms

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 open the UART and use an EFI handle

On Mon, Oct 5, 2015 at 2:15 PM, celelibi--- via Syslinux <syslinux at zytor.com> wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > Some linker scripts were splitted into i386 and x86_64 versions in > commit d8eede3f2a360163235fad222a0190cd7c5bef38 but older scripts were > left there. > > Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com>

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

On Aug 4, 2015 2:45 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

On Wed, Aug 5, 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

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

2015-10-15 12:53 UTC+02:00, Gene Cumm <gene.cumm at gmail.com>: > On Mon, Oct 5, 2015 at 2:15 PM, celelibi--- via Syslinux > <syslinux at zytor.com> wrote: >> From: Sylvain Gault <sylvain.gault at gmail.com> >> >> Some linker scripts were splitted into i386 and x86_64 versions in >> commit d8eede3f2a360163235fad222a0190cd7c5bef38 but older scripts

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

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

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

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