Syslinux - May 2013 - PXE sometimes fails to reboot

Hello,

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

On 05/07/2013 03:00 AM, Gerrit Binnenmars wrote:
> 
> 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.
This memory location is documented in just about any BIOS documentation
(it is usually referred to as 40:72 hexadecimal).  It is more than a bit
embarrassing that the
> We think that the best way to do it is to use the reset
> register (RST_CNT) from the PCH controller.
That is fine if you have to worry about one specific system, but that
only works on a subset of systems in the field.  Furthermore, to do it
right requires ACPI handling.

In contrast, jumping to F000:FFF0 has been supported since the original
IBM PC.  The memory location 40:72 is just to set cold boot vs warm boot.

Most likely this manufacturer's problem is that they haven't implemented
warm boot correctly, which is why you are having intermittent problems.
> 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
That's not even the standard value for a reset, which is 06h.

	-hpa