• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 99 subscribers
  • Views 1975 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3517: PRM_RSTST register showing wrong value

Börje Sewing
Prodigy 150 points
Part Number: AM3517

Hi,

after a software reset the PRM_RSTST register (physical address 0x48307258) of an AM3517 (customer specific board) is showing a wrong value:

0x00000001

instead of

0x00000002

If the reset is triggered by watchdog, the value in the register is

0x00000011

which is in my understanding correct.

It doens't matter if i try to read the register value from bootloader or linux userspace (devmem 0x48307258). 

Do you have an idea what can cause the wrong value?

Thanks and Best Regards,

Börje Sewing

  • 0
    TI__Guru**** 393215 points
    Hi,

    How are you triggering the SW reset?
  • 0 in reply to Biser Gatchev-XID
    TI__Guru**** 393215 points
    And another question: Have you checked that SW reset doesn't actually cause a hardware cold reset on your board?
  • 0 in reply to Biser Gatchev-XID
    Prodigy 150 points
    Hi Biser,

    i've asked the hardware guys: sw reset doesn't cause a hw cold reser on our board.
    The sw reset is triggered by the linux userspace command /sbin/reboot.

    Best Regards,
    Börje
  • 0
    TI__Guru 65405 points
    Hi Boerje,

    I confirm the PRM_RSTST register has value 0x00000001 after software reboot by "reboot" console command.
    The issue will be additionally investigated.

    BR
    Tsvetolin Shulev
  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 150 points

    Hi Tsvetolin,

    thanks for further investigating this issue. Do you already have a clue what the problem could be?

    Best Regards,

    Börje Sewing

  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 150 points
    Hi,

    anything new on this issue?

    Best Regards,
    Börje Sewing
  • 0
    TI__Guru 65405 points
    Hi Börje,

    I'm sorry for the long delay.
    I performed some test with the PRM_RSTST register focused on software reset and I observe expected results:
    After power on PRM_RSTST register has value 0x00000001.
    After a global software reset (which is triggered by writing 1 to RST_GS field of PRM_RSTCTRL register) PRM_RSTST register has value 0x00000002.
    Could you make the same tests and share the results?

    BR
    Tsvetolin Shulev
  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 150 points
    Hi Tsvetolin,

    same on my machine: warm reset triggered by
    devmem 0x48307250 8 0x2
    results in PRM_RSTST register value 0x00000002.
    Reset triggered by "reboot" console command results in PRM_RSTST register value 0x00000001.

    Think i have to investigate what's going wrong with linux reboot code on AM35XX platform. Your help would be highly appreciated.

    Best Regards,
    Börje Sewing
  • 0 in reply to Börje Sewing
    Prodigy 150 points

    Hi Tsvetolin,

    it turns out that all am3xxx compatible SoCs (except the am33xx) are resetted by writing the DPLL3 bit (RST_DPLL3 in PRM_RSTCTRL register) -
    considering Errata i520. For the am35xx this causes the PRM_RSTST register to be set to cold start if reset is triggered by "reboot" console command.

    arch/arm/mach-omap2/prm3xxx.c
    133 /**
    134 * omap3xxx_prm_dpll3_reset - use DPLL3 reset to reboot the OMAP SoC
    135 *
    136 * Set the DPLL3 reset bit, which should reboot the SoC. This is the
    137 * recommended way to restart the SoC, considering Errata i520. No
    138 * return value.
    139 */
    140 static void omap3xxx_prm_dpll3_reset(void)
    141 {
    142 omap2_prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, OMAP3430_GR_MOD,
    143 OMAP2_RM_RSTCTRL);
    144 /* OCP barrier */
    145 omap2_prm_read_mod_reg(OMAP3430_GR_MOD, OMAP2_RM_RSTCTRL);
    146 }

    Further information: patchwork.kernel.org/.../

    Where could i find more details about errata i520?

    Best Regards,
    Börje Sewing

  • 0 in reply to Börje Sewing
    TI__Guru 65405 points
    The workaround described in the linked patch is useful but unfortunately I have no additional information about errata i520.

    BR
    Tsvetolin Shulev
  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 150 points

    Hi Tsvetolin,

    i can't find errata i520 in any document. And i can't find something similar in the AM35XX errata document.

    The cited patch is intended for the entire am3xxx family, but irritatingly, the am33xx is unaffected by this bug. It has it's own reboot code.

    Now i am curious if the am35xx family is unaffected either?

    Best Regards,

    Börje Sewing

  • 0 in reply to Börje Sewing
    TI__Guru* 86180 points
    Borje,
    there is an issue with warm reset on the AM35x that is described in Advisory 1.1.22 in the AM35x errata

    The intended operation of a warm reset is when it is initiated, the EMIF puts the DDR into self-refresh, and then upon completion of the warm reset, the EMIF should not have to be re-configured (just an exit from self-refresh is necessary)

    However, as the errata describes, the EMIF contents are not maintained, so a full re-initialization of the EMIF is necessary on each warm reset. Essentially, this renders a warm reset inoperable, and thus, there really is no difference between warm and cold reset. So the linux patch just maps a 'reboot' command to a cold reset

    i520 errata actually refers to a different errata (you can see text of this errata in a similar device, Advisory 1.51 in AM37x errata), however the workaround is the same, essentially eliminating the difference between a warm and cold reset.

    Regards,
    James