Subject: Re: kernel please ???
To: Peter Galbavy <peter@wonderland.org>
From: Chris G Demetriou <Chris_G_Demetriou@UX2.SP.CS.CMU.EDU>
List: port-alpha
Date: 05/24/1996 00:40:13
> I am not having any luck with my Multia, and I am now sure I have the
> latest firmware released. (It say 4.33 on the arc console).
> [ ... ]
> The box panics after com1 but before com2, with a panic, reported
> a week or more ago to the list. [ ... ]

So, I went mailng list archive diving, since i'm sure people have
reported problems with AXPpci-family (which includes the Multia... 8-)
machines in the past...

Anyway, I found the following interesting tidbits:

	(1) First of all, I don't believe that you have the latest
	    firmware.  If a salesweasel told you that, you might want
	    to take it with a grain of salt.  I say this because
	    John Birrell <jb@cimlogic.com.au> reported a while
	    ago that he has AXPpci firmware with versions:

		SROM Console Firmware V4.3-3114 for AXPpci33
		ARC  Console Firmware V4.36 for AXPpci33

	    which he obtained from Digital.  I just checked around on
	    gatekeeper.dec.com (a.k.a. ftp.digital.com), and in
	    pub/DEC/Alpha/firmware/v3.5/doc/decxappci33_v14_fw_relnote.txt
	    are instructions which detail the process of updating to
	    firmware which with versions:

		SRM Firmware: X4.3-3114
		ARC Firmware: 4.42
	    
	    The firmware images themselves are also in that tree,
	    but we all know that we should print and read the docs
	    before doing firmware upgrades...  8-)


	(2) On March 3, Thomas J. Merrit <tjm@cgt.com> reported:

		> The Multia SRM console improperly initializes the
		> Saturn I/O chip on the Multia and netbsd panics when
		> it discovers this and places you back in the SRM
		> console. 

	    but you already know that.  8-)  However, he also said:

		> DEC is supposed to have a firmware upgrade for the
		> Multias sometime soon that will allow them to run
		> OSF/1.  When that happens the odds of netbsd booting
		> should be higher.

	    That may be the AXPpci firmware mentioned above.

	(3) In a batch of diffs he sent just over a month ago (some
	    of which I integrated into the master sources, some
	    of which I didn't), Trevor Mendez <tmendez@bbn.com>
	    sent me some changes to reset the PICs on AXPpci systems.
	    I've included them below, because I didn't accept them
	    for inclusion.  (I didn't include the changes to the same
	    file that I did apply.)

	    In case anybody wonders why I didn't include them:
		(a) they work around a firmware bug; that bug should
		    go away in future firmware revisions (and perhaps
		    already has),
		(b) the code was not actually called in the diffs that
		    Trevor sent, so they couldn't have been _too_
		    important, and
		(c) the operating system shouldn't be mucking with
		    interrupt routing, in any case.

	    Since the diffs he sent didn't actually _call_ the code,
	    I can only assume that the need for the code was
	    eliminated by a later firmware revision.  Perhaps
	    he can confirm that...  Trevor?


Anyway, i'd suggest:

	(1) Making Really Really Really Sure that you're using the
	    latest firmware revision, and then, if you still have
	    problems,
	(2) trying the functions below, calling one or both of
	    them early on in lcaattach().  (I'm not sure that that's
	    where they should go, and i'm not sure what second
	    argument the latter should receive, but it shouldn't be
	    too hard to come up with something.)
	


later,

chris
=========================================
Index: sys/arch/alpha/pci/pci_axppci_33.c
===================================================================
RCS file: /MULTIGIG-CVS/netbsd/sys/arch/alpha/pci/pci_axppci_33.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 pci_axppci_33.c
--- pci_axppci_33.c	1996/04/16 20:18:10	1.1.1.2
+++ pci_axppci_33.c	1996/04/18 20:49:07
@@ -89,6 +90,88 @@
 #endif
 }
 
+/*
+ * d e c _ a x p p c i _ s i o _ i n t r _ r e s e t
+ *
+ * Reset the AXPpci33's interrupt controllers on the SIO chip.
+ * Refer to Intel documentation for the SIO chip and the 82C59 -- the
+ * "Peripheral Components" manual.
+ */
+void
+dec_axppci_sio_intr_reset(lcp)
+	struct lca_config *lcp;
+{
+	bus_chipset_tag_t bc = &lcp->lc_bc;
+	bus_io_handle_t ioh_icu1, ioh_icu2;
+
+	if (bus_io_map(bc, SIO_REG_ICU1, SIO_ICUSIZE, &ioh_icu1) ||
+	    bus_io_map(bc, SIO_REG_ICU2, SIO_ICUSIZE, &ioh_icu2))
+		panic("dec_axppci_sio_intr_reset: can't map I/O ports");
+
+#define	outb(reg, off, val) \
+    bus_io_write_1((bc), (reg), (off), (val))
+#define	inb(reg, off) \
+    bus_io_read_1((bc), (reg), (off))
+
+	/*
+	 * Attempt to reset the two Intel 82C59 interrupt controllers.
+	 */
+#define	IVBASE	0x01
+	outb(ioh_icu1, 0, 0x11);	/* ICW1: reset; program device */
+	outb(ioh_icu1, 1, IVBASE);	/* ICW2: set vector base address */
+	outb(ioh_icu1, 1, 0x04);	/* ICW3: slave on line 2 */
+	outb(ioh_icu1, 1, 0x01);	/* ICW4: 8086 mode */
+
+	outb(ioh_icu2, 0, 0x11);	/* reset; program device */
+	outb(ioh_icu2, 1, IVBASE+8);	/* set vector base address */
+	outb(ioh_icu2, 1, 0x02);	/* my slave id is 2 */
+	outb(ioh_icu2, 1, 0x01);	/* 8086 mode */
+
+#if	not_needed
+	outb(ioh_icu2, 0, 0xc0|0x07);	/* OCW2: set pri order 8-15 */
+#endif
+	outb(ioh_icu1, 0, 0xc0|0x07);	/* OCW2: set pri order 0-1, 8-15, 3-7 */
+
+	DELAY(10);
+}
+
+/*
+ * d e c _ a x p p c i _ 3 3 _ p c i _ i n t r _ r e s e t
+ *
+ * Re-configure the PCI interrupt routing.  The interrupt controller(s)
+ * must also be reset.
+ */
+void
+dec_axppci_33_pci_intr_reset(lcp, pirq)
+	struct lca_config *lcp;
+	pcireg_t pirq;
+{
+	pci_chipset_tag_t pc = &lcp->lc_pc;
+	pcireg_t cr;
+
+	/* Configure interrupt routing for PIRQ0, PIRQ1, PIRQ2, and PIRQ3.
+	 * Note that corresponding bits in the ISA Edge/Level Control registers
+	 * will also have to be set.  But this takes place automatically when
+	 * the interrupt vector is actually installed -- when
+	 * sio_intr_establish() calls sio_setirqstat().
+	 */ 
+	pci_conf_write(pc, pci_make_tag(pc, 0, LCA_SIO_DEVICE, 0),
+		SIO_PCIREG_PIRQ_RTCTRL, pirq);
+
+	dec_axppci_sio_intr_reset(lcp);
+
+#ifdef	REPROGRAM_ARBITER
+	/* Configure the PCI arbiter's priority order, placing all banks in
+	 * rotating priority mode.
+	 */
+	cr = pci_conf_read(pc, pci_make_tag(pc, 0, LCA_SIO_DEVICE, 0),
+		SIO_PCIREG_PCICON);
+	cr &= 0xff00ffff;
+	pci_conf_write(pc, pci_make_tag(pc, 0, LCA_SIO_DEVICE, 0),
+		SIO_PCIREG_PCICON, cr | 0x00f00000);
+#endif
+}
+
 int
 dec_axppci_33_intr_map(lcv, bustag, buspin, line, ihp)
 	void *lcv;