public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: [PATCH v3 7/7] riscv: Add some comments to start.S
Date: Mon, 21 Sep 2020 18:23:41 +0200	[thread overview]
Message-ID: <94e3ff14-77f7-254b-8846-260eed092bef@gmx.de> (raw)
In-Reply-To: <20200921115141.70598-8-seanga2@gmail.com>

On 21.09.20 13:51, Sean Anderson wrote:
> This adds comments regarding the ordering and purpose of certain
> instructions as I understand them.
>
> Signed-off-by: Sean Anderson <seanga2@gmail.com>
> Reviewed-by: Bin Meng <bin.meng@windriver.com>
> Reviewed-by: Rick Chen <rick@andestech.com>
> Reviewed-by: Leo Liang <ycliang@andestech.com>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Clarify comments regarding tp
>
>  arch/riscv/cpu/start.S | 19 +++++++++++++++++--
>  1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index eb852538ca..bbc737ed9a 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -43,7 +43,10 @@ _start:
>  	csrr	a0, CSR_MHARTID
>  #endif
>
> -	/* save hart id and dtb pointer */
> +	/*
> +	 * Save hart id and dtb pointer. The thread pointer register is not
> +	 * modified by C code. It is used by secondary_hart_loop.
> +	 */
>  	mv	tp, a0
>  	mv	s1, a1

I would like to understand the implications for the UEFI sub-system.

The current design only takes care of the conservation of the global
data gd.

When U-Boot calls a UEFI payload it saves the value of gd (register gp,
x3) in a variable.

When the payload calls the UEFI API implemented in U-Boot we store the
payload's value of register gp and restore the U-Boot value (see macro
EFI_ENTRY).

Before returning from the UEFI call we restore the payload's value of gp
(see macro EFI_EXIT).

When a payload returns to the U-Boot shell we restore gp.

Up to now we do not take care of any other register. I am not aware of
any specification requiring register tp to be conserved by the UEFI payload.

Is there any other register that has to be conserved except gp?

Best regards

Heinrich

>
> @@ -54,10 +57,18 @@ _start:
>  	 */
>  	mv	gp, zero
>
> +	/*
> +	 * Set the trap handler. This must happen after initializing gp because
> +	 * the handler may use it.
> +	 */
>  	la	t0, trap_entry
>  	csrw	MODE_PREFIX(tvec), t0
>
> -	/* mask all interrupts */
> +	/*
> +	 * Mask all interrupts. Interrupts are disabled globally (in m/sstatus)
> +	 * for U-Boot, but we will need to read m/sip to determine if we get an
> +	 * IPI
> +	 */
>  	csrw	MODE_PREFIX(ie), zero
>
>  #if CONFIG_IS_ENABLED(SMP)
> @@ -412,6 +423,10 @@ secondary_hart_relocate:
>  	mv	gp, a2
>  #endif
>
> +/*
> + * Interrupts are disabled globally, but they can still be read from m/sip. The
> + * wfi function will wake us up if we get an IPI, even if we do not trap.
> + */
>  secondary_hart_loop:
>  	wfi
>
>

  reply	other threads:[~2020-09-21 16:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-21 11:51 [PATCH v3 0/7] riscv: Correctly handle IPIs already pending upon boot Sean Anderson
2020-09-21 11:51 ` [PATCH v3 1/7] Revert "riscv: Clear pending interrupts before enabling IPIs" Sean Anderson
2020-09-22  0:56   ` Rick Chen
2020-09-21 11:51 ` [PATCH v3 2/7] riscv: Match memory barriers between send_ipi_many and handle_ipi Sean Anderson
2020-09-21 11:51 ` [PATCH v3 3/7] riscv: Use a valid bit to ignore already-pending IPIs Sean Anderson
2020-09-21 11:51 ` [PATCH v3 4/7] riscv: Clear pending IPIs on initialization Sean Anderson
2020-09-22  0:58   ` Rick Chen
2020-09-21 11:51 ` [PATCH v3 5/7] riscv: Consolidate fences into AMOs for available_harts_lock Sean Anderson
2020-09-21 11:51 ` [PATCH v3 6/7] riscv: Ensure gp is NULL or points to valid data Sean Anderson
2020-09-22  1:05   ` Rick Chen
2020-09-21 11:51 ` [PATCH v3 7/7] riscv: Add some comments to start.S Sean Anderson
2020-09-21 16:23   ` Heinrich Schuchardt [this message]
2020-09-21 16:40     ` Sean Anderson

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=94e3ff14-77f7-254b-8846-260eed092bef@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=u-boot@lists.denx.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