HW reboot problem on DM8168

Hi Omar,

Omar Pighi17 said:

The system is shutting down and we see the RSTOUTn signal going low (byt hte way wehre are the timings of this signal, i could not find it on data sheet or ref manual),

Refer to the DM816x datasheet (SPRS614F – MARCH 2011 – REVISED MARCH 2015), section 8.2.17 Reset Electrical Data and Timing

You have to check the HW design of the power supply of the failing boards. Refer to DM816x datasheet, DM816x Silicon errata, DM816x TI EVM schematics.

Regards,
Pavel

Hi I checked those issue, thanks.

But I have some more important information, that can be important to understand what is going on.

1) First the boards that have this problem are a part of a bigger round of production, and only few of them have it.

So my first idea was: sowm HW issue, but:

2) I stopped the boot at the uboot prompt than i issue the "reset" command from the uboot consolle, and It works, the system reboot normally.

At this point i investigated how uboot perform the Reset command and how linux does its reboot command:

from uboot source code  (file board/ti/ti8168/evm.c)

/* Reset the board */
void reset_cpu (ulong addr)
{
    addr = __raw_readl(PRM_DEVICE_RSTCTRL);
    addr &= ~BIT(1);
    addr |= BIT(1);
    __raw_writel(addr, PRM_DEVICE_RSTCTRL);
}

so it set the COLD_RESET bit in the PRM_DEVICE_RSTCTRL register

from linux kernel source code (file arch/arm/mach-omap2/prcm.c )

void omap_prcm_arch_reset(char mode, const char *cmd)
{
    s16 prcm_offs = 0;

    if (cpu_is_omap24xx()) {
        omap2xxx_clk_prepare_for_reboot();

        prcm_offs = WKUP_MOD;
    } else if (cpu_is_omap34xx()) {
        prcm_offs = OMAP3430_GR_MOD;
        omap3_ctrl_write_boot_mode((cmd ? (u8)*cmd : 0));
    } else if (cpu_is_omap44xx()) {
        omap4_prm_global_warm_sw_reset(); /* never returns */
    } else if (cpu_is_ti81xx()) {
        omap2_prm_set_mod_reg_bits(TI81XX_GLOBAL_RST_COLD, prcm_offs,
                        TI81XX_PRM_DEVICE_RSTCTRL);
    } else {
        WARN_ON(1);
    }

    /*
     * As per Errata i520, in some cases, user will not be able to
     * access DDR memory after warm-reset.
     * This situation occurs while the warm-reset happens during a read
     * access to DDR memory. In that particular condition, DDR memory
     * does not respond to a corrupted read command due to the warm
     * reset occurrence but SDRC is waiting for read completion.
     * SDRC is not sensitive to the warm reset, but the interconnect is
     * reset on the fly, thus causing a misalignment between SDRC logic,
     * interconnect logic and DDR memory state.
     * WORKAROUND:
     * Steps to perform before a Warm reset is trigged:
     * 1. enable self-refresh on idle request
     * 2. put SDRC in idle
     * 3. wait until SDRC goes to idle
     * 4. generate SW reset (Global SW reset)
     *
     * Steps to be performed after warm reset occurs (in bootloader):
     * if HW warm reset is the source, apply below steps before any
     * accesses to SDRAM:
     * 1. Reset SMS and SDRC and wait till reset is complete
     * 2. Re-initialize SMS, SDRC and memory
     *
     * NOTE: Above work around is required only if arch reset is implemented
     * using Global SW reset(GLOBAL_SW_RST). DPLL3 reset does not need
     * the WA since it resets SDRC as well as part of cold reset.
     */

    /* XXX should be moved to some OMAP2/3 specific code */
    omap2_prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs,
                   OMAP2_RM_RSTCTRL);
    omap2_prm_read_mod_reg(prcm_offs, OMAP2_RM_RSTCTRL); /* OCP barrier */
}

this means (i checked that we pass in the right else if item)

  omap2_prm_set_mod_reg_bits(TI81XX_GLOBAL_RST_COLD, prcm_offs, TI81XX_PRM_DEVICE_RSTCTRL);

does the same set the COLD_RESET bit in TI81XX_PRM_DEVICE_RSTCTRL

3) these test tell me that it is not an hardware issue... well not completely hardware at least. uboot works but linux doesn't. The reboot reach the final phase (infact i see the RESETOUT signal going low then high)..

BUT WHY THE LINUX REBOOT DOESN'T go ahead?....

Omar

Omar,

Omar Pighi17 said:

3) these test tell me that it is not an hardware issue...

Then how it is possible this SW to work fine on the TI EVM and on some of your boards but failed on some of your other boards?

What is the silicon revision (PG) of your failing boards? Is it the same as the working boards?

You can also try with the latest version of the linux kernel available at:

Regards,
Pavel

The silicon revision should be the same but i will double check.
but the strange is why if i set the COLD reset bit in the uboot it works , if i do the same in linux it doesn't....
at the lower level it is always a bit set in a register....

Omar

the bootmode pin are shared with GPMC (A1 to A5) and in uboot ,of course, the GPMC is not yet configured, but it is in our Linux setup... could be someway related ?
I mean maybe those pin are held in some status that overcome the pullup, pulldown resistors...
So the processor is booting but in the wrong mode.... (on wrong media : we use NAND boot 10011)

Omar

Omar Pighi17 said:

the bootmode pin are shared with GPMC (A1 to A5) and in uboot ,of course, the GPMC is not yet configured, but it is in our Linux setup... could be someway related ?
I mean maybe those pin are held in some status that overcome the pullup, pulldown resistors...
So the processor is booting but in the wrong mode.... (on wrong media : we use NAND boot 10011)

Can you try with MMC/SD boot?

Regards,
Pavel

can be an idea to use stronger pull up and pull on btmode pin?
Ore make the reset time longer (with PRM_RSTTIME register)...
Omar

Omar,

Omar Pighi17 said:

can be an idea to use stronger pull up and pull on btmode pin?

Yes, you can try that. See DM816x datasheet, 6.3.1 Pullup and Pulldown Resistors

Omar Pighi17 said:

Ore make the reset time longer (with PRM_RSTTIME register)...

I do not think you can control the Global Cold SW reset signal duration through the PRM_RSTTIME register. Where you found that piece of info?

Regards,
Pavel

Pavel Botev said:

Omar,

Omar Pighi17

can be an idea to use stronger pull up and pull on btmode pin?

Yes, you can try that. See DM816x datasheet, 6.3.1 Pullup and Pulldown Resistors

Omar Pighi17

Ore make the reset time longer (with PRM_RSTTIME register)...

I do not think you can control the Global Cold SW reset signal duration through the PRM_RSTTIME register. Where you found that piece of info?

Was just An idea... maybe that time setting could also have some influence on reset

Regards,
Pavel

A little resume:

1) with uboot "reset" command the board reset fine.

2) with linux "reboot" it doesn't ; but i reach the function where the bit COLD reset is set, And i see the reset_out_n signal going low and up (after more or less 1 msec), 

3) what i noticed is that the GPIO doesn't go to the default input state, they stay at the last value (if they were an output they keep the level...) so it seems that the internal reset procedure just doesn't end

I think this point (numer 3) is VERY IMPORTANT to understand what is going on.... 

What do you think Pavel?

Omar

Omar,

Actually you can try with PRM_RSTTIME[7:0] RSTTIME1 bits. May be you can increase the reset duration of the Cold reset with this bitfield.

Are you using EZSDK or DVR RDK or pure PSP? May be you can try with PSP + arago FS (minimal linux configuration).

Can you provide me the console output when you launch the "reboot" command?

Regards,
Pavel

See also if the below e2e threads will be in help:

e2e.ti.com/.../360513

e2e.ti.com/.../242515

Regards,
Pavel

I already tried to rise the timing at the maximum permitted value, but nothing change.
I will try to do the test you suggested me.

Omar

Reading the second thread, this sound interesting to me..

""""""""""""""""""""""""""
The PRCM must stall the release of the global power-on reset until after de-assertion of all cold reset sources and until after receiving indication that the voltage domains, have all ramped to their operating levels and until after receiving an indication that the system clock is running and is stable. The PRCM implements a counter after all of these indications have occurred to provide a delay before releasing internal global power on reset signals. This requires use of a PM FW Reset Manager. The "always-on" 27 MHz clock must run the RM's stall-period timer. The max count is provided by PRM register PRM_RSTTIME.RSTTIME1 bit-field. During device power-up, this mechanism enforces the system requirement of a running 27 MHz clock.
""""""""""""""""""""""""""

The words "must stall" could means that in some situation it could Hang?

Can you please clarify to me the condition required for a correct restart (releasse from PRCM of the POR...)...

Omar

Omar Pighi17 said:

""""""""""""""""""""""""""
The PRCM must stall the release of the global power-on reset until after de-assertion of all cold reset sources and until after receiving indication that the voltage domains, have all ramped to their operating levels and until after receiving an indication that the system clock is running and is stable. The PRCM implements a counter after all of these indications have occurred to provide a delay before releasing internal global power on reset signals. This requires use of a PM FW Reset Manager. The "always-on" 27 MHz clock must run the RM's stall-period timer. The max count is provided by PRM register PRM_RSTTIME.RSTTIME1 bit-field. During device power-up, this mechanism enforces the system requirement of a running 27 MHz clock.
""""""""""""""""""""""""""

Omar Pighi17 said:

The words "must stall" could means that in some situation it could Hang?

No, I do not think this TRM quote (see section 18.5.3) means that. I think it means that the reset timing requirements and sequence should be met.

Omar Pighi17 said:

Can you please clarify to me the condition required for a correct restart (releasse from PRCM of the POR...)...

This is described in the DM816x documentation (TRM, datasheet, silicon errata).

Regards,
Pavel

well.. it is really not clear what the PRCM module reference manual means...
i.e.: What does it means?

The software must ensure the SDRAM is properly put in sef-refresh mode before applying this reset.

What have i to do before set the cold reset bit? the linux cpu_reset function does it?
what could happen if i don't?

Omar

I think the linux kernel should handle the cold reset properly, with no need of specific modifications of the linux kernel code.

Regards,
Pavel