[syslinux] Problem with PXE reboot option

[Gerrit Binnenmars]

Hello, on may 7th I send the following mail. Can you confirm that it is 
received and can you comment on the reaction of the manufacturer?


In our system (lot of CPCI boards) the atftp server is sometimes so busy 
that a TFTP request times out. I added the PXE option reboottime to 
force a quick reboot.
Once in a while this fails and the board just doesn't reboot.
I can easily reproduce the problem when I rename/delete the pxelinux.cfg 
directory. In that case the board reboots fine a few times but hangs 
within 15 minutes.

In my opinion this is a board/BIOS problem but the manufacturer proposes 
to adapt the PXE reset code.

Additional info: (shown by the board at start-up)
Intel(R) Boot Agent GE v1.3.72
Version 2.14.1219. Copyright (C) 2011 American Megatrends, 
Inc.                 BIOS Date: 12/10/2012 14:55:32 Ver: B3C01015
B2EFI Shell version 2.31 [4.651]
Current running mode 1.1.2


Can you comment on the following answer from the board manufacturer?
At first, I would like to say that we've not found the root cause why 
this call doesn't work on this platform. The sources to this piece of 
code are not available to us. Nevertheless, we analyzed the PXE source 
code at this point. As you already know, the pxelinux code tries to jump 
to the reset vector of the CPU. Just before this jump, it writes some 
magic code into a memory location (0x472).
I've found not really a specification for this location. The best 
information I found can be retrieved from a linux source code file 
(http://www.cab.u-szeged.hu/linux/kernel/linux/arch/i386/kernel/process.c.html 
<http://www.cab.u-szeged.hu/linux/kernel/linux/arch/i386/kernel/process.c.html>). 
In this file, the comments from the programmer give not very high 
confidence that this approach is necessarily working on every hardware.
For sure, you'll say now that it's sometimes working and sometimes not. 
As the code doesn't change, a stable behavior would be expected. For 
unknown reason, we don't have this stable behavior.
Our recommendation in this case is to use a reliable, documented way to 
reset the platform. We think that the best way to do it is to use the 
reset register (RST_CNT) from the PCH controller.
A reset generated by a keyboard controller is not recommended as it's 
not sure if future platforms will support this (=> legacy free design). 
 From the complexity point of view, it makes no difference which method 
to use. The reset via PCH register is just a write to IO space register 
0xCF9h.
We recommend to perform a full reset via this register. In order to do 
this, a value of 0x0eh needs to be written into this location.
I'm not the assembler guru but the following code should do the job:
Mov DX,0cf9h ; load port address
Mov al, 0e ; load reset value into al register
Out al,dx ;execute a full reset of the board


With kind regards,

Gerrit Binnenmars