public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox