re: Panic at boot on 4/330 with cgfour and cgsix

Izumi Tsutsui writes:
> > #define PFOUR_COLOR_OFF_CMAP 0xfff00000 /* (-0x00100000) */
> > 
> > Since the cgfour works on sun3 I went and looked at what it does and
> > it has an equivalent file sys/arch/sun3/dev/p4reg.h that says the same
> > thing. However I noticed the sun3 cgfour driver doesn't use that file
> > instead it's using sys/arch/sun3/dev/cg4reg.h which says something
> > different.
> > 
> > /*
> >  * Memory layout of the Type B hardware (OBMEM)
> >  * P4 appears on the Sun3/60 at 0xFF300000, so
> >  * define things relative to that.
> >  */
> > #define CG4B_OFF_CMAP  (-0x100000)
> > 
> > So I changed PFOUR_COLOR_OFF_CMAP to (-0x00100000) and I was able to
> > boot successfully. I don't know if this is the right way to fix it but
> > at least now I can boot the system and test things some more. Thanks
> > everyone for the help so far, I'll be trying to run X and other things
> > soon and hopefully have some good news.
>
> Somehow bus_addr_t (in sys/arch/sparc/include/bus_defs.h) is uint64_t
> so passing "oba->oba_paddr + PFOUR_COLOR_OFF_CMAP"
> (i.e. "oba->oba_paddr + 0xfff00000") to bus_space_map(9)
> causes unintended (no wraparound) address.

the sun4m MMU supports upto 24 bits of page number, which means
upto 36 bits of physical address with 4K pages.

from sparc/include/pte.h:

#if defined(SUN4M) || defined(SUN4D)
struct srmmu_pte {
        u_int   pg_pfnum:24,

probably best to fix this by either explicitly casting 
PFOUR_COLOR_OFF_CMAP as ((paddr_t)0xfff00000) or simply making
it unsigned as 0xfff00000u.

thanks.


.mrg.