This commit adds a coreboot patch which causes kgpe-d16 to skip the
PNP enumeration/assignment process for the "hardware monitor"
(basically a temperature sensor and fan-speed controller) block on
the southbridge chip.
I have found this patch solves the last remaining boot reliability
problem I was having with my unattended kgpe-d16 machines.
The commit message for this patch is below:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The hardware monitor is one of the blocks within the w83667hg-a chip
(there are many others). It is basically a bunch of ADCs (analog to
digital converters) hooked up to voltage, current, and temperature
sensors in various locations on the motherboard.
This block has the ability to generate several different interrupts
(SMI#, OVT#, etc) in response to thermal conditions. It appears to
sometimes (about 10% of boot-ups, depending on temperature) spew
erroneous alarm interrupts the instant you enable it, when doing so
from within coreboot. This causes the w83667hg-a chip and the
entire system to hang, and the watchdog cannot recover from this
state because it is part of the w83667hg-a chip too.
An even bigger problem is that the hardware monitor is initialized
*before* the fans are brought up to full speed. So if the CPU is
above the critical temperature it will remain there because the fans
are in their default low-speed boot state. The chip just keeps
getting hotter and hotter -- not enough to damage itself, but hot
enough that it won't come down to an acceptable temperature with
simple reboots and power-cycles; you have to leave the system off
for a while. Since the fans aren't running while the system is off
this takes quite a while (several minutes). It's a very fussy and
fidgety process, and not something you want to walk a remote-hands
guy at the datacenter through over the phone.
To avoid this whole mess, let's simply not assign PNP resources to
the hardware monitor from coreboot. Linux doesn't need these
anyways; it communicates with the hardware using I2C.
This commit integrates five more kgpe-d16 patches from my local
tree:
treewide: reduce many messages to BIOS_SPEW
southbridge/amd/sb700/lpc.c: leave LPC timeout mechanism enabled
I've been experiencing boot hangs during PNP enumeration of the LPC
bus. The southbridge chip comes with a mechanism to prevent
unresponsive/syncflooding LPC devices from wedging the system; let's
use it.
mainboard/asus/kgpe-d16/romstage.c: support console on ttyS1
Currently the romstage serial console initialization always
initializes SP1 (the DB9 header on the back of the motherboard).
Changing UART_FOR_CONSOLE simply causes the romstage to map the same
serial port at a different address (0x2f8).
This commit accounts for UART_FOR_CONSOLE (and its effect on
TTYS0_BASE) correctly: if UART_FOR_CONSOLE is changed from 0 to 1,
the romstage console output will be printed on the SP2 header (the
IDC ribbon header on the motherboard).
southbridge/amd/sb700/lpc.c: set SPI flash aperture to 16MB
The SPI flash aperture for the southbridge chip is set to 8MB, even
when a 16MB chip is used. Let's make the aperture large enough for
the maximum size chip that this board can accomodate.
amd/sb700/early_setup.c: select console properly
Currently, sb700/early_setup.c has this comment:
// XXX Serial port decode on LPC is hardcoded to 0x3f8
... and it unconditionally sets the output enable for ttyS0, even if
ttyS1 is also enabled. As a result, if coreboot is configured to
use ttyS1 for serial output, the romstage console output will appear
on *both* consoles.
This commit fixes that.
kgpe-d16: disable TPM
I have never heard of anybody using a TPM on this board, and the
fewer things we need to deal with during the somewhat-flaky LPC
init, the better.
Adam Joseph