similar to: elflink issues

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

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

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.

Hi Peter, The main part of this pull request includes commits that try to replace as many __intcall() invocations as possible. Some remain, but not many (and eventually they'll be gone too). There's also a patch to make better use of ld's --as-needed option and various other bug fixes/cleanups. The following changes since commit ff7334a2ce536b7f4b1f6d6f93ff4e285a3bd45a: Only

From: Matt Fleming <matt.fleming at intel.com> Since we can't use __intcall() for EFI, and since we can now have the ELF module code resolve all our symbols at runtime, we should delete as many references to __intcall() as possible and just access the symbols directly. The most interesting patch is the support for weak symbols. We need to be able to reference derivative-specific

I have reason to believe that an odd box that is having boot trouble has three instances 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

On Tue, Oct 27, 2015 at 10:15 PM, Bruno Cornec via Syslinux <syslinux at zytor.com> wrote: > 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:

Hi, I've got a question regarding pxelinux: It seems that there is a buck in syslinux 3.86 (or still is in the current build) in the reset_pxe function. If I call "syslinux_local_boot(0)" (in a COM32 binary) the KeepPXE variable is always 1 which resets the PXE stack instead of unloading it: local_boot: push cs pop ds mov [LocalBootType],ax call vgaclearmode mov

Has anyone played with the syslinux/lwip.git tree? It works fine with pxelinux: qemu -boot n -net nic -net user,bootfile=/pxelinux.0,tftp=/pxe (although it hangs while trying to resolve www3.kernel.org because of the lack of proper DNS with -net user) The same command hangs earlier with gpxelinux.0 though: Getting cached packet 01 pxe_call op 0071 data 0x00012518 -- Pierre-Alexandre

Op 2013-07-15 om 12:40 schreef Michael Szerencsits: > > If it is http://rosa.stappers.nl/ff/boot-efi-s100.cap > > then is at packet 2242 the client ( .243) started to send > > "TCP Dup ACK" of packet 2241 > > > > > > Thing I what to mention is that there packets of sizes bigger as 9000bytes. > } So large as a jumbo frame. > > > > I

BTRFS file systems will be corrupted on 6.02 (mainstream) and some previous versions. DYNAMIC_DEBUG makes the core larger than the allowed. Even before its introduction, building Syslinux with DEBUG_PORT enabled would probably corrupt BTRFS images (IIRC) *if* ldlinux.sys surpasses the maximum allowed size. Besides, the installer isn't safe at all... The check could be easily made there to

> > Sounds like you may want to contact Cisco... > > And tell them what? There's a bug in their PXE/BIOS stack somewhere? Just some random and humble thoughts... Perhaps it would be worth some additional tests? Maybe a test with pxelinux.0 version 4.07? And using "LINUX", not "KERNEL": ### DEFAULT biginitrd PROMPT 0 LABEL biginitrd LINUX mykernel INITRD

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

PXELINUX has stopped recognizing the keeppxe option on the kernel command line. Here is a patch to make it work again. With COM32, it is no longer possible to use preprocessor directives to determine the SYSLINUX variant. The code inside the #if will never be compiled. So, I changed it to use syslinux_filesystem() to determine the variant. Also, I moved the relevant code from

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

Hello Geert Thanks for replying.. But i think i can?t use it, as i don?t reach the point where the debug module will be available.. it just pulls the lpxelinux.0 and tries to get the next download-- the ldlinux.c32 and it fails...and freezes. And the next step would be other modules i think.. if i?m wrong.. excuse me 8-).. yesterday i managed to get ipxelinux working from ipxe.org.. so the nic

Hmm... well adding the __export stopped the "undefined symbol" error from showing up when I add "SENDCOOKIES" in the config, however I'm still not seeing any cookies being sent to my webserver. Any ideas on how to further debug? (if you want to send me the debug compile options privately that's okay too) -----Original Message----- From: H. Peter Anvin [mailto:hpa at

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

On Tue, Apr 14, 2015 at 03:20:08PM -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

FYI -- Did some more digging. These two changes lets SENDCOOKIES behavior work as desired/intended. --- syslinux-6.02/com32/include/syslinux/pxe_api.h 2013-10-13 13:59:03.000000000 -0400 +++ syslinux-6.02-changed/com32/include/syslinux/pxe_api.h 2013-11-21 17:00:57.379519000 -0500 @@ -589,7 +589,7 @@ void __weak unload_pxe(uint16_t flags); uint32_t __weak dns_resolv(const char *);