Date: Thu, 22 Jun 2000 21:01:29 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Rasmus Skaarup <rasmus@gal.dk>, freebsd-alpha@FreeBSD.ORG Subject: Re: Problems installing FreeBSD 4.0-RELEASE on an Alpha system Message-ID: <Pine.LNX.4.10.10006222031520.1257-100000@linux.local> In-Reply-To: <14674.13167.247088.580096@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 22 Jun 2000, Andrew Gallatin wrote:
> Rasmus Skaarup writes:
>=20
> >=20
> > PCI Hose 01
> > Bus 00 Slot 07: NCR 53C895
> > pka0.7.0.7.1 SCSI Bus ID 7
> > dka0.0.0.7.1 RZ2DD-LS
> > dka100.1.0.7.1 RZ2DD-LS
> > Bus 00 Slot 08: DEGPA-SA
> >=20
>=20
>=20
> There is a bug (probably in FreeBSD, not the sym driver) regarding
> placement of ncr scsi adapters on hoses other than 0. Until it is
> fixed, the workaround is to move the NCR 53C895 to a PCI slot which is
> attached to hose 0.
According to the output messages the SCRIPTS processor jumped at
initialisation to a location that was filled with DWORD 0. This
instruction (MOVE 0 byte) is never used by the driver and according to=20
the manual triggers an ILLEGAL INSTRUCTION condition.
Reason could be:
1) The BUS physical address (as seen from CPU) used by the driver to
download SCRIPTS to on-chip RAM was wrong.
OR
2) memcpy_toio() failed copying SCRIPTS to the on-chip SRAM.
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=
=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 :).
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=20
the on-chip RAM must match the BUS physical address of the on-chip RAM=20
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.
G=E9rard.
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.10006222031520.1257-100000>