Forum Discussion

GGeor25's avatar
GGeor25
Icon for New Contributor rankNew Contributor
6 years ago

Why Cyclon V Reset manager status register always read 0?

Hello,

In our project we have u-boot v2018.11. I have been requested to write a functionality related to reset reason. Following the already implemented functionality mainly in iMX devices I wrote similar function. And read values from the register is always 0! Why? This is my code:

static struct socfpga_reset_manager *reset_manager_base =

(struct socfpga_reset_manager *)SOCFPGA_RSTMGR_ADDRESS;

u32 cause;

cause = readl(&reset_manager_base->status) & 0xFFFFF;

I thought it could be related to incorrect access to the register. In Cyclon V HPS TRM is written:

Important:To prevent indeterminate system behavior, reserved areas of memory must not be accessed bysoftware or hardware. Any area of the memory map that is not explicitly defined as a registerspace or accessible memory is considered reserved

And in this status register has some reserved bit fields.

Any suggestions?

5 Replies

  • AnilErinch_A_Intel's avatar
    AnilErinch_A_Intel
    Icon for Frequent Contributor rankFrequent Contributor
    6 years ago

    Hi,

    Can you try the code snippet below and let us know the results

    static const struct socfpga_reset_manager *reset_manager_base = (void *)SOCFPGA_RSTMGR_ADDRESS;

    int cause;

    cause = readl(&reset_manager_base->status) &0xFFFFFFFF;

    Regards

    Anil

    • GGeor25's avatar
      GGeor25
      Icon for New Contributor rankNew Contributor
      6 years ago

      Hi,

      No, it is not working. I will try some assembly routine tomorrow using tst instructions. I still think it is due to incorrect access or this is done after some code relocation and read a wrong place...

      By the way what is the difference between your code and mine? I see in all cases always 0.

  • AnilErinch_A_Intel's avatar
    AnilErinch_A_Intel
    Icon for Frequent Contributor rankFrequent Contributor
    6 years ago

    Hi

    Please let us know whether you are using a custom board

    also in the socfpga.dtsi file which you are using whether a cell similar to this is present

    rst: rstmgr@ffd05000 {

    #reset-cells = <1>;

    compatible = "altr,rst-mgr";

    reg = <0xffd05000 0x1000>;

    altr,modrst-offset = <0x10>;

    };

    if yes what is the address mentioned in the cell , is it same like ffd05000 or some thing else.

    Also having reserved bits in a register doesn't mean that you cannot read the register. It means that you cannot change those bits or use it for some custom functionality.

    Regards

    Anil

    • GGeor25's avatar
      GGeor25
      Icon for New Contributor rankNew Contributor
      6 years ago

      Hi Anil,

      Before answering your question, one small update. We have SPL enabled and I moved my code in the very beginning of board_init_f:

      @@ -306,6 +310,7 @@ void board_init_f(ulong dummy)
         * First C code to run. Clear fake OCRAM ECC first as SBE
         * and DBE might triggered during power on
         */
+        reset_cause = readl(&reset_manager_base->status);
        reg = readl(&sysmgr_regs->eccgrp_ocram);
        if (reg & SYSMGR_ECC_OCRAM_SERR)
                writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
@@ -316,6 +321,7 @@ void board_init_f(ulong dummy)

      And I am displaying it later when SPL partition index is printed.

      Yes, the board is our design.

      The cell in socfpga.dtsi is similar. Our missing "altr,modrst-offset = <0x10>;" and I added it just in case. The address is the same.

      --- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -754,6 +754,7 @@
                       #reset-cells = <1>;
                       compatible = "altr,rst-mgr";
                       reg = <0xffd05000 0x1000>;
+                      altr,modrst-offset = <0x10>;
               };

      I also added in some desperate move in our dtsi the next:

      --- a/arch/arm/dts/socfpga_cyclone5.dtsi
+++ b/arch/arm/dts/socfpga_cyclone5.dtsi
@@ -28,6 +28,10 @@
                       smplsel = <0>;
               };
+              rstmgr@ffd05000 {
+                      status = <0xffd05000>;
+              };
+

      But without success.

      Cordially

      Georgi

      P.S. Do you know how to make warm reset from u-boot. I found one thread here before one year, and the person was complaining the same as me with not custom board. But at least he had warm reset bit read.

  • AnilErinch_A_Intel's avatar
    AnilErinch_A_Intel
    Icon for Frequent Contributor rankFrequent Contributor
    6 years ago

    Hi Georgi,

    It turns out as follows

    The BootROM reads the reset manager stat register, then clears it. This is why when you read it is always zero.

    However, the BootROM keeps a copy into an internal data structure, and passes a pointer to that data structure to the Preloader (typically U-Boot SPL) in register r0.

    Then the Preloader can read the value from r0 + 0x38.

    See the following excerpts from

    https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-v/cv_54001.pdf

    Slave Interface and Status Register

    The reset manager slave interface is used to control and monitor the reset states.

    The status register (stat) in the reset manager contains the status of the reset requester. The register

    contains a bit for each monitored reset request. The stat register captures all reset requests that have

    occurred. Software is responsible for clearing the bits.

    During the boot process, the Boot ROM copies the stat register value into memory before clearing it.

    After booting, you can read the value of the reset status register at memory address (r0 + 0x0038). For

    more information, refer to the "Shared Memory" section of the Booting and Configuration appendix.

    Shared Memory

    The shared memory contains information that the boot ROM code passes to the preloader. The boot ROM

    code passes the location of shared memory to the preloader in register r0, as described in the HPS State on

    Entry to Preloader section.

    The shared memory holds the last value of the stat register in the Reset Manager Module and a version

    number that is passed by the boot ROM. The value of the stat register in shared memory is only valid if

    the version number passed by the boot ROM is 0x00000000. The table below shows where the stat

    register value and version number reside in the shared memory as an offset from the address stored in

    register r0.

    So you would need to save it from initialization of SPL from offset 0x38 added to register r0 as it is passed by BootROM

    Regards

    Anil