| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <AANLkTinN4w=P7oferD35bBMkPE+9z+2OyYsBcy3ptBzL@mail.gmail.com>
Date: Tue, 31 Aug 2010 03:28:13 -0400
From: "Mark F. Brown" <mark.brown314@...il.com>
To: Haojian Zhuang <haojian.zhuang@...il.com>
Cc: Eric Miao <eric.y.miao@...il.com>,
Haojian Zhuang <haojian.zhuang@...vell.com>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] ARM: pxa168: fix corrected reset vector
On Tue, Aug 31, 2010 at 3:21 AM, Haojian Zhuang
<haojian.zhuang@...il.com> wrote:
> On Tue, Aug 31, 2010 at 3:08 PM, Eric Miao <eric.y.miao@...il.com> wrote:
>> On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang
>> <haojian.zhuang@...il.com> wrote:
>>> On Tue, Aug 31, 2010 at 2:48 PM, Mark F. Brown <mark.brown314@...il.com> wrote:
>>>> On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang
>>>> <haojian.zhuang@...il.com> wrote:
>>>>> On Tue, Aug 31, 2010 at 2:08 PM, Eric Miao <eric.y.miao@...il.com> wrote:
>>>>>> On Tue, Aug 31, 2010 at 2:04 PM, Eric Miao <eric.y.miao@...il.com> wrote:
>>>>>>> On Tue, Aug 31, 2010 at 2:02 PM, Mark F. Brown <mark.brown314@...il.com> wrote:
>>>>>>>> On Tue, Aug 31, 2010 at 1:48 AM, Eric Miao <eric.y.miao@...il.com> wrote:
>>>>>>>>> On Thu, Aug 26, 2010 at 5:07 PM, Mark F. Brown <mark.brown314@...il.com> wrote:
>>>>>>>>>> Signed-off-by: Mark F. Brown <mark.brown314@...il.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@...il.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@...r.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists