From mboxrd@z Thu Jan  1 00:00:00 1970
From: Reinhard Meyer <u-boot@emk-elektronik.de>
Date: Sat, 13 Nov 2010 23:38:54 +0100
Subject: [U-Boot] RFC: Aligning arch initialisation sequences
In-Reply-To: <20101113215302.6BEA3CEA55B@gemini.denx.de>
References: <4CD67A22.9040802@gmail.com> <201011091835.38581.vapier@gentoo.org>
	<4CDE1107.80108@gmail.com> <4CDE30CF.9010509@emk-elektronik.de>
	<20101113081712.C5D85150ADD@gemini.denx.de>
	<4CDF04A8.4050802@emk-elektronik.de>
	<20101113215302.6BEA3CEA55B@gemini.denx.de>
Message-ID: <4CDF137E.2000902@emk-elektronik.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> In message<4CDF04A8.4050802@emk-elektronik.de>  you wrote:
>>
>> But whats left of my ideas is the following:
>>
>> in asm: set stack to end of SRAM (or whatever)
>> (board-config.h would not subtract GENERATED_GBL_DATA_SIZE
>> anymore)
>>
>> in c:
>> board_early_init(void)
>> {
>> 	gd_t auto_gd;
>> 	gd =&auto_gd;
>>
>> That would rid us of all alignment concerns:
>> Setting stack to end of initial storage will certainly
>> be aligned, and the auto_gd will be aligned as the
>> toolchain deems necessary.
>>
>> We would not need GENERATED_GBL_DATA_SIZE anymore.
>>
>> The auto_gd space on stack will be valid even into the call
>> to relocate_code.
>
> This has but on tiny shortcoming: we use GD to pass data around, for
> example to pass clock frequencies determind before relocation to the
> code running after relocation - which means that GD must be of a
> statically allocated storage class.
>
> Your stack variable above will go out of scope as soon as we leave the
> board_early_init() function...

Correct, that's why its even now copied over to storage in SDRAM...
(at least on ARM:
	debug ("relocation Offset is: %08lx\n", gd->reloc_off);
	memcpy (id, (void *)gd, sizeof (gd_t));

	relocate_code (addr_sp, id, addr);
)

Best Regards,
Reinhard