[syslinux] PXE sometimes fails to reboot

H. Peter Anvin hpa at zytor.com
Mon May 13 15:35:34 PDT 2013

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.


More information about the Syslinux mailing list