linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mcoquelin.stm32@gmail.com (Maxime Coquelin)
To: linux-arm-kernel@lists.infradead.org
Subject: v7-M: Fixing XIP when the kernel is in ROM
Date: Tue, 27 Oct 2015 22:33:01 +0100	[thread overview]
Message-ID: <CALszF6Di3LWLu_W67Zdn2LyKKRF_5U241eKFKMmJ-0s+0boFag@mail.gmail.com> (raw)
In-Reply-To: <85aea33b93066d0959d98b56f8787ba3@agner.ch>

2015-10-27 21:33 GMT+01:00 Stefan Agner <stefan@agner.ch>:
> On 2015-10-27 13:25, Maxime Coquelin wrote:
>> 2015-10-27 17:03 GMT+01:00 Maxime Coquelin <maxime.coquelin@st.com>:
>>> Hi Ezequiel,
>>>
>>> On 10/27/2015 04:35 PM, Ezequiel Garcia wrote:
>>>>>
>>>>> >>>The temporary stack is allocated in the .text.init section
>>>>> >>>and so this doesn't work when the kernel is executing from ROM.
>>>>
>>>> >>
>>>> >>If sp isn't used, how does it break you setup?
>>>
>>> STM32 machine works fine with XIP from internal flash memory, so as Uwe, I'm
>>> surprised it solves your problem.
>>>
>>> I will have a try with your patch later today.
>>
>> Just tested, and confirm it works with (and without) your patch in XIP on STM32.
>
> It probably depends what exactly happens when the CPU core tries to use
> the stack. I mean, the CPU core will issue a write to the flash, and how
> that behaves is probably implementation specific. However, I would
> expect that it should lead to some kind of fault... Do we have fault
> handlers at that time?

Yes we have fault handlers at that time.
I agree the behaviour is probably implementation specific.

>
> Anyway, I guess Ezequiel's fix is the right thing to do...
Or, maybe we should put the stack in RAM as Uwe suggest?

Regards,
Maxime

  reply	other threads:[~2015-10-27 21:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-26  1:27 v7-M: Fixing XIP when the kernel is in ROM Ezequiel Garcia
2015-10-26  8:05 ` Uwe Kleine-König
2015-10-26 13:12   ` Ezequiel Garcia
2015-10-27 15:35     ` Ezequiel Garcia
2015-10-27 16:03       ` Maxime Coquelin
2015-10-27 20:25         ` Maxime Coquelin
2015-10-27 20:33           ` Stefan Agner
2015-10-27 21:33             ` Maxime Coquelin [this message]
2015-10-27 21:46               ` Ezequiel Garcia
2015-10-27 21:52                 ` Maxime Coquelin
2015-10-27 22:08                   ` Ezequiel Garcia
2015-10-28  7:43                     ` Uwe Kleine-König
2015-11-03 17:52                       ` Chris Brandt
2015-11-03 20:09                         ` Uwe Kleine-König
2015-11-03 20:30                           ` Russell King - ARM Linux
2015-10-27 20:21 ` Uwe Kleine-König
2015-10-27 20:57   ` Ezequiel Garcia
2015-10-27 21:20     ` Uwe Kleine-König
2015-10-27 22:40       ` Russell King - ARM Linux
2015-10-28  7:34         ` Uwe Kleine-König

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=CALszF6Di3LWLu_W67Zdn2LyKKRF_5U241eKFKMmJ-0s+0boFag@mail.gmail.com \
    --to=mcoquelin.stm32@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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).