public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.aribaud@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] RFC: Aligning arch initialisation sequences
Date: Sun, 14 Nov 2010 21:05:27 +0100	[thread overview]
Message-ID: <4CE04107.7050004@free.fr> (raw)
In-Reply-To: <4CE039CD.90706@gmail.com>

Le 14/11/2010 20:34, Graeme Russ a ?crit :
> On 15/11/10 06:23, Wolfgang Denk wrote:
>> Dear Albert ARIBAUD,
>>
>> In message<4CE0221A.7030502@free.fr>  you wrote:
>>>
>>> Alright, then I think we should document how we comply, or do not
>>> comply, with GNU EABI / AAPCS (maybe a README.arm that people could read
>>> up) -- and I think if there is a way to access GD both before and after
>>> relocation without making a register unavailable to the whole u-boot
>>> code, then we should use it.
>>
>> By the way - it should be not difficult to use a normal extern pointer
>> to reference the global data; see
>> "arch/powerpc/include/asm/global_data.h":
>>
>> 194 #if 1
>> 195 #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r2")
>> 196 #else /* We could use plain global data, but the resulting code is bigger */
>> 197 #define XTRN_DECLARE_GLOBAL_DATA_PTR    extern
>> 198 #define DECLARE_GLOBAL_DATA_PTR     XTRN_DECLARE_GLOBAL_DATA_PTR \
>> 199                                     gd_t *gd
>> 200 #endif
>
> I think you will find this peculiar to PowerPC

I don't think Wolfgang's idea is actually processor-specific.

Each processor has a way to define globals, which end up in the 
initialized data or bss area. BSS is not available before relocation, 
but initialized data is, and remains so after relocation.

So if we define gd as an initialized pointer (residing in the 
initialized data area), it will be available both before and after 
relocation.

Before relocation, this pointer will be read-only. We can set it at 
compile time if we know for each arch (or board) a good address in RAM 
or IRAM where gd can exist.

After relocation, the pointer becomes read-write: we can copy gd content 
from (I)RAM to RAM if necessary and then update the gd pointer.

> What you are talking about is exactly how x86 defines gd, but for x86, gd
> is not accessible until after relocation

Could it become accessible with the idea I expose above?

> Regards,
>
> Graeme

Amicalement,
-- 
Albert.

  reply	other threads:[~2010-11-14 20:05 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
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 [this message]
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=4CE04107.7050004@free.fr \
    --to=albert.aribaud@free.fr \
    --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