Eldee Stephens III wrote:

>Well, after having discussed my prospects with MacBSD on my PowerBook,
>I decided to give it a go with the latest kernels. Here are some
>results:
>
>Using the GENERIC and GENERIC #67 from Steve Allen, the machine froze
>during startup at:
>
>mrg: Not setting up egret.
>mrg: ADB interrupts enabled

Not setting up egret may be the desired behavor if the PowerBook doesn't 
have Egret. Someone inserted the address of InitPwrMgr for InitEgret for 
most of te PowerBooks and all the Duos in the ROM Vector Tables.  
However, if this routine was meant to be called during setup instead of 
InitEgret this may be a problem. It appears that the routine at this 
address in the ROM Vector Tables is only called on machines assumed to 
have Egret as determined by the contents of HwCfgFlags3. Maybe the person 
or persons who put the address of InitPwrMgr into the Tables could 
elaborate on this?

The ROM initializtion code on some systems might access some additional 
ToolBox routines not currently mapped as FixDiv and FixMul did on some 
systems.  I checked to make sure that if this happened the user would get 
a meaningful error message, and the code certainly shows that this was 
planned for.  I didn't recall ever seeing the message on my system which 
uses FixDiv/FixMul, so as a test I removed them from a GENERIC Kernel and 
tried booting.  The expected error message never came out, instead I got 
a "panic: kernel jump to zero".  It seems that others have recently 
reported seeing this message while booting GENERIC Kernels on their 
systems.  I was able to isolate the problem to a "movl a0@,a0 ; bne xxx" 
sequence. One would assume that the Condition Codes would be properly set 
based on the results placed into Register a0, but that wasn't happening.  
The Data Book seems to indicate the Condition Codes are set using some 
bizzare DST AND ^SRC sequence which obviously works in most cases, but 
breaks if the instruction execution changes the register used to fetch 
the source operand. The fix in this case was easy, but I was left with 
the feeling that there may be other places in the code where Condition 
Codes are assumed to be set properly but aren't because of this very same 
thing.  I'm not an assembler whiz but it looked like this could be 
happening in some of the FPU exception handling routines and that could 
explain some of the random results some are reporting with FPU emulation.

-bob