[PATCH 0/1] ARM: pxa168: fix corrected reset vector

[PATCH 0/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

Reset vector for pxa168 is 0xffff_0000 not 0x0
This fix allows reboot to work

Mark F. Brown (1):
  ARM: pxa168: fix corrected reset vector

 arch/arm/mach-mmp/include/mach/system.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

[PATCH 0/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

Reset vector for pxa168 is 0xffff_0000 not 0x0
This fix allows reboot to work

Mark F. Brown (1):
  ARM: pxa168: fix corrected reset vector

 arch/arm/mach-mmp/include/mach/system.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
---
 arch/arm/mach-mmp/include/mach/system.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
index 4f5b0e0..926e9c0 100644
--- a/arch/arm/mach-mmp/include/mach/system.h
+++ b/arch/arm/mach-mmp/include/mach/system.h
@@ -16,6 +16,6 @@ static inline void arch_idle(void)
 
 static inline void arch_reset(char mode, const char *cmd)
 {
-	cpu_reset(0);
+	cpu_reset(0xffff0000);
 }
 #endif /* __ASM_MACH_SYSTEM_H */
-- 
1.7.0.4

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
---
 arch/arm/mach-mmp/include/mach/system.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
index 4f5b0e0..926e9c0 100644
--- a/arch/arm/mach-mmp/include/mach/system.h
+++ b/arch/arm/mach-mmp/include/mach/system.h
@@ -16,6 +16,6 @@ static inline void arch_idle(void)
 
 static inline void arch_reset(char mode, const char *cmd)
 {
-	cpu_reset(0);
+	cpu_reset(0xffff0000);
 }
 #endif /* __ASM_MACH_SYSTEM_H */
-- 
1.7.0.4

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
> ---
>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
> index 4f5b0e0..926e9c0 100644
> --- a/arch/arm/mach-mmp/include/mach/system.h
> +++ b/arch/arm/mach-mmp/include/mach/system.h
> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>
>  static inline void arch_reset(char mode, const char *cmd)
>  {
> -       cpu_reset(0);
> +       cpu_reset(0xffff0000);

Not sure if this correct. But normally reset jump happens after we turn
off the MMU and so on. Ain't the BootROM starts from 0 ?

>  }
>  #endif /* __ASM_MACH_SYSTEM_H */
> --
> 1.7.0.4
>
>

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
> ---
> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
> index 4f5b0e0..926e9c0 100644
> --- a/arch/arm/mach-mmp/include/mach/system.h
> +++ b/arch/arm/mach-mmp/include/mach/system.h
> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>
> ?static inline void arch_reset(char mode, const char *cmd)
> ?{
> - ? ? ? cpu_reset(0);
> + ? ? ? cpu_reset(0xffff0000);

Not sure if this correct. But normally reset jump happens after we turn
off the MMU and so on. Ain't the BootROM starts from 0 ?

> ?}
> ?#endif /* __ASM_MACH_SYSTEM_H */
> --
> 1.7.0.4
>
>

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>> ---
>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>> index 4f5b0e0..926e9c0 100644
>> --- a/arch/arm/mach-mmp/include/mach/system.h
>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>
>>  static inline void arch_reset(char mode, const char *cmd)
>>  {
>> -       cpu_reset(0);
>> +       cpu_reset(0xffff0000);
>
> Not sure if this correct. But normally reset jump happens after we turn
> off the MMU and so on. Ain't the BootROM starts from 0 ?
>
>>  }
>>  #endif /* __ASM_MACH_SYSTEM_H */
>> --
>> 1.7.0.4
>>
>>
>

Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
about that! If you set the reset vector to 0x0 it will crash during
reboot. I will send you xdb snapshots if you need me to.

Regards,
-- Mark

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>> ---
>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>> index 4f5b0e0..926e9c0 100644
>> --- a/arch/arm/mach-mmp/include/mach/system.h
>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>
>> ?static inline void arch_reset(char mode, const char *cmd)
>> ?{
>> - ? ? ? cpu_reset(0);
>> + ? ? ? cpu_reset(0xffff0000);
>
> Not sure if this correct. But normally reset jump happens after we turn
> off the MMU and so on. Ain't the BootROM starts from 0 ?
>
>> ?}
>> ?#endif /* __ASM_MACH_SYSTEM_H */
>> --
>> 1.7.0.4
>>
>>
>

Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
about that! If you set the reset vector to 0x0 it will crash during
reboot. I will send you xdb snapshots if you need me to.

Regards,
-- Mark

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>> ---
>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>> index 4f5b0e0..926e9c0 100644
>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>
>>>  static inline void arch_reset(char mode, const char *cmd)
>>>  {
>>> -       cpu_reset(0);
>>> +       cpu_reset(0xffff0000);
>>
>> Not sure if this correct. But normally reset jump happens after we turn
>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>
>>>  }
>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>> --
>>> 1.7.0.4
>>>
>>>
>>
>
> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
> about that! If you set the reset vector to 0x0 it will crash during
> reboot. I will send you xdb snapshots if you need me to.
>

OK, you are expert on this :-)

Applied to 'fix'.

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>> ---
>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>> index 4f5b0e0..926e9c0 100644
>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>
>>> ?static inline void arch_reset(char mode, const char *cmd)
>>> ?{
>>> - ? ? ? cpu_reset(0);
>>> + ? ? ? cpu_reset(0xffff0000);
>>
>> Not sure if this correct. But normally reset jump happens after we turn
>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>
>>> ?}
>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>> --
>>> 1.7.0.4
>>>
>>>
>>
>
> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
> about that! If you set the reset vector to 0x0 it will crash during
> reboot. I will send you xdb snapshots if you need me to.
>

OK, you are expert on this :-)

Applied to 'fix'.

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>> ---
>>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>> index 4f5b0e0..926e9c0 100644
>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>
>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>  {
>>>> -       cpu_reset(0);
>>>> +       cpu_reset(0xffff0000);
>>>
>>> Not sure if this correct. But normally reset jump happens after we turn
>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>
>>>>  }
>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>> --
>>>> 1.7.0.4
>>>>
>>>>
>>>
>>
>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>> about that! If you set the reset vector to 0x0 it will crash during
>> reboot. I will send you xdb snapshots if you need me to.
>>
>
> OK, you are expert on this :-)
>
> Applied to 'fix'.
>

One moment. Since this is really global to pxa910 and mmp2, so I
suggest this being fixed for pxa168 only first. How about this:

    ARM: pxa168: fix corrected reset vector

    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
    reboot to work

    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>

diff --git a/arch/arm/mach-mmp/include/mach/system.h
b/arch/arm/mach-mmp/include/mach/system.h
index 4f5b0e0..1a8a25e 100644
--- a/arch/arm/mach-mmp/include/mach/system.h
+++ b/arch/arm/mach-mmp/include/mach/system.h
@@ -9,6 +9,8 @@
 #ifndef __ASM_MACH_SYSTEM_H
 #define __ASM_MACH_SYSTEM_H

+#include <mach/cputype.h>
+
 static inline void arch_idle(void)
 {
 	cpu_do_idle();
@@ -16,6 +18,9 @@ static inline void arch_idle(void)

 static inline void arch_reset(char mode, const char *cmd)
 {
-	cpu_reset(0);
+	if (cpu_is_pxa168())
+		cpu_reset(0xffff0000);
+	else
+		cpu_reset(0);
 }
 #endif /* __ASM_MACH_SYSTEM_H */

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>> ---
>>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>> index 4f5b0e0..926e9c0 100644
>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>
>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>> ?{
>>>> - ? ? ? cpu_reset(0);
>>>> + ? ? ? cpu_reset(0xffff0000);
>>>
>>> Not sure if this correct. But normally reset jump happens after we turn
>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>
>>>> ?}
>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>> --
>>>> 1.7.0.4
>>>>
>>>>
>>>
>>
>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>> about that! If you set the reset vector to 0x0 it will crash during
>> reboot. I will send you xdb snapshots if you need me to.
>>
>
> OK, you are expert on this :-)
>
> Applied to 'fix'.
>

One moment. Since this is really global to pxa910 and mmp2, so I
suggest this being fixed for pxa168 only first. How about this:

    ARM: pxa168: fix corrected reset vector

    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
    reboot to work

    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>

diff --git a/arch/arm/mach-mmp/include/mach/system.h
b/arch/arm/mach-mmp/include/mach/system.h
index 4f5b0e0..1a8a25e 100644
--- a/arch/arm/mach-mmp/include/mach/system.h
+++ b/arch/arm/mach-mmp/include/mach/system.h
@@ -9,6 +9,8 @@
 #ifndef __ASM_MACH_SYSTEM_H
 #define __ASM_MACH_SYSTEM_H

+#include <mach/cputype.h>
+
 static inline void arch_idle(void)
 {
 	cpu_do_idle();
@@ -16,6 +18,9 @@ static inline void arch_idle(void)

 static inline void arch_reset(char mode, const char *cmd)
 {
-	cpu_reset(0);
+	if (cpu_is_pxa168())
+		cpu_reset(0xffff0000);
+	else
+		cpu_reset(0);
 }
 #endif /* __ASM_MACH_SYSTEM_H */

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Haojian Zhuang]

On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>> ---
>>>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>> index 4f5b0e0..926e9c0 100644
>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>
>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>  {
>>>>> -       cpu_reset(0);
>>>>> +       cpu_reset(0xffff0000);
>>>>
>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>
>>>>>  }
>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>> --
>>>>> 1.7.0.4
>>>>>
>>>>>
>>>>
>>>
>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>> about that! If you set the reset vector to 0x0 it will crash during
>>> reboot. I will send you xdb snapshots if you need me to.
>>>
>>
>> OK, you are expert on this :-)
>>
>> Applied to 'fix'.
>>
>
> One moment. Since this is really global to pxa910 and mmp2, so I
> suggest this being fixed for pxa168 only first. How about this:
>
>    ARM: pxa168: fix corrected reset vector
>
>    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>    reboot to work
>
>    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>
> diff --git a/arch/arm/mach-mmp/include/mach/system.h
> b/arch/arm/mach-mmp/include/mach/system.h
> index 4f5b0e0..1a8a25e 100644
> --- a/arch/arm/mach-mmp/include/mach/system.h
> +++ b/arch/arm/mach-mmp/include/mach/system.h
> @@ -9,6 +9,8 @@
>  #ifndef __ASM_MACH_SYSTEM_H
>  #define __ASM_MACH_SYSTEM_H
>
> +#include <mach/cputype.h>
> +
>  static inline void arch_idle(void)
>  {
>        cpu_do_idle();
> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>
>  static inline void arch_reset(char mode, const char *cmd)
>  {
> -       cpu_reset(0);
> +       if (cpu_is_pxa168())
> +               cpu_reset(0xffff0000);
> +       else
> +               cpu_reset(0);
>  }
>  #endif /* __ASM_MACH_SYSTEM_H */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
The reset code is in below.

	.align	5
ENTRY(cpu_mohawk_reset)
	mov	ip, #0
	mcr	p15, 0, ip, c7, c7, 0		@ invalidate I,D caches
	mcr	p15, 0, ip, c7, c10, 4		@ drain WB
	mcr	p15, 0, ip, c8, c7, 0		@ invalidate I & D TLBs
	mrc	p15, 0, ip, c1, c0, 0		@ ctrl register
	bic	ip, ip, #0x0007			@ .............cam
	bic	ip, ip, #0x1100			@ ...i...s........
	mcr	p15, 0, ip, c1, c0, 0		@ ctrl register
	mov	pc, r0

MMU is disabled at here and replace PC with r0 value. I doubt code
executed correctly at here. While MMU is disabled, the PC should be
continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
shouldn't be executed. Instruction fetch failure should occurs since
there's no physical address in 0xCxxx_xxxx.

Correct me if I'm wrong.

Thanks
Haojian

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Haojian Zhuang]

On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>> ---
>>>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>> index 4f5b0e0..926e9c0 100644
>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>
>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>> ?{
>>>>> - ? ? ? cpu_reset(0);
>>>>> + ? ? ? cpu_reset(0xffff0000);
>>>>
>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>
>>>>> ?}
>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>> --
>>>>> 1.7.0.4
>>>>>
>>>>>
>>>>
>>>
>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>> about that! If you set the reset vector to 0x0 it will crash during
>>> reboot. I will send you xdb snapshots if you need me to.
>>>
>>
>> OK, you are expert on this :-)
>>
>> Applied to 'fix'.
>>
>
> One moment. Since this is really global to pxa910 and mmp2, so I
> suggest this being fixed for pxa168 only first. How about this:
>
> ? ?ARM: pxa168: fix corrected reset vector
>
> ? ?Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
> ? ?reboot to work
>
> ? ?Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>
> diff --git a/arch/arm/mach-mmp/include/mach/system.h
> b/arch/arm/mach-mmp/include/mach/system.h
> index 4f5b0e0..1a8a25e 100644
> --- a/arch/arm/mach-mmp/include/mach/system.h
> +++ b/arch/arm/mach-mmp/include/mach/system.h
> @@ -9,6 +9,8 @@
> ?#ifndef __ASM_MACH_SYSTEM_H
> ?#define __ASM_MACH_SYSTEM_H
>
> +#include <mach/cputype.h>
> +
> ?static inline void arch_idle(void)
> ?{
> ? ? ? ?cpu_do_idle();
> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>
> ?static inline void arch_reset(char mode, const char *cmd)
> ?{
> - ? ? ? cpu_reset(0);
> + ? ? ? if (cpu_is_pxa168())
> + ? ? ? ? ? ? ? cpu_reset(0xffff0000);
> + ? ? ? else
> + ? ? ? ? ? ? ? cpu_reset(0);
> ?}
> ?#endif /* __ASM_MACH_SYSTEM_H */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
The reset code is in below.

	.align	5
ENTRY(cpu_mohawk_reset)
	mov	ip, #0
	mcr	p15, 0, ip, c7, c7, 0		@ invalidate I,D caches
	mcr	p15, 0, ip, c7, c10, 4		@ drain WB
	mcr	p15, 0, ip, c8, c7, 0		@ invalidate I & D TLBs
	mrc	p15, 0, ip, c1, c0, 0		@ ctrl register
	bic	ip, ip, #0x0007			@ .............cam
	bic	ip, ip, #0x1100			@ ...i...s........
	mcr	p15, 0, ip, c1, c0, 0		@ ctrl register
	mov	pc, r0

MMU is disabled at here and replace PC with r0 value. I doubt code
executed correctly at here. While MMU is disabled, the PC should be
continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
shouldn't be executed. Instruction fetch failure should occurs since
there's no physical address in 0xCxxx_xxxx.

Correct me if I'm wrong.

Thanks
Haojian

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>> ---
>>>>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>
>>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>>  {
>>>>>> -       cpu_reset(0);
>>>>>> +       cpu_reset(0xffff0000);
>>>>>
>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>
>>>>>>  }
>>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>>> --
>>>>>> 1.7.0.4
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>
>>>
>>> OK, you are expert on this :-)
>>>
>>> Applied to 'fix'.
>>>
>>
>> One moment. Since this is really global to pxa910 and mmp2, so I
>> suggest this being fixed for pxa168 only first. How about this:
>>
>>    ARM: pxa168: fix corrected reset vector
>>
>>    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>    reboot to work
>>
>>    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>
>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>> b/arch/arm/mach-mmp/include/mach/system.h
>> index 4f5b0e0..1a8a25e 100644
>> --- a/arch/arm/mach-mmp/include/mach/system.h
>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>> @@ -9,6 +9,8 @@
>>  #ifndef __ASM_MACH_SYSTEM_H
>>  #define __ASM_MACH_SYSTEM_H
>>
>> +#include <mach/cputype.h>
>> +
>>  static inline void arch_idle(void)
>>  {
>>        cpu_do_idle();
>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>
>>  static inline void arch_reset(char mode, const char *cmd)
>>  {
>> -       cpu_reset(0);
>> +       if (cpu_is_pxa168())
>> +               cpu_reset(0xffff0000);
>> +       else
>> +               cpu_reset(0);
>>  }
>>  #endif /* __ASM_MACH_SYSTEM_H */
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
> The reset code is in below.
>
>        .align  5
> ENTRY(cpu_mohawk_reset)
>        mov     ip, #0
>        mcr     p15, 0, ip, c7, c7, 0           @ invalidate I,D caches
>        mcr     p15, 0, ip, c7, c10, 4          @ drain WB
>        mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
>        mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
>        bic     ip, ip, #0x0007                 @ .............cam
>        bic     ip, ip, #0x1100                 @ ...i...s........
>        mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
>        mov     pc, r0
>
> MMU is disabled at here and replace PC with r0 value. I doubt code
> executed correctly at here. While MMU is disabled, the PC should be
> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
> shouldn't be executed. Instruction fetch failure should occurs since
> there's no physical address in 0xCxxx_xxxx.
>
> Correct me if I'm wrong.
>
> Thanks
> Haojian
>

Haojian,

I think there is a pipeline execution of the mov pc, r0 instruction.
If I remember correctly you need to do a similar jump when you turn
the MMU on in early boot code. If it makes any difference I did test
this code on pxa168 before submitting it. I will double check the mmp2
and the pxa910 reset vectors with the Boot ROM developers.

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>> ---
>>>>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>
>>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>>> ?{
>>>>>> - ? ? ? cpu_reset(0);
>>>>>> + ? ? ? cpu_reset(0xffff0000);
>>>>>
>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>
>>>>>> ?}
>>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>>> --
>>>>>> 1.7.0.4
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>
>>>
>>> OK, you are expert on this :-)
>>>
>>> Applied to 'fix'.
>>>
>>
>> One moment. Since this is really global to pxa910 and mmp2, so I
>> suggest this being fixed for pxa168 only first. How about this:
>>
>> ? ?ARM: pxa168: fix corrected reset vector
>>
>> ? ?Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>> ? ?reboot to work
>>
>> ? ?Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>
>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>> b/arch/arm/mach-mmp/include/mach/system.h
>> index 4f5b0e0..1a8a25e 100644
>> --- a/arch/arm/mach-mmp/include/mach/system.h
>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>> @@ -9,6 +9,8 @@
>> ?#ifndef __ASM_MACH_SYSTEM_H
>> ?#define __ASM_MACH_SYSTEM_H
>>
>> +#include <mach/cputype.h>
>> +
>> ?static inline void arch_idle(void)
>> ?{
>> ? ? ? ?cpu_do_idle();
>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>
>> ?static inline void arch_reset(char mode, const char *cmd)
>> ?{
>> - ? ? ? cpu_reset(0);
>> + ? ? ? if (cpu_is_pxa168())
>> + ? ? ? ? ? ? ? cpu_reset(0xffff0000);
>> + ? ? ? else
>> + ? ? ? ? ? ? ? cpu_reset(0);
>> ?}
>> ?#endif /* __ASM_MACH_SYSTEM_H */
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at ?http://www.tux.org/lkml/
>>
> The reset code is in below.
>
> ? ? ? ?.align ?5
> ENTRY(cpu_mohawk_reset)
> ? ? ? ?mov ? ? ip, #0
> ? ? ? ?mcr ? ? p15, 0, ip, c7, c7, 0 ? ? ? ? ? @ invalidate I,D caches
> ? ? ? ?mcr ? ? p15, 0, ip, c7, c10, 4 ? ? ? ? ?@ drain WB
> ? ? ? ?mcr ? ? p15, 0, ip, c8, c7, 0 ? ? ? ? ? @ invalidate I & D TLBs
> ? ? ? ?mrc ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
> ? ? ? ?bic ? ? ip, ip, #0x0007 ? ? ? ? ? ? ? ? @ .............cam
> ? ? ? ?bic ? ? ip, ip, #0x1100 ? ? ? ? ? ? ? ? @ ...i...s........
> ? ? ? ?mcr ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
> ? ? ? ?mov ? ? pc, r0
>
> MMU is disabled at here and replace PC with r0 value. I doubt code
> executed correctly at here. While MMU is disabled, the PC should be
> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
> shouldn't be executed. Instruction fetch failure should occurs since
> there's no physical address in 0xCxxx_xxxx.
>
> Correct me if I'm wrong.
>
> Thanks
> Haojian
>

Haojian,

I think there is a pipeline execution of the mov pc, r0 instruction.
If I remember correctly you need to do a similar jump when you turn
the MMU on in early boot code. If it makes any difference I did test
this code on pxa168 before submitting it. I will double check the mmp2
and the pxa910 reset vectors with the Boot ROM developers.

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>> ---
>>>>>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>
>>>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>>>  {
>>>>>>> -       cpu_reset(0);
>>>>>>> +       cpu_reset(0xffff0000);
>>>>>>
>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>
>>>>>>>  }
>>>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>>>> --
>>>>>>> 1.7.0.4
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>
>>>>
>>>> OK, you are expert on this :-)
>>>>
>>>> Applied to 'fix'.
>>>>
>>>
>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>> suggest this being fixed for pxa168 only first. How about this:
>>>
>>>    ARM: pxa168: fix corrected reset vector
>>>
>>>    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>    reboot to work
>>>
>>>    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>
>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>> b/arch/arm/mach-mmp/include/mach/system.h
>>> index 4f5b0e0..1a8a25e 100644
>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>> @@ -9,6 +9,8 @@
>>>  #ifndef __ASM_MACH_SYSTEM_H
>>>  #define __ASM_MACH_SYSTEM_H
>>>
>>> +#include <mach/cputype.h>
>>> +
>>>  static inline void arch_idle(void)
>>>  {
>>>        cpu_do_idle();
>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>
>>>  static inline void arch_reset(char mode, const char *cmd)
>>>  {
>>> -       cpu_reset(0);
>>> +       if (cpu_is_pxa168())
>>> +               cpu_reset(0xffff0000);
>>> +       else
>>> +               cpu_reset(0);
>>>  }
>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
>> The reset code is in below.
>>
>>        .align  5
>> ENTRY(cpu_mohawk_reset)
>>        mov     ip, #0
>>        mcr     p15, 0, ip, c7, c7, 0           @ invalidate I,D caches
>>        mcr     p15, 0, ip, c7, c10, 4          @ drain WB
>>        mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
>>        mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
>>        bic     ip, ip, #0x0007                 @ .............cam
>>        bic     ip, ip, #0x1100                 @ ...i...s........
>>        mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
>>        mov     pc, r0
>>
>> MMU is disabled at here and replace PC with r0 value. I doubt code
>> executed correctly at here. While MMU is disabled, the PC should be
>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>> shouldn't be executed. Instruction fetch failure should occurs since
>> there's no physical address in 0xCxxx_xxxx.
>>
>> Correct me if I'm wrong.
>>
>> Thanks
>> Haojian
>>
>
> Haojian,
>
> I think there is a pipeline execution of the mov pc, r0 instruction.

It does depend on the prefetch unit for that. So the branch instruction
should follow right after the mcr one.

> If I remember correctly you need to do a similar jump when you turn
> the MMU on in early boot code. If it makes any difference I did test
> this code on pxa168 before submitting it. I will double check the mmp2
> and the pxa910 reset vectors with the Boot ROM developers.
>

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>> ---
>>>>>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>>>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>
>>>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>>>> ?{
>>>>>>> - ? ? ? cpu_reset(0);
>>>>>>> + ? ? ? cpu_reset(0xffff0000);
>>>>>>
>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>
>>>>>>> ?}
>>>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>>>> --
>>>>>>> 1.7.0.4
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>
>>>>
>>>> OK, you are expert on this :-)
>>>>
>>>> Applied to 'fix'.
>>>>
>>>
>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>> suggest this being fixed for pxa168 only first. How about this:
>>>
>>> ? ?ARM: pxa168: fix corrected reset vector
>>>
>>> ? ?Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>> ? ?reboot to work
>>>
>>> ? ?Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>
>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>> b/arch/arm/mach-mmp/include/mach/system.h
>>> index 4f5b0e0..1a8a25e 100644
>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>> @@ -9,6 +9,8 @@
>>> ?#ifndef __ASM_MACH_SYSTEM_H
>>> ?#define __ASM_MACH_SYSTEM_H
>>>
>>> +#include <mach/cputype.h>
>>> +
>>> ?static inline void arch_idle(void)
>>> ?{
>>> ? ? ? ?cpu_do_idle();
>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>
>>> ?static inline void arch_reset(char mode, const char *cmd)
>>> ?{
>>> - ? ? ? cpu_reset(0);
>>> + ? ? ? if (cpu_is_pxa168())
>>> + ? ? ? ? ? ? ? cpu_reset(0xffff0000);
>>> + ? ? ? else
>>> + ? ? ? ? ? ? ? cpu_reset(0);
>>> ?}
>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at ?http://www.tux.org/lkml/
>>>
>> The reset code is in below.
>>
>> ? ? ? ?.align ?5
>> ENTRY(cpu_mohawk_reset)
>> ? ? ? ?mov ? ? ip, #0
>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c7, 0 ? ? ? ? ? @ invalidate I,D caches
>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c10, 4 ? ? ? ? ?@ drain WB
>> ? ? ? ?mcr ? ? p15, 0, ip, c8, c7, 0 ? ? ? ? ? @ invalidate I & D TLBs
>> ? ? ? ?mrc ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>> ? ? ? ?bic ? ? ip, ip, #0x0007 ? ? ? ? ? ? ? ? @ .............cam
>> ? ? ? ?bic ? ? ip, ip, #0x1100 ? ? ? ? ? ? ? ? @ ...i...s........
>> ? ? ? ?mcr ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>> ? ? ? ?mov ? ? pc, r0
>>
>> MMU is disabled at here and replace PC with r0 value. I doubt code
>> executed correctly at here. While MMU is disabled, the PC should be
>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>> shouldn't be executed. Instruction fetch failure should occurs since
>> there's no physical address in 0xCxxx_xxxx.
>>
>> Correct me if I'm wrong.
>>
>> Thanks
>> Haojian
>>
>
> Haojian,
>
> I think there is a pipeline execution of the mov pc, r0 instruction.

It does depend on the prefetch unit for that. So the branch instruction
should follow right after the mcr one.

> If I remember correctly you need to do a similar jump when you turn
> the MMU on in early boot code. If it makes any difference I did test
> this code on pxa168 before submitting it. I will double check the mmp2
> and the pxa910 reset vectors with the Boot ROM developers.
>

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Haojian Zhuang]

On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>> ---
>>>>>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>
>>>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>>>  {
>>>>>>> -       cpu_reset(0);
>>>>>>> +       cpu_reset(0xffff0000);
>>>>>>
>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>
>>>>>>>  }
>>>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>>>> --
>>>>>>> 1.7.0.4
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>
>>>>
>>>> OK, you are expert on this :-)
>>>>
>>>> Applied to 'fix'.
>>>>
>>>
>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>> suggest this being fixed for pxa168 only first. How about this:
>>>
>>>    ARM: pxa168: fix corrected reset vector
>>>
>>>    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>    reboot to work
>>>
>>>    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>
>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>> b/arch/arm/mach-mmp/include/mach/system.h
>>> index 4f5b0e0..1a8a25e 100644
>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>> @@ -9,6 +9,8 @@
>>>  #ifndef __ASM_MACH_SYSTEM_H
>>>  #define __ASM_MACH_SYSTEM_H
>>>
>>> +#include <mach/cputype.h>
>>> +
>>>  static inline void arch_idle(void)
>>>  {
>>>        cpu_do_idle();
>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>
>>>  static inline void arch_reset(char mode, const char *cmd)
>>>  {
>>> -       cpu_reset(0);
>>> +       if (cpu_is_pxa168())
>>> +               cpu_reset(0xffff0000);
>>> +       else
>>> +               cpu_reset(0);
>>>  }
>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
>> The reset code is in below.
>>
>>        .align  5
>> ENTRY(cpu_mohawk_reset)
>>        mov     ip, #0
>>        mcr     p15, 0, ip, c7, c7, 0           @ invalidate I,D caches
>>        mcr     p15, 0, ip, c7, c10, 4          @ drain WB
>>        mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
>>        mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
>>        bic     ip, ip, #0x0007                 @ .............cam
>>        bic     ip, ip, #0x1100                 @ ...i...s........
>>        mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
>>        mov     pc, r0
>>
>> MMU is disabled at here and replace PC with r0 value. I doubt code
>> executed correctly at here. While MMU is disabled, the PC should be
>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>> shouldn't be executed. Instruction fetch failure should occurs since
>> there's no physical address in 0xCxxx_xxxx.
>>
>> Correct me if I'm wrong.
>>
>> Thanks
>> Haojian
>>
>
> Haojian,
>
> I think there is a pipeline execution of the mov pc, r0 instruction.
> If I remember correctly you need to do a similar jump when you turn
> the MMU on in early boot code. If it makes any difference I did test
> this code on pxa168 before submitting it. I will double check the mmp2
> and the pxa910 reset vectors with the Boot ROM developers.
>

In early boot code, 1:1 (physical:virtual) mapping is used. It means
that physical address is same as virtual address. So you can operature
mmu as you wish.

By the way, I don't suggest to reset CPU by this way. Reset is not
only make code running from the head, it should also clear registers
and RTL logic in CPU.

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Haojian Zhuang]

On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>> ---
>>>>>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>>>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>
>>>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>>>> ?{
>>>>>>> - ? ? ? cpu_reset(0);
>>>>>>> + ? ? ? cpu_reset(0xffff0000);
>>>>>>
>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>
>>>>>>> ?}
>>>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>>>> --
>>>>>>> 1.7.0.4
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>
>>>>
>>>> OK, you are expert on this :-)
>>>>
>>>> Applied to 'fix'.
>>>>
>>>
>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>> suggest this being fixed for pxa168 only first. How about this:
>>>
>>> ? ?ARM: pxa168: fix corrected reset vector
>>>
>>> ? ?Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>> ? ?reboot to work
>>>
>>> ? ?Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>
>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>> b/arch/arm/mach-mmp/include/mach/system.h
>>> index 4f5b0e0..1a8a25e 100644
>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>> @@ -9,6 +9,8 @@
>>> ?#ifndef __ASM_MACH_SYSTEM_H
>>> ?#define __ASM_MACH_SYSTEM_H
>>>
>>> +#include <mach/cputype.h>
>>> +
>>> ?static inline void arch_idle(void)
>>> ?{
>>> ? ? ? ?cpu_do_idle();
>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>
>>> ?static inline void arch_reset(char mode, const char *cmd)
>>> ?{
>>> - ? ? ? cpu_reset(0);
>>> + ? ? ? if (cpu_is_pxa168())
>>> + ? ? ? ? ? ? ? cpu_reset(0xffff0000);
>>> + ? ? ? else
>>> + ? ? ? ? ? ? ? cpu_reset(0);
>>> ?}
>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at ?http://www.tux.org/lkml/
>>>
>> The reset code is in below.
>>
>> ? ? ? ?.align ?5
>> ENTRY(cpu_mohawk_reset)
>> ? ? ? ?mov ? ? ip, #0
>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c7, 0 ? ? ? ? ? @ invalidate I,D caches
>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c10, 4 ? ? ? ? ?@ drain WB
>> ? ? ? ?mcr ? ? p15, 0, ip, c8, c7, 0 ? ? ? ? ? @ invalidate I & D TLBs
>> ? ? ? ?mrc ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>> ? ? ? ?bic ? ? ip, ip, #0x0007 ? ? ? ? ? ? ? ? @ .............cam
>> ? ? ? ?bic ? ? ip, ip, #0x1100 ? ? ? ? ? ? ? ? @ ...i...s........
>> ? ? ? ?mcr ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>> ? ? ? ?mov ? ? pc, r0
>>
>> MMU is disabled at here and replace PC with r0 value. I doubt code
>> executed correctly at here. While MMU is disabled, the PC should be
>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>> shouldn't be executed. Instruction fetch failure should occurs since
>> there's no physical address in 0xCxxx_xxxx.
>>
>> Correct me if I'm wrong.
>>
>> Thanks
>> Haojian
>>
>
> Haojian,
>
> I think there is a pipeline execution of the mov pc, r0 instruction.
> If I remember correctly you need to do a similar jump when you turn
> the MMU on in early boot code. If it makes any difference I did test
> this code on pxa168 before submitting it. I will double check the mmp2
> and the pxa910 reset vectors with the Boot ROM developers.
>

In early boot code, 1:1 (physical:virtual) mapping is used. It means
that physical address is same as virtual address. So you can operature
mmu as you wish.

By the way, I don't suggest to reset CPU by this way. Reset is not
only make code running from the head, it should also clear registers
and RTL logic in CPU.

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>> <haojian.zhuang@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>> ---
>>>>>>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>>
>>>>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>>>>  {
>>>>>>>> -       cpu_reset(0);
>>>>>>>> +       cpu_reset(0xffff0000);
>>>>>>>
>>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>>
>>>>>>>>  }
>>>>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>>>>> --
>>>>>>>> 1.7.0.4
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>>
>>>>>
>>>>> OK, you are expert on this :-)
>>>>>
>>>>> Applied to 'fix'.
>>>>>
>>>>
>>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>>> suggest this being fixed for pxa168 only first. How about this:
>>>>
>>>>    ARM: pxa168: fix corrected reset vector
>>>>
>>>>    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>>    reboot to work
>>>>
>>>>    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>
>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>>> b/arch/arm/mach-mmp/include/mach/system.h
>>>> index 4f5b0e0..1a8a25e 100644
>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>> @@ -9,6 +9,8 @@
>>>>  #ifndef __ASM_MACH_SYSTEM_H
>>>>  #define __ASM_MACH_SYSTEM_H
>>>>
>>>> +#include <mach/cputype.h>
>>>> +
>>>>  static inline void arch_idle(void)
>>>>  {
>>>>        cpu_do_idle();
>>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>>
>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>  {
>>>> -       cpu_reset(0);
>>>> +       if (cpu_is_pxa168())
>>>> +               cpu_reset(0xffff0000);
>>>> +       else
>>>> +               cpu_reset(0);
>>>>  }
>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>>
>>> The reset code is in below.
>>>
>>>        .align  5
>>> ENTRY(cpu_mohawk_reset)
>>>        mov     ip, #0
>>>        mcr     p15, 0, ip, c7, c7, 0           @ invalidate I,D caches
>>>        mcr     p15, 0, ip, c7, c10, 4          @ drain WB
>>>        mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
>>>        mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
>>>        bic     ip, ip, #0x0007                 @ .............cam
>>>        bic     ip, ip, #0x1100                 @ ...i...s........
>>>        mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
>>>        mov     pc, r0
>>>
>>> MMU is disabled at here and replace PC with r0 value. I doubt code
>>> executed correctly at here. While MMU is disabled, the PC should be
>>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>>> shouldn't be executed. Instruction fetch failure should occurs since
>>> there's no physical address in 0xCxxx_xxxx.
>>>
>>> Correct me if I'm wrong.
>>>
>>> Thanks
>>> Haojian
>>>
>>
>> Haojian,
>>
>> I think there is a pipeline execution of the mov pc, r0 instruction.
>> If I remember correctly you need to do a similar jump when you turn
>> the MMU on in early boot code. If it makes any difference I did test
>> this code on pxa168 before submitting it. I will double check the mmp2
>> and the pxa910 reset vectors with the Boot ROM developers.
>>
>
> In early boot code, 1:1 (physical:virtual) mapping is used. It means
> that physical address is same as virtual address. So you can operature
> mmu as you wish.
>
> By the way, I don't suggest to reset CPU by this way. Reset is not
> only make code running from the head, it should also clear registers
> and RTL logic in CPU.
>

Depends on if pxa168 has a reset signal asserted from internal or from
external GPIO, which is controllable from the CPU itself. That's what
pxa is doing at this moment.

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>> <haojian.zhuang@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>> ---
>>>>>>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>>>>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>>
>>>>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>>>>> ?{
>>>>>>>> - ? ? ? cpu_reset(0);
>>>>>>>> + ? ? ? cpu_reset(0xffff0000);
>>>>>>>
>>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>>
>>>>>>>> ?}
>>>>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>>>>> --
>>>>>>>> 1.7.0.4
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>>
>>>>>
>>>>> OK, you are expert on this :-)
>>>>>
>>>>> Applied to 'fix'.
>>>>>
>>>>
>>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>>> suggest this being fixed for pxa168 only first. How about this:
>>>>
>>>> ? ?ARM: pxa168: fix corrected reset vector
>>>>
>>>> ? ?Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>> ? ?reboot to work
>>>>
>>>> ? ?Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>
>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>>> b/arch/arm/mach-mmp/include/mach/system.h
>>>> index 4f5b0e0..1a8a25e 100644
>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>> @@ -9,6 +9,8 @@
>>>> ?#ifndef __ASM_MACH_SYSTEM_H
>>>> ?#define __ASM_MACH_SYSTEM_H
>>>>
>>>> +#include <mach/cputype.h>
>>>> +
>>>> ?static inline void arch_idle(void)
>>>> ?{
>>>> ? ? ? ?cpu_do_idle();
>>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>>
>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>> ?{
>>>> - ? ? ? cpu_reset(0);
>>>> + ? ? ? if (cpu_is_pxa168())
>>>> + ? ? ? ? ? ? ? cpu_reset(0xffff0000);
>>>> + ? ? ? else
>>>> + ? ? ? ? ? ? ? cpu_reset(0);
>>>> ?}
>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at ?http://www.tux.org/lkml/
>>>>
>>> The reset code is in below.
>>>
>>> ? ? ? ?.align ?5
>>> ENTRY(cpu_mohawk_reset)
>>> ? ? ? ?mov ? ? ip, #0
>>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c7, 0 ? ? ? ? ? @ invalidate I,D caches
>>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c10, 4 ? ? ? ? ?@ drain WB
>>> ? ? ? ?mcr ? ? p15, 0, ip, c8, c7, 0 ? ? ? ? ? @ invalidate I & D TLBs
>>> ? ? ? ?mrc ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>>> ? ? ? ?bic ? ? ip, ip, #0x0007 ? ? ? ? ? ? ? ? @ .............cam
>>> ? ? ? ?bic ? ? ip, ip, #0x1100 ? ? ? ? ? ? ? ? @ ...i...s........
>>> ? ? ? ?mcr ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>>> ? ? ? ?mov ? ? pc, r0
>>>
>>> MMU is disabled at here and replace PC with r0 value. I doubt code
>>> executed correctly at here. While MMU is disabled, the PC should be
>>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>>> shouldn't be executed. Instruction fetch failure should occurs since
>>> there's no physical address in 0xCxxx_xxxx.
>>>
>>> Correct me if I'm wrong.
>>>
>>> Thanks
>>> Haojian
>>>
>>
>> Haojian,
>>
>> I think there is a pipeline execution of the mov pc, r0 instruction.
>> If I remember correctly you need to do a similar jump when you turn
>> the MMU on in early boot code. If it makes any difference I did test
>> this code on pxa168 before submitting it. I will double check the mmp2
>> and the pxa910 reset vectors with the Boot ROM developers.
>>
>
> In early boot code, 1:1 (physical:virtual) mapping is used. It means
> that physical address is same as virtual address. So you can operature
> mmu as you wish.
>
> By the way, I don't suggest to reset CPU by this way. Reset is not
> only make code running from the head, it should also clear registers
> and RTL logic in CPU.
>

Depends on if pxa168 has a reset signal asserted from internal or from
external GPIO, which is controllable from the CPU itself. That's what
pxa is doing at this moment.

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Haojian Zhuang]

On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>> <haojian.zhuang@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>>> ---
>>>>>>>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>>>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>>>
>>>>>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>>>>>  {
>>>>>>>>> -       cpu_reset(0);
>>>>>>>>> +       cpu_reset(0xffff0000);
>>>>>>>>
>>>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>>>
>>>>>>>>>  }
>>>>>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>>>>>> --
>>>>>>>>> 1.7.0.4
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>>>
>>>>>>
>>>>>> OK, you are expert on this :-)
>>>>>>
>>>>>> Applied to 'fix'.
>>>>>>
>>>>>
>>>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>>>> suggest this being fixed for pxa168 only first. How about this:
>>>>>
>>>>>    ARM: pxa168: fix corrected reset vector
>>>>>
>>>>>    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>>>    reboot to work
>>>>>
>>>>>    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>
>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>>>> b/arch/arm/mach-mmp/include/mach/system.h
>>>>> index 4f5b0e0..1a8a25e 100644
>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>> @@ -9,6 +9,8 @@
>>>>>  #ifndef __ASM_MACH_SYSTEM_H
>>>>>  #define __ASM_MACH_SYSTEM_H
>>>>>
>>>>> +#include <mach/cputype.h>
>>>>> +
>>>>>  static inline void arch_idle(void)
>>>>>  {
>>>>>        cpu_do_idle();
>>>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>>>
>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>  {
>>>>> -       cpu_reset(0);
>>>>> +       if (cpu_is_pxa168())
>>>>> +               cpu_reset(0xffff0000);
>>>>> +       else
>>>>> +               cpu_reset(0);
>>>>>  }
>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>>>
>>>> The reset code is in below.
>>>>
>>>>        .align  5
>>>> ENTRY(cpu_mohawk_reset)
>>>>        mov     ip, #0
>>>>        mcr     p15, 0, ip, c7, c7, 0           @ invalidate I,D caches
>>>>        mcr     p15, 0, ip, c7, c10, 4          @ drain WB
>>>>        mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
>>>>        mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
>>>>        bic     ip, ip, #0x0007                 @ .............cam
>>>>        bic     ip, ip, #0x1100                 @ ...i...s........
>>>>        mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
>>>>        mov     pc, r0
>>>>
>>>> MMU is disabled at here and replace PC with r0 value. I doubt code
>>>> executed correctly at here. While MMU is disabled, the PC should be
>>>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>>>> shouldn't be executed. Instruction fetch failure should occurs since
>>>> there's no physical address in 0xCxxx_xxxx.
>>>>
>>>> Correct me if I'm wrong.
>>>>
>>>> Thanks
>>>> Haojian
>>>>
>>>
>>> Haojian,
>>>
>>> I think there is a pipeline execution of the mov pc, r0 instruction.
>>> If I remember correctly you need to do a similar jump when you turn
>>> the MMU on in early boot code. If it makes any difference I did test
>>> this code on pxa168 before submitting it. I will double check the mmp2
>>> and the pxa910 reset vectors with the Boot ROM developers.
>>>
>>
>> In early boot code, 1:1 (physical:virtual) mapping is used. It means
>> that physical address is same as virtual address. So you can operature
>> mmu as you wish.
>>
>> By the way, I don't suggest to reset CPU by this way. Reset is not
>> only make code running from the head, it should also clear registers
>> and RTL logic in CPU.
>>
>
> Depends on if pxa168 has a reset signal asserted from internal or from
> external GPIO, which is controllable from the CPU itself. That's what
> pxa is doing at this moment.
>

Yes, it depends on reset signal. Watchdog timer is built in pxa168. So
I think that watchdog reset could be better.

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Haojian Zhuang]

On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>> <haojian.zhuang@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>>> ---
>>>>>>>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>>>>>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>>>
>>>>>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>>>>>> ?{
>>>>>>>>> - ? ? ? cpu_reset(0);
>>>>>>>>> + ? ? ? cpu_reset(0xffff0000);
>>>>>>>>
>>>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>>>
>>>>>>>>> ?}
>>>>>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>>>>>> --
>>>>>>>>> 1.7.0.4
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>>>
>>>>>>
>>>>>> OK, you are expert on this :-)
>>>>>>
>>>>>> Applied to 'fix'.
>>>>>>
>>>>>
>>>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>>>> suggest this being fixed for pxa168 only first. How about this:
>>>>>
>>>>> ? ?ARM: pxa168: fix corrected reset vector
>>>>>
>>>>> ? ?Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>>> ? ?reboot to work
>>>>>
>>>>> ? ?Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>
>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>>>> b/arch/arm/mach-mmp/include/mach/system.h
>>>>> index 4f5b0e0..1a8a25e 100644
>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>> @@ -9,6 +9,8 @@
>>>>> ?#ifndef __ASM_MACH_SYSTEM_H
>>>>> ?#define __ASM_MACH_SYSTEM_H
>>>>>
>>>>> +#include <mach/cputype.h>
>>>>> +
>>>>> ?static inline void arch_idle(void)
>>>>> ?{
>>>>> ? ? ? ?cpu_do_idle();
>>>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>>>
>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>> ?{
>>>>> - ? ? ? cpu_reset(0);
>>>>> + ? ? ? if (cpu_is_pxa168())
>>>>> + ? ? ? ? ? ? ? cpu_reset(0xffff0000);
>>>>> + ? ? ? else
>>>>> + ? ? ? ? ? ? ? cpu_reset(0);
>>>>> ?}
>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>>> the body of a message to majordomo at vger.kernel.org
>>>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>>>> Please read the FAQ at ?http://www.tux.org/lkml/
>>>>>
>>>> The reset code is in below.
>>>>
>>>> ? ? ? ?.align ?5
>>>> ENTRY(cpu_mohawk_reset)
>>>> ? ? ? ?mov ? ? ip, #0
>>>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c7, 0 ? ? ? ? ? @ invalidate I,D caches
>>>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c10, 4 ? ? ? ? ?@ drain WB
>>>> ? ? ? ?mcr ? ? p15, 0, ip, c8, c7, 0 ? ? ? ? ? @ invalidate I & D TLBs
>>>> ? ? ? ?mrc ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>>>> ? ? ? ?bic ? ? ip, ip, #0x0007 ? ? ? ? ? ? ? ? @ .............cam
>>>> ? ? ? ?bic ? ? ip, ip, #0x1100 ? ? ? ? ? ? ? ? @ ...i...s........
>>>> ? ? ? ?mcr ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>>>> ? ? ? ?mov ? ? pc, r0
>>>>
>>>> MMU is disabled at here and replace PC with r0 value. I doubt code
>>>> executed correctly at here. While MMU is disabled, the PC should be
>>>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>>>> shouldn't be executed. Instruction fetch failure should occurs since
>>>> there's no physical address in 0xCxxx_xxxx.
>>>>
>>>> Correct me if I'm wrong.
>>>>
>>>> Thanks
>>>> Haojian
>>>>
>>>
>>> Haojian,
>>>
>>> I think there is a pipeline execution of the mov pc, r0 instruction.
>>> If I remember correctly you need to do a similar jump when you turn
>>> the MMU on in early boot code. If it makes any difference I did test
>>> this code on pxa168 before submitting it. I will double check the mmp2
>>> and the pxa910 reset vectors with the Boot ROM developers.
>>>
>>
>> In early boot code, 1:1 (physical:virtual) mapping is used. It means
>> that physical address is same as virtual address. So you can operature
>> mmu as you wish.
>>
>> By the way, I don't suggest to reset CPU by this way. Reset is not
>> only make code running from the head, it should also clear registers
>> and RTL logic in CPU.
>>
>
> Depends on if pxa168 has a reset signal asserted from internal or from
> external GPIO, which is controllable from the CPU itself. That's what
> pxa is doing at this moment.
>

Yes, it depends on reset signal. Watchdog timer is built in pxa168. So
I think that watchdog reset could be better.

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

On Tue, Aug 31, 2010 at 2:08 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>> ---
>>>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>> index 4f5b0e0..926e9c0 100644
>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>
>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>  {
>>>>> -       cpu_reset(0);
>>>>> +       cpu_reset(0xffff0000);
>>>>
>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>
>>>>>  }
>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>> --
>>>>> 1.7.0.4
>>>>>
>>>>>
>>>>
>>>
>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>> about that! If you set the reset vector to 0x0 it will crash during
>>> reboot. I will send you xdb snapshots if you need me to.
>>>
>>
>> OK, you are expert on this :-)
>>
>> Applied to 'fix'.
>>
>
> One moment. Since this is really global to pxa910 and mmp2, so I
> suggest this being fixed for pxa168 only first. How about this:
>
>    ARM: pxa168: fix corrected reset vector
>
>    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>    reboot to work
>
>    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>
> diff --git a/arch/arm/mach-mmp/include/mach/system.h
> b/arch/arm/mach-mmp/include/mach/system.h
> index 4f5b0e0..1a8a25e 100644
> --- a/arch/arm/mach-mmp/include/mach/system.h
> +++ b/arch/arm/mach-mmp/include/mach/system.h
> @@ -9,6 +9,8 @@
>  #ifndef __ASM_MACH_SYSTEM_H
>  #define __ASM_MACH_SYSTEM_H
>
> +#include <mach/cputype.h>
> +
>  static inline void arch_idle(void)
>  {
>        cpu_do_idle();
> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>
>  static inline void arch_reset(char mode, const char *cmd)
>  {
> -       cpu_reset(0);
> +       if (cpu_is_pxa168())
> +               cpu_reset(0xffff0000);
> +       else
> +               cpu_reset(0);
>  }
>  #endif /* __ASM_MACH_SYSTEM_H */
>

That will work!

-- Mark

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

On Tue, Aug 31, 2010 at 2:08 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>> ---
>>>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>> index 4f5b0e0..926e9c0 100644
>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>
>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>> ?{
>>>>> - ? ? ? cpu_reset(0);
>>>>> + ? ? ? cpu_reset(0xffff0000);
>>>>
>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>
>>>>> ?}
>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>> --
>>>>> 1.7.0.4
>>>>>
>>>>>
>>>>
>>>
>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>> about that! If you set the reset vector to 0x0 it will crash during
>>> reboot. I will send you xdb snapshots if you need me to.
>>>
>>
>> OK, you are expert on this :-)
>>
>> Applied to 'fix'.
>>
>
> One moment. Since this is really global to pxa910 and mmp2, so I
> suggest this being fixed for pxa168 only first. How about this:
>
> ? ?ARM: pxa168: fix corrected reset vector
>
> ? ?Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
> ? ?reboot to work
>
> ? ?Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>
> diff --git a/arch/arm/mach-mmp/include/mach/system.h
> b/arch/arm/mach-mmp/include/mach/system.h
> index 4f5b0e0..1a8a25e 100644
> --- a/arch/arm/mach-mmp/include/mach/system.h
> +++ b/arch/arm/mach-mmp/include/mach/system.h
> @@ -9,6 +9,8 @@
> ?#ifndef __ASM_MACH_SYSTEM_H
> ?#define __ASM_MACH_SYSTEM_H
>
> +#include <mach/cputype.h>
> +
> ?static inline void arch_idle(void)
> ?{
> ? ? ? ?cpu_do_idle();
> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>
> ?static inline void arch_reset(char mode, const char *cmd)
> ?{
> - ? ? ? cpu_reset(0);
> + ? ? ? if (cpu_is_pxa168())
> + ? ? ? ? ? ? ? cpu_reset(0xffff0000);
> + ? ? ? else
> + ? ? ? ? ? ? ? cpu_reset(0);
> ?}
> ?#endif /* __ASM_MACH_SYSTEM_H */
>

That will work!

-- Mark

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 3:21 PM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
>> <haojian.zhuang@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>>> <haojian.zhuang@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>>>> ---
>>>>>>>>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>>>>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>>>>
>>>>>>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>>>>>>  {
>>>>>>>>>> -       cpu_reset(0);
>>>>>>>>>> +       cpu_reset(0xffff0000);
>>>>>>>>>
>>>>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>>>>
>>>>>>>>>>  }
>>>>>>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>>>>>>> --
>>>>>>>>>> 1.7.0.4
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>>>>
>>>>>>>
>>>>>>> OK, you are expert on this :-)
>>>>>>>
>>>>>>> Applied to 'fix'.
>>>>>>>
>>>>>>
>>>>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>>>>> suggest this being fixed for pxa168 only first. How about this:
>>>>>>
>>>>>>    ARM: pxa168: fix corrected reset vector
>>>>>>
>>>>>>    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>>>>    reboot to work
>>>>>>
>>>>>>    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>
>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>>>>> b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> index 4f5b0e0..1a8a25e 100644
>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> @@ -9,6 +9,8 @@
>>>>>>  #ifndef __ASM_MACH_SYSTEM_H
>>>>>>  #define __ASM_MACH_SYSTEM_H
>>>>>>
>>>>>> +#include <mach/cputype.h>
>>>>>> +
>>>>>>  static inline void arch_idle(void)
>>>>>>  {
>>>>>>        cpu_do_idle();
>>>>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>>>>
>>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>>  {
>>>>>> -       cpu_reset(0);
>>>>>> +       if (cpu_is_pxa168())
>>>>>> +               cpu_reset(0xffff0000);
>>>>>> +       else
>>>>>> +               cpu_reset(0);
>>>>>>  }
>>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>>>>
>>>>> The reset code is in below.
>>>>>
>>>>>        .align  5
>>>>> ENTRY(cpu_mohawk_reset)
>>>>>        mov     ip, #0
>>>>>        mcr     p15, 0, ip, c7, c7, 0           @ invalidate I,D caches
>>>>>        mcr     p15, 0, ip, c7, c10, 4          @ drain WB
>>>>>        mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
>>>>>        mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
>>>>>        bic     ip, ip, #0x0007                 @ .............cam
>>>>>        bic     ip, ip, #0x1100                 @ ...i...s........
>>>>>        mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
>>>>>        mov     pc, r0
>>>>>
>>>>> MMU is disabled at here and replace PC with r0 value. I doubt code
>>>>> executed correctly at here. While MMU is disabled, the PC should be
>>>>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>>>>> shouldn't be executed. Instruction fetch failure should occurs since
>>>>> there's no physical address in 0xCxxx_xxxx.
>>>>>
>>>>> Correct me if I'm wrong.
>>>>>
>>>>> Thanks
>>>>> Haojian
>>>>>
>>>>
>>>> Haojian,
>>>>
>>>> I think there is a pipeline execution of the mov pc, r0 instruction.
>>>> If I remember correctly you need to do a similar jump when you turn
>>>> the MMU on in early boot code. If it makes any difference I did test
>>>> this code on pxa168 before submitting it. I will double check the mmp2
>>>> and the pxa910 reset vectors with the Boot ROM developers.
>>>>
>>>
>>> In early boot code, 1:1 (physical:virtual) mapping is used. It means
>>> that physical address is same as virtual address. So you can operature
>>> mmu as you wish.
>>>
>>> By the way, I don't suggest to reset CPU by this way. Reset is not
>>> only make code running from the head, it should also clear registers
>>> and RTL logic in CPU.
>>>
>>
>> Depends on if pxa168 has a reset signal asserted from internal or from
>> external GPIO, which is controllable from the CPU itself. That's what
>> pxa is doing at this moment.
>>
>
> Yes, it depends on reset signal. Watchdog timer is built in pxa168. So
> I think that watchdog reset could be better.
>

Haojian, note we have a reboot mode, so possibly will have to implement
all of them if capable.

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 3:21 PM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
>> <haojian.zhuang@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>>> <haojian.zhuang@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>>>> ---
>>>>>>>>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>>>>>>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>>>>
>>>>>>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>>>>>>> ?{
>>>>>>>>>> - ? ? ? cpu_reset(0);
>>>>>>>>>> + ? ? ? cpu_reset(0xffff0000);
>>>>>>>>>
>>>>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>>>>
>>>>>>>>>> ?}
>>>>>>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>>>>>>> --
>>>>>>>>>> 1.7.0.4
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>>>>
>>>>>>>
>>>>>>> OK, you are expert on this :-)
>>>>>>>
>>>>>>> Applied to 'fix'.
>>>>>>>
>>>>>>
>>>>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>>>>> suggest this being fixed for pxa168 only first. How about this:
>>>>>>
>>>>>> ? ?ARM: pxa168: fix corrected reset vector
>>>>>>
>>>>>> ? ?Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>>>> ? ?reboot to work
>>>>>>
>>>>>> ? ?Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>
>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>>>>> b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> index 4f5b0e0..1a8a25e 100644
>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> @@ -9,6 +9,8 @@
>>>>>> ?#ifndef __ASM_MACH_SYSTEM_H
>>>>>> ?#define __ASM_MACH_SYSTEM_H
>>>>>>
>>>>>> +#include <mach/cputype.h>
>>>>>> +
>>>>>> ?static inline void arch_idle(void)
>>>>>> ?{
>>>>>> ? ? ? ?cpu_do_idle();
>>>>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>>>>
>>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>>> ?{
>>>>>> - ? ? ? cpu_reset(0);
>>>>>> + ? ? ? if (cpu_is_pxa168())
>>>>>> + ? ? ? ? ? ? ? cpu_reset(0xffff0000);
>>>>>> + ? ? ? else
>>>>>> + ? ? ? ? ? ? ? cpu_reset(0);
>>>>>> ?}
>>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>>>>> Please read the FAQ at ?http://www.tux.org/lkml/
>>>>>>
>>>>> The reset code is in below.
>>>>>
>>>>> ? ? ? ?.align ?5
>>>>> ENTRY(cpu_mohawk_reset)
>>>>> ? ? ? ?mov ? ? ip, #0
>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c7, 0 ? ? ? ? ? @ invalidate I,D caches
>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c10, 4 ? ? ? ? ?@ drain WB
>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c8, c7, 0 ? ? ? ? ? @ invalidate I & D TLBs
>>>>> ? ? ? ?mrc ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>>>>> ? ? ? ?bic ? ? ip, ip, #0x0007 ? ? ? ? ? ? ? ? @ .............cam
>>>>> ? ? ? ?bic ? ? ip, ip, #0x1100 ? ? ? ? ? ? ? ? @ ...i...s........
>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>>>>> ? ? ? ?mov ? ? pc, r0
>>>>>
>>>>> MMU is disabled at here and replace PC with r0 value. I doubt code
>>>>> executed correctly at here. While MMU is disabled, the PC should be
>>>>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>>>>> shouldn't be executed. Instruction fetch failure should occurs since
>>>>> there's no physical address in 0xCxxx_xxxx.
>>>>>
>>>>> Correct me if I'm wrong.
>>>>>
>>>>> Thanks
>>>>> Haojian
>>>>>
>>>>
>>>> Haojian,
>>>>
>>>> I think there is a pipeline execution of the mov pc, r0 instruction.
>>>> If I remember correctly you need to do a similar jump when you turn
>>>> the MMU on in early boot code. If it makes any difference I did test
>>>> this code on pxa168 before submitting it. I will double check the mmp2
>>>> and the pxa910 reset vectors with the Boot ROM developers.
>>>>
>>>
>>> In early boot code, 1:1 (physical:virtual) mapping is used. It means
>>> that physical address is same as virtual address. So you can operature
>>> mmu as you wish.
>>>
>>> By the way, I don't suggest to reset CPU by this way. Reset is not
>>> only make code running from the head, it should also clear registers
>>> and RTL logic in CPU.
>>>
>>
>> Depends on if pxa168 has a reset signal asserted from internal or from
>> external GPIO, which is controllable from the CPU itself. That's what
>> pxa is doing at this moment.
>>
>
> Yes, it depends on reset signal. Watchdog timer is built in pxa168. So
> I think that watchdog reset could be better.
>

Haojian, note we have a reboot mode, so possibly will have to implement
all of them if capable.

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

On Tue, Aug 31, 2010 at 3:21 AM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
>> <haojian.zhuang@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>>> <haojian.zhuang@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>>>> ---
>>>>>>>>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>>>>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>>>>
>>>>>>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>>>>>>  {
>>>>>>>>>> -       cpu_reset(0);
>>>>>>>>>> +       cpu_reset(0xffff0000);
>>>>>>>>>
>>>>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>>>>
>>>>>>>>>>  }
>>>>>>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>>>>>>> --
>>>>>>>>>> 1.7.0.4
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>>>>
>>>>>>>
>>>>>>> OK, you are expert on this :-)
>>>>>>>
>>>>>>> Applied to 'fix'.
>>>>>>>
>>>>>>
>>>>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>>>>> suggest this being fixed for pxa168 only first. How about this:
>>>>>>
>>>>>>    ARM: pxa168: fix corrected reset vector
>>>>>>
>>>>>>    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>>>>    reboot to work
>>>>>>
>>>>>>    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>
>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>>>>> b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> index 4f5b0e0..1a8a25e 100644
>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> @@ -9,6 +9,8 @@
>>>>>>  #ifndef __ASM_MACH_SYSTEM_H
>>>>>>  #define __ASM_MACH_SYSTEM_H
>>>>>>
>>>>>> +#include <mach/cputype.h>
>>>>>> +
>>>>>>  static inline void arch_idle(void)
>>>>>>  {
>>>>>>        cpu_do_idle();
>>>>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>>>>
>>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>>  {
>>>>>> -       cpu_reset(0);
>>>>>> +       if (cpu_is_pxa168())
>>>>>> +               cpu_reset(0xffff0000);
>>>>>> +       else
>>>>>> +               cpu_reset(0);
>>>>>>  }
>>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>>>>
>>>>> The reset code is in below.
>>>>>
>>>>>        .align  5
>>>>> ENTRY(cpu_mohawk_reset)
>>>>>        mov     ip, #0
>>>>>        mcr     p15, 0, ip, c7, c7, 0           @ invalidate I,D caches
>>>>>        mcr     p15, 0, ip, c7, c10, 4          @ drain WB
>>>>>        mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
>>>>>        mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
>>>>>        bic     ip, ip, #0x0007                 @ .............cam
>>>>>        bic     ip, ip, #0x1100                 @ ...i...s........
>>>>>        mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
>>>>>        mov     pc, r0
>>>>>
>>>>> MMU is disabled at here and replace PC with r0 value. I doubt code
>>>>> executed correctly at here. While MMU is disabled, the PC should be
>>>>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>>>>> shouldn't be executed. Instruction fetch failure should occurs since
>>>>> there's no physical address in 0xCxxx_xxxx.
>>>>>
>>>>> Correct me if I'm wrong.
>>>>>
>>>>> Thanks
>>>>> Haojian
>>>>>
>>>>
>>>> Haojian,
>>>>
>>>> I think there is a pipeline execution of the mov pc, r0 instruction.
>>>> If I remember correctly you need to do a similar jump when you turn
>>>> the MMU on in early boot code. If it makes any difference I did test
>>>> this code on pxa168 before submitting it. I will double check the mmp2
>>>> and the pxa910 reset vectors with the Boot ROM developers.
>>>>
>>>
>>> In early boot code, 1:1 (physical:virtual) mapping is used. It means
>>> that physical address is same as virtual address. So you can operature
>>> mmu as you wish.
>>>
>>> By the way, I don't suggest to reset CPU by this way. Reset is not
>>> only make code running from the head, it should also clear registers
>>> and RTL logic in CPU.
>>>
>>
>> Depends on if pxa168 has a reset signal asserted from internal or from
>> external GPIO, which is controllable from the CPU itself. That's what
>> pxa is doing at this moment.
>>
>
> Yes, it depends on reset signal. Watchdog timer is built in pxa168. So
> I think that watchdog reset could be better.
>

Haojian,

That is true, I am planning to send an update to support watchdog
timer reset soon. The problem is I need to test pxa910 and mmp2 as
well and determine if the watchdog reset code is consistent. It was
simpler for me to just fix this at the moment.

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Mark F. Brown]

On Tue, Aug 31, 2010 at 3:21 AM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
>> <haojian.zhuang@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>>> <haojian.zhuang@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>>>> ---
>>>>>>>>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>>>>>>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>>>>
>>>>>>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>>>>>>> ?{
>>>>>>>>>> - ? ? ? cpu_reset(0);
>>>>>>>>>> + ? ? ? cpu_reset(0xffff0000);
>>>>>>>>>
>>>>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>>>>
>>>>>>>>>> ?}
>>>>>>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>>>>>>> --
>>>>>>>>>> 1.7.0.4
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>>>>
>>>>>>>
>>>>>>> OK, you are expert on this :-)
>>>>>>>
>>>>>>> Applied to 'fix'.
>>>>>>>
>>>>>>
>>>>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>>>>> suggest this being fixed for pxa168 only first. How about this:
>>>>>>
>>>>>> ? ?ARM: pxa168: fix corrected reset vector
>>>>>>
>>>>>> ? ?Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>>>> ? ?reboot to work
>>>>>>
>>>>>> ? ?Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>
>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>>>>> b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> index 4f5b0e0..1a8a25e 100644
>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>> @@ -9,6 +9,8 @@
>>>>>> ?#ifndef __ASM_MACH_SYSTEM_H
>>>>>> ?#define __ASM_MACH_SYSTEM_H
>>>>>>
>>>>>> +#include <mach/cputype.h>
>>>>>> +
>>>>>> ?static inline void arch_idle(void)
>>>>>> ?{
>>>>>> ? ? ? ?cpu_do_idle();
>>>>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>>>>
>>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>>> ?{
>>>>>> - ? ? ? cpu_reset(0);
>>>>>> + ? ? ? if (cpu_is_pxa168())
>>>>>> + ? ? ? ? ? ? ? cpu_reset(0xffff0000);
>>>>>> + ? ? ? else
>>>>>> + ? ? ? ? ? ? ? cpu_reset(0);
>>>>>> ?}
>>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>>>>> Please read the FAQ at ?http://www.tux.org/lkml/
>>>>>>
>>>>> The reset code is in below.
>>>>>
>>>>> ? ? ? ?.align ?5
>>>>> ENTRY(cpu_mohawk_reset)
>>>>> ? ? ? ?mov ? ? ip, #0
>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c7, 0 ? ? ? ? ? @ invalidate I,D caches
>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c10, 4 ? ? ? ? ?@ drain WB
>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c8, c7, 0 ? ? ? ? ? @ invalidate I & D TLBs
>>>>> ? ? ? ?mrc ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>>>>> ? ? ? ?bic ? ? ip, ip, #0x0007 ? ? ? ? ? ? ? ? @ .............cam
>>>>> ? ? ? ?bic ? ? ip, ip, #0x1100 ? ? ? ? ? ? ? ? @ ...i...s........
>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>>>>> ? ? ? ?mov ? ? pc, r0
>>>>>
>>>>> MMU is disabled at here and replace PC with r0 value. I doubt code
>>>>> executed correctly at here. While MMU is disabled, the PC should be
>>>>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>>>>> shouldn't be executed. Instruction fetch failure should occurs since
>>>>> there's no physical address in 0xCxxx_xxxx.
>>>>>
>>>>> Correct me if I'm wrong.
>>>>>
>>>>> Thanks
>>>>> Haojian
>>>>>
>>>>
>>>> Haojian,
>>>>
>>>> I think there is a pipeline execution of the mov pc, r0 instruction.
>>>> If I remember correctly you need to do a similar jump when you turn
>>>> the MMU on in early boot code. If it makes any difference I did test
>>>> this code on pxa168 before submitting it. I will double check the mmp2
>>>> and the pxa910 reset vectors with the Boot ROM developers.
>>>>
>>>
>>> In early boot code, 1:1 (physical:virtual) mapping is used. It means
>>> that physical address is same as virtual address. So you can operature
>>> mmu as you wish.
>>>
>>> By the way, I don't suggest to reset CPU by this way. Reset is not
>>> only make code running from the head, it should also clear registers
>>> and RTL logic in CPU.
>>>
>>
>> Depends on if pxa168 has a reset signal asserted from internal or from
>> external GPIO, which is controllable from the CPU itself. That's what
>> pxa is doing at this moment.
>>
>
> Yes, it depends on reset signal. Watchdog timer is built in pxa168. So
> I think that watchdog reset could be better.
>

Haojian,

That is true, I am planning to send an update to support watchdog
timer reset soon. The problem is I need to test pxa910 and mmp2 as
well and determine if the watchdog reset code is consistent. It was
simpler for me to just fix this at the moment.

Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 3:28 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 3:21 AM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
>>> <haojian.zhuang@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>>>> <haojian.zhuang@gmail.com> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>>>>> ---
>>>>>>>>>>>  arch/arm/mach-mmp/include/mach/system.h |    2 +-
>>>>>>>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>>>>>
>>>>>>>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>>>>>>>  {
>>>>>>>>>>> -       cpu_reset(0);
>>>>>>>>>>> +       cpu_reset(0xffff0000);
>>>>>>>>>>
>>>>>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>>>>>
>>>>>>>>>>>  }
>>>>>>>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>>>>>>>> --
>>>>>>>>>>> 1.7.0.4
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>>>>>
>>>>>>>>
>>>>>>>> OK, you are expert on this :-)
>>>>>>>>
>>>>>>>> Applied to 'fix'.
>>>>>>>>
>>>>>>>
>>>>>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>>>>>> suggest this being fixed for pxa168 only first. How about this:
>>>>>>>
>>>>>>>    ARM: pxa168: fix corrected reset vector
>>>>>>>
>>>>>>>    Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>>>>>    reboot to work
>>>>>>>
>>>>>>>    Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>
>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> index 4f5b0e0..1a8a25e 100644
>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> @@ -9,6 +9,8 @@
>>>>>>>  #ifndef __ASM_MACH_SYSTEM_H
>>>>>>>  #define __ASM_MACH_SYSTEM_H
>>>>>>>
>>>>>>> +#include <mach/cputype.h>
>>>>>>> +
>>>>>>>  static inline void arch_idle(void)
>>>>>>>  {
>>>>>>>        cpu_do_idle();
>>>>>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>>>>>
>>>>>>>  static inline void arch_reset(char mode, const char *cmd)
>>>>>>>  {
>>>>>>> -       cpu_reset(0);
>>>>>>> +       if (cpu_is_pxa168())
>>>>>>> +               cpu_reset(0xffff0000);
>>>>>>> +       else
>>>>>>> +               cpu_reset(0);
>>>>>>>  }
>>>>>>>  #endif /* __ASM_MACH_SYSTEM_H */
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>>>>>
>>>>>> The reset code is in below.
>>>>>>
>>>>>>        .align  5
>>>>>> ENTRY(cpu_mohawk_reset)
>>>>>>        mov     ip, #0
>>>>>>        mcr     p15, 0, ip, c7, c7, 0           @ invalidate I,D caches
>>>>>>        mcr     p15, 0, ip, c7, c10, 4          @ drain WB
>>>>>>        mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
>>>>>>        mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
>>>>>>        bic     ip, ip, #0x0007                 @ .............cam
>>>>>>        bic     ip, ip, #0x1100                 @ ...i...s........
>>>>>>        mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
>>>>>>        mov     pc, r0
>>>>>>
>>>>>> MMU is disabled at here and replace PC with r0 value. I doubt code
>>>>>> executed correctly at here. While MMU is disabled, the PC should be
>>>>>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>>>>>> shouldn't be executed. Instruction fetch failure should occurs since
>>>>>> there's no physical address in 0xCxxx_xxxx.
>>>>>>
>>>>>> Correct me if I'm wrong.
>>>>>>
>>>>>> Thanks
>>>>>> Haojian
>>>>>>
>>>>>
>>>>> Haojian,
>>>>>
>>>>> I think there is a pipeline execution of the mov pc, r0 instruction.
>>>>> If I remember correctly you need to do a similar jump when you turn
>>>>> the MMU on in early boot code. If it makes any difference I did test
>>>>> this code on pxa168 before submitting it. I will double check the mmp2
>>>>> and the pxa910 reset vectors with the Boot ROM developers.
>>>>>
>>>>
>>>> In early boot code, 1:1 (physical:virtual) mapping is used. It means
>>>> that physical address is same as virtual address. So you can operature
>>>> mmu as you wish.
>>>>
>>>> By the way, I don't suggest to reset CPU by this way. Reset is not
>>>> only make code running from the head, it should also clear registers
>>>> and RTL logic in CPU.
>>>>
>>>
>>> Depends on if pxa168 has a reset signal asserted from internal or from
>>> external GPIO, which is controllable from the CPU itself. That's what
>>> pxa is doing at this moment.
>>>
>>
>> Yes, it depends on reset signal. Watchdog timer is built in pxa168. So
>> I think that watchdog reset could be better.
>>
>
> Haojian,
>
> That is true, I am planning to send an update to support watchdog
> timer reset soon. The problem is I need to test pxa910 and mmp2 as
> well and determine if the watchdog reset code is consistent. It was
> simpler for me to just fix this at the moment.
>

This fix can go ahead in my POV.

[PATCH 1/1] ARM: pxa168: fix corrected reset vector

[Eric Miao]

On Tue, Aug 31, 2010 at 3:28 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 3:21 AM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
>>> <haojian.zhuang@gmail.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>>>> <haojian.zhuang@gmail.com> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
>>>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@gmail.com> wrote:
>>>>>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>>>>> ---
>>>>>>>>>>> ?arch/arm/mach-mmp/include/mach/system.h | ? ?2 +-
>>>>>>>>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>>> index 4f5b0e0..926e9c0 100644
>>>>>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>>>>>> @@ -16,6 +16,6 @@ static inline void arch_idle(void)
>>>>>>>>>>>
>>>>>>>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>>>>>>>> ?{
>>>>>>>>>>> - ? ? ? cpu_reset(0);
>>>>>>>>>>> + ? ? ? cpu_reset(0xffff0000);
>>>>>>>>>>
>>>>>>>>>> Not sure if this correct. But normally reset jump happens after we turn
>>>>>>>>>> off the MMU and so on. Ain't the BootROM starts from 0 ?
>>>>>>>>>>
>>>>>>>>>>> ?}
>>>>>>>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>>>>>>>> --
>>>>>>>>>>> 1.7.0.4
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure
>>>>>>>>> about that! If you set the reset vector to 0x0 it will crash during
>>>>>>>>> reboot. I will send you xdb snapshots if you need me to.
>>>>>>>>>
>>>>>>>>
>>>>>>>> OK, you are expert on this :-)
>>>>>>>>
>>>>>>>> Applied to 'fix'.
>>>>>>>>
>>>>>>>
>>>>>>> One moment. Since this is really global to pxa910 and mmp2, so I
>>>>>>> suggest this being fixed for pxa168 only first. How about this:
>>>>>>>
>>>>>>> ? ?ARM: pxa168: fix corrected reset vector
>>>>>>>
>>>>>>> ? ?Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
>>>>>>> ? ?reboot to work
>>>>>>>
>>>>>>> ? ?Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
>>>>>>>
>>>>>>> diff --git a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> index 4f5b0e0..1a8a25e 100644
>>>>>>> --- a/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> +++ b/arch/arm/mach-mmp/include/mach/system.h
>>>>>>> @@ -9,6 +9,8 @@
>>>>>>> ?#ifndef __ASM_MACH_SYSTEM_H
>>>>>>> ?#define __ASM_MACH_SYSTEM_H
>>>>>>>
>>>>>>> +#include <mach/cputype.h>
>>>>>>> +
>>>>>>> ?static inline void arch_idle(void)
>>>>>>> ?{
>>>>>>> ? ? ? ?cpu_do_idle();
>>>>>>> @@ -16,6 +18,9 @@ static inline void arch_idle(void)
>>>>>>>
>>>>>>> ?static inline void arch_reset(char mode, const char *cmd)
>>>>>>> ?{
>>>>>>> - ? ? ? cpu_reset(0);
>>>>>>> + ? ? ? if (cpu_is_pxa168())
>>>>>>> + ? ? ? ? ? ? ? cpu_reset(0xffff0000);
>>>>>>> + ? ? ? else
>>>>>>> + ? ? ? ? ? ? ? cpu_reset(0);
>>>>>>> ?}
>>>>>>> ?#endif /* __ASM_MACH_SYSTEM_H */
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>>>>>> Please read the FAQ at ?http://www.tux.org/lkml/
>>>>>>>
>>>>>> The reset code is in below.
>>>>>>
>>>>>> ? ? ? ?.align ?5
>>>>>> ENTRY(cpu_mohawk_reset)
>>>>>> ? ? ? ?mov ? ? ip, #0
>>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c7, 0 ? ? ? ? ? @ invalidate I,D caches
>>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c7, c10, 4 ? ? ? ? ?@ drain WB
>>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c8, c7, 0 ? ? ? ? ? @ invalidate I & D TLBs
>>>>>> ? ? ? ?mrc ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>>>>>> ? ? ? ?bic ? ? ip, ip, #0x0007 ? ? ? ? ? ? ? ? @ .............cam
>>>>>> ? ? ? ?bic ? ? ip, ip, #0x1100 ? ? ? ? ? ? ? ? @ ...i...s........
>>>>>> ? ? ? ?mcr ? ? p15, 0, ip, c1, c0, 0 ? ? ? ? ? @ ctrl register
>>>>>> ? ? ? ?mov ? ? pc, r0
>>>>>>
>>>>>> MMU is disabled at here and replace PC with r0 value. I doubt code
>>>>>> executed correctly at here. While MMU is disabled, the PC should be
>>>>>> continue in the range of 0xCxxx_xxxx (kernel space). "mov pc, r0"
>>>>>> shouldn't be executed. Instruction fetch failure should occurs since
>>>>>> there's no physical address in 0xCxxx_xxxx.
>>>>>>
>>>>>> Correct me if I'm wrong.
>>>>>>
>>>>>> Thanks
>>>>>> Haojian
>>>>>>
>>>>>
>>>>> Haojian,
>>>>>
>>>>> I think there is a pipeline execution of the mov pc, r0 instruction.
>>>>> If I remember correctly you need to do a similar jump when you turn
>>>>> the MMU on in early boot code. If it makes any difference I did test
>>>>> this code on pxa168 before submitting it. I will double check the mmp2
>>>>> and the pxa910 reset vectors with the Boot ROM developers.
>>>>>
>>>>
>>>> In early boot code, 1:1 (physical:virtual) mapping is used. It means
>>>> that physical address is same as virtual address. So you can operature
>>>> mmu as you wish.
>>>>
>>>> By the way, I don't suggest to reset CPU by this way. Reset is not
>>>> only make code running from the head, it should also clear registers
>>>> and RTL logic in CPU.
>>>>
>>>
>>> Depends on if pxa168 has a reset signal asserted from internal or from
>>> external GPIO, which is controllable from the CPU itself. That's what
>>> pxa is doing at this moment.
>>>
>>
>> Yes, it depends on reset signal. Watchdog timer is built in pxa168. So
>> I think that watchdog reset could be better.
>>
>
> Haojian,
>
> That is true, I am planning to send an update to support watchdog
> timer reset soon. The problem is I need to test pxa910 and mmp2 as
> well and determine if the watchdog reset code is consistent. It was
> simpler for me to just fix this at the moment.
>

This fix can go ahead in my POV.