search for: dcore_debug

...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 listens to I/O port 0x402 and prints to stdio, add "-debugcon stdio -global isa-debugcon.iobase=0x402" to the QEMU command line. Jonathan Boeing (1): dprintf: add debug console support com32/include/dprintf.h |...

...PM -0400, Gene Cumm wrote: > > I thought I would try to find out how pxelinux copes with this, by trying > > to insert printfs in pxe_init, but nothing gets printed. > > This is normal. Can you give me hint as to why setting > > DEBUGOPT = -DDEBUG=1 -DDEBUG_STDIO -DCORE_DEBUG=1 changes that state of normality? (AFAICT dprintf.h defines dprintf to printf, so why wouldn't using printf directly work? printf.o gets built regardless of DEBUG settings AFAICT.) > > From looking at com32/include/dprintf.h, it looks as though all this does is > > to define dpri...

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

...nstances of "!PXE" in the chunk of memory that "Method D" should look at. I thought I would try to find out how pxelinux copes with this, by trying to insert printfs in pxe_init, but nothing gets printed. I can spew lots of output if I set DEBUGOPT = -DDEBUG=1 -DDEBUG_STDIO -DCORE_DEBUG=1 but given that this box doesn't have a serial port, anything I add will whizz off the screen. >From looking at com32/include/dprintf.h, it looks as though all this does is to define dprintf to printf, so why is it that if don't define DEBUG_STDIO and CORE_DEBUG, and just use printf d...

...d on Wed, Oct 28, 2015 at 01:45:22AM +0100: >> >> Is there a way to increase the debug level of syslinux.efi in order to >> check what it tries to do and diagnose more precisely what happens ? > > > Ok, I tried to modify mk/devel.mk to put: > 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...

...sages 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 listens to I/O port 0x402 and prints to > stdio, add "-debugcon stdio -global isa-debugcon.iobase=0x402" to the QEMU > command line. When enabled, what will the effect on real hardware without the diagn...

Gene Cumm said on Wed, Oct 28, 2015 at 05:58:59AM -0400: >> Ok, I tried to modify mk/devel.mk to put: >> 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. Ok I can drop them, but that doesn't change the fact it doesn't build :-( >> libcom32.a(bios.o...

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

...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.c32' resulted in...

...h other. 2) Method D is quite the fall back. > I thought I would try to find out how pxelinux copes with this, by trying > to insert printfs in pxe_init, but nothing gets printed. This is normal. > I can spew lots of output if I set > > DEBUGOPT = -DDEBUG=1 -DDEBUG_STDIO -DCORE_DEBUG=1 > > but given that this box doesn't have a serial port, anything I add will > whizz off the screen. Serial or some sort of IP KVM with logging is ideal. > From looking at com32/include/dprintf.h, it looks as though all this does is > to define dprintf to printf, so why is it...

...gt; > I thought I would try to find out how pxelinux copes with this, by trying >> > to insert printfs in pxe_init, but nothing gets printed. >> >> This is normal. > > Can you give me hint as to why setting > >> > DEBUGOPT = -DDEBUG=1 -DDEBUG_STDIO -DCORE_DEBUG=1 > > changes that state of normality? What commit ID or numerical version? -- -Gene

...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 a > simpler conf...

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" to take the at...

Bruno Cornec via Syslinux said on Wed, Oct 28, 2015 at 01:45:22AM +0100: >Is there a way to increase the debug level of syslinux.efi in order to >check what it tries to do and diagnose more precisely what happens ? Ok, I tried to modify mk/devel.mk to put: GCCWARN += -Wno-clobbered -DCORE_DEBUG=1 -DDEBUG_MALLOC -DDEBUG_THREAD And removing the -DDYNAMIC_DEBUG but now syslinux doesn't want to build: ranlib liblpxelinux.a ld -m elf_i386 -Bsymbolic -pie -E --hash-style=gnu -T /root/syslinux/core/i386/syslinux.ld -M -o ldlinux.elf ldlinux.o \ --start-group libcom32.a --whole-arch...

...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 reminder, the hardware I?m...

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

...sole. 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 listens to I/O port 0x402 > > and prints to stdio, add "-debugcon stdio -global > > isa-debugcon.iobase=0x402" to the QEMU command line. > > > When enabled, what will the effect...

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