Subject: bus_space_* with CATS super I/O stuff
To: None <port-arm32@netbsd.org>
From: David Forbes <david@flossy.u-net.com>
List: port-arm32
Date: 07/04/1999 14:05:36
Summary:  Under what circumstances does a bus_space_read_1() return 0xff
	rather than the real value?

Details:

I've been having a bit of bother lately trying to get my CATS machine to
engage ECP mode on it's parallel port.  The problem, it appears, is that
any reading the ECR, CNFGA and CNFGB returns 0xff (and it is therefore
difficult to determine whether writing to the ECR has any effect).  For
those who don't have docs to hand, CNFGA should alway return 0x10 and
CNFGB should never have it's top bit set.

I can read and write the standard parallel port registers without any
trouble at all.  The difference, apparently, is that CNFGA, CNFGB and ECR
are at offsets 0x400, 0x401 and 0x402 whilst the basic registers are at
0x00, 0x01 and 0x02. 

The code that give this is:

	ppc->ppc_sc = malloc(sizeof(struct ppc_softc),M_DEVBUF,M_NOWAIT);
	ppc->ppc_sc->iot = ia->ia_iot;
	if (bus_space_map(ppc->ppc_sc->iot, ia->ia_iobase, 0x404, 0,
		&ppc->ppc_sc->ioh)) {
	  printf("%s: can't map i/o space\n", "GODDAMNED ppc£$%^$%%");
	  return (0);
	}
	

	printf("\t%x\n",r_cnfgA(ppc));
	printf("\t%x\n",r_cnfgB(ppc));
	printf("\t%x\n",r_ecr(ppc));
	printf("\t%x\n",r_dtr(ppc));
	printf("\t%x\n",r_ctr(ppc));
	printf("\t%x\n",r_str(ppc));

	printf("Writing ECR gives \n");
	w_ecr(ppc,0xd4);
	
	printf("\t%x\n",r_cnfgA(ppc));
	printf("\t%x\n",r_cnfgB(ppc));
	printf("\t%x\n",r_ecr(ppc));
	printf("\t%x\n",r_dtr(ppc));
	printf("\t%x\n",r_ctr(ppc));
	printf("\t%x\n",r_str(ppc));

r_ecr() and w_ecr() are macros:

#define r_ecr(ppc) (bus_space_read_1(ppc->ppc_sc->iot,ppc->ppc_sc->ioh,\
                                     PPC_ECP_ECR))

#define w_ecr(ppc,byte) (bus_space_write_1(ppc->ppc_sc->iot,ppc->ppc_sc->ioh,\
                                           PPC_ECP_ECR, byte))

and similarly the other r_*().  I have checked and double checked that the
PPC_ECP_ECR value (and others) are correct.

This is all done in a device probe routine.  Note that the softc structure
is only malloc()'d temporarily and is released just after the
corresponding bus_space_unmap() call.  During boot, we get:

        ff
        ff
        ff
        8
        0
        78
Writing ECR gives 
        ff
        ff
        ff
        8
        0
        78

Basically, the core question is why is the read returning 0xff?
(Esp. when the other registers work... I hope I haven't fried my
southbridge chip ;-)

Thanks,

David.