Date: Tue, 5 Sep 2000 22:12:49 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Peter Wemm <peter@netplex.com.au> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, obrien@FreeBSD.ORG, alpha@FreeBSD.ORG Subject: Re: what was the last patch you sent out? Message-ID: <Pine.BSF.4.21.0009052207370.50261-100000@beppo.feral.com> In-Reply-To: <200009060344.e863i9G48367@netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> What I'd like to know is what is different about the CIA setup in the PC164
> (vs PC164SX)..
>
> Also, consider this difference:
>
> PC164:
> cia0: ALCOR/ALCOR2, pass 3
> cia0: extended capabilities: 21<DWEN,BWEN>
> PC164SX:
> cia0: Pyxis, pass 1
> cia0: extended capabilities: 1<BWEN>
>
> And consider:
> if (cia_rev >= 2 || cia_ispyxis)
> cia_config = REGVAL(CIA_CSR_CNFG);
> else
> cia_config = 0;
> ..
> if (alpha_implver() != ALPHA_IMPLVER_EV5
> || alpha_amask(ALPHA_AMASK_BWX)
> || !(cia_config & CNFG_BWEN)) {
> ..
> chipset = cia_swiz_chipset;
> } else {
> ..
> chipset = cia_bwx_chipset;
> }
>
> IE: we are setting cia_bwx_chipset for all capable chipsets, including
> both the ALCOR and Pyxis ones that I've seen console cut/pastes from.
>
> While later:
> if (cia_ispyxis) {
> snprintf(chipset_type, sizeof(chipset_type), "pyxis");
> chipset_bwx = 1;
> chipset_ports = CIA_EV56_BWIO;
> chipset_memory = CIA_EV56_BWMEM;
> chipset_dense = CIA_PCI_DENSE;
> } else {
> snprintf(chipset_type, sizeof(chipset_type), "cia");
> chipset_bwx = 0;
> chipset_ports = CIA_PCI_SIO1;
> chipset_memory = CIA_PCI_SMEM1;
> chipset_dense = CIA_PCI_DENSE;
> chipset_hae_mask = 7L << 29;
> }
>
> It seems to me that at one point, we are setting the Pyxis/ALCOR to use
> BWX and later on we are setting BWX modes on Pyxis-only (missing out the
> PC164's ALCOR chips), but we are leaving the chipset[] vector pointer
> setup for BWX.
>
> Could this possibly explain it? (ie: machine half setup for SWIZ and half
> for BWX) I really do not understand the finer details of this area of the
> Alphas.
I noticed the code. It *is* bogus. But it isn't what's killing me.
I traced thing far enough to see things wedge just after it first identifies
the first card in the PCI bus. I can't quite tell yet whether I'm dying right
after reading the vendor id or whether the DELAY's I put in to let things
drain enough so that printf's could get out weren't enough or what- part of
the problem here is the !$)*@$~)(*~_)@~!)@$ stupid way FreeBSD/NetBSD do their
console setup on Alpha (begging everyone's pardon- I've hated this stand on
your head out of order init stuff that gets done) so it's really hard to know
quite when you got stomped if you have a serial console.
I won't be back in the office until tomorrow night when I'll resume. Since
4100 worked for me (to a 1st approx), which is a hard case, let's assume that
the pure PC164 is 'something else' for the moment.
-matt
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.BSF.4.21.0009052207370.50261-100000>