AM62A7-Q1: Is the AM62A SDK set up to use the Power On memory region referenced in the watchdog driver?

Hello Bas,

Just to clarify, when you say "reason" in the initial question, do you mean to say "region"? If so I will edit the post.

Please describe for me how you are hoping to use the power on memory region.

Regards,

Nick

If I understand the rti_wdt driver correctly, the power on memory region can be used to get the reboot reason (at least that's what it is used for in the driver).

I need to know why the board rebooted, to keep track of the number of times we had a watchdog reset. I would like to use the watchdog driver to do this, preferrably in such a way as to not actually trigger the watchdog.

In order to be able to do so, I need to configure the power on memory region in my device tree. I haven't seen this configured for the AM62A, and am unsure whether this needs additional support in the the bootloader(s) to make this happen.

I would like to get clarification on how to configure the power on memory region for the AM62A, and what changes are needed (if any) in the bootloader(s) and device tree to make this work correctly.

Regards,

Bas Vermeulen

Hello Bas,

Ahh, thank you for the clarification. I am blocking off my afternoon tomorrow to dig into watchdog, will provide responses on both threads then.

Regards,

Nick

Looking forward to your reply!

Regards,

Bas

Hi Nick,

Were you able to get some progress in this topic?

Bas

Hi Nick Saulnier,

Just giving you a ping as requested.

Bas

Hello Bas,

Thank you for the pings.

Watchdog driver code 

I assume you are referring to this part of the rti_wdt_probe function:

        node = of_parse_phandle(pdev->dev.of_node, "memory-region", 0);
        if (node) {
...
                /*
                 * If reserved memory is defined for watchdog reset cause.
                 * Readout the Power-on(PON) reason and pass to bootstatus.
                 */
                paddr = res.start;
                reserved_mem_size = resource_size(&res);
...
                vaddr = memremap(paddr, reserved_mem_size, MEMREMAP_WB);
                if (!vaddr) {
                        dev_err(dev, "Failed to map memory-region.\n");
                        ret = -ENOMEM;
                        goto err_iomap;
                }

                if (vaddr[0] == PON_REASON_SOF_NUM &&
                    vaddr[1] == PON_REASON_MAGIC_NUM &&
                    vaddr[2] == PON_REASON_EOF_NUM) {
                        wdd->bootstatus |= WDIOF_CARDRESET;
                }
                memset(vaddr, 0, reserved_mem_size);
                memunmap(vaddr);

and the memory-region defined in the bindings documentation:
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml?h=ti-linux-6.12.y#n37

So... This is going to take a bit of time to look into. At a glance, I do not actually see how this arbitrary memory allocation in DDR would work.

First off, in the probe function we can see that the driver is only looking for 12 specific bytes that are supposed to indicate a watchdog reset. bootstatus is not updated if there are any other values in the memory region. So it would only be able to say if a watchdog reset occurred, not any other reset source.

But some other driver code would need to know that the user allocated that specific DDR region to hold a reset value, and then write the 12 magic bytes to the DDR region during a watchdog reset event. I do not see that memory region getting used anywhere, so I do not know how those 12 bytes would even get written to DDR in the first place.

I could be missing something. I am reaching out to some other team members for ideas.

Other options for seeing reset reason

Does this section from the TRM describe the functionality you are looking for?

"Reset Source Status Registers"
register WKUP_CTRL_MMR1_RST_SRC

Regards,

Nick

Hi NIck,

Yes, that was the watchdog driver code I was looking at. I need to know whether we had a watchdog reset for one of my requirements/functionalities, and this would fit the bill if it's (supposed to be) working.

The register WKUP_CTRL_MMR1_RST_SRC is what I currently use with devmem2 to get the reset status. This works from the command line, but I would like something readily available to userspace (without having to recreate devmem2 in my application).

Another option would be to read that from u-boot and update my kernel command line with the reboot reason.

Regards,

Bas Vermeulen

Thanks Nick, that answered my question.