Android reboot hangs up when SPI NOR is boot device

[aabitria]

I have a product based on Sabresd board and has iMX6Q.  It boots from SPI-NOR and its OS and other SW are in eMMC.  Using Mfg Tool I can flash the U-Boot to SPI and other binaries to eMMC, and the U-boot, Kernel, and Android system can boot up successfully.

The problem is that when I try to reboot the Android OS via the "reboot" command in the serial connection, my device hangs after the reset. U-Boot does not start. If I save the u-boot in eMMC together with the rest of the binaries, I am able to successfully reboot.

How come this is happening?  There is no question that the U-Boot is built correctly and indeed working.  The U-Boot launches from SPI-NOR upon power up so I figured it was working correctly. It is only when I perform a reboot command that it does not launch.

I also looked at the WDOG_B line together with PWRON line, since its WDOG_B circuitry to PMIC is essentially the same as that in Sabresd board.  The WDOG_B indeed triggers and the PWRON line dips as expected as a result of the reboot command, but it doesn't still reboot.  The same WDOG_B behavior is also observed when rebooting from eMMC but this one successfully reboots.

How come this reboot failure happens only when booting from SPI-NOR?

[aabitria]

So far, using an oscilloscope, I've observed that during reboot, the SPI bus clk of the SPI NOR device has some clock cycles.  However, I compared it to the normal boot.  In the normal boot, SPI lines become really busy and has lots of activity some 20ms after POR is deasserted.  During reboot, it seems there are only very limited SPI clock cycles to the SPINOR boot device and nothing else.  As if the imx6 and the spinor stopped communicating.

Any idea on this?

[igorpadykov]

one can also check if spi-nor in reset condition during reboot, some parts have RST signal.

Best regards
igor

[aabitria]

Unfortunately, the spinor chip we're using has no reset pin.

I tried to do an experiment in Linux, which is to reset the imx6 without triggering POR in the PMIC.  I've tried to reboot imx6 cpu via watchdog timeout, in the same way that the reset command in u-boot is working. Let the wdog timer expire, and you'll get a cpu reset. We know it's working, despite of SPINOR. And we know that since it's just CPU WDOG reset, the power supply is not being reset as well, so the power to the SPINOR is steady. Our suspect is that the lack of reset after power reset to the SPINOR messes it up, and so the reboot in android messes up as well. So I tried to bypass that.  If we do this in Linux, SPINOR wouldn't encounter power dips and so we should be able to reboot.

So I did that to Android Linux, I edited the imx2_wdt_restart in imx2_wdt.c. The edits are to set the WT bits in WCR to zero for minimum timeout (0.5s), leave WDA and SRS bits as 1 to deassert them. I also edited the dtsi to use WDOG1 instead of WDOG2, meaning the WDOG_B line we were using, since it's not connected to WDOG1, should never assert. Add to that I've cleared the WDA bit here.

unsigned int wcr_enable = IMX2_WDT_WCR_WDE;

wcr_enable |= IMX2_WDT_WCR_SRS; /* do not assert int reset */
wcr_enable |= IMX2_WDT_WCR_WDA; /* do not assert ext-reset */
regmap_write(wdev->regmap, IMX2_WDT_WCR, wcr_enable);
if (imx2_wdt_is_running(wdev))
    imx2_wdt_ping(wdog);

The watchdog indeed timed out (since all printks after imx2_wdt_ping never took place) but it didn't reboot like in u-boot's reset command. Reboot still failed.  I checked the waveform to the SPINOR during this time, checking its SPI CLK signal, but there are just very few of them, as if the imx6 stopped communicating with spinor. We are sure we didn't POR'ed the power to the SPINOR.

I checked the oscope waveform in the correct reset case which is U-boot's reset and it showed the imx6 neatly provided a lot lot lot more SPI clock cycles to the SPINOR.

So, is it still the SPINOR that has problem here?

[igorpadykov]

so had you checked with jtag debugger registers SRC_SBMR1,2 ?

Settings should have correct spi-nor boot configuration.

Resetting the imx6 without triggering POR in the PMIC is not reliable, it is known issue.

Also just for test during reset one can manually prolong POR in the PMIC, PWRON

signal on p.21 on spf-27392 i.MX6Q SabreSD schematic, this will allow to fully discharge

all board capacitors:

https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/sabre-board-for...

Best regards
igor

[aabitria]

Hello igor,

I also want to prolong the POR signal by capacitor value, however, my client wants a software solution as some units are on the field already.  Is it possible to prolong POR in software?

As for checking the SBMR registers, unfortunately I don't have a JTAG.  Will J-Link work?

[igorpadykov]

Hi aabitria

> Is it possible to prolong POR in software?

not sorry.

>Will J-Link work

if it is Segger J-Link Debug Probe , then yes.

Best regards
igor

[igorpadykov]

Hi aabitria

to narrow down possible reason of failure one can try:

- after hang check with jtag debugger registers SRC_SBMR1,2 described in sect.60.7.2 RM

if they have correct boot mode settings

i.MX 6Dual/6Quad Applications Processor Reference Manual

- check with oscilloscope board power supplies when PWRON line dips, they should be discharged

so processor should behave as in initial powering on supply event.

Best regards
igor