On 15/11/10 07:05, Albert ARIBAUD wrote:
> 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.7030...@free.fr> you wrote:
Alright, then I think we should document how we comply, or do not
comply,
Dear Mike Frysinger,
In message <201011091835.38581.vap...@gentoo.org> you 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
On Mon, Nov 15, 2010 at 7:05 AM, Albert ARIBAUD wrote:
> 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.7030...@free.fr> you wrote:
Alright, then I think we should document how we comply,
On Mon, Nov 15, 2010 at 7:16 AM, Reinhard Meyer
wrote:
> Dear Graeme Russ,
>>
>> On 15/11/10 00:46, Reinhard Meyer wrote:
>>>
>>> Dear Wolfgang Denk,
>>>
>>> To make it crystal clear now, and put the complete context:
>>>
>>> That simple change would rid us of all alignment concerns:
>>> Setting s
Dear Albert ARIBAUD,
In message <4ce04241.7070...@free.fr> you wrote:
>
> > OK, this is not even 0.1% of the size, but anyway...
>
> If the difference in size is marginal, then I prefer the implementation
> that has the least 'quirks' and most closely complies with EABI/AAPCS.
Yes, I agree. O
Dear Graeme Russ,
> On 15/11/10 00:46, Reinhard Meyer wrote:
>> Dear Wolfgang Denk,
>>
>> To make it crystal clear now, and put the complete context:
>>
>> That simple change would rid us of all alignment concerns:
>> Setting stack to end of initial storage will certainly
>> be aligned, and the aut
Le 14/11/2010 20:55, Wolfgang Denk a écrit :
> Actually situation might be differenton ARM. I just did quick and
> ditry test for the TX25 board:
>
> [...]
>
> The global pointer method saves a total of 152 bytes here
> (156 in .text saved, but 4 in .data needed).
>
> OK, this is not eve
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.7030...@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 pe
Dear Albert ARIBAUD,
In message <4ce0388e.2070...@free.fr> you wrote:
>
> > Register use is documented in the top level README.
>
> My bad: I'd missed that one because I always go straight to the doc/
> directory for documentation of this kind -- the root README I never read
> apart from the first
On 14/11/10 21:21, Graeme Russ wrote:
> On 14/11/10 20:04, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message <4cdf36e3.7060...@gmail.com> you wrote:
>>>
> Why don't we just change board_init_f(ulong bootflag) to board_init_f(gd_t
> *gd)? avr would need a slight mod to add board_type to gd
On 15/11/10 00:46, Reinhard Meyer wrote:
> Dear Wolfgang Denk,
>
> To make it crystal clear now, and put the complete context:
>
> That simple change 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 t
On 15/11/10 06:23, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message <4ce0221a.7030...@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
Le 14/11/2010 20:06, Wolfgang Denk a écrit :
>> 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
>
> Register use is documented in the top level README.
My bad: I'd missed that one because I always go stra
Dear Albert ARIBAUD,
In message <4ce0221a.7030...@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
> reloca
Dear Albert ARIBAUD,
In message <4ce0221a.7030...@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
Register use is documented in the top level README.
> up) -- and I think if there
Le 14/11/2010 16:01, Wolfgang Denk a écrit :
> This is perfectly OK, as we don't have to interface in any way with
> any strictly EABI conforming code - we are working in a completely
> controlled environment and can adjust rules as needed.
Alright, then I think we should document how we comply,
Dear Albert ARIBAUD,
In message <4cdfd1ae.1070...@free.fr> you wrote:
>
> >> There is no way to set aside a register in ARM code for applicative
> >> purposes.
>
> > What exactly do you mean by that?
>
> Use of the 16 ARM registers r0 to r15 in C code is governed by ABIs; we
> use the one known as
Dear Wolfgang Denk,
To make it crystal clear now, and put the complete context:
That simple change 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 GENERA
Le 14/11/2010 11:30, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4cdfa8e9.3050...@free.fr> you wrote:
>>
>>> Is there any reason the other arches could not implement an inline function
>>> as well? ARM for example:
>>>
>>> -#define DECLARE_GLOBAL_DATA_PTR register volatile gd
Dear Albert ARIBAUD,
In message <4cdfa8e9.3050...@free.fr> you wrote:
>
> > Is there any reason the other arches could not implement an inline function
> > as well? ARM for example:
> >
> > -#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8")
>
> There is no way to set asid
On 14/11/10 20:04, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4cdf36e3.7060...@gmail.com> you wrote:
>>
>> board_early_init_f() is (in most cases) the very first entry in the
>> init_sequence[]
>
> Right.
>
>> So if global data is defined on the stack in board_init_f() and copied t
Le 14/11/2010 06:48, Graeme Russ a écrit :
> Is there any reason the other arches could not implement an inline function
> as well? ARM for example:
>
> -#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8")
There is no way to set aside a register in ARM code for applicative
Dear Reinhard Meyer,
In message <4cdf6070.20...@emk-elektronik.de> you wrote:
> Dear Wolfgang Denk,
> > Yes, and this is correct. board_init_f != board_early_init_f
>
> To make it crystal clear now:
>
> void board_init_f (ulong bootflag)
That's not crystal clear at all. Until now, you've been
Dear Graeme Russ,
In message <4cdf36e3.7060...@gmail.com> you wrote:
>
> board_early_init_f() is (in most cases) the very first entry in the
> init_sequence[]
Right.
> 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 O
On 14/11/10 16:10, Graeme Russ wrote:
> On 13/11/10 22:18, Graeme Russ wrote:
>> On 13/11/10 19:20, Albert ARIBAUD wrote:
>>> Le 13/11/2010 05:16, Graeme Russ a écrit :
>>>
> static inline void *get_gd_ptr(void)
> {
> void *gd_ptr;
>
> asm volatile("gs mov 0, %0\n" : "=r" (gd_ptr));
>
On 13/11/10 22:18, Graeme Russ wrote:
> On 13/11/10 19:20, Albert ARIBAUD wrote:
>> Le 13/11/2010 05:16, Graeme Russ a écrit :
>>
>>> 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
Dear Wolfgang Denk,
> Yes, and this is correct. board_init_f != board_early_init_f
To make it crystal clear now:
void board_init_f (ulong bootflag)
{
bd_t *bd;
init_fnc_t **init_fnc_ptr;
gd_t *id;
ulong addr, addr_sp;
+ gd_t auto_gd;
/* Pointer is wr
On 14/11/10 11:35, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4cdf2c8b.3060...@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
>> a
Dear Graeme Russ,
In message <4cdf2c8b.3060...@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
>
>
On 14/11/10 11:07, Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message <4cdf15bb.1090...@emk-elektronik.de> you wrote:
>>
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);
m
Dear Reinhard Meyer,
In message <4cdf15bb.1090...@emk-elektronik.de> you wrote:
>
> >> 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));
> >>
>
Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> In message<4cdf137e.2000...@emk-elektronik.de> you wrote:
>>
>>> 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 me
Dear Reinhard Meyer,
In message <4cdf137e.2000...@emk-elektronik.de> you wrote:
>
> > 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
>
Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> In message<4cdf04a8.4050...@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:
>>
Dear Reinhard Meyer,
In message <4cdf04a8.4050...@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)
> {
>
Dear Wolfgang Denk,
> I think you would quickly find this becoming a pretty serious pain.
Yes, I saw that soon after my first post:)
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)
On 13/11/10 19:20, Albert ARIBAUD wrote:
> Le 13/11/2010 05:16, Graeme Russ a écrit :
>
>> 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 :(
>
>
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
>
Le 13/11/2010 05:16, Graeme Russ a écrit :
> 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 :(
Dusting off old knowledge of x86 and without eve
Dear Reinhard Meyer,
In message <4cde30cf.9010...@emk-elektronik.de> you wrote:
>
> 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
I think you would quickly find this becoming a pretty serious pain.
I've b
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
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 ba
On Friday, November 12, 2010 23:16:07 Graeme Russ wrote:
> 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
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 t
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 ju
Hi All,
I've been looking at how x86 does things compared to other arches, and it
seems to have one big difference - Very little is initialised prior to
relocation. The general order for x86 is:
- ultra-low level board initialisation
- DRAM controller initialisation
- DRAM sizing
- low-level
46 matches
Mail list logo
