Problem with OF entry point

[Benjamin Herrenschmidt]

> 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.

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

No (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
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.

> 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 ;)

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.

Ben.


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