public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Peng Fan <peng.fan@oss.nxp.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Frank Li <Frank.Li@nxp.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
	imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
Date: Tue, 31 Mar 2026 10:49:32 +0800	[thread overview]
Message-ID: <acs2PAZq2k3zjmDW@shlinux89> (raw)
In-Reply-To: <acqjS440STRl2sK2@p14s>

On Mon, Mar 30, 2026 at 10:22:35AM -0600, Mathieu Poirier wrote:
>On Fri, Mar 27, 2026 at 10:42:03AM +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@nxp.com>
>> 
>> Cortex-M[7,33] processors use a fixed reset vector table format:
>> 
>>   0x00  Initial SP value
>>   0x04  Reset vector
>>   0x08  NMI
>>   0x0C  ...
>>   ...
>>   IRQ[n]
>> 
>> In ELF images, the corresponding layout is:
>> 
>> reset_vectors:  --> hardware reset address
>>         .word __stack_end__
>>         .word Reset_Handler
>>         .word NMI_Handler
>>         .word HardFault_Handler
>>         ...
>>         .word UART_IRQHandler
>>         .word SPI_IRQHandler
>>         ...
>> 
>> Reset_Handler:  --> ELF entry point address
>>         ...
>> 
>> The hardware fetches the first two words from reset_vectors and populates
>> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
>> Reset_Handler.
>> 
>> However, the ELF entry point does not always match the hardware reset
>> address. For example, on i.MX94 CM33S:
>> 
>>   ELF entry point:     0x0ffc211d
>>   hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
>>
>
>But why?  Why can't the ELF image be set to the right reset base?

Per zephyr general link script[1]:
ENTRY(CONFIG_KERNEL_ENTRY)

CONFIG_KERNEL_ENTRY(_start) is the first instruction that Cortex-M starts to
execute.

config KERNEL_ENTRY
        string "Kernel entry symbol"
        default "__start"
        help
          Code entry symbol, to be set at linking phase.

The hardware reset base is different: it is the address where the hardware
fetches the initial MSP and PC values from the vector table. Hardware uses
this base to initialize the stack pointer and program counter, and only then
does the Cortex‑M begin execution at the reset handler.

Aligning the ELF entry point with the hardware reset base on Cortex‑M systems
is possible, but it comes with several risks.
1, Semantic mismatch (ELF vs. hardware behavior)
2, Debuggers may attempt to set breakpoints or start execution at the entry symbol

[1] https://elixir.bootlin.com/zephyr/v4.4.0-rc1/source/include/zephyr/arch/arm/cortex_m/scripts/linker.ld#L103

Regards
Peng.
> 

  reply	other threads:[~2026-03-31  2:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-27  2:42 [PATCH v2 0/3] Add i.MX94 remoteproc support and reset vector handling improvements Peng Fan (OSS)
2026-03-27  2:42 ` [PATCH v2 1/3] dt-bindings: remoteproc: imx-rproc: Support i.MX94 Peng Fan (OSS)
2026-03-27  2:42 ` [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector Peng Fan (OSS)
2026-03-27  9:45   ` Daniel Baluta
2026-03-30 16:22   ` Mathieu Poirier
2026-03-31  2:49     ` Peng Fan [this message]
2026-04-01  1:31   ` Peng Fan
2026-03-27  2:42 ` [PATCH v2 3/3] remoteproc: imx_rproc: Add support for i.MX94 Peng Fan (OSS)
2026-03-27  9:46   ` Daniel Baluta

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=acs2PAZq2k3zjmDW@shlinux89 \
    --to=peng.fan@oss.nxp.com \
    --cc=Frank.Li@nxp.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=daniel.baluta@nxp.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=peng.fan@nxp.com \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    /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