search for: ddebug_port

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 6/6/19 8:16 AM, Ady Ady via Syslinux wrote: > >> the PXELINUX log line is >> printed (PXELINUX 6.04 lwIP 6.04-pre3 Copyright (C) 1994-2015 H. Peter >> Anvin et al), > > (snip) > > FWIW, the official binaries from 6.04-pre2 and 6.04-pre3 are not good > for troubleshooting. > > Is the same behavior present when testing with other versions? I would

...something to COM1 as I have to order some hardware for that, but this also works very well. A pity I didn't think of using it earlier. 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 And used ipmi_console to capture the output. Another way is to use the vsp command in the ILO4 shell. For future reference. > Any suggestions while I keep on debugging? Got some result! I was using 'vesamenu.c32' to display a menu. Changing this to 'menu.c...

...nd a special build must be made by > changing mk/devel.mk (although it's been a while). Lines 3 and 4 must > be uncommented and line 5 must be commented out. Booting such a build > may take a long time while data is pumped over the serial. > GCCWARN += -DDEBUG_MALLOC GCCWARN += -DDEBUG_PORT=0x3f8 -DCORE_DEBUG=1 These directives have made it unnecessary: - switch to 'isolinux-debug.bin' usage - engage "serial 0" within the 'isolinux.cfg' To put it another way, the effect is the same. > Although perhaps not helpful in this case, I'd normally suggest...

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

.... > They access the PXE stack in very different ways, so it is a good idea to > check both. I can confirm that using pxelinux.0 instead of lpxelinux.0 does indeed work in my setup! I will switch to pxelinux.0 for the time being. I tried enabling debug output by using: echo 'GCCWARN += -DDEBUG_PORT=0x3f8 -DCORE_DEBUG=1' >> mk/devel.mk ?but unfortunately I don?t see any additional messages on the serial console except for the initial message: PXELINUX 6.04 lwIP Copyright (C) 1994-2015 H. Peter Anvin et al Do you happen to know off-head what might be wrong here? As a quick reminde...

I noticed several issues when diagnosing why pxechn.c32 didn't work in 5.01-pre3. 1) pxechn.c32, prdhcp.c32 and other modules crash Syslinux and force a reboot by executing an unresolved symbols. unload_pxe(), dns_resolv() and pxe_call() are the three. "Error: An undefined symbol was referenced" 2) In past versions, I built a debug build by having "CFLAGS += -DDEBUG=1"

On Fri, Jul 12, 2013 at 2:21 AM, H. Peter Anvin <hpa at zytor.com> wrote: > On 07/11/2013 10:16 PM, Raphael S.Carvalho wrote: >> This patch adds support for serial output functions. >> It may be useful for debugging purposes since you can separate ordinary outputs from debugging dumps. >> Just add "serial.h", and use either serial_print or serial_puts as you

On 04-08-15 14:42, Patrick Masotta wrote: > I think we solved a bug but we found a new one. > AFAIK you were not able to retrieve anything after loading syslinux.efi > Now you retrieve ldlinux.e32, libcom32.c32, etc but it crashes when loading a png. > If this is the case then the multi-nic issue is solved; the new code is able to > find the NIC that booted syslinux.efi and then

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

...y different ways, so it is a good idea to >> check both. > > I can confirm that using pxelinux.0 instead of lpxelinux.0 does indeed > work in my setup! I will switch to pxelinux.0 for the time being. > > I tried enabling debug output by using: > > echo 'GCCWARN += -DDEBUG_PORT=0x3f8 -DCORE_DEBUG=1' >> mk/devel.mk > > ?but unfortunately I don?t see any additional messages on the serial > console except for the initial message: > > PXELINUX 6.04 lwIP Copyright (C) 1994-2015 H. Peter Anvin et al > > Do you happen to know off-head what migh...

On Tue, Jun 30, 2015 at 4:29 PM, poma <pomidorabelisima at gmail.com> wrote: > "A real serial port that can reliably operate at 115200 8n1 may be > necessary." > > Gene, is there something special in "A real serial port" usage, compared to emulated? I should restate: A serial port that responds on BIOS IO port 3F8h that can reliably operate at 115200 8n1 may

...t: > GCCWARN += -Wno-clobbered -DCORE_DEBUG=1 -DDEBUG_MALLOC -DDEBUG_THREAD > And removing the -DDYNAMIC_DEBUG but now syslinux doesn't want to build: MALLOC and THREAD are two debugs you probably don't want. If you can capture the serial port and the firmware would allow it, "-DDEBUG_PORT=0x3f8" would direct output to the first serial port. "-DDEBUG_STDIO" may be useful but by the looks of it, not until after ldlinux.* is loaded as printf()'s code isn't in the core but ldlinux.*. > ranlib liblpxelinux.a > ld -m elf_i386 -Bsymbolic -pie -E --hash-style...

This patch adds support for printing messages through a debug console. QEMU, for example, supports this through the debugcon facility. The benefit is that it's *much* faster than printing over a serial port. To print to I/O port 0x402 (the default used by SeaBIOS and OVMF), add "-DDEBUG_IO_PORT=0x402 -DCORE_DEBUG=1" to the build CFLAGS. To enable a debug console in QEMU that

Hello, This is my first post to this list. After searching through the archives and google searches I could not find a solution for my memtest problem. In previous versions of pxelinux/gpxelinux (4.04 and 4.06) I could successfully start the memtest utility. But using pxelinux/gpxelinux versions 5.01 and 5.02 the memtest utility does not boot and I get an error message: boot: Loading

Hello Thomas, Thomas Schmitt via Syslinux said on Sun, Oct 25, 2015 at 04:35:57PM +0100: >I assume you can boot Fedora Live CD on the same (virtual) hardware. Not sure for Fedora, but the system is installed with either RHEL6, RHEL7 or Ubuntu 14.04 depending on the Lab I'm making on it without issue. >Just to make sure that the firmware works so far. Globally they do ;-) >