On Sun, 1 May 2005 14:55:44 +0200
R=E9mi Zara <remi_zara@mac.com> wrote:

> start=3D0x100000
> Loaded initial symtab at 0x4bc934, strtab at 0x4e8d48, # entries 11253
> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
> 2005
>      The NetBSD Foundation, Inc.  All rights reserved.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>      The Regents of the University of California.  All rights
>      reserved.

Nice!

I've been taking a different approach.  I suspect there is a problem
with how the BATs are mapped.

>=20
> So the kernel seems to hang in or after the (second) call to=20
> 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.=20
Currently all four BATs get used with the first 32M of memory.

The first two BATs could be mapped to handle the first 16M,
and then one BAT could be mapped to 0x80800000, and the last one to
0xf3000000. This still leaves /platinum, which is the display device
on 7200s, unmapped. As far as I can tell, platinum is not an OF
frame-buffer.  It contains none of the necessary words (none at all,
actually), so it might be that 7200s will be serial only or configured
to go into X at boot.

The range on bandit@f2000000 for the PCI slots is a full 256M, but I put
two cards in the slots and both were contained within the 0x80800000
space.

I've been trying this approach:

                for (i =3D 0; i < 16; i++) {
                        battable[i].batl =3D BATL601(i << 23,
                           BAT601_BSM_8M, BAT601_V);
                        battable[i].batu =3D BATU601(i << 23,
                            BAT601_M, BAT601_Ku, BAT601_PP_NONE);
                }
        =20
                battable[0x80800000 >> 23].batl =3D (0x80800000 |=20
                                                    BAT601_BSM_8M |
                                                    BAT601_V);
        =20
                battable[0x80800000 >> 23].batu =3D (0x80800000 |
                                                    BAT601_M  |
                                                    BAT601_Ku |
                                                    BAT601_PP_NONE);
                       =20
                battable[0xf3000000 >> 23].batl =3D (0xf3000000 |
                                                    BAT601_BSM_8M |=20
                                                    BAT601_V);
               =20
                battable[0xf3000000 >> 23].batu =3D (0xf3000000 |
                                                    BAT601_M  |
                                                    BAT601_Ku |
                                                    BAT601_PP_NONE);
                       =20
                     __asm __volatile ("mtibatu 0,%1; mtibatl 0,%0"    =20
                    :: "r"(battable[0x00000000 >> 23].batl),
                       "r"(battable[0x00000000 >> 23].batu));
                __asm __volatile ("mtibatu 1,%1; mtibatl 1,%0"
                    :: "r"(battable[0x00800000 >> 23].batl),
                       "r"(battable[0x00800000 >> 23].batu)); =20
                __asm __volatile ("mtibatu 2,%1; mtibatl 2,%0"=20
                    :: "r"(battable[0x80800000 >> 23].batl),
                       "r"(battable[0x80800000 >> 23].batu));
                __asm __volatile ("mtibatu 3,%1; mtibatl 3,%0"
                    :: "r"(battable[0xf3000000 >> 23].batl),
                       "r"(battable[0xf3000000 >> 23].batu));

        /*
         * Add any I/O BATs specificed;
         * use I/O segments on the BAT-starved 601.
         */
        if (cpuvers =3D=3D MPC601) {
                while (pa !=3D 0) {
                        if ((pa !=3D 0x8000000) &&
                                (pa !=3D 0xf0000000)) {
                                register_t len =3D va_arg(ap, register_t);
                                mpc601_ioseg_add(pa, len); =20
                                pa =3D va_arg(ap, paddr_t);
                        }
                }
     =20

However, this hasn't gotten too far.  I'm not completely sure what the
problem is.  I am also unable to build MD kernels thanks to the chronic
problem with -current userland being unable to build on macppc, so I'm
having to try compressed raw kernels.

It looks like your debug trace does imply there is still a problem with
the BATs.  The approach I suggested turns off virtual mode in Open
Firmware.  It will treat memory addresses as real.  SRR1 is the MSR at
the time of the exception and 0x40003030 has 11 for bits 26 and 27, so
address translation is on at the CPU.  I believe the ofw_stack() call is
expecting addresses to be virtual.

What's the instruction at

0x0049d2c0: at OF_getprop+0x68

?

One aspect that I've noticed is that the BAT init in initppc doesn't
actually examine where the hardware is.  While the address space mapped
to BATs does cover hardware space, it is coded in rather than
discovered. =20

tim