Linux-compatible watchdog add-on?

Hi,

Sorry if my question is off-topic for this list.

I have a computer that experienced a kernel failure while a was far away and nobody could reboot it. So I thought it would be nice to have a watchdog. Unfortunately, to the best of my knowledge, it has no hardware watchdog, so I thought I should add one.

Hence, do you have suggestions for I²C-, serial- or USB-connected watchdog add-ons? It should of course be compatible with linux.

I found
http://www.berkprod.com/Product_Web_Pages/usb_v1_pc_watchdog.aspx
but I think it is a little too expensive.

If no such thing exists, I might consider designing my own (open hardware) I²C- or USB-connected watchdog add-on, using a cheap MCU. But then I would welcome opinions on what the interface between the host and watchdog should look like.

Cheers,

Nicolas Boullis

Hi

Am 25.08.2016 um 18:31 schrieb Nicolas Boullis:

How about SPI?
If yes, you can try this project:
https://plus.google.com/102032716864870215256/posts/PwMMKYP5PKR
https://plus.google.com/102032716864870215256/posts/QJqPxSi1Str

Linux side is configured as watchdog, MCU side currently do only demo blinking, but watchdog should be a main future.

Regards,
Oleksij

Hi,

Thanks for telling me about this project.

But, to be honnest, I don’t really understand what this project is about. I never hearded about the SSI32 protocol (while I know the SPI protocol)…

Anyway, as far as I know, my motherboard has no SPI bus… I guess I might buy or design an USB-SPI interface, but I wonder if designing an USB watchdog wouldn’t be easier…

Anyway, I would still be interested to understand a little more what that project is about; it might at least be a good source for inspiration…

Cheers,

Nicolas Boullis
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi

Am 27.08.2016 um 01:14 schrieb Nicolas Boullis:

This project have different components levels:
1. SPI - it is cheap any mostly available on all SoCs and MCUs. IMO same can be implemented on UART.
2. Flow control line. SPI don't have it and if we use MCU with many tasks on other end, there is no way to predict where we can start our transfer. The are many ways to implement flow control on SPI, some of them implemented directly to IPcore which is not really portable.
3. Request/Interrupt line is muxed with Flow Control, it means by using 5 wire we still able to do slave to master transfer and flow control.
4. on transport level it has 4 byte header with some control information, size and checksumming. Practice has show that even on stable products we can get some weard DMA or FIFO related bugs so the transfer got corrupted.
4. LUN or Endpoint number, so one MCU can provide different functions at same time. For example watchdog, rtc clock, package filter, gpio extender. At same time since it all done in software we can use unified linux drivers.
5. App to App acknowledgement, so each side knows if package was actually delivered.
6. linux side bus implementation, so on linux we create a device tree with MCU capabilities and drivers are loaded automatically.

In my link i provided a example watchdog driver, but in this case MCU is only toggling LEDs. Need more time to finish it.

Regards,
Oleksij

Anything you come up with will need a connection to the system reset, so you'll have to have an in-chassis solution. Any cheap MCU with USB or I2C port and a couple of GPIO ports would probably do.

If you consider the above product, make sure that you get an assurance that its Linux driver still works - it is quite old.

Guenter