Date: Thu, 22 Jun 2000 23:12:21 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Problems installing FreeBSD 4.0-RELEASE on an Alpha system Message-ID: <Pine.LNX.4.10.10006222211320.207-100000@linux.local> In-Reply-To: <14674.26845.214876.230507@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 22 Jun 2000, Andrew Gallatin wrote:
> G=E9rard Roudier writes:
> > 3) The BUS physical addresses (as seen from PCI BUS), the SCRIPTS
> > processor is provided with, are wrong.
> >=20
> > Given that the driver succeeded initialisations and seems to successfu=
lly=20
> > read chip IO registers using MMIO, the actual reason of the breakage i=
s=20
> > probably not (1) and (2) does not seem to me a good culprit :).
> >=20
> > Regarding possible reason (3), the SCRIPTS processor fetches instructi=
ons
> > from on-chip RAM using internal path (not using PCI external cycles).
> > For this to work, the BAR that is supposed to contain the address of=
=20
> > the on-chip RAM must match the BUS physical address of the on-chip RAM=
=20
> > as seen from the BUS.
> >=20
> > If for some reason BUS physical addresses ad seen from CPU differs fro=
m
> > BUS physical address as seen from the PCI BUS, and the BAR contains th=
e
> > former address value, then the current driver code will not work. A
> > work-around could consist in using main memory for SCRIPTS instead of
> > on-chip RAM.
>=20
> #3 is most likely the culprit. Right now we steal the upper bit(s) of
> the port or address passed down to the chipset's inX/outX readX/writeX
> functions to allow drivers to use inX/outX and readX/writeX. This is
> done so as to give hints to the lowlevel chipset code as to which hose
> the address in question is on. This hackery will go away when the
> previously mentioned changes to the alpha pci code happen. (Those
> changes are why Doug wanted to get all important drivers using
> busspace).
>=20
> Thanks for explaining it! I've long suspected that something like
> this was going on but never had the time to really understand either
> ncr driver well enough to figure it out for myself.
Thnaks for the explanation.
But it takes me a long time for locating the hack since I naturally=20
looked into the alpha code.:(
Btw, may-be the following counter-hack :) has some chance to work for
hose 1: (Virtually diffed by hand and fully untestable by me)
=09/*
=09 * Calculate BUS addresses where we are going=20
=09 * to load the SCRIPTS.
=09 */
=09np->script_ba=09=3D vtobus(np->script0);
=09np->scripth_ba=09=3D vtobus(np->scripth0);
=09np->scripth0_ba=09=3D np->scripth_ba;
=09if (np->ram_ba) {
=09=09np->script_ba=09=3D np->ram_ba;
+=09=09np->script_ba=09&=3D 0x7fffffff;
=09=09if (np->features & FE_RAM8K) {
=09=09=09np->ram_ws =3D 8192;
=09=09=09np->scripth_ba =3D np->script_ba + 4096;
-------
For latest driver the line to add should look like
+=09=09np->scripta_ba=09&=3D 0x7fffffff;
Gerard.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10006222211320.207-100000>