RESET_REQ_B signal not asserted on T4240 when 'reboot' command issued from Linux

[alexey_talalush]

Hello,

I have a custom board based on T4240 and when 'reboot' cmd issued from linux console, the cpu hangs after messages:

The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL tosd 1:0:0:0: [sdb] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Synchronizing SCSI cache
reboot: Restarting system
System Halted, OK to turn off power

At this stage I expect that RESET_REQ_B signal to be asserted as described in https://community.nxp.com/t5/T-Series/T4160RDB-hang-issue/m-p/904910#M3112 and hardware can do a reset.

However RESET_REQ_B level remains the same.

Also, tried manualy to set RESET_REQ in DCFG_CCSR_RSTCR register with devmem, but it also had no effect.

Is there any additional condition for assertion of RESET_REQ_B?

[alexey_talalush]

Hi ufedor,

Thank you for a quick response. I've attached schematic with reset pins connection.

We probed signal with saleae logic analyzer and with 2 boards tested both were failed.

I confirm RESET_REQ_B is not low during POR.

Also RESET_REQ_B asserted when POR_RESET_B or HRESET_B asserted instead of 'reboot' linux cmd.

[ufedor]

> RESET_REQ_B asserted when POR_RESET_B or HRESET_B asserted instead of 'reboot' linux cmd.

What exactly does it mean?

Provide "real" PDF - not a picture - showing the RESET_REQ_B connection.

[alexey_talalush]

> What exactly does it mean?
I mean, I see RESET_REQ_B is asserted during POR (before linux starting), then when linux is running the signal is low.
Then if I assert PORESET_B, RESET_REQ_B signal will be asserted by CPU also. But if 'reboot' cmd issued there is no RESET_REQ_B assertion.

[ufedor]

You write:

> I see RESET_REQ_B is asserted during POR

This definitely is an ubnormal situation and it is required to determine cause of the RESET_REQ_B assertion. Further issue investigation will be possible only after that. 

[alexey_talalush]

Loks like I was wrong about RESET_REQ_B level when it is asserted. Should it be low?

I see RESET_REQ_B is low and  RSTRQSR1[SRDS_RST_RR] is set, so it looks like the board is already requesting to be resetted.

Will proceed with investigation of the reason of SRDS_RST_RR. Will be appreciated if you share your ideas where should i look at first?

Also shouldn't RSTRQSR1[SW_RR] (Software settable reset requested) be also set after 'reboot' cmd?

[ufedor · Accepted solution]

> Loks like I was wrong about RESET_REQ_B level when it is asserted. Should it be low?

It should be low.

RESET_REQ_B can be asserted in case of incorrect RCW.

Also there could be other reasons - please refer to the QorIQ T4240 Reference Manual, 27.3.17 Reset Request Status Register (DCFG_CCSR_RSTRQSR1).

[alexey_talalush]

@ufedor , you was right, this issue was due to incorrect RCW. There are some unused Serdes PLLs in board design, I've disabled them in RCW[SRDS_PLL_PD_Sx] and RESET_REQ_B goes high.

Now 'reboot' command makes RESET_REQ_B to go low and I can do board reset by external logic.

Thank you for support and ++Kudos to you

[ufedor]

Similar issue never was reported by other customers.

Please provide the processor connection schematics as PDF for inspection and explain how RESET_REQ_B is probed.

How many boards were tested and how many failed?

Ensure that RESET_REQ_B is not low during POR.