leon zadorin said on 2/2/07 07:41:
> 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 :-)
>

Hi Leon,

Firstly, thank you for pursuing this problem. I have one of the last
generation of 12" PowerBooks, and it exhibits the same problem as your
iBook. I also tried the patches posted by Antoine Reilles, but as he
reported they didn't reliably solve the problem.

In Motorolas PowerPC 601 manual it says to set the MSR[EE] bit to 0 if
you want to ignore exceptions such as the decrementer one. I could
send you the complete description of the decrementer exception of it
would be of any help to you - it's only about 50 lines of text.

Regards,

Chris