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(-)
Signed-off-by: Mark F. Brown <[email protected]>
---
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
On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
> Signed-off-by: Mark F. Brown <[email protected]>
> ---
> 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
>
>
On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>> Signed-off-by: Mark F. Brown <[email protected]>
>> ---
>> ?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
On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>> Signed-off-by: Mark F. Brown <[email protected]>
>>> ---
>>> 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'.
On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <[email protected]> wrote:
> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>>> Signed-off-by: Mark F. Brown <[email protected]>
>>>> ---
>>>> 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 <[email protected]>
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 */
On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <[email protected]> wrote:
> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <[email protected]> wrote:
>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>>>> Signed-off-by: Mark F. Brown <[email protected]>
>>>>> ---
>>>>> ?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 <[email protected]>
>
> 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 [email protected]
> 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
On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
<[email protected]> wrote:
> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <[email protected]> wrote:
>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <[email protected]> wrote:
>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>>>>> Signed-off-by: Mark F. Brown <[email protected]>
>>>>>> ---
>>>>>> ?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 <[email protected]>
>>
>> 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 [email protected]
>> 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.
On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <[email protected]> wrote:
> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
> <[email protected]> wrote:
>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <[email protected]> wrote:
>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <[email protected]> wrote:
>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>>>>>> Signed-off-by: Mark F. Brown <[email protected]>
>>>>>>> ---
>>>>>>> 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 <[email protected]>
>>>
>>> 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 [email protected]
>>> 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.
>
On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <[email protected]> wrote:
> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
> <[email protected]> wrote:
>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <[email protected]> wrote:
>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <[email protected]> wrote:
>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>>>>>> Signed-off-by: Mark F. Brown <[email protected]>
>>>>>>> ---
>>>>>>> ?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 <[email protected]>
>>>
>>> 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 [email protected]
>>> 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.
On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
<[email protected]> wrote:
> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <[email protected]> wrote:
>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>> <[email protected]> wrote:
>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <[email protected]> wrote:
>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <[email protected]> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>>>>>>> Signed-off-by: Mark F. Brown <[email protected]>
>>>>>>>> ---
>>>>>>>> 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 <[email protected]>
>>>>
>>>> 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 [email protected]
>>>> 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.
On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <[email protected]> wrote:
> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
> <[email protected]> wrote:
>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <[email protected]> wrote:
>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>> <[email protected]> wrote:
>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <[email protected]> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <[email protected]> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>>>>>>>> Signed-off-by: Mark F. Brown <[email protected]>
>>>>>>>>> ---
>>>>>>>>> ?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 <[email protected]>
>>>>>
>>>>> 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 [email protected]
>>>>> 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.
On Tue, Aug 31, 2010 at 2:08 AM, Eric Miao <[email protected]> wrote:
> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <[email protected]> wrote:
>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>>>> Signed-off-by: Mark F. Brown <[email protected]>
>>>>> ---
>>>>> ?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 <[email protected]>
>
> 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
On Tue, Aug 31, 2010 at 3:21 PM, Haojian Zhuang
<[email protected]> wrote:
> On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <[email protected]> wrote:
>> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
>> <[email protected]> wrote:
>>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <[email protected]> wrote:
>>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>>> <[email protected]> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <[email protected]> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <[email protected]> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
>>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>>>>>>>>> Signed-off-by: Mark F. Brown <[email protected]>
>>>>>>>>>> ---
>>>>>>>>>> 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 <[email protected]>
>>>>>>
>>>>>> 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 [email protected]
>>>>>> 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.
On Tue, Aug 31, 2010 at 3:21 AM, Haojian Zhuang
<[email protected]> wrote:
> On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <[email protected]> wrote:
>> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
>> <[email protected]> wrote:
>>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <[email protected]> wrote:
>>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>>> <[email protected]> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <[email protected]> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <[email protected]> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
>>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>>>>>>>>> Signed-off-by: Mark F. Brown <[email protected]>
>>>>>>>>>> ---
>>>>>>>>>> ?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 <[email protected]>
>>>>>>
>>>>>> 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 [email protected]
>>>>>> 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.
On Tue, Aug 31, 2010 at 3:28 PM, Mark F. Brown <[email protected]> wrote:
> On Tue, Aug 31, 2010 at 3:21 AM, Haojian Zhuang
> <[email protected]> wrote:
>> On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <[email protected]> wrote:
>>> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
>>> <[email protected]> wrote:
>>>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <[email protected]> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>>>> <[email protected]> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <[email protected]> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <[email protected]> wrote:
>>>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <[email protected]> wrote:
>>>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <[email protected]> wrote:
>>>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <[email protected]> wrote:
>>>>>>>>>>> Signed-off-by: Mark F. Brown <[email protected]>
>>>>>>>>>>> ---
>>>>>>>>>>> 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 <[email protected]>
>>>>>>>
>>>>>>> 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 [email protected]
>>>>>>> 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.