All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Anderson <seanga2@gmail.com>
To: Nikita Shubin <nikita.shubin@maquefel.me>
Cc: linux@yadro.com, Nikita Shubin <n.shubin@yadro.com>,
	Rick Chen <rick@andestech.com>, Leo <ycliang@andestech.com>,
	Simon Glass <sjg@chromium.org>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Bin Meng <bmeng.cn@gmail.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Alexandru Gagniuc <mr.nuke.me@gmail.com>,
	Andrew Davis <afd@ti.com>,
	Alper Nebi Yasak <alpernebiyasak@gmail.com>,
	u-boot@lists.denx.de
Subject: Re: [PATCH] spl: introduce SPL_XIP to config
Date: Fri, 26 Aug 2022 10:10:30 -0400	[thread overview]
Message-ID: <30f43f76-d146-ea24-2dfd-a48197ad2839@gmail.com> (raw)
In-Reply-To: <20220826084428.24276-1-nikita.shubin@maquefel.me>

On 8/26/22 4:44 AM, Nikita Shubin wrote:
> From: Nikita Shubin <n.shubin@yadro.com>
> 
> U-Boot and SPL don't necessary share the same location, so we might end
> with U-Boot SPL in read-only memory (XIP) and U-Boot in read-write memory.
> 
> In case of non XIP boot mode, we rely on such variables as "hart_lottery"
> and "available_harts_lock" which we use as atomics.
> 
> The problem is that CONFIG_XIP also propagate to main U-Boot, not only SPL,
> so we need CONFIG_SPL_XIP to distinguish SPL XIP from other XIP modes.
> 
> This adds an option special for SPL to behave it in XIP manner and we don't
> use hart_lottery and available_harts_lock, during start proccess.
> 
> Signed-off-by: Nikita Shubin <n.shubin@yadro.com>
> ---
> rfc->v0:
> Sean Anderson:
> 	- replace defined with CONFIG_IS_ENABLED
> 	- add proper description to KConfig
> ---
>   arch/riscv/cpu/cpu.c                 | 2 +-
>   arch/riscv/cpu/start.S               | 4 ++--
>   arch/riscv/include/asm/global_data.h | 2 +-
>   arch/riscv/lib/asm-offsets.c         | 2 +-
>   arch/riscv/lib/smp.c                 | 2 +-
>   common/spl/Kconfig                   | 7 +++++++
>   6 files changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index 9f5fa0bcb3..5d8163b19f 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -19,7 +19,7 @@
>    * The variables here must be stored in the data section since they are used
>    * before the bss section is available.
>    */
> -#ifndef CONFIG_XIP
> +#if !CONFIG_IS_ENABLED(XIP)
>   u32 hart_lottery __section(".data") = 0;
>   
>   /*
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index ac81783a90..c3c859e667 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -122,7 +122,7 @@ call_board_init_f_0:
>   call_harts_early_init:
>   	jal	harts_early_init
>   
> -#ifndef CONFIG_XIP
> +#if !CONFIG_IS_ENABLED(XIP)
>   	/*
>   	 * Pick hart to initialize global data and run U-Boot. The other harts
>   	 * wait for initialization to complete.
> @@ -150,7 +150,7 @@ call_harts_early_init:
>   	/* save the boot hart id to global_data */
>   	SREG	tp, GD_BOOT_HART(gp)
>   
> -#ifndef CONFIG_XIP
> +#if !CONFIG_IS_ENABLED(XIP)
>   	la	t0, available_harts_lock
>   	amoswap.w.rl zero, zero, 0(t0)
>   
> diff --git a/arch/riscv/include/asm/global_data.h b/arch/riscv/include/asm/global_data.h
> index 9a146d1d49..a4d3cf430b 100644
> --- a/arch/riscv/include/asm/global_data.h
> +++ b/arch/riscv/include/asm/global_data.h
> @@ -30,7 +30,7 @@ int iccm[CONFIG_NR_CPUS];
>   #if CONFIG_IS_ENABLED(SMP)
>   	struct ipi_data ipi[CONFIG_NR_CPUS];
>   #endif
> -#ifndef CONFIG_XIP
> +#if !CONFIG_IS_ENABLED(XIP)
>   	ulong available_harts;
>   #endif
>   };
> diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
> index f1fe089b3d..c4f48c8373 100644
> --- a/arch/riscv/lib/asm-offsets.c
> +++ b/arch/riscv/lib/asm-offsets.c
> @@ -16,7 +16,7 @@ int main(void)
>   {
>   	DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
>   	DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t, arch.firmware_fdt_addr));
> -#ifndef CONFIG_XIP
> +#if !CONFIG_IS_ENABLED(XIP)
>   	DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
>   #endif
>   
> diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c
> index ba992100ad..f8b756291f 100644
> --- a/arch/riscv/lib/smp.c
> +++ b/arch/riscv/lib/smp.c
> @@ -45,7 +45,7 @@ static int send_ipi_many(struct ipi_data *ipi, int wait)
>   			continue;
>   		}
>   
> -#ifndef CONFIG_XIP
> +#if !CONFIG_IS_ENABLED(XIP)
>   		/* skip if hart is not available */
>   		if (!(gd->arch.available_harts & (1 << reg)))
>   			continue;
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 07c03d611d..b3719f9626 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -27,6 +27,13 @@ config SPL_FRAMEWORK
>   	  supports MMC, NAND and YMODEM and other methods loading of U-Boot
>   	  and the Linux Kernel.  If unsure, say Y.
>   
> +config SPL_XIP
> +	bool "Enable XIP mode for SPL"
> +	help
> +	  If SPL starts in read-only memory (XIP for example) then we shouldn't
> +	  rely on lock variables (for example hart_lottery and available_harts_lock),
> +	  this affects only SPL, other stages should proceed as non-XIP.
> +

Kconfig descriptions should tell you what should happen when you enable this config.
So the way you have worded this is strange; I would expect something more like

Support booting SPL from read-only memory (such as XIP). Don't rely on lock variables
(for example hart_lottery and available_harts_lock) since they cannot be modified.

The rest looks good.

--Sean

>   config SPL_FRAMEWORK_BOARD_INIT_F
>   	bool "Define a generic function board_init_f"
>   	depends on SPL_FRAMEWORK
> 


  reply	other threads:[~2022-08-26 14:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-11  9:37 [RFC PATCH 0/1] spl: introduce SPL_XIP to config Nikita Shubin
2022-08-11  9:37 ` [RFC PATCH 1/1] " Nikita Shubin
2022-08-13  4:35   ` Sean Anderson
2022-08-15  7:27     ` Nikita Shubin
2022-08-23  4:25       ` Sean Anderson
2022-08-26  8:44         ` [PATCH] " Nikita Shubin
2022-08-26 14:10           ` Sean Anderson [this message]
2022-08-31  7:25             ` [PATCH v2] " Nikita Shubin
     [not found]               ` <HK0PR03MB2994C85219E6217F7F9F4A05C17A9@HK0PR03MB2994.apcprd03.prod.outlook.com>
2022-09-02  7:25                 ` Rick Chen
2022-09-02  8:42                   ` Nikita Shubin
2022-09-02  8:47                   ` [PATCH v3] " Nikita Shubin
     [not found]                     ` <HK0PR03MB29942A55774ED60C5568E72CC17F9@HK0PR03MB2994.apcprd03.prod.outlook.com>
2022-09-08  0:45                       ` Rick Chen

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=30f43f76-d146-ea24-2dfd-a48197ad2839@gmail.com \
    --to=seanga2@gmail.com \
    --cc=afd@ti.com \
    --cc=alpernebiyasak@gmail.com \
    --cc=bmeng.cn@gmail.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=linux@yadro.com \
    --cc=mr.nuke.me@gmail.com \
    --cc=n.shubin@yadro.com \
    --cc=nikita.shubin@maquefel.me \
    --cc=rick@andestech.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    --cc=ycliang@andestech.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.