Hello nVIDIA staff.
Setting up WDT up to Jetpack 3.2 is a software reset using exception handling.
It will not work in abnormal situations like “Linux goes down” or “Tegra stops”.
It seems that it is possible to generate a hard reset when reading TRM of Tegra_X1.
I have changed various settings, but it does not work as expected.
Lecture about changes in the device tree and the debudor that let you function to reset the whole Tegra without using iRQ / FIQ.
that’s all.
Try this app. Also attached the code for your reference.
sudo ./wdt 20 20
#include <stdio.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <sys/ioctl.h>
#include <linux/watchdog.h>
#define DEV_NAME "/dev/watchdog"
int main(int argc, char **argv) {
int interval, margin;
if (argc >= 2) interval = atoi(argv[1]);
if (argc >= 3) margin = atoi(argv[2]);
printf("watchdogd started (interval %d, margin %d)!\n", interval, margin);
int fd = open(DEV_NAME, O_RDWR|O_CLOEXEC);
if (fd == -1) {
fprintf(stderr, "watchdogd: Failed to open %s: %s\n", DEV_NAME, strerror(errno));
return 1;
}
int timeout = interval + margin;
int ret = ioctl(fd, WDIOC_SETTIMEOUT, &timeout);
if (ret) {
ret = ioctl(fd, WDIOC_GETTIMEOUT, &timeout);
if (ret) {
fprintf(stderr, "watchdogd: Failed to get timeout: %s\n", strerror(errno));
} else {
if (timeout > margin) {
interval = timeout - margin;
} else {
interval = 1;
}
fprintf(stderr, "watchdogd: Adjusted interval to timeout returned by driver: timeout %d, interval %d, margin %d\n",
timeout, interval, margin);
}
} else {
printf ("watchdogd: set timeout success\n");
}
return 0;
}
wdt.txt (9.76 KB)
Hi. ShaneCCC
Thank you for your reply.
As far as the application is concerned, it looks like a code for confirming whether WDT works or not.
We are confirmed to jump to “tegraboot” in IRQ mode setting in our environment.
What we want to know is to change the operation of the WDT / PMIC and reset the Tegra itself with a hard reset.
Do you understand that point?
that’s all.
I am not really understand your point. However the watchdog timer designed for the CPU hang to reboot the system.
Well, as you can see, I will explain in a bit more detail.
We would like to make it a WDT using ‘4th expiration (System reset)’ in Figure 11 on page 217 of ‘Tegra_X1_TRM_v1.2.pdf’.
I tried the ShaneCCC code, but it does the same thing.
that’s all.
Have you try to modify the tegra_wdt.c to enable only the WDT_CFG_PMC2CAR_RST_EN ?
static int tegra_wdt_init(struct watchdog_device *wdd)
{
struct tegra_wdt *wdt = watchdog_get_drvdata(wdd);
u32 val;
/*
* The timeout needs to be divided by expiry_count here so as to
* keep the ultimate watchdog reset timeout the same as the program
* timeout requested by application. The program timeout should make
* sure WDT FIQ will never be asserted in a valid use case.
*/
val = (wdd->timeout * USEC_PER_SEC) / expiry_count;
val |= (TIMER_EN | TIMER_PERIODIC);
writel(val, wdt->tmr_regs + TIMER_PTV);
/*
* Set number of periods and start counter.
*
* Interrupt handler is not required for user space
* WDT accesses, since the caller is responsible to ping the
* WDT to reset the counter before expiration, through ioctls.
*/
val = (wdt->timer_id) |
(trigger_period << WDT_CFG_PERIOD_SHIFT) |
WDT_CFG_INT_EN | WDT_CFG_FIQ_EN | WDT_CFG_PMC2CAR_RST_EN;
writel(val, wdt->wdt_regs + WDT_CFG);
writel(WDT_CMD_START_COUNTER, wdt->wdt_regs + WDT_CMD);
return 0;
}
We tried exactly the same thing.
However, restarting will take place at WDT, but after outputting “Starting CPU & Halting coprocesser” log, boot will stop 100%.
Linux did not start up.
The RESET_OUT signal of Jetson_TX 1 was not asserted ‘L’.
I talk about whether MAX 77620 setting is related, but because there is no information, it is a fumbling state.
This inquiry stems from the occurrence of a phenomenon in which software locks in cboot due to restart by WDT.
There are cases where it does not start if you increase the number of tests (500, 1,000 times).
It is not a system that restarts 100%.
As one can see,
· All ‘1 to 4th expiration’ are occurring …
· The restart of software is occurring in ‘4th expiration’.
· When you want to set to WDT of 20 [s], TRM: The WDT cycle in Fig. 11 is set to 5 [s] and restarted with 4 timeouts.
Product shipment can not be done as it is.
Analyze what is happening while arranging JTAG_ICE, but please also provide information and analysis cooperation so that nVIDIA can provide complete WDT.
Additional questions>
· Is nSYS_RST generated in 4th expiration not output to the RESET_OUT terminal of Jetson_TX1?
that’s all.
@BlueYatagarasu
After check the WDT internally, it’s a known issue. Please check below errata
Thank you for providing the information.
Is the content of ‘BR-2’ in errata and the problem not restarting in WDT which is happening in our place the same?
Our WDT test environment has simply created a state in which WDT is started and not accessing WDT after Linux startup. The application does not run. Tegra temperature rise is also low.
If it was a similar problem, what would you say about the details of “Use PMIC WDT”?
Although Jetpack 3.2 announced that the WDT problem was solved softly, it will be using the WDT built in Tegra_X1.
We conducted our WDT test with multiple Jetson_TX1, but we know that there are individual differences in frequency of not starting normally.
When RESET of the 64bit ARM core is enabled with ‘3rd expiration’, not all Jetson_TX1 will stop at startup.
Therefore we anticipate the problem of margin of hard reset time.
nVIDIA needs to present more detailed information and solutions for all customers.
that’s all