Problem with OF entry point

[Segher Boessenkool]

>> The client interface is required to not change _either_ SPRG2 or R1.
>> It is allowed to modify only LR, CTR, XER, CR[01567], and R3-R12.
>> (And, when running in virtual mode, some of the stuff related to
>> MMU functions, of course).
>
> Apparently, it's not about changing them, it's about using them ;)
>
> It seems OF sets some stuffs in these registers before calling us
> and will die on the next exception if we happen to change those values.

Ah yes.  That behaviour is just as broken, of course.

>> So normally you don't need any special save/restore, as the normal
>> calling conventions will handle it Just Fine(tm).
>
> No (see below)

This is also because of broken OF implementation (see below).

>> Unfortunately, Apple's 64-bit OF only has a 32-bit Client Interface,
>> and seems to be a bit buggy as well, as you found out ;-)
>>
>> Your changes look sane to me, though.  But why do we need assembler
>> code for this anyway?  Except for fixing up buggy firmware...
>
> No. The firmware is 32 bits, so it will internally fail to properly

Actually, it is 64 bit, just not all of it.

Not saving the high half of the registers is a bug.

And it doesn't have a 64-bit client interface.  Which isn't really
a bug, but is also not implementing the firm recommendations by the
standard.

> save/restore the high bits of non-volatile registers. We need the
> asm wrapper to save them and switch to 32 bits for the OF call.

Another bug; the OF entry point should switch to 32-bit mode itself.

>> It might make a lot of sense to run the kernel-side client-interface
>> code (i.e., prom.c) in 32-bit mode, if there's only a 32-bit
>> client interface available?
>
> Hehe, it would, it would ... but then, we would also need to get
> rid of all the shared data structures between prom.c "init" code
> and the rest of the kernel ;)

Which is a good idea, anyway :-)

> Note that we do plan to do that at one point. Step #1 will be to
> split prom.c, a bit like we did on ppc32. Step #2 will be to
> define a cleaner "interface" between prom_init.c and the rest
> of the kernel, at which point we may be able to just compile
> prom_init as a completely separate (and 32 bits relocatable)
> binary.

/me cheers you on :-)


Segher


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/