Syslinux - Aug 2015 - EFI: HP + syslinux = crash [ brown paper bag update ]

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

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.