public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Reinhard Meyer <u-boot@emk-elektronik.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] ALERT! >90% of all board configurations BROKEN
Date: Tue, 26 Oct 2010 02:11:02 +0200	[thread overview]
Message-ID: <4CC61C96.9010806@emk-elektronik.de> (raw)
In-Reply-To: <20101025220712.35FCC135C64@gemini.denx.de>

Dear Wolfgang Denk,
> In message<4CC5E865.70003@emk-elektronik.de>  you wrote:
>>
>> Grep-ing for CONFIG_SYS_GBL_DATA_SIZE in *.[chsS] Makefile *.ld it
>> seems to me that with "ELF-reloc" active that define is not used
>> anywhere at least in ARM.
>
> Are you sure? My very first smaple sees:
>
> "arch/arm/cpu/arm926ejs/start.S"
>
> 346         /* Set up the stack                                                 */
> 347 stack_setup:
> 348         ldr     r0, _TEXT_BASE          /* upper 128 KiB: relocated uboot   */
> 349         sub     sp, r0, #128            /* leave 32 words for abort-stack   */
> 350 #ifndef CONFIG_PRELOADER
> 351         sub     r0, r0, #CONFIG_SYS_MALLOC_LEN  /* malloc area                      */
> 352         sub     r0, r0, #CONFIG_SYS_GBL_DATA_SIZE /* bdinfo                        */

That is #ifdef-ed away in case of ARM-relocation. Perhaps we should remove
all code that pertains to "WITHOUT_RELOC"... Would make the rest of the code
less obscure...

I changed my board.config like this:
...
/*#define CONFIG_SYS_GBL_DATA_SIZE 128*/	/* 128 bytes for initial data */
...
#define	CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_SDRAM_BASE + 0x1000 /*- CONFIG_SYS_GBL_DATA_SIZE*/)
...
and it still compiles. The second line is the only use of GBL_DATA_SIZE,
since that is often set to somewhere in SRAM, it is still ok - even if
set to the end of SRAM it will most likely wrap into the repeated SRAM
image on most SoCs.

in start.S:

/* Set stackpointer in internal RAM to call board_init_f */
call_board_init_f:
	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)
	ldr	r0,=0x00000000
	bl	board_init_f

in board.c:

void board_init_f (ulong bootflag)
{
	bd_t *bd;
	init_fnc_t **init_fnc_ptr;
	gd_t *id;
	ulong addr, addr_sp;

	/* Pointer is writable since we allocated a register for it */
	gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);

So global data is at CONFIG_SYS_INIT_SP_ADDR, stack goes down from
CONFIG_SYS_INIT_SP_ADDR.

Board maintainers for ARM should be aware that CONFIG_SYS_INIT_SP_ADDR
should point to RAM with enough space for global data above and enough
stack space below.

Best Regards,
Reinhard

  reply	other threads:[~2010-10-26  0:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-25 20:00 [U-Boot] ALERT! >90% of all board configurations BROKEN Wolfgang Denk
2010-10-25 20:28 ` Reinhard Meyer
2010-10-25 22:07   ` Wolfgang Denk
2010-10-26  0:11     ` Reinhard Meyer [this message]
2010-10-26  6:31       ` Albert ARIBAUD
2010-10-26  8:26         ` Reinhard Meyer
2010-10-26  9:40           ` Wolfgang Denk
2010-10-26  6:39   ` Heiko Schocher

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=4CC61C96.9010806@emk-elektronik.de \
    --to=u-boot@emk-elektronik.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