On 2/2/07, Allen Briggs <briggs@netbsd.org> wrote:
>         lis     8,openfirmware_entry@ha
>
> Loads the upper 16 bits of r8 with the upper 16 bits of the address
> of our variable 'openfirmware_entry' (load immediate data with a shift,
> and the @ha says to the assembler/linker to take the upper 16 bits of
> the symbol's address, suitable for signed arithmetic with the lower half
> to get the actual address).
>
>         stw     5,openfirmware_entry@l(8) /* save client interface handler*/
>
> Stores r5 into the address formed by adding the contents of r8 to the
> lower 16 bits of the address of our 'openfirmware_entry' variable.
>
> Make sense?


yead - cool - thaks for that, although there is a little cloud in my
head as to why one would have no store high 16bits of variable's
address in the high 16bits of some register only to add them back to
the low 16bits of the variables address... but I will "chew" on that
one...

in the meantime... it would appear that when the code jumps from
kernel back to openfirmware (i.e. that "blrl" call in the above posts)
that perhaps the msr register gets reset and ends up generating the
interrupts... i.e. putting infinite loop just after the "blrl" ends up
with decrementer exception, whils the same infinite loop prior to
"blrl" does not cause the exception (but rather, as anticipated,
pauses at the point of infinite loop) (what does the machine do, by
the way, when it is "back" in openfirmware before it gets back from it
?)


but as a side stepping way of getting things to work - i wonder if i
could install a dummy "no op" interrupt handler for decrementer (and
perhaps external) interrputs (decrementer interrupts are at 0x900 and
external ones are at 0x500) right at the "start" (before even calling
ofwinit) which would simply return without doing anything (and then
will be overwritted by valid handlers automatically as the kernel
loads...) but to do so (i.e. install the "no op" handlers) - how would
i do that in assembler... For example, i know that i firstly need to
store the actual executable code in 0x900 (as this is where the
processor will jump when there is an interrupt)... but then what? How
would I make it return back to "normal" execution?... Hmm i will have
a look at some google i guess... will be ... fun ... ufn ... NUF :-)