linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: dillon min <dillon.minfei@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@st.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	linux-stm32@st-md-mailman.stormreply.com,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux@armlinux.org.uk, afzal.mohd.ma@gmail.com
Subject: Re: [PATCH 1/8] ARM: ARMv7-M: Fix register restore corrupt after svc call
Date: Wed, 3 Mar 2021 14:19:19 +0000	[thread overview]
Message-ID: <5efe3d44-8045-e376-003e-3ccbff54fb23@arm.com> (raw)
In-Reply-To: <CAL9mu0KUhctbBzmem1ZSgEwf5CebivHOSUr9Q7VTyzib8pW=Cw@mail.gmail.com>

On 3/3/21 1:35 PM, dillon min wrote:
> Hi Vladimir,
> 
> Thanks for the review.
> 
> On Wed, Mar 3, 2021 at 5:52 PM Vladimir Murzin <vladimir.murzin@arm.com> wrote:
>>
>> On 3/3/21 8:05 AM, dillon.minfei@gmail.com wrote:
>>> From: dillon min <dillon.minfei@gmail.com>
>>>
>>> For some case, kernel not boot by u-boot(single thread),
>>> but by rtos , as most rtos use pendsv to do context switch.
>>
>>
>> Hmm, does it mean that it starts kernel from process context?
>    Yes, kernel might be started from process context, since u-boot not
> switch context, so kernel always startup under msp.
>>
>> I'd assume that it is not only kernel who expects MSP. So, what
>> if RTOS you mentioned want to boot other RTOS (even itself)? What
>> if you have no access to the source code for those RTOS(es) to
>> patch MSP/PSP switch?
> 
> My case is a little complicated.
> stm32h7 only have 128Kbytes internal flash, can't store u-boot.bin (>200K),
> so, set a bootloader (rt-thread rtos) to internal flash, load
> linux/u-boot from serial port via ymodem
> store to qspi flash(8Mbytes), then jump to u-boot.
> 
> qspi flash layout:
> 0 - 512K:    u-boot
> 512K- 8M : kernel(xip)
> 
> load process : rt-thread -> u-boot -> linux
> 
> before add psp/msp check after svc call, register restore corrupt.
> add a printhex8 around svc call, found the sp stack is 0x24040000c0ffcff8
> it should be 0xc0ffcdf8c0ffcff8. 0x24040000 is the sp stack address
> assigned by u-boot
> i've no idea how it's become to u-boot's sp.
> 
> I have the rtos code, and will try to fix it on the rtos side.

That would be great!

> 
> Can you give more explanation about why linux relies on MSP ? thanks

MSP is what set from boot, thus it is natural assumption that boot code
would preserve that illusion.

I'd guess that kernel is in line in such assumption across different
(RT)OS capable to run on M-class cores (please, note that some variants
might not have two stack pointers)

Cheers
Vladimir

> 
>>
>> I'd very much prefer to keep stack switching logic outside kernel,
>> say, in some shim which RTOS/bootloader can maintain.
>>
>> Cheers
>> Vladimir
>>
>>>
>>> So, we need add an lr check after svc call, to find out should
>>> use psp or msp. else register restore after svc call might be
>>> corrupted.
>>>
>>> Fixes: b70cd406d7fe ("ARM: 8671/1: V7M: Preserve registers across switch from Thread to Handler mode")
>>> Signed-off-by: dillon min <dillon.minfei@gmail.com>
>>> ---
>>>  arch/arm/mm/proc-v7m.S | 5 ++++-
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mm/proc-v7m.S b/arch/arm/mm/proc-v7m.S
>>> index 84459c1d31b8..c93d2757312d 100644
>>> --- a/arch/arm/mm/proc-v7m.S
>>> +++ b/arch/arm/mm/proc-v7m.S
>>> @@ -137,7 +137,10 @@ __v7m_setup_cont:
>>>  1:   cpsid   i
>>>       /* Calculate exc_ret */
>>>       orr     r10, lr, #EXC_RET_THREADMODE_PROCESSSTACK
>>> -     ldmia   sp, {r0-r3, r12}
>>> +     tst     lr, #EXC_RET_STACK_MASK
>>> +     mrsne   r4, psp
>>> +     moveq   r4, sp
>>> +     ldmia   r4!, {r0-r3, r12}
>>>       str     r5, [r12, #11 * 4]      @ restore the original SVC vector entry
>>>       mov     lr, r6                  @ restore LR
>>>
>>>
>>
> 


  reply	other threads:[~2021-03-03 18:23 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03  8:05 [PATCH 0/8] ARM: STM32: add art-pi(stm32h750xbh6) board support dillon.minfei
2021-03-03  8:05 ` [PATCH 1/8] ARM: ARMv7-M: Fix register restore corrupt after svc call dillon.minfei
2021-03-03  9:52   ` Vladimir Murzin
2021-03-03 13:35     ` dillon min
2021-03-03 14:19       ` Vladimir Murzin [this message]
2021-03-04  5:42         ` dillon min
2021-03-04  9:02           ` Vladimir Murzin
2021-03-03  8:05 ` [PATCH 2/8] Documentation: arm: stm32: Add stm32h750 value line dillon.minfei
2021-03-03  8:05 ` [PATCH 3/8] dt-bindings: arm: stm32: Add compatible strings for ART-PI board dillon.minfei
2021-03-08 19:50   ` Rob Herring
2021-03-03  8:05 ` [PATCH 4/8] dt-bindings: pinctrl: stm32: Add stm32h750 pinctrl dillon.minfei
2021-03-08 19:50   ` Rob Herring
2021-03-03  8:05 ` [PATCH 5/8] ARM: dts: stm32: introduce stm32h7-pinctrl.dtsi to support stm32h75x dillon.minfei
2021-03-11 10:40   ` Alexandre TORGUE
2021-03-11 12:23     ` dillon min
2021-03-11 12:54       ` [Linux-stm32] " Ahmad Fatoum
2021-03-11 13:03         ` dillon min
2021-03-11 13:30       ` Alexandre TORGUE
2021-03-11 14:32         ` dillon min
2021-03-11 14:50           ` Alexandre TORGUE
2021-03-03  8:05 ` [PATCH 6/8] ARM: dts: stm32: add stm32h750-pinctrl.dtsi dillon.minfei
2021-03-03  8:05 ` [PATCH 7/8] ARM: dts: stm32: add support for art-pi board based on stm32h750xbh6 dillon.minfei
2021-03-11 10:42   ` Alexandre TORGUE
2021-03-11 12:32     ` dillon min
2021-03-11 13:31       ` Alexandre TORGUE
2021-03-03  8:05 ` [PATCH 8/8] ARM: stm32: add initial support for stm32h750 dillon.minfei
2021-03-11 10:43   ` Alexandre TORGUE
2021-03-11 12:34     ` dillon min
2021-03-10 11:47 ` [PATCH 0/8] ARM: STM32: add art-pi(stm32h750xbh6) board support dillon min
2021-03-11 10:26   ` Alexandre TORGUE
2021-03-11 11:30     ` dillon min

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5efe3d44-8045-e376-003e-3ccbff54fb23@arm.com \
    --to=vladimir.murzin@arm.com \
    --cc=afzal.mohd.ma@gmail.com \
    --cc=alexandre.torgue@st.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dillon.minfei@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux@armlinux.org.uk \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).