I know that this hardware is old, but it's lovely and still rocks! However I have some rather annoying lockups I couldn't investigate. I decided to search for a watchdog. It turned out that the chipset has one. Once there was a driver existed, but it was removed, because it was reported to malfunction.
Here is a brief summary of the proposed mechanism:
Writing to PM40[TCO_RLD] reloads the counter with the value stored in PM41[TCO_TIME] (page 119). After the first countdown PM44[TOUT_STS] is set (page 120). The second timeout will set PM46[2NDTO_STS], which can trigger a reboot (page 121), if DevB:3x48[NO_REBOOT] is cleared (page 97). Here it is indicated, that PORTCF9[FULLRST] must be taken care of. If this later bit is not high, the system won't reboot, just the reset signals are asserted. It defaults to low. The PORTCF9 register is enabled by DevB:3x41[PCF9EN] (page 94). The TCO timer can be halted by setting PM48[TCOHALT] (page 121).
I saw, that FULLRST wasn't set high. This form of the driver made the counter work, only it wasn't rebooted the machine. Flipping it to 1 made the machine reboot immediately, which is not the effect it supposed to cause. In the mean time I've found some IRC conversation archives about exactly the same problem: zwane & Gandalf 1, zwane and Gandalf 2.
Can someone clarify in which order these registers must be programmed? Is there someone out there ever made this component of the chipset work?
I hope, that there are still some AMD developers out there, who have sweet memories of amd 768 with enough experience will help me. I won't give it up so easy!
At least there's no errata for the 768 like for the 8111 about the watchdog.
In the mean time I've found another disappointing email on LKML about this issue. However I still keep on trying. If some AMD person would confirm, that this is caused by an implementation error or - who knows - a bug in the chipset (as it happens with 8111), I wouldn't waste my time on this.