From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] RFC: Aligning arch initialisation sequences
Date: Sat, 13 Nov 2010 20:51:37 +1100 [thread overview]
Message-ID: <4CDE5FA9.4000309@gmail.com> (raw)
In-Reply-To: <4CDE3251.6080402@emk-elektronik.de>
On 13/11/10 17:38, Reinhard Meyer wrote:
> On 13.11.2010 07:31, Reinhard Meyer wrote:
>> Dear Graeme Russ, Dear All,
>>> On 10/11/10 10:35, Mike Frysinger wrote:
>>>> On Sunday, November 07, 2010 05:06:26 Graeme Russ wrote:
>>>>> Should all architectures strive to look as much like one another as
>>>>> possible? Should we accept that maybe this particular issue be thrown in
>>>>> the too hard basket?
>>>>
>>>> imo, we should strive to have these things in one common place and not
>>>> just
>>>> have the different files look the sam
>>>
>>> I was afraid someone would say that. I've been having a look and a think
>>> about the situation for x86, and I cannot come up with a sane way to
>>> emulate the way the global data pointer is handled by the other arches.
>>>
>>> I essence, the gd pointer is a unique global variable available prior to
>>> relocation. On all other arches, this is achieved by using a reserved
>>> register which I do not have the luxury of on x86 :(
>>>
>>> Unless I can resolve this, I cannot move x86 in line with the other arches
>>> (i.e. init functions can only be done after relocation).
>>
>> <Ducks><Flame shield>
>> I *personally* prefer code without tool-chain specific, out of "C"
>> constructs. So I would be fine with passing gd as a parameter to all
>> pre-relocation functions. The way they are called with a function array
>> that would probably only marginally increase code size. And instead of
>> all the funky stack calculations to get the space for gd, it could be
>> achieved in a much simpler way:
>>
>> in asm: set stack to end (or begin) of SRAM (or whatever)
>>
>> in c:
>> board_early_init(void)
>> {
>> gd_t auto_gd;
>> ...
>> call all pre-relocation functions with&auto_gd as parameter
>> ...
>> relocate and fixup (preferably in C) - would probably
>> have arch-specific parts in the ELF fix-up
>> ...
>> memcpy (&static_gd,&auto_gd, sizeof auto_gd);
>> ...
>> setup final stack and jump to relocated code...
>> that should be a *small* assembly helper function
>> }
>>
>> You get the idea ;)
>>
>> </Flame Shield></Ducks>
>
> Ok, ok, I forgot the hitch that some functions called from
> the pre-relocation functions also would need the auto_gd passed on,
> *if* they need to use gd. That might become ugly, but x86 has solved
> that somehow?
>
Yes, by declaring gd as a global (static) variable and only referencing it
after relocation (well actually, it is passed as a parameter to
board_init_f (in lieu of boot_params) where the relocation is performed
Regards,
Graeme
next prev parent reply other threads:[~2010-11-13 9:51 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-07 10:06 [U-Boot] RFC: Aligning arch initialisation sequences Graeme Russ
2010-11-09 23:35 ` Mike Frysinger
2010-11-13 4:16 ` Graeme Russ
2010-11-13 4:58 ` Mike Frysinger
2010-11-13 6:31 ` Reinhard Meyer
2010-11-13 6:38 ` Reinhard Meyer
2010-11-13 9:51 ` Graeme Russ [this message]
2010-11-13 8:17 ` Wolfgang Denk
2010-11-13 21:35 ` Reinhard Meyer
2010-11-13 21:53 ` Wolfgang Denk
2010-11-13 22:38 ` Reinhard Meyer
2010-11-13 22:45 ` Wolfgang Denk
2010-11-13 22:48 ` Reinhard Meyer
2010-11-14 0:07 ` Wolfgang Denk
2010-11-14 0:25 ` Graeme Russ
2010-11-14 0:35 ` Wolfgang Denk
2010-11-14 1:09 ` Graeme Russ
2010-11-14 9:04 ` Wolfgang Denk
2010-11-14 10:21 ` Graeme Russ
2010-11-14 19:43 ` Graeme Russ
2010-11-14 4:07 ` Reinhard Meyer
2010-11-14 9:07 ` Wolfgang Denk
2010-11-14 13:46 ` Reinhard Meyer
2010-11-14 19:36 ` Graeme Russ
2010-11-14 20:16 ` Reinhard Meyer
2010-11-14 21:01 ` Graeme Russ
2010-11-13 8:20 ` Albert ARIBAUD
2010-11-13 11:18 ` Graeme Russ
2010-11-14 5:10 ` Graeme Russ
2010-11-14 5:48 ` Graeme Russ
2010-11-14 9:16 ` Albert ARIBAUD
2010-11-14 10:30 ` Wolfgang Denk
2010-11-14 12:10 ` Albert ARIBAUD
2010-11-14 15:01 ` Wolfgang Denk
2010-11-14 17:53 ` Albert ARIBAUD
2010-11-14 19:06 ` Wolfgang Denk
2010-11-14 19:29 ` Albert ARIBAUD
2010-11-14 19:55 ` Wolfgang Denk
2010-11-14 20:10 ` Albert ARIBAUD
2010-11-14 20:42 ` Wolfgang Denk
2010-11-14 19:23 ` Wolfgang Denk
2010-11-14 19:34 ` Graeme Russ
2010-11-14 20:05 ` Albert ARIBAUD
2010-11-14 21:27 ` Graeme Russ
2010-11-15 11:08 ` Graeme Russ
2010-11-14 21:51 ` Wolfgang Denk
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=4CDE5FA9.4000309@gmail.com \
--to=graeme.russ@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.