[PATCH 05/16] mips: add an option to support initialize SRAM for initial stack

[PATCH 05/16] mips: add an option to support initialize SRAM for initial stack

[Weijie Gao]

Currently CONFIG_MIPS_INIT_STACK_IN_SRAM assumes the memory space for the
initial stack can be used directly. However on some platform the SRAM needs
initialization, e.g. lock cache.

This patch adds an option to allow a new function mips_sram_init() being
called before setup_stack_gd.

Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
---
 arch/mips/Kconfig     | 9 +++++++++
 arch/mips/cpu/start.S | 7 +++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 52afbf79c5..015a7f6358 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -402,6 +402,15 @@ config MIPS_INIT_STACK_IN_SRAM
 	  lowlevel_init. Thus lowlevel_init does not need to be implemented
 	  in assembler.
 
+config MIPS_SRAM_INIT
+	bool
+	default n
+	depends on MIPS_INIT_STACK_IN_SRAM
+	help
+	  Select this if the SRAM for initial stack needs to be initialized
+	  before it can be used. If enabled, a function mips_sram_init() will
+	  be called just before setup_stack_gd.
+
 config SYS_DCACHE_SIZE
 	int
 	default 0
diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S
index 1d21b2324a..f9805fa000 100644
--- a/arch/mips/cpu/start.S
+++ b/arch/mips/cpu/start.S
@@ -216,6 +216,13 @@ wr_done:
 #endif
 
 #ifdef CONFIG_MIPS_INIT_STACK_IN_SRAM
+#ifdef CONFIG_MIPS_SRAM_INIT
+	/* Initialize the SRAM first */
+	PTR_LA	t9, mips_sram_init
+	jalr	t9
+	 nop
+#endif
+
 	/* Set up initial stack and global data */
 	setup_stack_gd
 
-- 
2.17.1

[PATCH 05/16] mips: add an option to support initialize SRAM for initial stack

[Daniel Schwierzeck]

Am 08.01.20 um 04:01 schrieb Weijie Gao:
> Currently CONFIG_MIPS_INIT_STACK_IN_SRAM assumes the memory space for the
> initial stack can be used directly. However on some platform the SRAM needs
> initialization, e.g. lock cache.
> 
> This patch adds an option to allow a new function mips_sram_init() being
> called before setup_stack_gd.
> 
> Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
> ---
>  arch/mips/Kconfig     | 9 +++++++++
>  arch/mips/cpu/start.S | 7 +++++++
>  2 files changed, 16 insertions(+)
> 

Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

-- 
- Daniel

[PATCH 05/16] mips: add an option to support initialize SRAM for initial stack

[Stefan Roese]

On 08.01.20 04:01, Weijie Gao wrote:
> Currently CONFIG_MIPS_INIT_STACK_IN_SRAM assumes the memory space for the
> initial stack can be used directly. However on some platform the SRAM needs
> initialization, e.g. lock cache.
> 
> This patch adds an option to allow a new function mips_sram_init() being
> called before setup_stack_gd.
> 
> Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
> ---
>   arch/mips/Kconfig     | 9 +++++++++
>   arch/mips/cpu/start.S | 7 +++++++
>   2 files changed, 16 insertions(+)
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 52afbf79c5..015a7f6358 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -402,6 +402,15 @@ config MIPS_INIT_STACK_IN_SRAM
>   	  lowlevel_init. Thus lowlevel_init does not need to be implemented
>   	  in assembler.
>   
> +config MIPS_SRAM_INIT
> +	bool
> +	default n
> +	depends on MIPS_INIT_STACK_IN_SRAM
> +	help
> +	  Select this if the SRAM for initial stack needs to be initialized
> +	  before it can be used. If enabled, a function mips_sram_init() will
> +	  be called just before setup_stack_gd.
> +
>   config SYS_DCACHE_SIZE
>   	int
>   	default 0
> diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S
> index 1d21b2324a..f9805fa000 100644
> --- a/arch/mips/cpu/start.S
> +++ b/arch/mips/cpu/start.S
> @@ -216,6 +216,13 @@ wr_done:
>   #endif
>   
>   #ifdef CONFIG_MIPS_INIT_STACK_IN_SRAM
> +#ifdef CONFIG_MIPS_SRAM_INIT
> +	/* Initialize the SRAM first */
> +	PTR_LA	t9, mips_sram_init
> +	jalr	t9
> +	 nop

Nitpicking: This looks like a indentation issue above (stray space).
Please double check.

Other than that:

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan