From owner-freebsd-alpha Thu Jun 22 14:34:45 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by hub.freebsd.org (Postfix) with ESMTP id E5E2737B52F for ; Thu, 22 Jun 2000 14:34:36 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from Cergy-2-127.club-internet.fr (Cergy-2-127.club-internet.fr [195.36.197.127]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA29897; Thu, 22 Jun 2000 23:34:27 +0200 (MET DST) Date: Thu, 22 Jun 2000 23:12:21 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Andrew Gallatin Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Problems installing FreeBSD 4.0-RELEASE on an Alpha system In-Reply-To: <14674.26845.214876.230507@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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