arm: socfpga: dm: Fix DM initialization failure after warm reset

PATCH New Jian Luo 3 participants 33 messages Aug 28, 2015 – Sep 22, 2015

Subsystems (3)

Arm (32-bit) Arm sub-architectures Arm/socfpga architecture

lore

Share & tools

lore

Jian Luo

author

2015-08-28 08:41 UTC #0 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.

Signed-off-by Jian Luo <[email protected]>

---
  arch/arm/mach-socfpga/spl.c | 6 ++++++
  1 file changed, 6 insertions(+)

arch/arm/mach-socfpga/spl.c +6 -0

index 13ec24b..59fe1f2 100644
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
         /* Configure simple malloc base pointer into RAM. */
         gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
+       /*
+        * gd->dm_root might contain non-zero value after warm reset.
+        * Clear it to avoid dm_init error
+        */
+       gd->dm_root = NULL;
+
         board_init_r(NULL, 0);
  }

Signature · 1 line

1.9.1

Marek Vasut

2015-08-28 09:24 UTC #1 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 4 lines · Jian Luo

gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.
Signed-off-by Jian Luo <[email protected]>

Hi!

Quoted 9 lines

---
  arch/arm/mach-socfpga/spl.c | 6 ++++++
  1 file changed, 6 insertions(+)

arch/arm/mach-socfpga/spl.c +0 -0

index 13ec24b..59fe1f2 100644

arch/arm/mach-socfpga/spl.c void board_init_f(ulong dummy) · line 188

Quoted 8 lines

arch/arm/mach-socfpga/spl.c +5 -0

@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
         /* Configure simple malloc base pointer into RAM. */
         gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
+       /*
+        * gd->dm_root might contain non-zero value after warm reset.
+        * Clear it to avoid dm_init error
+        */
+       gd->dm_root = NULL;

Nit: The indent should be done with tabs, not spaces. I think the email got messed up somewhere along the way.

The bigger concern I have is that if you look into arch/arm/lib/crt0.S , you will see that the entire global data are cleared there (_main, label
clr_gd: ) and this code is executed before the board_init_f() .

Can you try tracking it down a bit more? I suspect that you might see dm_init_and_scan() returned error -22 , is that what you observe please?

arch/arm/mach-socfpga/spl.c void board_init_f(ulong dummy) · line 191

Quoted 2 lines

arch/arm/mach-socfpga/spl.c +0 -0
         board_init_r(NULL, 0);
  }

Best regards,
Marek Vasut

Jian Luo

author

2015-08-28 10:27 UTC #2 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi Marek,

Quoted 19 lines · Marek Vasut

Quoted 4 lines · Jian Luo
gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.
Signed-off-by Jian Luo <[email protected]>
Hi!
Quoted 12 lines
---
   arch/arm/mach-socfpga/spl.c | 6 ++++++
   1 file changed, 6 insertions(+)
arch/arm/mach-socfpga/spl.c +0 -0
index 13ec24b..59fe1f2 100644
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
          /* Configure simple malloc base pointer into RAM. */
          gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 

Quoted 7 lines

arch/arm/mach-socfpga/spl.c void board_init_f(ulong dummy) · line 188
Quoted 5 lines
arch/arm/mach-socfpga/spl.c +5 -0
+       /*
+        * gd->dm_root might contain non-zero value after warm reset.
+        * Clear it to avoid dm_init error
+        */
+       gd->dm_root = NULL;
Nit: The indent should be done with tabs, not spaces. I think the email got messed up somewhere along the way.

Yes, sorry. I can't setup git send-email in our company network. Thunderbird messed the indent up.

Quoted 3 lines

The bigger concern I have is that if you look into arch/arm/lib/crt0.S , you will see that the entire global data are cleared there (_main, label
clr_gd: ) and this code is executed before the board_init_f() .

This was my first assumption, it should be cleared in crt0.S. I was using U-Boot to load a VxWorks image.
And wrote 1 to rstmgr ctrl in VxWorks to do a warm reset. Afterwards the SPL hangs.

It did not happen if I do reset direct in U-Boot.
I'll attach a JTAG Debug to dig deeper.

Quoted 2 lines

Can you try tracking it down a bit more? I suspect that you might see dm_init_and_scan() returned error -22 , is that what you observe please?

Yes, in dm_init() where gd->dm_root will be checked.

Quoted 5 lines

arch/arm/mach-socfpga/spl.c void board_init_f(ulong dummy) · line 191
Quoted 3 lines
arch/arm/mach-socfpga/spl.c +0 -0
          board_init_r(NULL, 0);
   }
Best regards,
Marek Vasut

Best regards,

Jian Luo

Marek Vasut

2015-08-28 10:30 UTC #3 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 34 lines · Jian Luo

Hi Marek,
Quoted 22 lines · Marek Vasut
Quoted 4 lines · Jian Luo
gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.
Signed-off-by Jian Luo <[email protected]>
Hi!
Quoted 14 lines
---
   arch/arm/mach-socfpga/spl.c | 6 ++++++
   1 file changed, 6 insertions(+)
arch/arm/mach-socfpga/spl.c +0 -0
index 13ec24b..59fe1f2 100644
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
 
          /* Configure simple malloc base pointer into RAM. */
          gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
Quoted 8 lines
arch/arm/mach-socfpga/spl.c void board_init_f(ulong dummy) · line 188
Quoted 5 lines
arch/arm/mach-socfpga/spl.c +5 -0
+       /*
+        * gd->dm_root might contain non-zero value after warm reset.
+        * Clear it to avoid dm_init error
+        */
+       gd->dm_root = NULL;
Nit: The indent should be done with tabs, not spaces. I think the email got messed up somewhere along the way.

Quoted 2 lines

Yes, sorry. I can't setup git send-email in our company network. Thunderbird messed the indent up.

Why not ?

Quoted 8 lines

Quoted 3 lines
The bigger concern I have is that if you look into arch/arm/lib/crt0.S , you will see that the entire global data are cleared there (_main, label
clr_gd: ) and this code is executed before the board_init_f() .
This was my first assumption, it should be cleared in crt0.S. I was using U-Boot to load a VxWorks image.
And wrote 1 to rstmgr ctrl in VxWorks to do a warm reset. Afterwards the SPL hangs.

Hangs in which way ? Can you share the output please ?

Quoted 2 lines

It did not happen if I do reset direct in U-Boot.
I'll attach a JTAG Debug to dig deeper.

Neat, that'd be really awesome, thanks for looking into this !

Quoted 4 lines

Quoted 2 lines
Can you try tracking it down a bit more? I suspect that you might see dm_init_and_scan() returned error -22 , is that what you observe please?
Yes, in dm_init() where gd->dm_root will be checked.

But if you get -ENOMEM, that means somehow the malloc is broken here. I wonder if this explicit setting of gd->malloc_area is screwing something up ?

Best regards,
Marek Vasut

Jian Luo

author

2015-08-28 11:40 UTC #4 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 32 lines · Marek Vasut

Quoted 31 lines · Jian Luo
Hi Marek,
Quoted 28 lines · Marek Vasut
Quoted 4 lines · Jian Luo
gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.
Signed-off-by Jian Luo <[email protected]>
Hi!
Quoted 10 lines
---
    arch/arm/mach-socfpga/spl.c | 6 ++++++
    1 file changed, 6 insertions(+)
arch/arm/mach-socfpga/spl.c +0 -0
index 13ec24b..59fe1f2 100644
arch/arm/mach-socfpga/spl.c void board_init_f(ulong dummy) · line 189
Quoted 9 lines
arch/arm/mach-socfpga/spl.c +5 -0
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
 
           /* Configure simple malloc base pointer into RAM. */
           gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
+       /*
+        * gd->dm_root might contain non-zero value after warm reset.
+        * Clear it to avoid dm_init error
+        */
+       gd->dm_root = NULL;
Nit: The indent should be done with tabs, not spaces. I think the email got messed up somewhere along the way.

Quoted 3 lines

Quoted 2 lines
Yes, sorry. I can't setup git send-email in our company network. Thunderbird messed the indent up.
Why not ?

"Security policy". :(

Quoted 9 lines

Quoted 8 lines
Quoted 4 lines
The bigger concern I have is that if you look into arch/arm/lib/crt0.S , you will see that the entire global data are cleared there (_main, label
clr_gd: ) and this code is executed before the board_init_f() .
This was my first assumption, it should be cleared in crt0.S. I was using U-Boot to load a VxWorks image.
And wrote 1 to rstmgr ctrl in VxWorks to do a warm reset. Afterwards the SPL hangs.
Hangs in which way ? Can you share the output please ?

Sorry, should attached the output in the first place. With CONFIG_DM_WARN defined:

*************************
***** VxWorks is up *****
*************************

-> reboot

U-Boot SPL 2015.10-rc2-00192-ge122af6-dirty (Aug 28 2015 - 11:35:27) drivers/ddr/altera/sequencer.c: Preparing to start memory calibration drivers/ddr/altera/sequencer.c: CALIBRATION PASSED drivers/ddr/altera/sequencer.c: Calibration complete Virtual root driver already exists!
### ERROR ### Please RESET the board ###

Quoted 11 lines

Quoted 3 lines
It did not happen if I do reset direct in U-Boot.
I'll attach a JTAG Debug to dig deeper.
Neat, that'd be really awesome, thanks for looking into this !
Quoted 3 lines
Quoted 2 lines
Can you try tracking it down a bit more? I suspect that you might see dm_init_and_scan() returned error -22 , is that what you observe please?
Yes, in dm_init() where gd->dm_root will be checked.
But if you get -ENOMEM, that means somehow the malloc is broken here. I wonder if this explicit setting of gd->malloc_area is screwing something up ?

Isn't 22 EINVAL?
It's in the drivers/core/root.c line 105

Quoted 3 lines

Best regards,
Marek Vasut

Best regards,

Jian Luo
*
*

Marek Vasut

2015-08-28 12:01 UTC #5 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 36 lines · Jian Luo

Quoted 35 lines · Marek Vasut
Quoted 34 lines · Jian Luo
Hi Marek,
Quoted 30 lines · Marek Vasut
Quoted 4 lines · Jian Luo
gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.
Signed-off-by Jian Luo <[email protected]>
Hi!
Quoted 10 lines
---
    arch/arm/mach-socfpga/spl.c | 6 ++++++
    1 file changed, 6 insertions(+)
arch/arm/mach-socfpga/spl.c +0 -0
index 13ec24b..59fe1f2 100644
arch/arm/mach-socfpga/spl.c void board_init_f(ulong dummy) · line 189
Quoted 9 lines
arch/arm/mach-socfpga/spl.c +5 -0
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
 
           /* Configure simple malloc base pointer into RAM. */
           gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
+       /*
+        * gd->dm_root might contain non-zero value after warm reset.
+        * Clear it to avoid dm_init error
+        */
+       gd->dm_root = NULL;
Nit: The indent should be done with tabs, not spaces. I think the email got messed up somewhere along the way.

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
Yes, sorry. I can't setup git send-email in our company network. Thunderbird messed the indent up.
Why not ?
"Security policy". :(

But thunderbird works ? Can't you just copy the SMTP settings from thunderbird into gitconfig ? :)

Quoted 18 lines

Quoted 10 lines
Quoted 8 lines
Quoted 3 lines
The bigger concern I have is that if you look into arch/arm/lib/crt0.S , you will see that the entire global data are cleared there (_main, label clr_gd: ) and this code is executed before the board_init_f() .
This was my first assumption, it should be cleared in crt0.S. I was using U-Boot to load a VxWorks image.
And wrote 1 to rstmgr ctrl in VxWorks to do a warm reset. Afterwards the SPL hangs.
Hangs in which way ? Can you share the output please ?
Sorry, should attached the output in the first place. With CONFIG_DM_WARN defined:
*************************
***** VxWorks is up *****
*************************

Quoted 8 lines

-> reboot
U-Boot SPL 2015.10-rc2-00192-ge122af6-dirty (Aug 28 2015 - 11:35:27) drivers/ddr/altera/sequencer.c: Preparing to start memory calibration drivers/ddr/altera/sequencer.c: CALIBRATION PASSED drivers/ddr/altera/sequencer.c: Calibration complete Virtual root driver already exists!
### ERROR ### Please RESET the board ###

Oh, ew. Now this is _weird_ . Simon, any idea(s) ?

Quoted 9 lines

Quoted 9 lines
Quoted 2 lines
It did not happen if I do reset direct in U-Boot.
I'll attach a JTAG Debug to dig deeper.
Neat, that'd be really awesome, thanks for looking into this !
Quoted 4 lines
Quoted 3 lines
Can you try tracking it down a bit more? I suspect that you might see dm_init_and_scan() returned error -22 , is that what you observe please?

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
Yes, in dm_init() where gd->dm_root will be checked.
But if you get -ENOMEM, that means somehow the malloc is broken here. I wonder if this explicit setting of gd->malloc_area is screwing something up ?
Isn't 22 EINVAL?

Yes it is, sorry.

Quoted 1 line

It's in the drivers/core/root.c line 105

Uhm ... how can this be if GD is zeroed out ?

Jian Luo

author

2015-08-28 12:09 UTC #6 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi Marek,

Quoted 1 line · Marek Vasut

On Friday, August 28, 2015 at 01:40:08 PM, Jian Luo wrote:

----snip----

Quoted 3 lines

Quoted 1 line
"Security policy". :(
But thunderbird works ? Can't you just copy the SMTP settings from

thunderbird

Quoted 1 line

into gitconfig ? :)

I tried w/o success. Might try again another time.

Best regards,

Jian Luo

Marek Vasut

2015-08-28 21:48 UTC #7 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 1 line · Jian Luo

Hi Marek,

Hi,

Quoted 6 lines · Marek Vasut

Quoted 1 line · Jian Luo
----snip----
Quoted 2 lines
Quoted 1 line
"Security policy". :(

Quoted 7 lines

Quoted 1 line
But thunderbird works ? Can't you just copy the SMTP settings from
thunderbird
Quoted 1 line
into gitconfig ? :)
I tried w/o success. Might try again another time.

Try using msmtp and configure your git send-email to send through it (and all your other MUAs too), it's really convenient :)

btw is this a custom board you're porting here ?

Best regards,
Marek Vasut

Jian Luo

author

2015-08-31 13:00 UTC #8 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi,

Quoted 12 lines · Marek Vasut

Quoted 1 line · Jian Luo
Hi Marek,
Hi,
Quoted 8 lines · Marek Vasut
Quoted 1 line · Jian Luo
----snip----
Quoted 3 lines
Quoted 1 line
"Security policy". :(
But thunderbird works ? Can't you just copy the SMTP settings from

Quoted 7 lines

Quoted 5 lines
thunderbird
Quoted 1 line
into gitconfig ? :)
I tried w/o success. Might try again another time.
Try using msmtp and configure your git send-email to send through it (and all your other MUAs too), it's really convenient :)

It works. Thanks. :)

Quoted 2 lines

btw is this a custom board you're porting here ?

Yes, but this particular error can also be reproduced on Altera SoCDK.

It seems to be a compiler and/or configuration error of gcc 4.8 generated by yocto dizzy.
After I switched to gcc 4.9 shiped with Altera Soc EDS 15.0, there is no warm reset error anymore.

Quoted 3 lines

Best regards,
Marek Vasut

Best regards,

Jian Luo

Marek Vasut

2015-08-31 13:28 UTC #9 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 1 line · Jian Luo

Hi,

Hi!

Quoted 16 lines · Marek Vasut

Quoted 15 lines · Jian Luo
Quoted 1 line
Hi Marek,
Hi,
Quoted 10 lines · Marek Vasut
Quoted 1 line · Jian Luo
----snip----
Quoted 3 lines
Quoted 1 line
"Security policy". :(
But thunderbird works ? Can't you just copy the SMTP settings from
thunderbird

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
Quoted 1 line
into gitconfig ? :)
I tried w/o success. Might try again another time.
Try using msmtp and configure your git send-email to send through it (and all your other MUAs too), it's really convenient :)
It works. Thanks. :)

Cool!

Quoted 6 lines

Quoted 1 line
btw is this a custom board you're porting here ?
Yes, but this particular error can also be reproduced on Altera SoCDK.
It seems to be a compiler and/or configuration error of gcc 4.8 generated by yocto dizzy.

Let me guess -- gcc 4.8.2 ?

Quoted 2 lines

After I switched to gcc 4.9 shiped with Altera Soc EDS 15.0, there is no warm reset error anymore.

Nice, thanks for the update :)

Best regards,
Marek Vasut

Jian Luo

author

2015-09-02 16:27 UTC #10 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi!

this error comes again. It isn't a compiler error after all. :(

JTAG inspection shows that the problem is located in arch/arm/mach-socfpga/spl.c line94.
It seems that re-enable ECC on OCRAM can cause some strange value changes in SRAM.
Disabling ECC might also cause value changes, which I didn't test.

On a cold (re)boot sysmgr_regs->eccgrp_ocram is 0x19 (derr|serr|en). So gd keeps intact.

In our VxWorks Image ECC on OCRAM happens to be disabled. After a warm reset sysmgr_regs->eccgrp_ocram is 0x18 (derr|serr). Thus after re-enable ECC, gd->dm_root turns to 0x80 every time.

My solution is keeping SYSMGR_ECC_OCRAM_EN bit untouched. And it works for me.

arch/arm/mach-socfpga/spl.c +8 -6

index 775a827..c858406 100644
@@ -90,12 +90,14 @@ void board_init_f(ulong dummy)
          * and DBE might triggered during power on
          */
         reg = readl(&sysmgr_regs->eccgrp_ocram);
-       if (reg & SYSMGR_ECC_OCRAM_SERR)
-               writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
-                      &sysmgr_regs->eccgrp_ocram);
-       if (reg & SYSMGR_ECC_OCRAM_DERR)
-               writel(SYSMGR_ECC_OCRAM_DERR  | SYSMGR_ECC_OCRAM_EN,
-                      &sysmgr_regs->eccgrp_ocram);
+       if (reg & SYSMGR_ECC_OCRAM_SERR) {
+               reg &= ~SYSMGR_ECC_OCRAM_SERR;
+               writel(reg, &sysmgr_regs->eccgrp_ocram);
+       }
+       if (reg & SYSMGR_ECC_OCRAM_DERR) {
+               reg &= ~SYSMGR_ECC_OCRAM_DERR;
+               writel(reg, &sysmgr_regs->eccgrp_ocram);
+       }
 
         memset(__bss_start, 0, __bss_end - __bss_start);

Other solution:
1. Moving OCRAM ECC setting to earlier stage: requires change in generic code.
2. Clear gd afterwards: requires replication of every early stage gd setting.

Best regards,

Jian Luo
DC-IA/EAH2

Tel. +49(9352)18-4266

BeQIK

Quoted 48 lines · Marek Vasut

Quoted 1 line · Jian Luo
Hi,
Hi!
Quoted 16 lines · Marek Vasut
Quoted 15 lines · Jian Luo
Quoted 1 line
Hi Marek,
Hi,
Quoted 10 lines · Marek Vasut
Quoted 1 line · Jian Luo
----snip----
Quoted 3 lines
Quoted 1 line
"Security policy". :(
But thunderbird works ? Can't you just copy the SMTP settings from
thunderbird
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
into gitconfig ? :)
I tried w/o success. Might try again another time.
Try using msmtp and configure your git send-email to send through it (and all your other MUAs too), it's really convenient :)
It works. Thanks. :)
Cool!
Quoted 6 lines
Quoted 1 line
btw is this a custom board you're porting here ?
Yes, but this particular error can also be reproduced on Altera SoCDK.
It seems to be a compiler and/or configuration error of gcc 4.8 generated by yocto dizzy.
Let me guess -- gcc 4.8.2 ?
Quoted 2 lines
After I switched to gcc 4.9 shiped with Altera Soc EDS 15.0, there is no warm reset error anymore.
Nice, thanks for the update :)
Best regards,
Marek Vasut

Marek Vasut

2015-09-03 09:41 UTC #11 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 10 lines · Jian Luo

Hi!
this error comes again. It isn't a compiler error after all. :(
JTAG inspection shows that the problem is located in arch/arm/mach-socfpga/spl.c line94.
It seems that re-enable ECC on OCRAM can cause some strange value changes in SRAM.
Disabling ECC might also cause value changes, which I didn't test.

Quoted 6 lines

On a cold (re)boot sysmgr_regs->eccgrp_ocram is 0x19 (derr|serr|en). So gd keeps intact.
In our VxWorks Image ECC on OCRAM happens to be disabled. After a warm reset sysmgr_regs->eccgrp_ocram is 0x18 (derr|serr). Thus after re-enable ECC, gd->dm_root turns to 0x80 every time.

Ew, Dinh, can you check this please ? This is scary.

Quoted 28 lines

My solution is keeping SYSMGR_ECC_OCRAM_EN bit untouched. And it works for me.

arch/arm/mach-socfpga/spl.c +8 -6

index 775a827..c858406 100644
@@ -90,12 +90,14 @@ void board_init_f(ulong dummy)
          * and DBE might triggered during power on
          */
         reg = readl(&sysmgr_regs->eccgrp_ocram);
-       if (reg & SYSMGR_ECC_OCRAM_SERR)
-               writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
-                      &sysmgr_regs->eccgrp_ocram);
-       if (reg & SYSMGR_ECC_OCRAM_DERR)
-               writel(SYSMGR_ECC_OCRAM_DERR  | SYSMGR_ECC_OCRAM_EN,
-                      &sysmgr_regs->eccgrp_ocram);
+       if (reg & SYSMGR_ECC_OCRAM_SERR) {
+               reg &= ~SYSMGR_ECC_OCRAM_SERR;
+               writel(reg, &sysmgr_regs->eccgrp_ocram);
+       }
+       if (reg & SYSMGR_ECC_OCRAM_DERR) {
+               reg &= ~SYSMGR_ECC_OCRAM_DERR;
+               writel(reg, &sysmgr_regs->eccgrp_ocram);
+       }
 
         memset(__bss_start, 0, __bss_end - __bss_start);

Quoted 5 lines

Other solution:
1. Moving OCRAM ECC setting to earlier stage: requires change in generic code.
2. Clear gd afterwards: requires replication of every early stage gd setting.

What I would be worried is that if this really happens, it likely also corrupts the SPL code which is loaded in OCRAM.

Can't you tune the VxWorks to keep the ECC enabled ?

Jian Luo

author

2015-09-03 10:03 UTC #12 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi!

Quoted 11 lines · Marek Vasut

Quoted 10 lines · Jian Luo
Hi!
this error comes again. It isn't a compiler error after all. :(
JTAG inspection shows that the problem is located in arch/arm/mach-socfpga/spl.c line94.
It seems that re-enable ECC on OCRAM can cause some strange value changes in SRAM.
Disabling ECC might also cause value changes, which I didn't test.

Quoted 8 lines

Quoted 6 lines
On a cold (re)boot sysmgr_regs->eccgrp_ocram is 0x19 (derr|serr|en). So gd keeps intact.
In our VxWorks Image ECC on OCRAM happens to be disabled. After a warm reset sysmgr_regs->eccgrp_ocram is 0x18 (derr|serr). Thus after re-enable ECC, gd->dm_root turns to 0x80 every time.
Ew, Dinh, can you check this please ? This is scary.

You can also reproduce the problem directly in U-Boot with 2 steps:
=> mw.l 0xFFD08144 0
=> reset

On my ade0-nano-soc it hangs even before serial output,
which means it did corrupt the SPL. I guess I just got (un)lucky with socdk.

Quoted 29 lines

My solution is keeping SYSMGR_ECC_OCRAM_EN bit untouched. And it works for me.

arch/arm/mach-socfpga/spl.c +8 -6

index 775a827..c858406 100644
@@ -90,12 +90,14 @@ void board_init_f(ulong dummy)
          * and DBE might triggered during power on
          */
         reg = readl(&sysmgr_regs->eccgrp_ocram);
-       if (reg & SYSMGR_ECC_OCRAM_SERR)
-               writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
-                      &sysmgr_regs->eccgrp_ocram);
-       if (reg & SYSMGR_ECC_OCRAM_DERR)
-               writel(SYSMGR_ECC_OCRAM_DERR  | SYSMGR_ECC_OCRAM_EN,
-                      &sysmgr_regs->eccgrp_ocram);
+       if (reg & SYSMGR_ECC_OCRAM_SERR) {
+               reg &= ~SYSMGR_ECC_OCRAM_SERR;
+               writel(reg, &sysmgr_regs->eccgrp_ocram);
+       }
+       if (reg & SYSMGR_ECC_OCRAM_DERR) {
+               reg &= ~SYSMGR_ECC_OCRAM_DERR;
+               writel(reg, &sysmgr_regs->eccgrp_ocram);
+       }
 
         memset(__bss_start, 0, __bss_end - __bss_start);

Quoted 7 lines

Quoted 5 lines
Other solution:
1. Moving OCRAM ECC setting to earlier stage: requires change in generic code.
2. Clear gd afterwards: requires replication of every early stage gd setting.
What I would be worried is that if this really happens, it likely

also corrupts

Quoted 3 lines

the SPL code which is loaded in OCRAM.
Can't you tune the VxWorks to keep the ECC enabled ?

Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC then clear
the entire
memory to zero before using it.

Best regards,

Jian Luo

Marek Vasut

2015-09-03 10:09 UTC #13 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 1 line · Jian Luo

Hi!

Hi!

Quoted 21 lines · Marek Vasut

Quoted 11 lines · Jian Luo
Quoted 10 lines
Hi!
this error comes again. It isn't a compiler error after all. :(
JTAG inspection shows that the problem is located in arch/arm/mach-socfpga/spl.c line94.
It seems that re-enable ECC on OCRAM can cause some strange value changes in SRAM.
Disabling ECC might also cause value changes, which I didn't test.
Quoted 8 lines
Quoted 6 lines
On a cold (re)boot sysmgr_regs->eccgrp_ocram is 0x19 (derr|serr|en). So gd keeps intact.
In our VxWorks Image ECC on OCRAM happens to be disabled. After a warm reset sysmgr_regs->eccgrp_ocram is 0x18 (derr|serr). Thus after re-enable ECC, gd->dm_root turns to 0x80 every time.
Ew, Dinh, can you check this please ? This is scary.

Quoted 7 lines

You can also reproduce the problem directly in U-Boot with 2 steps:
   => mw.l 0xFFD08144 0
   => reset
On my ade0-nano-soc it hangs even before serial output, which means it did corrupt the SPL. I guess I just got (un)lucky with socdk.

Oh, nice testcase, thanks!

Quoted 45 lines

Quoted 31 lines

My solution is keeping SYSMGR_ECC_OCRAM_EN bit untouched. And it works for me.

arch/arm/mach-socfpga/spl.c +8 -6

index 775a827..c858406 100644
@@ -90,12 +90,14 @@ void board_init_f(ulong dummy)
 
          * and DBE might triggered during power on
          */
 
         reg = readl(&sysmgr_regs->eccgrp_ocram);
 
-       if (reg & SYSMGR_ECC_OCRAM_SERR)
-               writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
-                      &sysmgr_regs->eccgrp_ocram);
-       if (reg & SYSMGR_ECC_OCRAM_DERR)
-               writel(SYSMGR_ECC_OCRAM_DERR  | SYSMGR_ECC_OCRAM_EN,
-                      &sysmgr_regs->eccgrp_ocram);
+       if (reg & SYSMGR_ECC_OCRAM_SERR) {
+               reg &= ~SYSMGR_ECC_OCRAM_SERR;
+               writel(reg, &sysmgr_regs->eccgrp_ocram);
+       }
+       if (reg & SYSMGR_ECC_OCRAM_DERR) {
+               reg &= ~SYSMGR_ECC_OCRAM_DERR;
+               writel(reg, &sysmgr_regs->eccgrp_ocram);
+       }

         memset(__bss_start, 0, __bss_end - __bss_start);

Quoted 7 lines

Quoted 5 lines
Other solution:
1. Moving OCRAM ECC setting to earlier stage: requires change in generic code.
2. Clear gd afterwards: requires replication of every early stage gd setting.
What I would be worried is that if this really happens, it likely

also corrupts

Quoted 3 lines

the SPL code which is loaded in OCRAM.
Can't you tune the VxWorks to keep the ECC enabled ?

Quoted 7 lines

Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC then clear
the entire
memory to zero before using it.

Oh, but that is a problem, since we're running from the OCRAM ourselves, thus we cannot clear the OCRAM. Maybe we should force-disable the ECC instead? But can we be sure that the corruption does not happen when you disable ECC ?

Jian Luo

author

2015-09-03 10:17 UTC #14 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 18 lines · Marek Vasut

Quoted 1 line · Jian Luo
Hi!
Hi!
Quoted 13 lines · Marek Vasut
Quoted 12 lines · Jian Luo
Quoted 11 lines
Hi!
this error comes again. It isn't a compiler error after all. :(
JTAG inspection shows that the problem is located in arch/arm/mach-socfpga/spl.c line94.
It seems that re-enable ECC on OCRAM can cause some strange value changes in SRAM.
Disabling ECC might also cause value changes, which I didn't test.
On a cold (re)boot sysmgr_regs->eccgrp_ocram is 0x19

(derr|serr|en). So
 >>  >> gd keeps intact.
 >>  >>
 >>  >> In our VxWorks Image ECC on OCRAM happens to be disabled.
 >>  >> After a warm reset sysmgr_regs->eccgrp_ocram is 0x18 (derr|serr).
 >>  >> Thus after re-enable ECC, gd->dm_root turns to 0x80 every time.
 >>  >
 >>  > Ew, Dinh, can you check this please ? This is scary.

Quoted 5 lines

Quoted 5 lines
You can also reproduce the problem directly in U-Boot with 2 steps:
   => mw.l 0xFFD08144 0
   => reset

Quoted 7 lines

Quoted 3 lines
On my ade0-nano-soc it hangs even before serial output, which means it did corrupt the SPL. I guess I just got (un)lucky with socdk.
Oh, nice testcase, thanks!
Quoted 1 line
Quoted 1 line
Quoted 1 line
My solution is keeping SYSMGR_ECC_OCRAM_EN bit untouched. And it

works

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Review
Quoted 3 lines
for me.
(quoted diff) +0 -0

b/arch/arm/mach-socfpga/spl.c

Quoted 41 lines

Quoted 27 lines

index 775a827..c858406 100644

arch/arm/mach-socfpga/spl.c +8 -6

@@ -90,12 +90,14 @@ void board_init_f(ulong dummy)
 
          * and DBE might triggered during power on
          */
 
         reg = readl(&sysmgr_regs->eccgrp_ocram);
 
-       if (reg & SYSMGR_ECC_OCRAM_SERR)
-               writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
- &sysmgr_regs->eccgrp_ocram);
-       if (reg & SYSMGR_ECC_OCRAM_DERR)
-               writel(SYSMGR_ECC_OCRAM_DERR  | SYSMGR_ECC_OCRAM_EN,
- &sysmgr_regs->eccgrp_ocram);
+       if (reg & SYSMGR_ECC_OCRAM_SERR) {
+               reg &= ~SYSMGR_ECC_OCRAM_SERR;
+               writel(reg, &sysmgr_regs->eccgrp_ocram);
+       }
+       if (reg & SYSMGR_ECC_OCRAM_DERR) {
+               reg &= ~SYSMGR_ECC_OCRAM_DERR;
+               writel(reg, &sysmgr_regs->eccgrp_ocram);
+       }

         memset(__bss_start, 0, __bss_end - __bss_start);

Quoted 7 lines

Quoted 5 lines
Other solution:
1. Moving OCRAM ECC setting to earlier stage: requires change in generic code.
2. Clear gd afterwards: requires replication of every early stage gd setting.
What I would be worried is that if this really happens, it likely

also corrupts

Quoted 3 lines

the SPL code which is loaded in OCRAM.
Can't you tune the VxWorks to keep the ECC enabled ?

Quoted 7 lines

Quoted 7 lines
Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC then clear
the entire
memory to zero before using it.

Hi!

Quoted 5 lines

Oh, but that is a problem, since we're running from the OCRAM ourselves, thus we cannot clear the OCRAM. Maybe we should force-disable the ECC instead? But can we be sure that the corruption does not happen when you disable ECC ?

Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN bit intact in the patch.

Best regards,

Jian Luo

Marek Vasut

2015-09-03 10:46 UTC #15 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote:

Hi!

[...]

Quoted 13 lines

Quoted 10 lines
Quoted 10 lines
Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC then clear
the entire
memory to zero before using it.
Hi!

Quoted 7 lines

Quoted 4 lines
Oh, but that is a problem, since we're running from the OCRAM ourselves, thus we cannot clear the OCRAM. Maybe we should force-disable the ECC instead? But can we be sure that the corruption does not happen when you disable ECC ?
Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN bit intact in the patch.

OK, but what about turning the ECC off in the SPL, will that also introduce corruption or not ? That might be the right fix, no ?

Best regards,
Marek Vasut

Jian Luo

author

2015-09-03 11:12 UTC #16 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 12 lines · Marek Vasut

On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote:
Hi!
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC

then clear

Quoted 8 lines

Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
the entire
memory to zero before using it.
Hi!
Quoted 1 line
Oh, but that is a problem, since we're running from the OCRAM

ourselves,

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
thus we cannot clear the OCRAM. Maybe we should force-disable the ECC instead? But can we be sure that the corruption does not happen when you disable ECC ?
Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN bit intact in the patch.
OK, but what about turning the ECC off in the SPL, will that also

introduce

Quoted 1 line

corruption or not ? That might be the right fix, no ?

Hi Marek,

Sorry, I don't know the detail of ECC implementation in socfpga. Dinh might have the answer to that.

Anyhow I still think let the setting untouched is the safest fix. SPL should use the same ECC setting which BROM loads SPL with.

Quoted 3 lines

Best regards,
Marek Vasut

Best regards,

Jian Luo

Marek Vasut

2015-09-03 11:14 UTC #17 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 39 lines · Jian Luo

Quoted 12 lines · Marek Vasut
On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote:
Hi!
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC
then clear
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
the entire
memory to zero before using it.
Hi!
Quoted 1 line
Oh, but that is a problem, since we're running from the OCRAM
ourselves,
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
thus we cannot clear the OCRAM. Maybe we should force-disable the ECC instead? But can we be sure that the corruption does not happen when you disable ECC ?
Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN bit intact in the patch.
OK, but what about turning the ECC off in the SPL, will that also
introduce
Quoted 1 line
corruption or not ? That might be the right fix, no ?

Quoted 7 lines

Hi Marek,
Sorry, I don't know the detail of ECC implementation in socfpga. Dinh might have the answer to that.
Anyhow I still think let the setting untouched is the safest fix. SPL should use the same ECC setting which BROM loads SPL with.

That's right, but I'd also like to have this bit in some defined state from the boot instead of having this in some random setting. Dinh, can you comment on this corruption please ?

Best regards,
Marek Vasut

Simon Glass

2015-09-04 00:23 UTC #18 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi,

Quoted 45 lines · Marek Vasut

Quoted 44 lines · Jian Luo
Quoted 12 lines · Marek Vasut
On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote:
Hi!
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC
then clear
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
the entire
memory to zero before using it.
Hi!
Quoted 1 line
Oh, but that is a problem, since we're running from the OCRAM
ourselves,
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
thus we cannot clear the OCRAM. Maybe we should force-disable the ECC instead? But can we be sure that the corruption does not happen when you disable ECC ?
Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN bit intact in the patch.
OK, but what about turning the ECC off in the SPL, will that also
introduce
Quoted 1 line
corruption or not ? That might be the right fix, no ?
Hi Marek,
Sorry, I don't know the detail of ECC implementation in socfpga. Dinh might have the answer to that.

Quoted 6 lines

Quoted 2 lines
Anyhow I still think let the setting untouched is the safest fix. SPL should use the same ECC setting which BROM loads SPL with.
That's right, but I'd also like to have this bit in some defined state from the boot instead of having this in some random setting. Dinh, can you comment on this corruption please ?

Also I'm still a bit confused.

The code in crt0.S zeroes global_data so how can it be non-zero a little later in board_init_f()?

Regards,
Simon

Jian Luo

author

2015-09-04 07:36 UTC #19 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi Simon,

Quoted 31 lines · Simon Glass

Hi,
Quoted 28 lines · Marek Vasut
Quoted 27 lines · Jian Luo
Quoted 12 lines · Marek Vasut
On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote:
Hi!
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC
then clear
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
the entire
memory to zero before using it.
Hi!
Quoted 1 line
Oh, but that is a problem, since we're running from the OCRAM
ourselves,
Quoted 1 line
Quoted 1 line
Quoted 1 line
thus we cannot clear the OCRAM. Maybe we should

force-disable the

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
ECC instead? But can we be sure that the corruption does not

happen

Quoted 19 lines

Quoted 19 lines
Quoted 18 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
when you disable ECC ?
Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN bit intact in the patch.
OK, but what about turning the ECC off in the SPL, will that also
introduce
Quoted 1 line
corruption or not ? That might be the right fix, no ?
Hi Marek,
Sorry, I don't know the detail of ECC implementation in socfpga. Dinh might have the answer to that.
Anyhow I still think let the setting untouched is the safest fix. SPL should use the same ECC setting which BROM loads SPL with.

Quoted 9 lines

Quoted 3 lines
That's right, but I'd also like to have this bit in some defined state from the boot instead of having this in some random setting. Dinh, can you comment on this corruption please ?
Also I'm still a bit confused.
The code in crt0.S zeroes global_data so how can it be non-zero a little later in board_init_f()?

board_init_f() enables the ECC of the SRAM regardless its previous state. If ECC is disabled beborehand, re-enabling it can cause SRAM misreading.

Best regards,

Jian Luo

Simon Glass

2015-09-04 14:16 UTC #20 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi,

Quoted 60 lines · Jian Luo

Hi Simon,
Quoted 56 lines · Simon Glass
Hi,
Quoted 52 lines · Marek Vasut
Quoted 40 lines · Jian Luo
Quoted 12 lines · Marek Vasut
On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote:
Hi!
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC
then clear
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
the entire
memory to zero before using it.
Hi!
Quoted 1 line
Oh, but that is a problem, since we're running from the OCRAM
ourselves,
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
thus we cannot clear the OCRAM. Maybe we should force-disable the ECC instead? But can we be sure that the corruption does not
happen
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
when you disable ECC ?
Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN bit intact in the patch.
OK, but what about turning the ECC off in the SPL, will that also
introduce
Quoted 1 line
corruption or not ? That might be the right fix, no ?
Quoted 7 lines
Hi Marek,
Sorry, I don't know the detail of ECC implementation in socfpga. Dinh might have the answer to that.
Anyhow I still think let the setting untouched is the safest fix. SPL should use the same ECC setting which BROM loads SPL with.
That's right, but I'd also like to have this bit in some defined state from the boot instead of having this in some random setting. Dinh, can you comment on this corruption please ?

Quoted 7 lines

Quoted 5 lines
Also I'm still a bit confused.
The code in crt0.S zeroes global_data so how can it be non-zero a little later in board_init_f()?
board_init_f() enables the ECC of the SRAM regardless its previous state. If ECC is disabled beborehand, re-enabling it can cause SRAM misreading.

OK thanks. It might be possible to do this earlier, say in cpu_init_crit().

Regards,
Simon

Marek Vasut

2015-09-04 14:25 UTC #21 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 67 lines · Simon Glass

Hi,
Quoted 64 lines · Jian Luo
Hi Simon,
Quoted 61 lines · Simon Glass
Hi,
Quoted 49 lines · Marek Vasut
Quoted 48 lines · Jian Luo
Quoted 12 lines · Marek Vasut
On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote:
Hi!
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC
then clear
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
the entire
memory to zero before using it.
Hi!
Quoted 1 line
Oh, but that is a problem, since we're running from the OCRAM
ourselves,
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
thus we cannot clear the OCRAM. Maybe we should force-disable the ECC instead? But can we be sure that the corruption does not
happen
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
when you disable ECC ?
Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN bit intact in the patch.
OK, but what about turning the ECC off in the SPL, will that also
introduce
Quoted 1 line
corruption or not ? That might be the right fix, no ?
Hi Marek,
Sorry, I don't know the detail of ECC implementation in socfpga. Dinh might have the answer to that.
Quoted 6 lines
Quoted 2 lines
Anyhow I still think let the setting untouched is the safest fix. SPL should use the same ECC setting which BROM loads SPL with.
That's right, but I'd also like to have this bit in some defined state from the boot instead of having this in some random setting. Dinh, can you comment on this corruption please ?
Also I'm still a bit confused.

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
The code in crt0.S zeroes global_data so how can it be non-zero a little later in board_init_f()?
board_init_f() enables the ECC of the SRAM regardless its previous state. If ECC is disabled beborehand, re-enabling it can cause SRAM misreading.
OK thanks. It might be possible to do this earlier, say in cpu_init_crit().

You cannot enable the bit, because it'd corrupt your OCRAM and your code is running from the OCRAM, thus you'd be susceptible to corrupting the code you're running itself :(

Simon Glass

2015-09-04 14:26 UTC #22 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 71 lines · Marek Vasut

Quoted 70 lines · Simon Glass
Hi,
Quoted 67 lines · Jian Luo
Hi Simon,
Quoted 63 lines · Simon Glass
Hi,
Quoted 49 lines · Marek Vasut
Quoted 48 lines · Jian Luo
Quoted 12 lines · Marek Vasut
On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote:
Hi!
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC
then clear
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
the entire
memory to zero before using it.
Hi!
Quoted 1 line
Oh, but that is a problem, since we're running from the OCRAM
ourselves,
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
thus we cannot clear the OCRAM. Maybe we should force-disable the ECC instead? But can we be sure that the corruption does not
happen
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
when you disable ECC ?
Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN bit intact in the patch.
OK, but what about turning the ECC off in the SPL, will that also
introduce
Quoted 1 line
corruption or not ? That might be the right fix, no ?
Hi Marek,
Sorry, I don't know the detail of ECC implementation in socfpga. Dinh might have the answer to that.
Quoted 6 lines
Quoted 2 lines
Anyhow I still think let the setting untouched is the safest fix. SPL should use the same ECC setting which BROM loads SPL with.
That's right, but I'd also like to have this bit in some defined state from the boot instead of having this in some random setting. Dinh, can you comment on this corruption please ?
Also I'm still a bit confused.
The code in crt0.S zeroes global_data so how can it be non-zero a little later in board_init_f()?

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
board_init_f() enables the ECC of the SRAM regardless its previous state. If ECC is disabled beborehand, re-enabling it can cause SRAM misreading.
OK thanks. It might be possible to do this earlier, say in cpu_init_crit().
You cannot enable the bit, because it'd corrupt your OCRAM and your code is running from the OCRAM, thus you'd be susceptible to corrupting the code you're running itself :(

Oh joy. Well anyway I think this is a chip-specific problem and there is nothing wrong in general with the current init process.

Regards,
Simon

Marek Vasut

2015-09-04 14:32 UTC #23 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 82 lines · Simon Glass

Quoted 81 lines · Marek Vasut
Quoted 79 lines · Simon Glass
Hi,
Quoted 65 lines · Jian Luo
Hi Simon,
Quoted 62 lines · Simon Glass
Hi,
Quoted 58 lines · Marek Vasut
Quoted 46 lines · Jian Luo
Quoted 13 lines · Marek Vasut
On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote:
Hi!
[...]
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC
then clear
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
the entire
memory to zero before using it.
Hi!
Quoted 2 lines
Oh, but that is a problem, since we're running from the OCRAM
ourselves,
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
thus we cannot clear the OCRAM. Maybe we should force-disable the ECC instead? But can we be sure that the corruption does not
happen
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
when you disable ECC ?
Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN bit intact in the patch.
OK, but what about turning the ECC off in the SPL, will that also
introduce
Quoted 1 line
corruption or not ? That might be the right fix, no ?
Quoted 7 lines
Hi Marek,
Sorry, I don't know the detail of ECC implementation in socfpga. Dinh might have the answer to that.
Anyhow I still think let the setting untouched is the safest fix. SPL should use the same ECC setting which BROM loads SPL with.
That's right, but I'd also like to have this bit in some defined state from the boot instead of having this in some random setting. Dinh, can you comment on this corruption please ?
Quoted 8 lines
Quoted 4 lines
Also I'm still a bit confused.
The code in crt0.S zeroes global_data so how can it be non-zero a little later in board_init_f()?
board_init_f() enables the ECC of the SRAM regardless its previous state. If ECC is disabled beborehand, re-enabling it can cause SRAM misreading.
OK thanks. It might be possible to do this earlier, say in cpu_init_crit().

Quoted 6 lines

Quoted 3 lines
You cannot enable the bit, because it'd corrupt your OCRAM and your code is running from the OCRAM, thus you'd be susceptible to corrupting the code you're running itself :(
Oh joy. Well anyway I think this is a chip-specific problem and there is nothing wrong in general with the current init process.

That's absolutelly correct.

I'd like to hear Dinh's opinion on this, because this seems quite important.

Jian Luo

author

2015-09-22 12:26 UTC #24 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi Dinh, Hi Marek,

any updates on this issue?

Best regards,

Jian Luo

Quoted 6 lines · Marek Vasut

Quoted 5 lines · Simon Glass
Quoted 4 lines · Marek Vasut
Quoted 3 lines · Simon Glass
Hi,
On 4 September 2015 at 01:36, Jian Luo <[email protected]>

Quoted 70 lines · wrote:

Quoted 70 lines
Quoted 70 lines
Quoted 70 lines
Quoted 70 lines
Hi Simon,
Quoted 66 lines · Simon Glass
Hi,
Quoted 52 lines · Marek Vasut
Quoted 51 lines · Jian Luo
Quoted 13 lines · Marek Vasut
On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote:
Hi!
[...]
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Yes, I can. But U-Boot can still have problem with other Image which disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC
then clear
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
the entire
memory to zero before using it.
Hi!
Quoted 2 lines
Oh, but that is a problem, since we're running from the OCRAM
ourselves,
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
thus we cannot clear the OCRAM. Maybe we should force-disable the ECC instead? But can we be sure that the corruption does not
happen
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
when you disable ECC ?
Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN bit intact in the patch.
OK, but what about turning the ECC off in the SPL, will that also
introduce
Quoted 1 line
corruption or not ? That might be the right fix, no ?
Hi Marek,
Sorry, I don't know the detail of ECC implementation in socfpga. Dinh might have the answer to that.
Quoted 6 lines
Quoted 2 lines
Anyhow I still think let the setting untouched is the safest fix. SPL should use the same ECC setting which BROM loads SPL with.
That's right, but I'd also like to have this bit in some defined state from the boot instead of having this in some random setting. Dinh, can you comment on this corruption please ?
Also I'm still a bit confused.
The code in crt0.S zeroes global_data so how can it be non-zero a little later in board_init_f()?

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
board_init_f() enables the ECC of the SRAM regardless its previous state. If ECC is disabled beborehand, re-enabling it can cause SRAM misreading.
OK thanks. It might be possible to do this earlier, say in cpu_init_crit().
You cannot enable the bit, because it'd corrupt your OCRAM and your

code

Quoted 9 lines

Quoted 5 lines
Quoted 2 lines
is running from the OCRAM, thus you'd be susceptible to corrupting the code you're running itself :(
Oh joy. Well anyway I think this is a chip-specific problem and there is nothing wrong in general with the current init process.
That's absolutelly correct.
I'd like to hear Dinh's opinion on this, because this seems quite

important.

Simon Glass

2015-08-28 23:21 UTC #25 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

In reply to Jian Luo

Hi,

Quoted 25 lines · Jian Luo

gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.

Signed-off-by Jian Luo <[email protected]>

---
 arch/arm/mach-socfpga/spl.c | 6 ++++++
 1 file changed, 6 insertions(+)

arch/arm/mach-socfpga/spl.c +6 -1

index 13ec24b..59fe1f2 100644
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
        /* Configure simple malloc base pointer into RAM. */
        gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
+       /*
+        * gd->dm_root might contain non-zero value after warm reset.
+        * Clear it to avoid dm_init error
+        */
+       gd->dm_root = NULL;
+
        board_init_r(NULL, 0);
 }
--

Quoted 2 lines

1.9.1

This does not look like the root cause to me. global_data is zeroed by crt0.S if CONFIG_SPL_FRAMEWORK is set, which it seems to be for socfpga.

What boot path does 'warm reset' take?

Also BTW it would be better if board_init_f() returned rather than calling board_init_r() directly.

Regards,
Simon

Marek Vasut

2015-08-29 07:56 UTC #26 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 32 lines · Simon Glass

Hi,

Quoted 29 lines · Jian Luo

gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.

Signed-off-by Jian Luo <[email protected]>

---

 arch/arm/mach-socfpga/spl.c | 6 ++++++
 1 file changed, 6 insertions(+)

arch/arm/mach-socfpga/spl.c +6 -0

index 13ec24b..59fe1f2 100644
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
 
        /* Configure simple malloc base pointer into RAM. */
        gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
+       /*
+        * gd->dm_root might contain non-zero value after warm reset.
+        * Clear it to avoid dm_init error
+        */
+       gd->dm_root = NULL;
+

        board_init_r(NULL, 0);

}

Quoted 8 lines

Quoted 2 lines
--
1.9.1
This does not look like the root cause to me. global_data is zeroed by crt0.S if CONFIG_SPL_FRAMEWORK is set, which it seems to be for socfpga.
What boot path does 'warm reset' take?

Warm reset resets the CPU core(s) and jumps to 0x0 in SRAM (without re-reading anything from the boot media).

Quoted 2 lines

Also BTW it would be better if board_init_f() returned rather than calling board_init_r() directly.

I'm all for it, it'd trim down the stack utilisation slightly too.

Best regards,
Marek Vasut

Simon Glass

2015-08-29 14:39 UTC #27 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi Marek,

Quoted 41 lines · Marek Vasut

Quoted 39 lines · Simon Glass
Hi,
Quoted 27 lines · Jian Luo
gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.
Signed-off-by Jian Luo <[email protected]>
---
 arch/arm/mach-socfpga/spl.c | 6 ++++++
 1 file changed, 6 insertions(+)
arch/arm/mach-socfpga/spl.c +6 -0
index 13ec24b..59fe1f2 100644
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
 
        /* Configure simple malloc base pointer into RAM. */
        gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
+       /*
+        * gd->dm_root might contain non-zero value after warm reset.
+        * Clear it to avoid dm_init error
+        */
+       gd->dm_root = NULL;
+
 
        board_init_r(NULL, 0);
Quoted 4 lines
}
--
1.9.1
This does not look like the root cause to me. global_data is zeroed by crt0.S if CONFIG_SPL_FRAMEWORK is set, which it seems to be for socfpga.

Quoted 4 lines

Quoted 1 line
What boot path does 'warm reset' take?
Warm reset resets the CPU core(s) and jumps to 0x0 in SRAM (without re-reading anything from the boot media).

Does that mean it skips crt0.S? How come global_data is not zeroed there?

Quoted 6 lines

Quoted 3 lines
Also BTW it would be better if board_init_f() returned rather than calling board_init_r() directly.
I'm all for it, it'd trim down the stack utilisation slightly too.

Sound good.

Regards,
Simon

Marek Vasut

2015-08-29 14:46 UTC #28 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 43 lines · Simon Glass

Hi Marek,
Quoted 40 lines · Marek Vasut
Quoted 39 lines · Simon Glass
Hi,
Quoted 27 lines · Jian Luo
gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.
Signed-off-by Jian Luo <[email protected]>
---
 arch/arm/mach-socfpga/spl.c | 6 ++++++
 1 file changed, 6 insertions(+)
(quoted diff) +0 -0
b/arch/arm/mach-socfpga/spl.c index 13ec24b..59fe1f2 100644
arch/arm/mach-socfpga/spl.c +6 -0
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
 
        /* Configure simple malloc base pointer into RAM. */
        gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
+       /*
+        * gd->dm_root might contain non-zero value after warm reset.
+        * Clear it to avoid dm_init error
+        */
+       gd->dm_root = NULL;
+
 
        board_init_r(NULL, 0);
Quoted 4 lines
}
--
1.9.1
This does not look like the root cause to me. global_data is zeroed by crt0.S if CONFIG_SPL_FRAMEWORK is set, which it seems to be for socfpga.

Quoted 6 lines

Quoted 4 lines
Quoted 1 line
What boot path does 'warm reset' take?
Warm reset resets the CPU core(s) and jumps to 0x0 in SRAM (without re-reading anything from the boot media).
Does that mean it skips crt0.S? How come global_data is not zeroed there?

No, it does not mean it skips crt0.S . After the warm reset, the bootrom jumps onto the reset vector, so crt0.S (_main) must be executed.

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
Also BTW it would be better if board_init_f() returned rather than calling board_init_r() directly.
I'm all for it, it'd trim down the stack utilisation slightly too.
Sound good.

Done ;-)

Best regards,
Marek Vasut

Simon Glass

2015-08-29 14:49 UTC #29 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi Marek,

Quoted 46 lines · Marek Vasut

Quoted 45 lines · Simon Glass
Hi Marek,
Quoted 42 lines · Marek Vasut
Quoted 40 lines · Simon Glass
Hi,
Quoted 27 lines · Jian Luo
gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.
Signed-off-by Jian Luo <[email protected]>
---
 arch/arm/mach-socfpga/spl.c | 6 ++++++
 1 file changed, 6 insertions(+)
(quoted diff) +0 -0
b/arch/arm/mach-socfpga/spl.c index 13ec24b..59fe1f2 100644
arch/arm/mach-socfpga/spl.c +6 -0
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
 
        /* Configure simple malloc base pointer into RAM. */
        gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
+       /*
+        * gd->dm_root might contain non-zero value after warm reset.
+        * Clear it to avoid dm_init error
+        */
+       gd->dm_root = NULL;
+
 
        board_init_r(NULL, 0);
Quoted 4 lines
}
--
1.9.1
This does not look like the root cause to me. global_data is zeroed by crt0.S if CONFIG_SPL_FRAMEWORK is set, which it seems to be for socfpga.
What boot path does 'warm reset' take?

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
Warm reset resets the CPU core(s) and jumps to 0x0 in SRAM (without re-reading anything from the boot media).
Does that mean it skips crt0.S? How come global_data is not zeroed there?
No, it does not mean it skips crt0.S . After the warm reset, the bootrom jumps onto the reset vector, so crt0.S (_main) must be executed.

Then I don't understand the need for this patch.

Quoted 9 lines

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Also BTW it would be better if board_init_f() returned rather than calling board_init_r() directly.
I'm all for it, it'd trim down the stack utilisation slightly too.
Sound good.
Done ;-)

:-)

Quoted 3 lines

Best regards,
Marek Vasut

Regards,
Simon

Marek Vasut

2015-08-29 15:45 UTC #30 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 52 lines · Simon Glass

Hi Marek,
Quoted 49 lines · Marek Vasut
Quoted 48 lines · Simon Glass
Hi Marek,
Quoted 44 lines · Marek Vasut
Quoted 32 lines · Simon Glass
Hi,
Quoted 29 lines · Jian Luo
gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.
Signed-off-by Jian Luo <[email protected]>
---
 arch/arm/mach-socfpga/spl.c | 6 ++++++
 1 file changed, 6 insertions(+)
(quoted diff) +0 -0
b/arch/arm/mach-socfpga/spl.c index 13ec24b..59fe1f2 100644
arch/arm/mach-socfpga/spl.c +2 -0
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
 
        /* Configure simple malloc base pointer into RAM. */
        gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
+       /*
+        * gd->dm_root might contain non-zero value after warm
reset. + * Clear it to avoid dm_init error
arch/arm/mach-socfpga/spl.c +3 -0
+        */
+       gd->dm_root = NULL;
+
 
        board_init_r(NULL, 0);
 
 }
Quoted 8 lines
Quoted 2 lines
--
1.9.1
This does not look like the root cause to me. global_data is zeroed by crt0.S if CONFIG_SPL_FRAMEWORK is set, which it seems to be for socfpga.
What boot path does 'warm reset' take?
Warm reset resets the CPU core(s) and jumps to 0x0 in SRAM (without re-reading anything from the boot media).

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
Does that mean it skips crt0.S? How come global_data is not zeroed there?
No, it does not mean it skips crt0.S . After the warm reset, the bootrom jumps onto the reset vector, so crt0.S (_main) must be executed.
Then I don't understand the need for this patch.

Apparently, the gd->dm_root is set to a non-NULL address for some (unknown) reason. I don't quite understand this myself.

The only possibility which can lead to gd->dm_root being set to non-NULL address is that crt0.S _main is not executed, is that correct ?

Simon Glass

2015-08-29 16:54 UTC #31 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Hi Marek,

Quoted 59 lines · Marek Vasut

Quoted 58 lines · Simon Glass
Hi Marek,
Quoted 54 lines · Marek Vasut
Quoted 43 lines · Simon Glass
Hi Marek,
Quoted 40 lines · Marek Vasut
Quoted 39 lines · Simon Glass
Hi,
Quoted 30 lines · Jian Luo
gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure.
Signed-off-by Jian Luo <[email protected]>
---
 arch/arm/mach-socfpga/spl.c | 6 ++++++
 1 file changed, 6 insertions(+)
(quoted diff) +0 -0
b/arch/arm/mach-socfpga/spl.c index 13ec24b..59fe1f2 100644
arch/arm/mach-socfpga/spl.c +2 -0
@@ -181,5 +181,11 @@ void board_init_f(ulong dummy)
 
        /* Configure simple malloc base pointer into RAM. */
        gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 
+       /*
+        * gd->dm_root might contain non-zero value after warm
reset. + * Clear it to avoid dm_init error
arch/arm/mach-socfpga/spl.c +3 -1
+        */
+       gd->dm_root = NULL;
+
 
        board_init_r(NULL, 0);
 
 }
 
--
Quoted 1 line
1.9.1
This does not look like the root cause to me. global_data is zeroed by crt0.S if CONFIG_SPL_FRAMEWORK is set, which it seems to be for socfpga.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
What boot path does 'warm reset' take?
Warm reset resets the CPU core(s) and jumps to 0x0 in SRAM (without re-reading anything from the boot media).
Does that mean it skips crt0.S? How come global_data is not zeroed there?
No, it does not mean it skips crt0.S . After the warm reset, the bootrom jumps onto the reset vector, so crt0.S (_main) must be executed.

Quoted 7 lines

Quoted 1 line
Then I don't understand the need for this patch.
Apparently, the gd->dm_root is set to a non-NULL address for some (unknown) reason. I don't quite understand this myself.
The only possibility which can lead to gd->dm_root being set to non-NULL address is that crt0.S _main is not executed, is that correct ?

I think so, unless driver model was already inited by a call to spl_init(). But I don't see where your board might do that.

Regards,
Simon

Marek Vasut

2015-08-29 19:19 UTC #32 lore raw

PATCH 1/1 arm: socfpga: dm: Fix DM initialization failure after warm reset

Quoted 1 line · Simon Glass

Hi Marek,

Hi Simon,

[...]

Quoted 9 lines

Quoted 9 lines
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Does that mean it skips crt0.S? How come global_data is not zeroed there?
No, it does not mean it skips crt0.S . After the warm reset, the bootrom jumps onto the reset vector, so crt0.S (_main) must be executed.
Then I don't understand the need for this patch.

Quoted 8 lines

Quoted 5 lines
Apparently, the gd->dm_root is set to a non-NULL address for some (unknown) reason. I don't quite understand this myself.
The only possibility which can lead to gd->dm_root being set to non-NULL address is that crt0.S _main is not executed, is that correct ?
I think so, unless driver model was already inited by a call to spl_init(). But I don't see where your board might do that.

That's correct.

Best regards,
Marek Vasut