| Message ID | HK2PR06MB0561D4F2B8C36A2A1427EE5A8A2B0@HK2PR06MB0561.apcprd06.prod.outlook.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hello, On Tue, Nov 03, 2015 at 05:52:53PM +0000, Chris Brandt wrote: > > So the right fix is to move __v7m_setup_stack to .data I guess. > > > Since my set of patches went nowhere, last week we had a look at doing just that (using a pre-allocated stack in .data instead of hard coding to the top of PLAT_PHYS_OFFSET). > > Here's the code we came up with. Seems to work on XIP and non-XIP builds as well as SMP and non-SMP. > > > Maybe you can try this technique to allocate the temporary stack in the data section. I think for v7-M it's easier. Just move the stack to .data and use it from there where the linker put it to. > arch/arm/mm/proc-v7.S | 25 +++++++++++++++++++++++-- I would have expected a patch to v7m in this thread. You seem to fix a different problem so I suggest you start a new thread with a subject that gets the attention from people that know about the v7-[AR] details. Best regards Uwe
On Tue, Nov 03, 2015 at 09:09:01PM +0100, Uwe Kleine-König wrote: > Hello, > > On Tue, Nov 03, 2015 at 05:52:53PM +0000, Chris Brandt wrote: > > > So the right fix is to move __v7m_setup_stack to .data I guess. > > > > > > Since my set of patches went nowhere, last week we had a look at doing just that (using a pre-allocated stack in .data instead of hard coding to the top of PLAT_PHYS_OFFSET). > > > > Here's the code we came up with. Seems to work on XIP and non-XIP builds as well as SMP and non-SMP. > > > > > > Maybe you can try this technique to allocate the temporary stack in the data section. > I think for v7-M it's easier. Just move the stack to .data and use it > from there where the linker put it to. Why waste memory - we already have a stack allocated in the .data segment already.
--- 0001/arch/arm/mm/proc-v7.S +++ work/arch/arm/mm/proc-v7.S 2015-10-28 15:44:48.980513000 +0900 @@ -274,7 +274,15 @@ __v7_ca15mp_setup: __v7_b15mp_setup: __v7_ca17mp_setup: mov r10, #0 -1: adr r12, __v7_setup_stack @ the local stack +1: adr r11, __v7_setup_stack_ptr @ pointer to local stack + ldmia r11, {r0, r12} +#ifdef CONFIG_XIP_KERNEL + ldr r11, =PLAT_PHYS_OFFSET @ fixed address +#else + sub r11, r11, r0 @ position independent offset +#endif + add r12, r12, r11 @ phys address + sub r12, #PAGE_OFFSET stmia r12, {r0-r5, lr} @ v7_invalidate_l1 touches r0-r6 bl v7_invalidate_l1 ldmia r12, {r0-r5, lr} @@ -415,7 +423,15 @@ __v7_pj4b_setup: #endif /* CONFIG_CPU_PJ4B */ __v7_setup: - adr r12, __v7_setup_stack @ the local stack + adr r11, __v7_setup_stack_ptr @ pointer to local stack + ldmia r11, {r0, r12} +#ifdef CONFIG_XIP_KERNEL + ldr r11, =PLAT_PHYS_OFFSET @ fixed address +#else + sub r11, r11, r0 @ position independent offset +#endif + add r12, r12, r11 @ phys address + sub r12, #PAGE_OFFSET stmia r12, {r0-r5, lr} @ v7_invalidate_l1 touches r0-r6 bl v7_invalidate_l1 ldmia r12, {r0-r5, lr} @@ -482,6 +498,11 @@ __errata_finish: ret lr @ return to head.S:__ret ENDPROC(__v7_setup) +__v7_setup_stack_ptr: + .long . + .long __v7_setup_stack + + .data .align 2 __v7_setup_stack: .space 4 * 7 @ 12 registers
> So the right fix is to move __v7m_setup_stack to .data I guess. Since my set of patches went nowhere, last week we had a look at doing just that (using a pre-allocated stack in .data instead of hard coding to the top of PLAT_PHYS_OFFSET). Here's the code we came up with. Seems to work on XIP and non-XIP builds as well as SMP and non-SMP. Maybe you can try this technique to allocate the temporary stack in the data section. (and if your patch gets in...then maybe I'll try submitting again...) -Chris arch/arm/mm/proc-v7.S | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-)