From mboxrd@z Thu Jan  1 00:00:00 1970
From: Graeme Russ <graeme.russ@gmail.com>
Date: Sun, 14 Nov 2010 12:09:55 +1100
Subject: [U-Boot] RFC: Aligning arch initialisation sequences
In-Reply-To: <20101114003501.82985CEA55B@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>
	<4CDF137E.2000902@emk-elektronik.de>
	<20101113224554.64D72CEA55B@gemini.denx.de>
	<4CDF15BB.1090107@emk-elektronik.de>
	<20101114000758.51B6ED302CB@gemini.denx.de>
	<4CDF2C8B.3060401@gmail.com>
	<20101114003501.82985CEA55B@gemini.denx.de>
Message-ID: <4CDF36E3.7060505@gmail.com>
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

On 14/11/10 11:35, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <4CDF2C8B.3060401@gmail.com> you wrote:
>>
>>> You cannot and must not touch SDRAM in board_early_init_f(). And even
>>> more, you must not at all run relocate_code() there!
>>>
>>
>> See:
>>  arch/powerpc/lib/board.c
>>  arch/m68k/lib/board.c
>>  arch/arm/lib/board.c
>>
>> They all malloc the final global data structure, memcpy the temporary
>> global data to the malloc'd global data, and call relocate_code passing a
>> pointer to the new global data all at the very end board_init_f() and
>> therefore after SDRAM has been initialised
> 
> Yes, and this is correct. board_init_f != board_early_init_f
> 

Ah, I see...

board_early_init_f() is (in most cases) the very first entry in the
init_sequence[]

So if global data is defined on the stack in board_init_f() and copied to
the heap at the end of board_init_f() we should be OK. Is global data
needed prior to board_init_f()?

For x86, I allocate global data in asm and set three members. The sticking
point for me is the single ulong parameter to board_init_f() which does not
present enough flexibility to pass all the information I need.

I could create a stub x86_board_init_f which has all the parameters I need,
allocate global_data on it's stack, setup global data based on the
parameters and call board_init_f() passing the pointer to global data. x86
could then do the same as the other arches and copy global data to a
malloc'd version.

One step closer to unification.

One nit-pick is that, in reality, the stack space used by board_init_f() is
never reclaimed because it never returns. What we could do is reset the
stack pointer prior to calling board_init_r()

I still have no way to globalise gd prior to relocation though :( (still
thinking)

Regards,

Graeme