>>>> 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 handle instead. -- -Gene <<< Weird as it sounds I was able to send debug info to COM2 (redirected to a pipe) on EFI64 VMware workstation clients. I got the debug messages on a terminal emulator pointing to the pipe. It does work. Best Patrick
[ merging a few sub-threads into one ]
> Weird as it sounds I was able to send debug info to COM2
> (redirected to a pipe) on EFI64 VMware workstation clients.
Ports 0x3f8 and 0x2f8 are so hardwired into my brain from back in the
old BBS-days that I did not expect them NOT to work. Apparently some
firmware engineers have this problem too. ;-)
>>>>
> If there is nothing yet, I think a wrapper around printf
> (and *prinf) is
> needed. This should [v]sprintf() to a buffer and then print the
> resulting buffer using APrint("%a", buffer) if EFI_BUILD is
> defined.
> <<<
> It sounds logical.
Even Print("%a", buf) would work. I first used APrint() because the
format string for it is a const char *, whereas Print() expects a const
unsigned short * pointing to an unicode string. But then I found that
any %s in both format string formats, also expects unicode strings. To
print a good old ascii string, one needs to use %a. A "#define printf
APrint" did not work very well because of this.
On 05-08-15 16:47, Patrick Masotta wrote:
> This is a big issue. Probably lot of code doing this in EFI...mmmhhh
> You can try redirecting printf to an empty function and see if it
> crashes the same way..
I'm quite sure it isn't the printf that causes the crashing. It just
doesn't appear. At one time I had this in efi/main.c:
if (!setjmp(load_error_buf)) {
printf("Is printf still working?\n");
Print(L"Entering: load_env32\n");
load_env32(NULL);
}
The output for this is:
| Entering: load_env32
The printf's i put in load_env32 itself didn't output anything either,
but now i can see the output of dprintf's on COM2.
(Grammar question, is printf's the correct plural of printf?)
> I would try with a minimalistic (1 entry) menu
I am doing that just now.
Oscar Roozen
2015-Aug-05 17:25 UTC
[syslinux] EFI: HP + syslinux = crash [ brown paper bag update ]
Update: I added my debugging stuff (just a bunch of Print()s and dprintf()s) to the branch without the multinic fix to see if I could find a common cause somewhere. This is based on commit 8702009f. Where I expected the machine to crash again, it just exited back to the bootloader without crashing. So.. somehow adding this debug code solved the crashing problem? Or did it? Then I went back to the latest branch (e466d249) and lo and behold... It did not crash! Not even with the vesamenu.c32! The same binary! Okay, vesamenu.c32 is still crashing if I enable the bootlogo.png but otherwise it seems pretty stable.. What on earth could have 'cured' my machine? [ some time later ] I probably messed up in copying over libutil.c32 and libcom32.c32 along with the various versions of syslinux.efi. I'm still not sure what I did exactly everytime, so I will do more tests. But this could really be very embarrassing... I will wear a brown paper bag over my head for a while.