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>