imx8m reset without WDOG_B signal usage

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

imx8m reset without WDOG_B signal usage

7,973 Views
wolfgang_baer
Contributor I

Hi,

i have a problem with the watchdog operation on our custom imx8m board.

Our board does NOT use the WDOG_B signal for PMIC reset and we are not able to change this.

Resetting the board in u-boot works like given in the reference manual:
Setting the 0x3028000 register to e.g. 0x14 resets the SOC and I get also watchdog timeout as the source of the reset in the status register. Also asserting the SRS bit resets the SOC and gives the correct reset source in the status register.

After booting Linux this no longer works - after forcing a watchdog timeout the SOC just freezes.

The voltage sources are as required for SOC startup so this should not be a problem. We boot from EMMC and the RST

pin is connected.

Any hints what else I can check or anyone with same setup (no WDOG_B signal to PMIC)?

Regards, 

Wolfgang

0 Kudos
Reply
18 Replies

6,008 Views
DefieldsJ
Contributor I

Hi, I'm having the same issue on a custom imx8mm-based board.  Uboot 'reset' command works as expected, but linux 'reboot' command hangs without any specific error output.

Has anyone figured out how to work around this issue without hardware modifications?

Thanks in advance,

Justin D.

0 Kudos
Reply

7,422 Views
emptyfridge
Contributor III

Hi guys,

Try to get out SRSR Reset Status Register (0x3039005c). Well it works, but it looks like it never changes status. No matter how I boot/reboot/reset/poweroffon/wdog/ the i.mx8mm src_reg srsr is every time 0x01.

Is there a known issue, that it is not working properly?

Or am I doing something wrong?

u-boot-imx_2019.04

u32 get_imx_reset_cause(void)
{
struct src *src_regs = (struct src *)SRC_BASE_ADDR;

if (reset_cause == -1) {
printf("0 src_regs %.8x \n", src_regs);
printf("0 src_regs %.8x \n", &src_regs);
printf("0 src_regs->srsr %.8x \n", src_regs->srsr);
printf("0 src_regs->srsr %.8x \n", &src_regs->srsr);
reset_cause = readl(&src_regs->srsr);
printf("1 reset cause %.8x \n", reset_cause);
/* preserve the value for U-Boot proper */
#if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_ANDROID_BOOT_IMAGE)
/* We will read the ssrs states later for android so we don't
* clear the states here.
*/
writel(reset_cause, &src_regs->srsr);
printf(" 2 write reset cause %.8x \n", &src_regs->srsr);
printf(" 2 read reset cause %.8x \n", src_regs->srsr);
#endif
writel(reset_cause, &src_regs->srsr);
printf(" 3 2write reset cause %.8x \n", &src_regs->srsr);
printf(" 3read reset cause %.8x \n", src_regs->srsr);
}

return reset_cause;
}

thanks for your help.

 

0 Kudos
Reply

7,596 Views
Yuri
NXP Employee
NXP Employee

Hello,

  

  It is recommended to remove power (voltage) to all components on the board,

even in case a processor reset, since some external devices, such as eMMC, SD,

QSPI, DDR) may stay in non predictable state; as result system boot does not work.

 

  In Your case, I think, memory is the reason. Perhaps it is necessary to issue

PreCharge All command at the beginning of the LPDDR initialization and to reset

the READ FIFO Pointers.

 


Have a great day,
Yuri

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

0 Kudos
Reply

7,597 Views
wolfgang_baer
Contributor I

Hi Yuri,

thanks for your fast response. I know it is recommended to remove power but as said this no option for us currently.

Regarding memory. Do you mean to perform the mentioned commands in the LPDDR4 initialization code in SPL?
Do you have any hints about documentation of these commands as I am currently just using the DDR Tool generated
initialization code in the SPL DDR initialization.

Do you also have a clue why it does work in u-boot (at command prompt) but not after loading of Linux?
What could be the difference here regarding memory?

Thanks, your help is really appreciated,

Wolfgang

0 Kudos
Reply

7,597 Views
Yuri
NXP Employee
NXP Employee

Hello,

  Is it possible to run simple memory test of U-boot - in order to exclude memory issue?

Regards,

Yuri.

0 Kudos
Reply

7,597 Views
wolfgang_baer
Contributor I

Hi Yuri,

a simple mtest in u-boot for the memory shows no errors.

Also the DDR-Tool stress-tests done during board bring up showed now errors.

Do you have a hint regarding documentation / changes for the memory commands you mentioned in your first post?

Thanks,

Wolfgang

0 Kudos
Reply

7,597 Views
Yuri
NXP Employee
NXP Employee

Hello,

  Since  for i.MX8M the SPL contains the codes for DDR PHY and DDR controller initialization
and DDR PHY training, usually it is recommended to use the recent firmware from the the DDR Tool;

it should provide all the required initialization.

  Also, it makes sense to get the Stress test working.

https://community.nxp.com/docs/DOC-340179 

Regards,

Yuri.

0 Kudos
Reply

7,597 Views
wolfgang_baer
Contributor I

Hi Yuri,

yes, we are using the latest Version of the DDR Tool (V2.10) with the latest Excel sheet for LPDDR4 (v23).

The stress test works on our board without issues.

The same effect I can also see on the EVK board if I disable the WDOG_B assert functionality:

- Watchdog works on the u-boot prompt -> it resets the device

- After booting to linux prompt -> the same watchdog call does just stall/freeze the device

Regards,

Wolfgang

0 Kudos
Reply

7,596 Views
reyhanehyazdani
Contributor II

Hi Wolfgang,

I also have the same problem. Did you find any answer for that?

Regards,

Reyhaneh

0 Kudos
Reply

7,597 Views
wolfgang_baer
Contributor I

Hi Reyhaneh,

I am sorry – no. I have not managed to get a solution regarding this issue.

Basically NXP states to reset the PMIC – however this is a no go for us too.

If we found a solution I will report it here.

Regards,

Wolfgang

0 Kudos
Reply

7,354 Views
wolfgang_baer
Contributor I

Hi Cedric,

we did not found/search for a solution but connected the WDOG_B pin via a 100k PU to the 
SOC reset pin (POR_B) in the next redesign. This way we can reset the SOC by
watchdog without touching the PMIC.

 

Regards,

Wolfgang

0 Kudos
Reply

7,240 Views
cedric_starke
Contributor III

Hi Wolfgang,

thanks for your answer. That's the same way we use to get the reboot work. Luckily we already intended this in the PCB layout with a unequipped bridge. In the next version we will insert this bridge.

But in my opinion it is a software issue of the imx8m mini package. Because uboot can do the reset without the POR_B signal and the imx8m nano also in uboot AND linux.

We tested this with the 4.14.98 and 5.4.47 version. In both the same "problem". This just as information for anybody else who reads this thread.

If anybody finds the software bug feel free to post her, because we are still interested in the correct solution.

 

Best regards

Cedric

6,741 Views
siva_prabhakara
Contributor III

@cedric_starke i also bumped to the same issue on imx8mm(5.4 kernel), were you or anyone able to identify the software issue here?

0 Kudos
Reply

5,988 Views
DefieldsJ
Contributor I

@siva_prabhakara Did you ever find a firmware solution to the issue?

0 Kudos
Reply

2,992 Views
timharvey
Contributor IV

I recently ran into this and found it related to PSCI cpu-idle. If you disable CONFIG_ARM_PSCI_CPUIDLE, or boot with cpuidle.off=1 which disables cpuidle in general I found the system warm resetting as expected. I'm not sure what causes this however.

0 Kudos
Reply

6,730 Views
cedric_starke
Contributor III

Hi Siva,

just like with Wolfgang. After we "fixed", or let me say optimized, the hardware we didn't investigate any more time to this issue. We still use the kernel 5.4.47. Meanwhile a newer version is available. Maybe there is a fix included. But honestly, I wouldn't expect it.

 

If you find any software fix the solution is still interesting.

 

Best regards

Cedric

0 Kudos
Reply

7,393 Views
cedric_starke
Contributor III

Hello @wolfgang_baer ,

I know, the issue is not really new, but we have the same problem with our imx8m mini and I just want to ask for your solution of this problem?

We additionally figured out that this just happens with the imx8m mini. We use the same PCB for the imx8m nano and this SOC is able to reboot correctly.

So, if you can share your last state with us we would be grateful.

 

Best regards

Cedric

0 Kudos
Reply

7,596 Views
Yuri
NXP Employee
NXP Employee

Hello,

  Let me look at the schematic. I will create request for it. 

Regards,

Yuri.

0 Kudos
Reply