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 I do not have the luxury of on x86 :(
>>
>> Dusting off ooooold knowledge of x86 and without even a glance at x86
>> u-boot... Since GD is the only global used pre-reloc, can you not ensure
>> it always ends up first in the data segment, and then manage two values
>> for the DS segment reg, one pre-reloc where only gd can be used, and one
>> post-reloc where gd and all the other globals can be accessed?
>
> I had though of something similar to that by using GS (which is not
> generally used by u-boot) but it is very messy
>
> All segments are currently setup to be full 4GB with the initial descriptor
> table hard-coded in flash and then reloaded after relocation (it needs to
> be reloaded so it does not get clobbered when erasing flash or relocating
> from RAM). I did have a dynamic GTD calculated in asm using self modifying
> code but changed that out to use the same 'C' methodology as Linux. I would
> prefer not to go back there...
>
> So yes, it is possible, but quite frankly, I would rather leave the init
> functions post relocation than mess around with the GTS pre-relocation
>
OK, I've had a good hard look at this, and setting aside a segment is the
only way that I can think of. I'll need to revisit the self-modifying code
I threw out, but I can live with that small ugliness to bring x86
board_init_f() in line with the other (relocating) arches.
For some bizarre reason, the BIOS emulation layer *yuck* uses GS *double
yuck*. FS is available though
So, I can set aside FS to store the global data pointer, but this
introduces a new problem. To get the pointer, I cannot simply use gd->, I
will need to write a function to retrieve the pointer, so I need gd()->
So I'm thinking of a #define GLOBAL_DATA which all existing arches can
define simply as gd and x86 can define as get_gd_ptr() and I write the
get_gd_ptr() function to extract the pointer using FS
static inline void *get_gd_ptr(void)
{
void *gd_ptr;
asm volatile("gs mov 0, %0\n" : "=r" (gd_ptr));
return gd_ptr;
}
Now I hope the compiler will optimise this down very well. For example,
accessing gd results in the following asm:
/* gd->baudrate = CONFIG_BAUDRATE; */
mov 0x602917c,%eax
movl $0x2580,0x8(%eax)
I would expect using FS to result in something like:
/* gd->baudrate = CONFIG_BAUDRATE; */
mov fs:0x00000000,%eax
movl $0x2580,0x8(%eax)
So no speed or size penalty :)
Does this sound like a plan?
Regards,
Graeme
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
