Thiemo Seufer wrote:
> Franck Bui-Huu wrote:
>> sorry to be ignorant of 64 bit kernels, but what's the point
>> to load them in KSEG0.
>
> Smaller code with better performance.
>
you mean we get smaller code _only_ by using the short 2 instructions
you described below ?
>>> and use short 2-instruction symbol references there.
>> do you mean "it allows to use only 2 'lui' instructions to load
>> a symbol address into a register" ?
>
> It allows a 2-instruction "lui ; addiu" sequence instead of a
> 6-instruction "lui ; lui ; addiu ; addiu ; dsll32 ; addu" sequence.
>
[snip]
>>
>> code_resource.start = virt_to_phys(&_text);
>> code_resource.end = virt_to_phys(&_etext) - 1;
>> data_resource.start = virt_to_phys(&_etext);
>> data_resource.end = virt_to_phys(&_edata) - 1;
>>
>> How does it work in this case ?
>
> Those are addresses in 64-bit space, no special handling is needed
> there.
hm I'missing something there. Let's say that '&_text' is in KSEG0 and
is equal to 0xffffffff80000000. In this case virt_to_phys() returns
0x57ffffff80000000 (with PAGE_OFFSET = 0xa800000000000000). Is this
physical address correct ??
>
> The same doesn't hold for the initrd addresses supplied by the (32-bit)
> firmware. The firmware doesn't convert the kernel parameters to 64-bit
> values because the O2 kernel used to allow a pure 32-bit build, and the
> firmware can't find out what's actually inside the object file.
>
This should be already handled by this code taken from setup.c:
static int __init rd_start_early(char *p)
{
unsigned long start = memparse(p, &p);
#ifdef CONFIG_64BIT
/* HACK: Guess if the sign extension was forgotten */
if (start > 0x0000000080000000 && start < 0x00000000ffffffff)
start |= 0xffffffff00000000UL;
#endif
initrd_start = start;
initrd_end += start;
return 0;
}
Thanks
Franck
