From owner-freebsd-alpha Thu Jun 22 12:54:47 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 4997D37BB40 for ; Thu, 22 Jun 2000 12:54:42 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA15202; Thu, 22 Jun 2000 15:54:41 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id PAA02632; Thu, 22 Jun 2000 15:54:41 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2000 15:54:40 -0400 (EDT) To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Problems installing FreeBSD 4.0-RELEASE on an Alpha system In-Reply-To: References: <14674.13167.247088.580096@grasshopper.cs.duke.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14674.26845.214876.230507@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 success= fully=20 > read chip IO registers using MMIO, the actual reason of the breakage= is=20 > probably not (1) and (2) does not seem to me a good culprit :). >=20 > Regarding possible reason (3), the SCRIPTS processor fetches instruc= tions > 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 R= AM=20 > as seen from the BUS. >=20 > If for some reason BUS physical addresses ad seen from CPU differs f= rom > BUS physical address as seen from the PCI BUS, and the BAR contains = the > former address value, then the current driver code will not work. A > work-around could consist in using main memory for SCRIPTS instead o= f > on-chip RAM. #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). 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. Cheers, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message