--yudcn1FV7Hsu/q59
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 10, 2003 at 04:39:50PM -0500, Rick Wash wrote:
> I've updated the patch slightly based on some comments I have received.
> The new patch is available at:
>=20
>   http://www.citi.umich.edu/u/rwash/projects/trusted/tcpa-1210.patch
>=20
> I'd appreciate any comments you have.  This patch is fairly similar to the
> previous one.
>=20
> There are a couple of questions I have regarding pci/bus_space functions,=
 as
> I haven't been able to get the working yet.
>=20
> In particular, the TCPA chip is attached to the LPC (low-pin-count) bus on
> the motherboard, and doesn't have its own PCI ID.  The driver looks for
> appropriate LPC bridge devices, and then checks that device to see if the
> TCPA chip is attached to it.

Actually, given that, what you need to implement is an LPC bus. The LPC=20
bus will attach wherever the bus interface attaches (if the bus=20
interface is a PCI device, you attach there, etc.). You then have the TCPA=
=20
driver attach to the LPC bus.

> As such, I'm not sure if the pci_attach_args structure or the pci_conf
> BAR's contain the information that is needed to use bus_space_ routines.
> I'd like to use these routines as they are vastly better than inb/outb, b=
ut
> I can't figure out how to map (with pci_mapreg_map(PCI_MAPREG_TYPE_IO...)=
 or
> bus_space_map(...).  I do know that this device is ONLY accessable via
> polling and i/o ports.
>=20
> Any suggestions how I can accomplish this?  What information do I need to
> find in order to use these?

I'd suggest looking at the driver writing guide documentation, which I=20
think is on the NetBSD web page. I have an earlier draft around if you=20
can't find it.

You definitely need to change the driver around. There can be other things=
=20
behind the LPC bridge. So just because you don't find a tcpa doesn't mean=
=20
you should shut down the LPC.

I also think you need serious help with the driver to get it to configure=
=20
right. Not because you aren't good enough, but because it looks like it=20
will tweak our config methodology.

As best I can tell from the LPC bus docs,=20
http://www.intel.com/design/chipsets/industry/25128901.pdf, they expect=20
the devices on the bus to be configured via something like ACPI. The rub=20
is that the PCI-LPC bridge chip doesn't (as best I can tell) do=20
subtractive decode; it has to be told what address ranges it should pass=20
through to the LPC bus.

So while the tcpa chip should look like an isa device with an ACPI attach=
=20
descriptor, the LPC bridge will have to have been initialized before tcpa=
=20
checks, as otherwise the probe will fail.

Also, I don't know if the ACPI config for the LPC bus indicates what=20
ranges it should map, or if the ACPI config for the tcpa has anything that=
=20
indicages it is behind the LPC bus. ??

> Also, I have written man pages for the libtcpa, which are available on my
> project's site at:
>=20
>   http://www.citi.umich.edu/u/rwash/projects/trusted/

Take care,

Bill

--yudcn1FV7Hsu/q59
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/18tbWz+3JHUci9cRAu/VAJ99wb+1EYfPUDNh59kMk88/+ySHZgCeL3jR
mvEfVyEuov7yHGDeDhJg3N8=
=mtbd
-----END PGP SIGNATURE-----

--yudcn1FV7Hsu/q59--