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>
index | next in thread | previous in thread | raw e-mail
On Thu, 22 Jun 2000, Andrew Gallatin wrote:
> Gérard Roudier writes:
> > 3) The BUS physical addresses (as seen from PCI BUS), the SCRIPTS
> > processor is provided with, are wrong.
> >
> > Given that the driver succeeded initialisations and seems to successfully
> > read chip IO registers using MMIO, the actual reason of the breakage is
> > probably not (1) and (2) does not seem to me a good culprit :).
> >
> > Regarding possible reason (3), the SCRIPTS processor fetches instructions
> > 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
> > the on-chip RAM must match the BUS physical address of the on-chip RAM
> > as seen from the BUS.
> >
> > If for some reason BUS physical addresses ad seen from CPU differs from
> > 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 of
> > 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.
Thnaks for the explanation.
But it takes me a long time for locating the hack since I naturally
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)
/*
* Calculate BUS addresses where we are going
* to load the SCRIPTS.
*/
np->script_ba = vtobus(np->script0);
np->scripth_ba = vtobus(np->scripth0);
np->scripth0_ba = np->scripth_ba;
if (np->ram_ba) {
np->script_ba = np->ram_ba;
+ np->script_ba &= 0x7fffffff;
if (np->features & FE_RAM8K) {
np->ram_ws = 8192;
np->scripth_ba = np->script_ba + 4096;
-------
For latest driver the line to add should look like
+ np->scripta_ba &= 0x7fffffff;
Gerard.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10006222211320.207-100000>