public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] SPL: sunxi: don't force .BSS into DRAM
Date: Thu, 30 Jun 2016 03:54:23 +0200	[thread overview]
Message-ID: <57747BCF.2020609@denx.de> (raw)
In-Reply-To: <20160630002912.2903-1-andre.przywara@arm.com>

On 06/30/2016 02:29 AM, Andre Przywara wrote:
> Probably due to some (ill-founded) fear of a large BSS all sunxi boards
> forced their SPL BSS section into DRAM.
> This only works if there is no usage of a .BSS variable before the DRAM
> is initialised.
> The recent inclusion of tiny-printf breaks this assumption (it has two
> variables in .BSS), so any early printf (printing a number) hangs a board.

I believe you should fix tiny-printf instead, try this patch:

diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
index 451f4f7..5b9b0dc 100644
--- a/lib/tiny-printf.c
+++ b/lib/tiny-printf.c
@@ -17,7 +17,7 @@ static char *bf;
 static char zs;

 /* Current position in sprintf() output string */
-static char *outstr;
+static char *outstr __section(".data");

 static void out(char c)
 {

> This in particular breaks the (WIP) Pine64 SPL, which at the moment links
> Allwinner's libdram library, trying to print debug information:
> DRAM:DRAM driver version: V1.0
> DRAM Type = <hangs>
> 
> As it turns out the normal BSS size for sunxi is about 256 Bytes, so we
> can happily remove the symbols and the linker script part that was
> forcing the section into DRAM and let the linker naturally put it into
> SRAM.

Except SRAM is limited, which is why bss was in DRAM.

> Tested on BananaPi M1 and Pine64(-SPL), also buildman sunxi was happy.
> 
> Thanks to Siarhei for providing helpful hints!
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> 
> (and now with the list in CC: as well) ...
> 
>  arch/arm/cpu/armv7/sunxi/u-boot-spl.lds | 4 +---
>  include/configs/sunxi-common.h          | 4 ----
>  2 files changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds b/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds
> index 53f0cbd..a90404f 100644
> --- a/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds
> +++ b/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds
> @@ -16,8 +16,6 @@
>   */
>  MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,\
>  		LENGTH = CONFIG_SPL_MAX_SIZE }
> -MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR, \
> -		LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
>  
>  OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
>  OUTPUT_ARCH(arm)
> @@ -54,5 +52,5 @@ SECTIONS
>  		*(.bss*)
>  		. = ALIGN(4);
>  		__bss_end = .;
> -	} > .sdram
> +	} > .sram
>  }
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 94275a7..e3fe965 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -75,7 +75,6 @@
>   * since it needs to fit in with the other values. By also #defining it
>   * we get warnings if the Kconfig value mismatches. */
>  #define CONFIG_SPL_STACK_R_ADDR		0x2fe00000
> -#define CONFIG_SPL_BSS_START_ADDR	0x2ff80000
>  #else
>  #define SDRAM_OFFSET(x) 0x4##x
>  #define CONFIG_SYS_SDRAM_BASE		0x40000000
> @@ -86,11 +85,8 @@
>   * since it needs to fit in with the other values. By also #defining it
>   * we get warnings if the Kconfig value mismatches. */
>  #define CONFIG_SPL_STACK_R_ADDR		0x4fe00000
> -#define CONFIG_SPL_BSS_START_ADDR	0x4ff80000
>  #endif
>  
> -#define CONFIG_SPL_BSS_MAX_SIZE		0x00080000 /* 512 KiB */
> -
>  #if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I)
>  /*
>   * The A80's A1 sram starts at 0x00010000 rather then at 0x00000000 and is
> 


-- 
Best regards,
Marek Vasut

  reply	other threads:[~2016-06-30  1:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30  0:29 [U-Boot] [PATCH] SPL: sunxi: don't force .BSS into DRAM Andre Przywara
2016-06-30  1:54 ` Marek Vasut [this message]
2016-06-30  8:50   ` Andre Przywara
     [not found] <20160630002500.2817-1-andre.przywara@arm.com>
     [not found] ` <af86054b-8fcc-3b58-6889-7af02cd7a9fc@redhat.com>
2016-06-30 15:43   ` Andre Przywara
2016-06-30 17:40     ` Peter Korsgaard
2016-06-30 21:09       ` Marek Vasut
     [not found]   ` <CAPnjgZ2ajoU90kSNMoHVhbXN4CdeKzs5-SQ-Hq-xePfC0brJ3A@mail.gmail.com>
2016-07-02 11:49     ` Hans de Goede
2016-07-03 21:15       ` Simon Glass
2016-07-03 22:24       ` André Przywara

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=57747BCF.2020609@denx.de \
    --to=marex@denx.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