On Sun, 1 May 2005 10:31:12 -0400
Tim Kelly <hockey@dialectronics.com> wrote:

> I use this code to test for 601 in the bootloader I use for testing
> 
>        mfspr   r0,287                  /* PVR = 287 */
>        srwi    r0,r0,0x10 
>        cmpi    0,1,r0,0x02          /* 601 CPU = 0x0001 */
>        blt     bat601                  /* skip over non-601 BAT setup
>        */
> 
> Seems to work on 601, but I haven't tested it against other CPUs. 
> mfpvr is not implemented on the 601; the value has to be extracted via
> the call to SPR 287 (PVR).

On Sun, 1 May 2005 09:23:03 -0400
Tim Kelly <hockey@dialectronics.com> wrote:

> 
> Nice!
> 
> I've been taking a different approach.  I suspect there is a problem
> with how the BATs are mapped.
> 
> > 
> > So the kernel seems to hang in or after the (second) call to 
> > src/sys/arch/powerpc/oea/oea_machdep.c:mpc601_ioseg_add()
> > with args (0xf0000000, BAT_BL_256M), but before the third call.
> 
> I've been looking at this and I think this might need to be handled
> differently. If it is not a 601 CPU, oea_batinit maps any device space
> that might occur to a BAT.  However, with a 601 CPU on a 7200, device
> space won't get mapped to a BAT.  This is because PCI slots are
> assigned 8M at 0x80800000 and gc (obio*) is assigned 1M at 0xf3000000.
> Currently all four BATs get used with the first 32M of memory.

The concerns I had above are unfounded.  The 601 implements a completely
different address translation structure than all other PowerPC CPUs and
uses segment registers that are capable of addressing 256M at a time.  

tim