All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sricharan R <r.sricharan@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 03/12] omap5: Expand CONFIG_SPL_MAX_SIZE and comment upon SRAM_SCRATCH_SPACE_ADDR
Date: Wed, 21 Aug 2013 10:52:26 +0530	[thread overview]
Message-ID: <52144E92.80006@ti.com> (raw)
In-Reply-To: <1377003234-16792-4-git-send-email-trini@ti.com>

Hi Tom,

On Tuesday 20 August 2013 06:23 PM, Tom Rini wrote:
> After examining both TRMs and doing some experimentation, we can rely on
> using the start of the download area for CONFIG_SPL_TEXT_BASE and then
> move SRAM_SCRATCH_SPACE_ADDR up, just like am335x.  This is required for
> peripheral boot modes such as UART.
>
> Signed-off-by: Tom Rini <trini@ti.com>
> ---
>  arch/arm/include/asm/arch-omap5/omap.h |   11 ++++++++++-
>  include/configs/omap5_common.h         |    4 ++--
>  2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h
> index 597c692..e9a51d3 100644
> --- a/arch/arm/include/asm/arch-omap5/omap.h
> +++ b/arch/arm/include/asm/arch-omap5/omap.h
> @@ -153,6 +153,15 @@ struct s32ktimer {
>  #define EFUSE_4 0x45145100
>  #endif /* __ASSEMBLY__ */
>  
> +/*
> + * In all cases, the TRM defines the RAM Memory Map for the processor
> + * and indicates the area for the downloaded image.  We use all of that
> + * space for download and once up and running may use other parts of the
> + * map for our needs.  We set a scratch space that is at the end of the
> + * OMAP5 download area, but within the DRA7xx download area (as it is
> + * much larger) and do not, at this time, make use of the additional
> + * space.
> + */
>  #ifdef CONFIG_DRA7XX
>  #define NON_SECURE_SRAM_START	0x40300000
>  #define NON_SECURE_SRAM_END	0x40380000	/* Not inclusive */
> @@ -160,7 +169,7 @@ struct s32ktimer {
>  #define NON_SECURE_SRAM_START	0x40300000
>  #define NON_SECURE_SRAM_END	0x40320000	/* Not inclusive */
>  #endif
> -#define SRAM_SCRATCH_SPACE_ADDR	NON_SECURE_SRAM_START
> +#define SRAM_SCRATCH_SPACE_ADDR	0x4031E000
>  
>  /* base address for indirect vectors (internal boot mode) */
>  #define SRAM_ROM_VECT_BASE	0x4031F000
> diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
> index 8e82fed..0345c57 100644
> --- a/include/configs/omap5_common.h
> +++ b/include/configs/omap5_common.h
> @@ -128,8 +128,8 @@
>  
>  
>  /* Defines for SPL */
> -#define CONFIG_SPL_TEXT_BASE		0x40300350
> -#define CONFIG_SPL_MAX_SIZE		0x19000	/* 100K */
> +#define CONFIG_SPL_TEXT_BASE		0x40300000
> +#define CONFIG_SPL_MAX_SIZE		(0x4031E000 - CONFIG_SPL_TEXT_BASE)
>  #define CONFIG_SPL_DISPLAY_PRINT
>  #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
>  
Ok, we keep the SPL stack at

#define CONFIG_SYS_INIT_SP_ADDR         (NON_SECURE_SRAM_END - GENERATED_GBL_DATA_SIZE)

So does this now create any possiblity of STACK overlap with the SCRATCH PAD area ? or
since we have 8K at TOP, this is enough to avoid overlap ?

Is it good to keep NON_SECURE_SRAM_END 0x4031E000 otherwise ?

Also with the base address change to 0x40300000, wanted to check this once on HS devices.
I can check this and let you know.

Regards,
 Sricharan

  reply	other threads:[~2013-08-21  5:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20 12:53 [U-Boot] [PATCH 00/12] am33xx/omap5: Improve docs for customization Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 01/12] am33xx: Correct and expand comments on CONFIG_SPL_MAX_SIZE Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 02/12] TI:armv7: Move CONFIG_SPL_LIBDISK_SUPPORT to MMC section Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 03/12] omap5: Expand CONFIG_SPL_MAX_SIZE and comment upon SRAM_SCRATCH_SPACE_ADDR Tom Rini
2013-08-21  5:22   ` Sricharan R [this message]
2013-08-21 13:49     ` Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 04/12] TI:am335x: Better comment and organize the networking related options Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 05/12] am335x_evm: Add comment by SPL SPI support Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 06/12] am335x_evm: Regroup USB options Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 07/12] TI:armv7: Re-order slightly the generic CONFIG options, expand related comments Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 08/12] am335x_evm: Update README for customization Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 09/12] TI:am33xx: Move SPL YMODEM support to the per-board config Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 10/12] TI:omap5: Clarify comments about SPL and DDR timings in common config Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 11/12] omap5_uevm: Better comment why we have TCA642X and the reset time Tom Rini
2013-08-20 12:53 ` [U-Boot] [PATCH 12/12] dra7xx_evm: Re-order and comment the networking related config options Tom Rini
2013-08-28 18:25 ` [U-Boot] [PATCH 00/12] am33xx/omap5: Improve docs for customization Tom Rini

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=52144E92.80006@ti.com \
    --to=r.sricharan@ti.com \
    --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 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.