mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <>
To: Ahmad Fatoum <>
Subject: Re: [PATCH v2 1/3] ARM: implement ENTRY_FUNCTION_WITHSTACK
Date: Fri, 14 Jan 2022 10:29:02 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Jan 14, 2022 at 09:42:25AM +0100, Ahmad Fatoum wrote:
> The point of ENTRY_FUNCTION is to write the entry point in C. Due to
> lack of __naked on ARM64, the start of the entry point will have prologue
> using stack and it's not possible to set up the stack safely without
> branching into non-inline assembly[0]. On ARM32, where we got __naked, we
> have the potential for a different problem: If BootROM sets up stack for
> us and we branch to a naked function, which doesn't set up its own
> stack, compiler may decide to spill local variables overwriting
> instructions it had already run[1].
> For code reuse between ARM and ARM64, it would be nice to use the same
> entry point structure for both. Currently, the only way is to write it
> in non-inline assembly using the ENTRY_PROC macro.
> This introduces another way: the ARM64 barebox header has enough space
> for 8 instructions of which 5 are unused (2 instructions compiler prologue
> + 1 instruction to jump after the header), we could place a stack setup
> routine there to avoid having to write a separate assembly file.
> For ARM32, we just call arm_setup_stack and branch out directly after,
> freeing board porters of the burden of getting it right.
> Add a new ENTRY_FUNCTION_WITHSTACK to realize this.
> [0]: 76bced6fe146 ("ARM: document arm_setup_stack() pitfalls"),
> [1]: b51b15ba1738 ("RISC-V: board-dt-2nd: move low level init into nonnaked function")
> Signed-off-by: Ahmad Fatoum <>
> ---
> v1 -> v2:
>  - add __ARM_SETUP_STACK(0) to normal ENTRY_FUNCTION. On ARM32, it's a
>    no-op, but on ARM64, it ensures the header isn't shifted
> ---
>  arch/arm/include/asm/barebox-arm-head.h |  6 +---
>  arch/arm/include/asm/barebox-arm.h      | 46 +++++++++++++++++++++++++
>  arch/arm/lib/                  |  1 +
>  3 files changed, 48 insertions(+), 5 deletions(-)

Applied, thanks


Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       |  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

barebox mailing list

      parent reply	other threads:[~2022-01-14  9:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14  8:42 Ahmad Fatoum
2022-01-14  8:42 ` [PATCH v2 2/3] ARM: turn arm_mem_stack_top into a macro Ahmad Fatoum
2022-01-14  8:42 ` [PATCH v2 3/3] ARM: rpi: use ENTRY_FUNCTION_WITHSTACK to prepare for ARM64 support Ahmad Fatoum
2022-01-14  9:29 ` Sascha Hauer [this message]

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:

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

  git send-email \ \ \ \ \

* 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