* [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset @ 2018-10-07 12:57 Jonas Danielsson 2018-10-16 13:30 ` Claudiu.Beznea 2018-10-16 14:03 ` Alexander Stein 0 siblings, 2 replies; 10+ messages in thread From: Jonas Danielsson @ 2018-10-07 12:57 UTC (permalink / raw) To: linux-kernel Cc: Jonas Danielsson, Sebastian Reichel, Nicolas Ferre, Alexandre Belloni, linux-pm, linux-arm-kernel From: Jonas Danielsson <jonas@orbital-systems.com> This fixes a bug where our embedded system (AT91SAM9260 based) would hang at reboot. At the most we managed 16 boot loops without a hang. With this patch applied the problem has not been observed and the board has managed above 250 boot loops. The AT91SAM9260 datasheet tells us that with the instruction cache disabled all instructions are fetched from SDRAM. And we have an errata telling us we must power down the SDRAM before issuing cpu reset. This means we need the instruction cache enabled in at91sam9260_reset() At the moment it is being disabled in cpu_proc_fin() which is called from arch/arm/kernel/reboot.c. Signed-off-by: Jonas Danielsson <jonas@orbital-systems.com> --- drivers/power/reset/at91-reset.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c index f44a9ffcc2ab..78972bba64df 100644 --- a/drivers/power/reset/at91-reset.c +++ b/drivers/power/reset/at91-reset.c @@ -50,14 +50,24 @@ static void __iomem *at91_ramc_base[2], *at91_rstc_base; static struct clk *sclk; /* -* unless the SDRAM is cleanly shutdown before we hit the +* Errata 43.1.7.1 RSTC: Reset during SDRAM Accesses +* +* Unless the SDRAM is cleanly shutdown before we hit the * reset register it can be left driving the data bus and * killing the chance of a subsequent boot from NAND +* +* Since we are disabling SDRAM need to make sure that the +* instruction cache is enabled. */ static int at91sam9260_restart(struct notifier_block *this, unsigned long mode, void *cmd) { asm volatile( + /* Enable I-cache */ + "mrc p15, 0, r0, c1, c0, 0\n\t" + "orr r0, r0, #4096\n\t" /* CR_I (bit 12) */ + "mcr p15, 0, r0, c1, c0, 0\n\t" + /* Align to cache lines */ ".balign 32\n\t" -- 2.14.4 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset 2018-10-07 12:57 [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset Jonas Danielsson @ 2018-10-16 13:30 ` Claudiu.Beznea 2018-10-16 14:15 ` Jonas Danielsson 2018-10-16 14:52 ` Alexander Stein 2018-10-16 14:03 ` Alexander Stein 1 sibling, 2 replies; 10+ messages in thread From: Claudiu.Beznea @ 2018-10-16 13:30 UTC (permalink / raw) To: jonas, linux-kernel Cc: sre, Nicolas.Ferre, alexandre.belloni, linux-pm, linux-arm-kernel Hi Jonas, On 07.10.2018 15:57, Jonas Danielsson wrote: > From: Jonas Danielsson <jonas@orbital-systems.com> > > This fixes a bug where our embedded system (AT91SAM9260 based) would > hang at reboot. At the most we managed 16 boot loops without a hang. > > With this patch applied the problem has not been observed and the board > has managed above 250 boot loops. > > The AT91SAM9260 datasheet tells us that with the instruction cache > disabled all instructions are fetched from SDRAM. And we have an errata > telling us we must power down the SDRAM before issuing cpu reset. > > This means we need the instruction cache enabled in at91sam9260_reset() > At the moment it is being disabled in cpu_proc_fin() which is called from > arch/arm/kernel/reboot.c. Are you using kexec reboot or implemented hibernate mode on this machine? I'm seeing cpu_proc_fin() is called only in case of kexec reboot or switching to hibernate mode. In case of normal reboot (e.g. reboot command) machine_restart() from arch/arm/kernel/reboot.c is called. Please correct me if I'm wrong. Thank you, Claudiu Beznea > > Signed-off-by: Jonas Danielsson <jonas@orbital-systems.com> > --- > drivers/power/reset/at91-reset.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c > index f44a9ffcc2ab..78972bba64df 100644 > --- a/drivers/power/reset/at91-reset.c > +++ b/drivers/power/reset/at91-reset.c > @@ -50,14 +50,24 @@ static void __iomem *at91_ramc_base[2], *at91_rstc_base; > static struct clk *sclk; > > /* > -* unless the SDRAM is cleanly shutdown before we hit the > +* Errata 43.1.7.1 RSTC: Reset during SDRAM Accesses > +* > +* Unless the SDRAM is cleanly shutdown before we hit the > * reset register it can be left driving the data bus and > * killing the chance of a subsequent boot from NAND > +* > +* Since we are disabling SDRAM need to make sure that the > +* instruction cache is enabled. > */ > static int at91sam9260_restart(struct notifier_block *this, unsigned long mode, > void *cmd) > { > asm volatile( > + /* Enable I-cache */ > + "mrc p15, 0, r0, c1, c0, 0\n\t" > + "orr r0, r0, #4096\n\t" /* CR_I (bit 12) */ > + "mcr p15, 0, r0, c1, c0, 0\n\t" > + > /* Align to cache lines */ > ".balign 32\n\t" > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset 2018-10-16 13:30 ` Claudiu.Beznea @ 2018-10-16 14:15 ` Jonas Danielsson 2018-10-16 14:52 ` Alexander Stein 1 sibling, 0 replies; 10+ messages in thread From: Jonas Danielsson @ 2018-10-16 14:15 UTC (permalink / raw) To: Claudiu.Beznea Cc: linux-kernel, Sebastian Reichel, Nicolas Ferre, Alexandre Belloni, linux-pm, linux-arm-kernel On Tue, Oct 16, 2018 at 3:30 PM <Claudiu.Beznea@microchip.com> wrote: > > Hi Jonas, > Hi, > On 07.10.2018 15:57, Jonas Danielsson wrote: > > From: Jonas Danielsson <jonas@orbital-systems.com> > > > > This fixes a bug where our embedded system (AT91SAM9260 based) would > > hang at reboot. At the most we managed 16 boot loops without a hang. > > > > With this patch applied the problem has not been observed and the board > > has managed above 250 boot loops. > > > > The AT91SAM9260 datasheet tells us that with the instruction cache > > disabled all instructions are fetched from SDRAM. And we have an errata > > telling us we must power down the SDRAM before issuing cpu reset. > > > > This means we need the instruction cache enabled in at91sam9260_reset() > > At the moment it is being disabled in cpu_proc_fin() which is called from > > arch/arm/kernel/reboot.c. > > Are you using kexec reboot or implemented hibernate mode on this machine? > I'm seeing cpu_proc_fin() is called only in case of kexec reboot or > switching to hibernate mode. > > In case of normal reboot (e.g. reboot command) machine_restart() from > arch/arm/kernel/reboot.c is called. Please correct me if I'm wrong. > We are not, we do regular reboots. I have read the code paths wrong. Then I wonder what disables icache. > Thank you, > Claudiu Beznea Thank you! > > > > > Signed-off-by: Jonas Danielsson <jonas@orbital-systems.com> > > --- > > drivers/power/reset/at91-reset.c | 12 +++++++++++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c > > index f44a9ffcc2ab..78972bba64df 100644 > > --- a/drivers/power/reset/at91-reset.c > > +++ b/drivers/power/reset/at91-reset.c > > @@ -50,14 +50,24 @@ static void __iomem *at91_ramc_base[2], *at91_rstc_base; > > static struct clk *sclk; > > > > /* > > -* unless the SDRAM is cleanly shutdown before we hit the > > +* Errata 43.1.7.1 RSTC: Reset during SDRAM Accesses > > +* > > +* Unless the SDRAM is cleanly shutdown before we hit the > > * reset register it can be left driving the data bus and > > * killing the chance of a subsequent boot from NAND > > +* > > +* Since we are disabling SDRAM need to make sure that the > > +* instruction cache is enabled. > > */ > > static int at91sam9260_restart(struct notifier_block *this, unsigned long mode, > > void *cmd) > > { > > asm volatile( > > + /* Enable I-cache */ > > + "mrc p15, 0, r0, c1, c0, 0\n\t" > > + "orr r0, r0, #4096\n\t" /* CR_I (bit 12) */ > > + "mcr p15, 0, r0, c1, c0, 0\n\t" > > + > > /* Align to cache lines */ > > ".balign 32\n\t" > > > > -- JONAS DANIELSSON Software Developer +46 72 361 5022 Malmö - Sweden ORBITAL SYSTEMS orbital-systems.com The information contained in this message is intended for the personal and confidential use of the designated recipients named above and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error, and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by ORBITAL SYSTEMS AB, its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset 2018-10-16 13:30 ` Claudiu.Beznea 2018-10-16 14:15 ` Jonas Danielsson @ 2018-10-16 14:52 ` Alexander Stein 2018-10-17 12:17 ` Jonas Danielsson 1 sibling, 1 reply; 10+ messages in thread From: Alexander Stein @ 2018-10-16 14:52 UTC (permalink / raw) To: Claudiu.Beznea Cc: jonas, linux-kernel, sre, Nicolas.Ferre, alexandre.belloni, linux-pm, linux-arm-kernel On Tuesday, October 16, 2018, 3:30:24 PM CEST Claudiu.Beznea@microchip.com wrote: > Hi Jonas, > > On 07.10.2018 15:57, Jonas Danielsson wrote: > > From: Jonas Danielsson <jonas@orbital-systems.com> > > > > This fixes a bug where our embedded system (AT91SAM9260 based) would > > hang at reboot. At the most we managed 16 boot loops without a hang. > > > > With this patch applied the problem has not been observed and the board > > has managed above 250 boot loops. > > > > The AT91SAM9260 datasheet tells us that with the instruction cache > > disabled all instructions are fetched from SDRAM. And we have an errata > > telling us we must power down the SDRAM before issuing cpu reset. > > > > This means we need the instruction cache enabled in at91sam9260_reset() > > At the moment it is being disabled in cpu_proc_fin() which is called from > > arch/arm/kernel/reboot.c. > > Are you using kexec reboot or implemented hibernate mode on this machine? > I'm seeing cpu_proc_fin() is called only in case of kexec reboot or > switching to hibernate mode. > > In case of normal reboot (e.g. reboot command) machine_restart() from > arch/arm/kernel/reboot.c is called. Please correct me if I'm wrong. Another location is cpu_reset() aka cpu_arm926_reset() in proc-arm926.S which also disables I-cache. But I can't track down a callstack ending there. Best regards, Alexander ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset 2018-10-16 14:52 ` Alexander Stein @ 2018-10-17 12:17 ` Jonas Danielsson 2018-10-17 13:10 ` Claudiu.Beznea 0 siblings, 1 reply; 10+ messages in thread From: Jonas Danielsson @ 2018-10-17 12:17 UTC (permalink / raw) To: alexander.stein Cc: Claudiu.Beznea, linux-kernel, Sebastian Reichel, Nicolas Ferre, Alexandre Belloni, linux-pm, linux-arm-kernel On Tue, Oct 16, 2018 at 4:52 PM Alexander Stein <alexander.stein@systec-electronic.com> wrote: > > On Tuesday, October 16, 2018, 3:30:24 PM CEST Claudiu.Beznea@microchip.com wrote: > > Hi Jonas, > > > > On 07.10.2018 15:57, Jonas Danielsson wrote: > > > From: Jonas Danielsson <jonas@orbital-systems.com> > > > > > > This fixes a bug where our embedded system (AT91SAM9260 based) would > > > hang at reboot. At the most we managed 16 boot loops without a hang. > > > > > > With this patch applied the problem has not been observed and the board > > > has managed above 250 boot loops. > > > > > > The AT91SAM9260 datasheet tells us that with the instruction cache > > > disabled all instructions are fetched from SDRAM. And we have an errata > > > telling us we must power down the SDRAM before issuing cpu reset. > > > > > > This means we need the instruction cache enabled in at91sam9260_reset() > > > At the moment it is being disabled in cpu_proc_fin() which is called from > > > arch/arm/kernel/reboot.c. > > > > Are you using kexec reboot or implemented hibernate mode on this machine? > > I'm seeing cpu_proc_fin() is called only in case of kexec reboot or > > switching to hibernate mode. > > > > In case of normal reboot (e.g. reboot command) machine_restart() from > > arch/arm/kernel/reboot.c is called. Please correct me if I'm wrong. > > Another location is cpu_reset() aka cpu_arm926_reset() in proc-arm926.S > which also disables I-cache. But I can't track down a callstack > ending there. > We take the normal path of sys_reboot => kernel_restart => machine_restart ... I added code to print the c1 register in different paths. And I-cache is enabled. So now I am really confused about why the patch worked. > Best regards, > Alexander Jonas > > > -- JONAS DANIELSSON Software Developer +46 72 361 5022 Malmö - Sweden ORBITAL SYSTEMS orbital-systems.com The information contained in this message is intended for the personal and confidential use of the designated recipients named above and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error, and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by ORBITAL SYSTEMS AB, its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset 2018-10-17 12:17 ` Jonas Danielsson @ 2018-10-17 13:10 ` Claudiu.Beznea 2018-10-19 10:30 ` Jonas Danielsson 0 siblings, 1 reply; 10+ messages in thread From: Claudiu.Beznea @ 2018-10-17 13:10 UTC (permalink / raw) To: jonas, alexander.stein Cc: linux-kernel, sre, Nicolas.Ferre, alexandre.belloni, linux-pm, linux-arm-kernel On 17.10.2018 15:17, Jonas Danielsson wrote: > On Tue, Oct 16, 2018 at 4:52 PM Alexander Stein > <alexander.stein@systec-electronic.com> wrote: >> >> On Tuesday, October 16, 2018, 3:30:24 PM CEST Claudiu.Beznea@microchip.com wrote: >>> Hi Jonas, >>> >>> On 07.10.2018 15:57, Jonas Danielsson wrote: >>>> From: Jonas Danielsson <jonas@orbital-systems.com> >>>> >>>> This fixes a bug where our embedded system (AT91SAM9260 based) would >>>> hang at reboot. At the most we managed 16 boot loops without a hang. >>>> >>>> With this patch applied the problem has not been observed and the board >>>> has managed above 250 boot loops. >>>> >>>> The AT91SAM9260 datasheet tells us that with the instruction cache >>>> disabled all instructions are fetched from SDRAM. And we have an errata >>>> telling us we must power down the SDRAM before issuing cpu reset. >>>> >>>> This means we need the instruction cache enabled in at91sam9260_reset() >>>> At the moment it is being disabled in cpu_proc_fin() which is called from >>>> arch/arm/kernel/reboot.c. >>> >>> Are you using kexec reboot or implemented hibernate mode on this machine? >>> I'm seeing cpu_proc_fin() is called only in case of kexec reboot or >>> switching to hibernate mode. >>> >>> In case of normal reboot (e.g. reboot command) machine_restart() from >>> arch/arm/kernel/reboot.c is called. Please correct me if I'm wrong. >> >> Another location is cpu_reset() aka cpu_arm926_reset() in proc-arm926.S >> which also disables I-cache. But I can't track down a callstack >> ending there. >> > > We take the normal path of sys_reboot => kernel_restart => machine_restart ... > > I added code to print the c1 register in different paths. And I-cache > is enabled. > So now I am really confused about why the patch worked. Just saying... maybe your instructions add some delay on the execution path and this is why it helps... try to access cp15 co-processor for read and write back the value you read without actually to modify it, to see if this could be the reason: e.g.: mrc p15, 0, r0, c1, c0, 0 orr r1, r1, #4096 // whatever is in r1, doesn't matter mcr p15, 0, r0, c1, c0, 0 Thank you, Claudiu Beznea > >> Best regards, >> Alexander > > Jonas > >> >> >> > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset 2018-10-17 13:10 ` Claudiu.Beznea @ 2018-10-19 10:30 ` Jonas Danielsson 2018-10-26 11:05 ` Claudiu.Beznea 0 siblings, 1 reply; 10+ messages in thread From: Jonas Danielsson @ 2018-10-19 10:30 UTC (permalink / raw) To: Claudiu.Beznea Cc: alexander.stein, linux-kernel, Sebastian Reichel, Nicolas Ferre, Alexandre Belloni, linux-pm, linux-arm-kernel On Wed, Oct 17, 2018 at 3:10 PM <Claudiu.Beznea@microchip.com> wrote: > > > > > We take the normal path of sys_reboot => kernel_restart => machine_restart ... > > > > I added code to print the c1 register in different paths. And I-cache > > is enabled. > > So now I am really confused about why the patch worked. > > Just saying... maybe your instructions add some delay on the execution path > and this is why it helps... try to access cp15 co-processor for read and > write back the value you read without actually to modify it, to see if this > could be the reason: e.g.: > > mrc p15, 0, r0, c1, c0, 0 > orr r1, r1, #4096 // whatever is in r1, doesn't matter > mcr p15, 0, r0, c1, c0, 0 > Yes, this also seems to work. I have over 100 reboots completed with this code. So what could be the issue here? It seem related to the powering down of the sdram at least. This thread on the AT91SAM community deals with the same issue: http://www.at91.com/viewtopic.php?t=25830 There the solution people chose was removing the SDRAM powering down. But that leaves one open to the cause of the errata. Do you have any thought on how to approach this? > Thank you, > Claudiu Beznea > Regards Jonas > > > >> Best regards, > >> Alexander > > > > Jonas > > > >> > >> > >> > > > > -- JONAS DANIELSSON Software Developer +46 72 361 5022 Malmö - Sweden ORBITAL SYSTEMS orbital-systems.com The information contained in this message is intended for the personal and confidential use of the designated recipients named above and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error, and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by ORBITAL SYSTEMS AB, its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset 2018-10-19 10:30 ` Jonas Danielsson @ 2018-10-26 11:05 ` Claudiu.Beznea 0 siblings, 0 replies; 10+ messages in thread From: Claudiu.Beznea @ 2018-10-26 11:05 UTC (permalink / raw) To: jonas Cc: alexander.stein, linux-kernel, sre, Nicolas.Ferre, alexandre.belloni, linux-pm, linux-arm-kernel On 19.10.2018 13:30, Jonas Danielsson wrote: > On Wed, Oct 17, 2018 at 3:10 PM <Claudiu.Beznea@microchip.com> wrote: >> >>> >>> We take the normal path of sys_reboot => kernel_restart => machine_restart ... >>> >>> I added code to print the c1 register in different paths. And I-cache >>> is enabled. >>> So now I am really confused about why the patch worked. >> >> Just saying... maybe your instructions add some delay on the execution path >> and this is why it helps... try to access cp15 co-processor for read and >> write back the value you read without actually to modify it, to see if this >> could be the reason: e.g.: >> >> mrc p15, 0, r0, c1, c0, 0 >> orr r1, r1, #4096 // whatever is in r1, doesn't matter >> mcr p15, 0, r0, c1, c0, 0 >> > > Yes, this also seems to work. I have over 100 reboots completed with this code. > So what could be the issue here? It seem related to the powering down > of the sdram at least. I don't know what could be the issue here. > > This thread on the AT91SAM community deals with the same issue: > http://www.at91.com/viewtopic.php?t=25830 > There the solution people chose was removing the SDRAM powering down. > But that leaves one open to the cause of the errata. > > Do you have any thought on how to approach this? For now, no. I didn't dug this issue. Thank you, Claudiu > >> Thank you, >> Claudiu Beznea >> > > Regards > Jonas > > >>> >>>> Best regards, >>>> Alexander >>> >>> Jonas >>> >>>> >>>> >>>> >>> >>> > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset 2018-10-07 12:57 [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset Jonas Danielsson 2018-10-16 13:30 ` Claudiu.Beznea @ 2018-10-16 14:03 ` Alexander Stein 2018-10-16 14:19 ` Jonas Danielsson 1 sibling, 1 reply; 10+ messages in thread From: Alexander Stein @ 2018-10-16 14:03 UTC (permalink / raw) To: Jonas Danielsson Cc: linux-kernel, Sebastian Reichel, Nicolas Ferre, Alexandre Belloni, linux-pm, linux-arm-kernel Do you have CONFIG_CPU_ICACHE_DISABLE enabled? I wonder why I-cache is disabled. I know about this errata, AT91SAM9G20 is affected as well. Best regards, Alexander On Sunday, October 7, 2018, 2:57:45 PM CEST Jonas Danielsson wrote: > From: Jonas Danielsson <jonas@orbital-systems.com> > > This fixes a bug where our embedded system (AT91SAM9260 based) would > hang at reboot. At the most we managed 16 boot loops without a hang. > > With this patch applied the problem has not been observed and the board > has managed above 250 boot loops. > > The AT91SAM9260 datasheet tells us that with the instruction cache > disabled all instructions are fetched from SDRAM. And we have an errata > telling us we must power down the SDRAM before issuing cpu reset. > > This means we need the instruction cache enabled in at91sam9260_reset() > At the moment it is being disabled in cpu_proc_fin() which is called from > arch/arm/kernel/reboot.c. > > Signed-off-by: Jonas Danielsson <jonas@orbital-systems.com> > --- > drivers/power/reset/at91-reset.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c > index f44a9ffcc2ab..78972bba64df 100644 > --- a/drivers/power/reset/at91-reset.c > +++ b/drivers/power/reset/at91-reset.c > @@ -50,14 +50,24 @@ static void __iomem *at91_ramc_base[2], *at91_rstc_base; > static struct clk *sclk; > > /* > -* unless the SDRAM is cleanly shutdown before we hit the > +* Errata 43.1.7.1 RSTC: Reset during SDRAM Accesses > +* > +* Unless the SDRAM is cleanly shutdown before we hit the > * reset register it can be left driving the data bus and > * killing the chance of a subsequent boot from NAND > +* > +* Since we are disabling SDRAM need to make sure that the > +* instruction cache is enabled. > */ > static int at91sam9260_restart(struct notifier_block *this, unsigned long mode, > void *cmd) > { > asm volatile( > + /* Enable I-cache */ > + "mrc p15, 0, r0, c1, c0, 0\n\t" > + "orr r0, r0, #4096\n\t" /* CR_I (bit 12) */ > + "mcr p15, 0, r0, c1, c0, 0\n\t" > + > /* Align to cache lines */ > ".balign 32\n\t" > > -- SYS TEC electronic GmbH Am Windrad 2 08468 Heinsdorfergrund Germany Telefon : +49 (0) 3765 38600-0 Fax : +49 (0) 3765 38600-4100 Email : alexander.stein@systec-electronic.com Website : http://www.systec-electronic.com Managing Director : Dipl.-Phys. Siegmar Schmidt Commercial registry : Amtsgericht Chemnitz, HRB 28082 USt.-Id Nr. : DE150534010 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset 2018-10-16 14:03 ` Alexander Stein @ 2018-10-16 14:19 ` Jonas Danielsson 0 siblings, 0 replies; 10+ messages in thread From: Jonas Danielsson @ 2018-10-16 14:19 UTC (permalink / raw) To: alexander.stein Cc: linux-kernel, Sebastian Reichel, Nicolas Ferre, Alexandre Belloni, linux-pm, linux-arm-kernel On Tue, Oct 16, 2018 at 4:03 PM Alexander Stein <alexander.stein@systec-electronic.com> wrote: > > Do you have CONFIG_CPU_ICACHE_DISABLE enabled? > I wonder why I-cache is disabled. I know about this errata, AT91SAM9G20 is affected as well. > Hi Alexander! I just checked, we do not have CONFIG_CPU_ICACHE_DISABLE enabled. I wonder as well! If you have any idea I can try them out on my board tomorrow! The effect of enabling them is real. I have managed over 1000 reboots with this patch. And at the most 20 without. > Best regards, > Alexander Jonas > > On Sunday, October 7, 2018, 2:57:45 PM CEST Jonas Danielsson wrote: > > From: Jonas Danielsson <jonas@orbital-systems.com> > > > > This fixes a bug where our embedded system (AT91SAM9260 based) would > > hang at reboot. At the most we managed 16 boot loops without a hang. > > > > With this patch applied the problem has not been observed and the board > > has managed above 250 boot loops. > > > > The AT91SAM9260 datasheet tells us that with the instruction cache > > disabled all instructions are fetched from SDRAM. And we have an errata > > telling us we must power down the SDRAM before issuing cpu reset. > > > > This means we need the instruction cache enabled in at91sam9260_reset() > > At the moment it is being disabled in cpu_proc_fin() which is called from > > arch/arm/kernel/reboot.c. > > > > Signed-off-by: Jonas Danielsson <jonas@orbital-systems.com> > > --- > > drivers/power/reset/at91-reset.c | 12 +++++++++++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c > > index f44a9ffcc2ab..78972bba64df 100644 > > --- a/drivers/power/reset/at91-reset.c > > +++ b/drivers/power/reset/at91-reset.c > > @@ -50,14 +50,24 @@ static void __iomem *at91_ramc_base[2], *at91_rstc_base; > > static struct clk *sclk; > > > > /* > > -* unless the SDRAM is cleanly shutdown before we hit the > > +* Errata 43.1.7.1 RSTC: Reset during SDRAM Accesses > > +* > > +* Unless the SDRAM is cleanly shutdown before we hit the > > * reset register it can be left driving the data bus and > > * killing the chance of a subsequent boot from NAND > > +* > > +* Since we are disabling SDRAM need to make sure that the > > +* instruction cache is enabled. > > */ > > static int at91sam9260_restart(struct notifier_block *this, unsigned long mode, > > void *cmd) > > { > > asm volatile( > > + /* Enable I-cache */ > > + "mrc p15, 0, r0, c1, c0, 0\n\t" > > + "orr r0, r0, #4096\n\t" /* CR_I (bit 12) */ > > + "mcr p15, 0, r0, c1, c0, 0\n\t" > > + > > /* Align to cache lines */ > > ".balign 32\n\t" > > > > > > > -- > SYS TEC electronic GmbH > Am Windrad 2 > 08468 Heinsdorfergrund > Germany > Telefon : +49 (0) 3765 38600-0 > Fax : +49 (0) 3765 38600-4100 > Email : alexander.stein@systec-electronic.com > Website : http://www.systec-electronic.com > > Managing Director : Dipl.-Phys. Siegmar Schmidt > Commercial registry : Amtsgericht Chemnitz, HRB 28082 > USt.-Id Nr. : DE150534010 > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. > Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. > > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. > Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > > -- JONAS DANIELSSON Software Developer +46 72 361 5022 Malmö - Sweden ORBITAL SYSTEMS orbital-systems.com The information contained in this message is intended for the personal and confidential use of the designated recipients named above and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error, and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by ORBITAL SYSTEMS AB, its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-10-26 11:05 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-07 12:57 [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset Jonas Danielsson 2018-10-16 13:30 ` Claudiu.Beznea 2018-10-16 14:15 ` Jonas Danielsson 2018-10-16 14:52 ` Alexander Stein 2018-10-17 12:17 ` Jonas Danielsson 2018-10-17 13:10 ` Claudiu.Beznea 2018-10-19 10:30 ` Jonas Danielsson 2018-10-26 11:05 ` Claudiu.Beznea 2018-10-16 14:03 ` Alexander Stein 2018-10-16 14:19 ` Jonas Danielsson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).