very minor 405GP and 405GPr PCI difference

very minor 405GP and 405GPr PCI difference

[Ralph Blach]

Yesterday I discovered a minor 405GP vs 405GPr PCI difference.
IN the 405GP the ptm1ms bit 31, the enable bit for the region is set to 1
by the hardware and cannot be written.
On the 405GPr the bit is writable and this makes necessitates  a change in
walnut.c

In walnut.c there is the line

out_le32((void *) &(pcip->ptm1ms), 0x00000000);

On the walnut, this would work fine because bit 31 cannot be written to a
0,
On the GPr, this disables the regions and PCI no longer functions.
The line should be changed to

out_le32((void*)&(pcip->ptm1ms),0x000000001);

This will fix the 405GPr and make no difference to the 405GP since the bit
is permanently to 1.

Chip


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Fri, Sep 27, 2002 at 08:27:35AM -0400, Ralph Blach wrote:
>
> Yesterday I discovered a minor 405GP vs 405GPr PCI difference.
> IN the 405GP the ptm1ms bit 31, the enable bit for the region is set to 1
> by the hardware and cannot be written.
> On the 405GPr the bit is writable and this makes necessitates  a change in
> walnut.c
>
> In walnut.c there is the line
>
> out_le32((void *) &(pcip->ptm1ms), 0x00000000);
>
> On the walnut, this would work fine because bit 31 cannot be written to a
> 0,
> On the GPr, this disables the regions and PCI no longer functions.
> The line should be changed to
>
> out_le32((void*)&(pcip->ptm1ms),0x000000001);
>
> This will fix the 405GPr and make no difference to the 405GP since the bit
> is permanently to 1.

I would put it more strongly than that:  this is a bug, which we just
happen to get away with because of the behaviour of the 405GP.

The arrangement of the code in walnut.c suggests some confusion
between the PLB->PCI and PCI->PLB windows, which is probably the
origin of the bug (the fact that the 405GP numbers the former from 0
and the latter from 1 probably didn't help).

The fix you've suggested should be correct for Walnut, and probably
the other places that that code has been copied.  I tend to think,
though, that this configuration of the 4xx PCI bridge should be moved
out of the board code and into ppc4xx_pci.c.  If we do that, though we
should fully configure the PTMs, to wit:
	out_le32((void *) &(pcip->ptm1ms), 0x00000000);
	out_le32((void *) &(pcip->ptm1la), 0x00000000);
	out_le32((void *) &(pcip->ptm1ms), 0x80000001);
	out_le32((void *) &(pcip->ptm2ms), 0x00000000);

Which should configure the PCI bridge to match the comments in
walnut.c (i.e. map PCI addresses 0x00000000-0x7fffffff to
corresponding PLB addresses).

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Mon, Sep 30, 2002 at 02:01:43PM +1000, David Gibson wrote:
>
> On Fri, Sep 27, 2002 at 08:27:35AM -0400, Ralph Blach wrote:
> >
> > Yesterday I discovered a minor 405GP vs 405GPr PCI difference.
> > IN the 405GP the ptm1ms bit 31, the enable bit for the region is set to 1
> > by the hardware and cannot be written.
> > On the 405GPr the bit is writable and this makes necessitates  a change in
> > walnut.c
> >
> > In walnut.c there is the line
> >
> > out_le32((void *) &(pcip->ptm1ms), 0x00000000);
> >
> > On the walnut, this would work fine because bit 31 cannot be written to a
> > 0,
> > On the GPr, this disables the regions and PCI no longer functions.
> > The line should be changed to
> >
> > out_le32((void*)&(pcip->ptm1ms),0x000000001);
> >
> > This will fix the 405GPr and make no difference to the 405GP since the bit
> > is permanently to 1.
>
> I would put it more strongly than that:  this is a bug, which we just
> happen to get away with because of the behaviour of the 405GP.
>
> The arrangement of the code in walnut.c suggests some confusion
> between the PLB->PCI and PCI->PLB windows, which is probably the
> origin of the bug (the fact that the 405GP numbers the former from 0
> and the latter from 1 probably didn't help).
>
> The fix you've suggested should be correct for Walnut, and probably
> the other places that that code has been copied.  I tend to think,
> though, that this configuration of the 4xx PCI bridge should be moved
> out of the board code and into ppc4xx_pci.c.  If we do that, though we
> should fully configure the PTMs, to wit:
> 	out_le32((void *) &(pcip->ptm1ms), 0x00000000);
> 	out_le32((void *) &(pcip->ptm1la), 0x00000000);
> 	out_le32((void *) &(pcip->ptm1ms), 0x80000001);
> 	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
>
> Which should configure the PCI bridge to match the comments in
> walnut.c (i.e. map PCI addresses 0x00000000-0x7fffffff to
> corresponding PLB addresses).

So, here is a patch to do that.  If there are no objections, I will
commit this to linuxppc-2.5 BK.

diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/kernel/4xx/ppc405_pci.c linux-bluefish/arch/ppc/kernel/4xx/ppc405_pci.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/kernel/4xx/ppc405_pci.c	2002-09-19 16:08:05.000000000 +1000
+++ linux-bluefish/arch/ppc/kernel/4xx/ppc405_pci.c	2002-10-01 15:14:57.000000000 +1000
@@ -53,7 +53,6 @@
 #include <asm/ibm_ocp_pci.h>


-extern void bios_fixup(struct pci_controller *, struct pcil0_regs *);
 extern int ppc405_map_irq(struct pci_dev *dev, unsigned char idsel,
 			  unsigned char pin);

@@ -112,6 +111,110 @@
 	return (bus == 0 && devfn == 0);
 }

+static void __init
+bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
+{
+#ifdef CONFIG_BIOS_FIXUP
+	unsigned int bar_response, bar;
+	/*
+	 * Expected PCI mapping:
+	 *
+	 *  PLB addr             PCI memory addr
+	 *  ---------------------       ---------------------
+	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
+	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
+	 *
+	 *  PLB addr             PCI io addr
+	 *  ---------------------       ---------------------
+	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
+	 *
+	 * The following code is simplified by assuming that the bootrom
+	 * has been well behaved in following this mapping.
+	 */
+
+#ifdef DEBUG
+	int i;
+
+	printk(KERN_DEBUG "ioremap PCLIO_BASE = 0x%p\n", pcip);
+	printk(KERN_DEBUG "PCI bridge regs before fixup \n");
+	for (i = 0; i <= 3; i++) {
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
+	}
+	printk(KERN_DEBUG " ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
+	printk(KERN_DEBUG " ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
+	printk(KERN_DEBUG " ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
+	printk(KERN_DEBUG " ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
+#endif
+
+	/* First set up the PLB->PCI window, we only use PMM0 */
+
+	/* Disable region first */
+	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
+	/* PLB starting addr, PCI: 0x80000000 */
+	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
+	/* PCI start addr, 0x80000000 */
+	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
+	/* 512MB range of PLB to PCI */
+	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
+	/* Enable no pre-fetch, enable region */
+	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
+						(PPC405_PCI_UPPER_MEM -
+						 PPC405_PCI_MEM_BASE)) | 0x01));
+
+	/* Disable region one */
+	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
+	out_le32((void *) &(pcip->pmm[1].la), 0x00000000);
+	out_le32((void *) &(pcip->pmm[1].pcila), 0x00000000);
+	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
+	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
+
+	/* Disable region two */
+	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
+	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
+	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
+	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
+	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
+
+	/* Now configure the PCI->PLB windows, we only use PTM1 */
+	out_le32((void *) &(pcip->ptm1ms), 0x00000000); /* first disable */
+	out_le32((void *) &(pcip->ptm1la), 0x00000000); /* base address */
+	out_le32((void *) &(pcip->ptm1ms), 0x80000001); /* re-enable */
+	out_le32((void *) &(pcip->ptm2ms), 0x00000000); /* disable PTM2 */
+
+	/* Zero config bars */
+	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
+		early_write_config_dword(hose, hose->first_busno,
+					 PCI_FUNC(hose->first_busno), bar,
+					 0x00000000);
+		early_read_config_dword(hose, hose->first_busno,
+					PCI_FUNC(hose->first_busno), bar,
+					&bar_response);
+		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
+		    hose->first_busno, PCI_SLOT(hose->first_busno),
+		    PCI_FUNC(hose->first_busno), bar, bar_response);
+	}
+	/* end work arround */
+
+#ifdef DEBUG
+	printk(KERN_DEBUG "PCI bridge regs after fixup \n");
+	for (i = 0; i <= 3; i++) {
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
+	}
+	printk(KERN_DEBUG " ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
+	printk(KERN_DEBUG " ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
+	printk(KERN_DEBUG " ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
+	printk(KERN_DEBUG " ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
+
+#endif /* DEBUG */
+#endif /* CONFIG_BIOS_FIXUP */
+}
+
 void
 ppc4xx_find_bridges(void)
 {
@@ -143,10 +246,8 @@

 	pcip = ioremap((unsigned long) ocp_get_paddr(OCP_FUNC_PCI, 0), PAGE_SIZE);
 	if (pcip != NULL) {
-
-#if defined(CONFIG_BIOS_FIXUP)
 		bios_fixup(hose_a, pcip);
-#endif
+
 		new_pmm_min = 0xffffffff;
 		for (reg_index = 0; reg_index < 3; reg_index++) {
 			tmp_size = in_le32((void *) &(pcip->pmm[reg_index].ma));	// *_PMM0MA
diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/ash.c linux-bluefish/arch/ppc/platforms/4xx/ash.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/ash.c	2002-09-19 16:08:06.000000000 +1000
+++ linux-bluefish/arch/ppc/platforms/4xx/ash.c	2002-10-01 15:06:13.000000000 +1000
@@ -95,137 +95,6 @@
 }

 void __init
-bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
-{
-
-	unsigned int bar_response, bar;
-	/*
-	 * Expected PCI mapping:
-	 *
-	 *  PLB addr             PCI memory addr
-	 *  ---------------------       ---------------------
-	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
-	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
-	 *
-	 *  PLB addr             PCI io addr
-	 *  ---------------------       ---------------------
-	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
-	 *
-	 * The following code is simplified by assuming that the bootrom
-	 * has been well behaved in following this mapping.
-	 */
-
-#ifdef DEBUG
-	int i;
-
-	printk("ioremap PCLIO_BASE = 0x%x\n", pcip);
-	printk("PCI bridge regs before fixup \n");
-	for (i = 0; i <= 2; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dla\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dpcila\t0x%x\n", i,
-		       in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dpciha\t0x%x\n", i,
-		       in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
-		early_read_config_dword(hose, hose->first_busno,
-					PCI_FUNC(hose->first_busno), bar,
-					&bar_response);
-		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
-		    hose->first_busno, PCI_SLOT(hose->first_busno),
-		    PCI_FUNC(hose->first_busno), bar, bar_response);
-	}
-
-#endif
-	if (ppc_md.progress)
-		ppc_md.progress("bios_fixup(): enter", 0x800);
-
-	/* added for IBM boot rom version 1.15 bios bar changes  -AK */
-
-	/* Disable region first */
-	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
-	/* PLB starting addr, PCI: 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
-	/* PCI start addr, 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
-	/* 512MB range of PLB to PCI */
-	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
-	/* Enable no pre-fetch, enable region */
-	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
-						(PPC405_PCI_UPPER_MEM -
-						 PPC405_PCI_MEM_BASE)) | 0x01));
-
-	/* Disable region one */
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-
-	/* Disable region two */
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-
-	/* Enable PTM1 and PTM2, mapped to PLB address 0. */
-
-	out_le32((void *) &(pcip->ptm1la), 0x00000000);
-	out_le32((void *) &(pcip->ptm1ms), 0x00000001);
-	out_le32((void *) &(pcip->ptm2la), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000001);
-
-	/* Write zero to PTM1 BAR. */
-
-	early_write_config_dword(hose, hose->first_busno,
-				 PCI_FUNC(hose->first_busno),
-				 PCI_BASE_ADDRESS_1,
-				 0x00000000);
-
-	/* Disable PTM2 (unused) */
-
-	out_le32((void *) &(pcip->ptm2la), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* end work arround */
-	if (ppc_md.progress)
-		ppc_md.progress("bios_fixup(): done", 0x800);
-
-#ifdef DEBUG
-	printk("PCI bridge regs after fixup \n");
-	for (i = 0; i <= 2; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dla\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dpcila\t0x%x\n", i,
-		       in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dpciha\t0x%x\n", i,
-		       in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
-		early_read_config_dword(hose, hose->first_busno,
-					PCI_FUNC(hose->first_busno), bar,
-					&bar_response);
-		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
-		    hose->first_busno, PCI_SLOT(hose->first_busno),
-		    PCI_FUNC(hose->first_busno), bar, bar_response);
-	}
-
-
-#endif
-}
-
-void __init
 board_io_mapping(void)
 {
 	io_block_mapping(ASH_RTC_VADDR, ASH_RTC_PADDR, ASH_RTC_SIZE, _PAGE_IO);
diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/ep405.c linux-bluefish/arch/ppc/platforms/4xx/ep405.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/ep405.c	2002-09-19 16:08:06.000000000 +1000
+++ linux-bluefish/arch/ppc/platforms/4xx/ep405.c	2002-10-01 15:05:32.000000000 +1000
@@ -71,73 +71,6 @@
 }

 void __init
-bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
-{
-	unsigned int bar_response, bar;
-	/*
-	 * Expected PCI mapping:
-	 *
-	 *  PLB addr             PCI memory addr
-	 *  ---------------------       ---------------------
-	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
-	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
-	 *
-	 *  PLB addr             PCI io addr
-	 *  ---------------------       ---------------------
-	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
-	 *
-	 */
-
-	/* Disable region zero first */
-	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
-	/* PLB starting addr, PCI: 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
-	/* PCI start addr, 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
-	/* 512MB range of PLB to PCI */
-	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
-	/* Enable no pre-fetch, enable region */
-	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
-						(PPC405_PCI_UPPER_MEM -
-						 PPC405_PCI_MEM_BASE)) | 0x01));
-
-	/* Disable region one */
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm1ms), 0x00000000);
-
-	/* Disable region two */
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* Configure PTM (PCI->PLB) region 1 */
-	out_le32((void *) &(pcip->ptm1la), 0x00000000); /* PLB base address */
-	/* Disable PTM region 2 */
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* Zero config bars */
-	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
-		early_write_config_dword(hose, hose->first_busno,
-					 PCI_FUNC(hose->first_busno), bar,
-					 0x00000000);
-		early_read_config_dword(hose, hose->first_busno,
-					PCI_FUNC(hose->first_busno), bar,
-					&bar_response);
-		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
-		    hose->first_busno, PCI_SLOT(hose->first_busno),
-		    PCI_FUNC(hose->first_busno), bar, bar_response);
-	}
-	/* end work arround */
-}
-
-void __init
 board_io_mapping(void)
 {
 	bd_t *bip = (bd_t *) __res;
diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/rainier.c linux-bluefish/arch/ppc/platforms/4xx/rainier.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/rainier.c	2002-09-19 16:08:06.000000000 +1000
+++ linux-bluefish/arch/ppc/platforms/4xx/rainier.c	2002-10-01 15:05:42.000000000 +1000
@@ -109,90 +109,6 @@
 }

 void __init
-bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
-{
-	/*
-	 * Expected PCI mapping:
-	 *
-	 *  PLB addr             PCI memory addr
-	 *  ---------------------       ---------------------
-	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
-	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
-	 *
-	 *  PLB addr             PCI io addr
-	 *  ---------------------       ---------------------
-	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
-	 *
-	 * The following code is simplified by assuming that the bootrom
-	 * has been well behaved in following this mapping.
-	 */
-
-#ifdef DEBUG
-	int i;
-
-	printk("ioremap PCLIO_BASE = 0x%x\n", pcip);
-	printk("PCI bridge regs before fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-
-	/* Disable region first */
-	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
-	/* PLB starting addr, PCI: 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
-	/* PCI start addr, 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
-	/* 512MB range of PLB to PCI */
-	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
-	/* Enable no pre-fetch, enable region */
-	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
-						(PPC405_PCI_UPPER_MEM -
-						 PPC405_PCI_MEM_BASE)) | 0x01));
-
-	/*region one used bu rainier*/
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].la), 0x80000000);
-	out_le32((void *) &(pcip->pmm[1].pcila), 0x80000000);
-	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].ma), 0xFFFF8001);
-	out_le32((void *) &(pcip->ptm1ms), 0x00000000);
-
-	/* Disable region two */
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* end work arround */
-
-#ifdef DEBUG
-	printk("PCI bridge regs after fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-}
-
-void __init
 board_io_mapping(void)
 {
 	io_block_mapping(RAINIER_IO_PAGE_INTERPOSER_PADDR,
diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/sycamore.c linux-bluefish/arch/ppc/platforms/4xx/sycamore.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/sycamore.c	2002-09-19 16:08:06.000000000 +1000
+++ linux-bluefish/arch/ppc/platforms/4xx/sycamore.c	2002-10-01 15:05:55.000000000 +1000
@@ -168,108 +168,6 @@
 }

 void __init
-bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
-{
-#ifdef CONFIG_PCI
-	unsigned int bar_response, bar;
-	/*
-	 * Expected PCI mapping:
-	 *
-	 *  PLB addr             PCI memory addr
-	 *  ---------------------       ---------------------
-	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
-	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
-	 *
-	 *  PLB addr             PCI io addr
-	 *  ---------------------       ---------------------
-	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
-	 *
-	 * The following code is simplified by assuming that the bootrom
-	 * has been well behaved in following this mapping.
-	 */
-
-#ifdef DEBUG
-	int i;
-
-	printk("ioremap PCLIO_BASE = 0x%x\n", pcip);
-	printk("PCI bridge regs before fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-
-	/* added for IBM boot rom version 1.15 bios bar changes  -AK */
-
-	/* Disable region first */
-	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
-	/* PLB starting addr, PCI: 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
-	/* PCI start addr, 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
-	/* 512MB range of PLB to PCI */
-	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
-	/* Enable no pre-fetch, enable region */
-	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
-						(PPC405_PCI_UPPER_MEM -
-						 PPC405_PCI_MEM_BASE)) | 0x01));
-
-	/* Disable region one */
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm1ms), 0x00000000);
-
-	/* Disable region two */
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* Zero config bars */
-	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
-		early_write_config_dword(hose, hose->first_busno,
-					 PCI_FUNC(hose->first_busno), bar,
-					 0x00000000);
-		early_read_config_dword(hose, hose->first_busno,
-					PCI_FUNC(hose->first_busno), bar,
-					&bar_response);
-		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
-		    hose->first_busno, PCI_SLOT(hose->first_busno),
-		    PCI_FUNC(hose->first_busno), bar, bar_response);
-	}
-	/* end work arround */
-
-#ifdef DEBUG
-	printk("PCI bridge regs after fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-#endif
-
-}
-
-void __init
 board_io_mapping(void)
 {
 	io_block_mapping(SYCAMORE_RTC_VADDR,
diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/walnut.c linux-bluefish/arch/ppc/platforms/4xx/walnut.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/walnut.c	2002-09-19 16:08:06.000000000 +1000
+++ linux-bluefish/arch/ppc/platforms/4xx/walnut.c	2002-10-01 15:05:22.000000000 +1000
@@ -128,107 +128,6 @@
 }

 void __init
-bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
-{
-#ifdef (CONFIG_PCI)
-	unsigned int bar_response, bar;
-	/*
-	 * Expected PCI mapping:
-	 *
-	 *  PLB addr             PCI memory addr
-	 *  ---------------------       ---------------------
-	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
-	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
-	 *
-	 *  PLB addr             PCI io addr
-	 *  ---------------------       ---------------------
-	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
-	 *
-	 * The following code is simplified by assuming that the bootrom
-	 * has been well behaved in following this mapping.
-	 */
-
-#ifdef DEBUG
-	int i;
-
-	printk("ioremap PCLIO_BASE = 0x%x\n", pcip);
-	printk("PCI bridge regs before fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-
-	/* added for IBM boot rom version 1.15 bios bar changes  -AK */
-
-	/* Disable region first */
-	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
-	/* PLB starting addr, PCI: 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
-	/* PCI start addr, 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
-	/* 512MB range of PLB to PCI */
-	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
-	/* Enable no pre-fetch, enable region */
-	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
-						(PPC405_PCI_UPPER_MEM -
-						 PPC405_PCI_MEM_BASE)) | 0x01));
-
-	/* Disable region one */
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm1ms), 0x00000000);
-
-	/* Disable region two */
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* Zero config bars */
-	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
-		early_write_config_dword(hose, hose->first_busno,
-					 PCI_FUNC(hose->first_busno), bar,
-					 0x00000000);
-		early_read_config_dword(hose, hose->first_busno,
-					PCI_FUNC(hose->first_busno), bar,
-					&bar_response);
-		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
-		    hose->first_busno, PCI_SLOT(hose->first_busno),
-		    PCI_FUNC(hose->first_busno), bar, bar_response);
-	}
-	/* end work arround */
-
-#ifdef DEBUG
-	printk("PCI bridge regs after fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-#endif
-}
-
-void __init
 board_io_mapping(void)
 {
 	io_block_mapping(WALNUT_RTC_VADDR,


--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

["David Müller (ELSOFT AG)"]

Hello

David Gibson wrote:
> On Mon, Sep 30, 2002 at 02:01:43PM +1000, David Gibson wrote:
>
>>On Fri, Sep 27, 2002 at 08:27:35AM -0400, Ralph Blach wrote:
>>
>>>Yesterday I discovered a minor 405GP vs 405GPr PCI difference.
>>>IN the 405GP the ptm1ms bit 31, the enable bit for the region is set to 1
>>>by the hardware and cannot be written.
>>>On the 405GPr the bit is writable and this makes necessitates  a change in
>>>walnut.c
>>>

[stuff deleted]

>
> So, here is a patch to do that.  If there are no objections, I will
> commit this to linuxppc-2.5 BK.
>


In your proposed patch, i'm missing a way to install a board specify
mapping either by using special constants, callback functions to board
specific code, .... AFAICS all boards are forced to use the same mapping.

Dave


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Tue, Oct 01, 2002 at 10:37:20AM +0200, "David M?ller (ELSOFT AG)" wrote:
>
> Hello
>
> David Gibson wrote:
> >On Mon, Sep 30, 2002 at 02:01:43PM +1000, David Gibson wrote:
> >
> >>On Fri, Sep 27, 2002 at 08:27:35AM -0400, Ralph Blach wrote:
> >>
> >>>Yesterday I discovered a minor 405GP vs 405GPr PCI difference.
> >>>IN the 405GP the ptm1ms bit 31, the enable bit for the region is set to 1
> >>>by the hardware and cannot be written.
> >>>On the 405GPr the bit is writable and this makes necessitates  a change
> >>>in
> >>>walnut.c
> >>>
>
> [stuff deleted]
>
> >So, here is a patch to do that.  If there are no objections, I will
> >commit this to linuxppc-2.5 BK.
>
>
> In your proposed patch, i'm missing a way to install a board specify
> mapping either by using special constants, callback functions to board
> specific code, .... AFAICS all boards are forced to use the same mapping.

That's right.  Is there a reason for boards to have different
mappings?  I can well believe that there is, but the current tree
doesn't show it - all the boards (in the tree) that have PCI appear to
do the same initialisation of the windows.  It doesn't seem worthwhile
to create board specific PCI initialisation hooks until we have a
board that needs it.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: very minor 405GP and 405GPr PCI difference

[Allen Curtis]

> That's right.  Is there a reason for boards to have different
> mappings?  I can well believe that there is, but the current tree
> doesn't show it - all the boards (in the tree) that have PCI appear to
> do the same initialisation of the windows.  It doesn't seem worthwhile
> to create board specific PCI initialisation hooks until we have a
> board that needs it.

If all boards are suppose to have the same mapping, why doesn't someone
document it as such? It would have saved me a lot of time. If it isn't a
good enough rule to be documented then make the system flexible enough to
take a different path if required. (proactive)


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Tue, Oct 01, 2002 at 09:26:18PM -0700, Allen Curtis wrote:
>
> > That's right.  Is there a reason for boards to have different
> > mappings?  I can well believe that there is, but the current tree
> > doesn't show it - all the boards (in the tree) that have PCI appear to
> > do the same initialisation of the windows.  It doesn't seem worthwhile
> > to create board specific PCI initialisation hooks until we have a
> > board that needs it.
>
> If all boards are suppose to have the same mapping, why doesn't someone
> document it as such? It would have saved me a lot of time. If it isn't a
> good enough rule to be documented then make the system flexible enough to
> take a different path if required. (proactive)

Um, well... I can't immediately think of a logical place to document
this.  It seems logical to me that the PCI setup should be handled by
the driver for the PCI bridge - which is common between the boards.
This could be seen as a first step of changing PCI from a special
system handled platform wide, to making the PCI bridge just another
gadget in the device tree.

There's no particular reason the mapping has to be the same between
boards, but I can't think of any particular reason you'd want it to be
different (maybe I just haven't seen a wacky enough board).

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Matt Porter]

On Wed, Oct 02, 2002 at 03:34:22PM +1000, David Gibson wrote:
>
> On Tue, Oct 01, 2002 at 09:26:18PM -0700, Allen Curtis wrote:
> >
> > > That's right.  Is there a reason for boards to have different
> > > mappings?  I can well believe that there is, but the current tree
> > > doesn't show it - all the boards (in the tree) that have PCI appear to
> > > do the same initialisation of the windows.  It doesn't seem worthwhile
> > > to create board specific PCI initialisation hooks until we have a
> > > board that needs it.
> >
> > If all boards are suppose to have the same mapping, why doesn't someone
> > document it as such? It would have saved me a lot of time. If it isn't a
> > good enough rule to be documented then make the system flexible enough to
> > take a different path if required. (proactive)
>
> Um, well... I can't immediately think of a logical place to document
> this.  It seems logical to me that the PCI setup should be handled by
> the driver for the PCI bridge - which is common between the boards.
> This could be seen as a first step of changing PCI from a special
> system handled platform wide, to making the PCI bridge just another
> gadget in the device tree.
>
> There's no particular reason the mapping has to be the same between
> boards, but I can't think of any particular reason you'd want it to be
> different (maybe I just haven't seen a wacky enough board).

That's exactly the problem.  If your world is filled with the
standard IBM reference platforms then a simple single host PCI
bridge in "CHRP-style" mapping probably seems reasonable.

In reality, it's necessary to design PCI host bridge library
code such that it can be called in a board-specific way to allow
for window mappings in "wacky" systems with 2 or more PCI connected
processors.  This is very common.

This is where the current flow of having a common thread of excecution
falls apart (ppc4xx_setup).  40x really should be following the model
of the embedded 7xx/74xx system where each <board>.c would call to a
PCI library with some parameters to set up a desired set of window
mappings.  It's possible to have a default common case to set up
a CHRP-like mapping.

We've had some threads in the past about the limitations of using
this "common flow" design in 4xx.  I believe there was some agreement
that it is a limiting way to do things.  I do recall that Dan said
it was only this way because he copied the 826x flow and it probably
didn't make sense anymore for 4xx.  If there's no serious objections
I'm suggesting that this is where we go in the 2.5 4xx reorg.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Wed, Oct 02, 2002 at 10:03:12AM -0700, Matt Porter wrote:
>
> On Wed, Oct 02, 2002 at 03:34:22PM +1000, David Gibson wrote:
> >
> > On Tue, Oct 01, 2002 at 09:26:18PM -0700, Allen Curtis wrote:
> > >
> > > > That's right.  Is there a reason for boards to have different
> > > > mappings?  I can well believe that there is, but the current tree
> > > > doesn't show it - all the boards (in the tree) that have PCI appear to
> > > > do the same initialisation of the windows.  It doesn't seem worthwhile
> > > > to create board specific PCI initialisation hooks until we have a
> > > > board that needs it.
> > >
> > > If all boards are suppose to have the same mapping, why doesn't someone
> > > document it as such? It would have saved me a lot of time. If it isn't a
> > > good enough rule to be documented then make the system flexible enough to
> > > take a different path if required. (proactive)
> >
> > Um, well... I can't immediately think of a logical place to document
> > this.  It seems logical to me that the PCI setup should be handled by
> > the driver for the PCI bridge - which is common between the boards.
> > This could be seen as a first step of changing PCI from a special
> > system handled platform wide, to making the PCI bridge just another
> > gadget in the device tree.
> >
> > There's no particular reason the mapping has to be the same between
> > boards, but I can't think of any particular reason you'd want it to be
> > different (maybe I just haven't seen a wacky enough board).
>
> That's exactly the problem.  If your world is filled with the
> standard IBM reference platforms then a simple single host PCI
> bridge in "CHRP-style" mapping probably seems reasonable.
>
> In reality, it's necessary to design PCI host bridge library
> code such that it can be called in a board-specific way to allow
> for window mappings in "wacky" systems with 2 or more PCI connected
> processors.  This is very common.

Ok, I can see why you'd want a different PCI mapping for that.

For boards like this, would it be sufficient for the generic code to
set up PMM0 and PTM1 with the standard mapping, then let the board
code use the remaining PMMs and PTMs for additional mappings?

> This is where the current flow of having a common thread of excecution
> falls apart (ppc4xx_setup).  40x really should be following the model
> of the embedded 7xx/74xx system where each <board>.c would call to a
> PCI library with some parameters to set up a desired set of window
> mappings.  It's possible to have a default common case to set up
> a CHRP-like mapping.

I agree absolutely.  The current flow of control of the board stuff is
a ghastly horrible mess.

> We've had some threads in the past about the limitations of using
> this "common flow" design in 4xx.  I believe there was some agreement
> that it is a limiting way to do things.  I do recall that Dan said
> it was only this way because he copied the 826x flow and it probably
> didn't make sense anymore for 4xx.  If there's no serious objections
> I'm suggesting that this is where we go in the 2.5 4xx reorg.

Quite.  In fact I recall suggesting a re-org along these lines some
time ago, but then I got busy and didn't have time to actually send
patches.  I seem to recall there was some resistance to such a re-org
at the time.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Matt Porter]

On Thu, Oct 03, 2002 at 11:10:44AM +1000, David Gibson wrote:
>
> On Wed, Oct 02, 2002 at 10:03:12AM -0700, Matt Porter wrote:
> > That's exactly the problem.  If your world is filled with the
> > standard IBM reference platforms then a simple single host PCI
> > bridge in "CHRP-style" mapping probably seems reasonable.
> >
> > In reality, it's necessary to design PCI host bridge library
> > code such that it can be called in a board-specific way to allow
> > for window mappings in "wacky" systems with 2 or more PCI connected
> > processors.  This is very common.
>
> Ok, I can see why you'd want a different PCI mapping for that.
>
> For boards like this, would it be sufficient for the generic code to
> set up PMM0 and PTM1 with the standard mapping, then let the board
> code use the remaining PMMs and PTMs for additional mappings?

In my book, that removes flexibility which is something I'm a
big believer in when it comes to embedded stuffs.  I'd prefer
to have something like:

	ibm_pci_init(<default_or_custom_map_flag>, <window_struct_ptr>)

If you want the default CHRP map you call like this:

	ibm_pci_init(IBM_PCI_DEFAULT_MAP, NULL);

If you want a custom map you fill out a window reg struct and do:

	ibm_pci_init(IBM_PCI_CUSTOM_MAP, &my_win_struct);

The implementation of the init function can be as simple as
just taking the values of the custom win struct and programming
verbatim into the PMMs and PTMs, or eventually one can get
fancy and provide a little more abstraction where one could
pass window start/end values and the code would do some range
checking a la pplus_common.c.

Since there's such an incredible amount of cleanup work to do
for 4xx, I think a bare bones back end implementation is more
than sufficient.  I should provide an example of this for
the 440gp/gx pcix logic, but having 440 stable seemed a bit
more important first. :)

> > This is where the current flow of having a common thread of excecution
> > falls apart (ppc4xx_setup).  40x really should be following the model
> > of the embedded 7xx/74xx system where each <board>.c would call to a
> > PCI library with some parameters to set up a desired set of window
> > mappings.  It's possible to have a default common case to set up
> > a CHRP-like mapping.
>
> I agree absolutely.  The current flow of control of the board stuff is
> a ghastly horrible mess.

Aha!  Good.

> > We've had some threads in the past about the limitations of using
> > this "common flow" design in 4xx.  I believe there was some agreement
> > that it is a limiting way to do things.  I do recall that Dan said
> > it was only this way because he copied the 826x flow and it probably
> > didn't make sense anymore for 4xx.  If there's no serious objections
> > I'm suggesting that this is where we go in the 2.5 4xx reorg.
>
> Quite.  In fact I recall suggesting a re-org along these lines some
> time ago, but then I got busy and didn't have time to actually send
> patches.  I seem to recall there was some resistance to such a re-org
> at the time.

Hrm, I will have to reread some of threads I saved.  I only recalled
some agreement from Dan that it probably didn't make sense any longer
and a tangential issue regarding the desire to build a single image
with multiple 4xx targets.  Something that I, incidentally, believe
is a waste of time since kernels can be built so quickly.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Thu, Oct 03, 2002 at 08:14:39AM -0700, Matt Porter wrote:
>
> On Thu, Oct 03, 2002 at 11:10:44AM +1000, David Gibson wrote:
> >
> > On Wed, Oct 02, 2002 at 10:03:12AM -0700, Matt Porter wrote:
> > > That's exactly the problem.  If your world is filled with the
> > > standard IBM reference platforms then a simple single host PCI
> > > bridge in "CHRP-style" mapping probably seems reasonable.
> > >
> > > In reality, it's necessary to design PCI host bridge library
> > > code such that it can be called in a board-specific way to allow
> > > for window mappings in "wacky" systems with 2 or more PCI connected
> > > processors.  This is very common.
> >
> > Ok, I can see why you'd want a different PCI mapping for that.
> >
> > For boards like this, would it be sufficient for the generic code to
> > set up PMM0 and PTM1 with the standard mapping, then let the board
> > code use the remaining PMMs and PTMs for additional mappings?
>
> In my book, that removes flexibility which is something I'm a
> big believer in when it comes to embedded stuffs.  I'd prefer
> to have something like:

On the other hand, it adds simplicity, which I'm a big believer in
generally.  Nonetheless, point taken.

> 	ibm_pci_init(<default_or_custom_map_flag>, <window_struct_ptr>)
>
> If you want the default CHRP map you call like this:
>
> 	ibm_pci_init(IBM_PCI_DEFAULT_MAP, NULL);
>
> If you want a custom map you fill out a window reg struct and do:
>
> 	ibm_pci_init(IBM_PCI_CUSTOM_MAP, &my_win_struct);

This approach would fall out naturally if the basic init structure is
re-organised as we both think it should be (i.e. making the board
files have top-level control).  As an interim measure (to remove the
bug that is in many versions, and discourage its further propagation),
though, how about the patch below.

It is much like my previous patch, but allows the board to override
the setup if CONFIG_BOARD_PCI_MAPPING is defined.

diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/kernel/4xx/ppc405_pci.c linux-bluefish/arch/ppc/kernel/4xx/ppc405_pci.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/kernel/4xx/ppc405_pci.c	2002-10-04 10:36:17.000000000 +1000
+++ linux-bluefish/arch/ppc/kernel/4xx/ppc405_pci.c	2002-10-04 12:29:25.000000000 +1000
@@ -53,7 +53,6 @@
 #include <asm/ibm_ocp_pci.h>


-extern void bios_fixup(struct pci_controller *, struct pcil0_regs *);
 extern int ppc405_map_irq(struct pci_dev *dev, unsigned char idsel,
 			  unsigned char pin);

@@ -112,6 +111,114 @@
 	return (bus == 0 && devfn == 0);
 }

+static void __init
+configure_host_bridge(struct pci_controller *hose, struct pcil0_regs *pcip)
+{
+#ifdef CONFIG_BOARD_PCI_MAPPING
+	extern void bios_fixup(struct pci_controller *, struct pcil0_regs *);
+
+	/* The board wants to control the PCI configuration, let it
+	 * set up the bridge */
+
+	bios_fixup(hose, pcip);
+#elif CONFIG_BIOS_FIXUP
+	unsigned int bar_response, bar;
+
+	/* Otherwise, just set up the "standard" PCI mapping:
+	 *
+	 *  PLB addr             PCI memory addr
+	 *  ---------------------       ---------------------
+	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
+	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
+	 *
+	 *  PLB addr             PCI io addr
+	 *  ---------------------       ---------------------
+	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
+	 */
+
+#ifdef DEBUG
+	int i;
+
+	printk(KERN_DEBUG "ioremap PCLIO_BASE = 0x%p\n", pcip);
+	printk(KERN_DEBUG "PCI bridge regs before fixup \n");
+	for (i = 0; i <= 3; i++) {
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
+	}
+	printk(KERN_DEBUG " ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
+	printk(KERN_DEBUG " ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
+	printk(KERN_DEBUG " ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
+	printk(KERN_DEBUG " ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
+#endif
+
+	/* First set up the PLB->PCI window, we only use PMM0 */
+
+	/* Disable region first */
+	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
+	/* PLB starting addr, PCI: 0x80000000 */
+	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
+	/* PCI start addr, 0x80000000 */
+	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
+	/* 512MB range of PLB to PCI */
+	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
+	/* Enable no pre-fetch, enable region */
+	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
+						(PPC405_PCI_UPPER_MEM -
+						 PPC405_PCI_MEM_BASE)) | 0x01));
+
+	/* Disable region one */
+	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
+	out_le32((void *) &(pcip->pmm[1].la), 0x00000000);
+	out_le32((void *) &(pcip->pmm[1].pcila), 0x00000000);
+	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
+	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
+
+	/* Disable region two */
+	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
+	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
+	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
+	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
+	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
+
+	/* Now configure the PCI->PLB windows, we only use PTM1 */
+	out_le32((void *) &(pcip->ptm1ms), 0x00000000); /* first disable */
+	out_le32((void *) &(pcip->ptm1la), 0x00000000); /* base address */
+	out_le32((void *) &(pcip->ptm1ms), 0x80000001); /* re-enable */
+	out_le32((void *) &(pcip->ptm2ms), 0x00000000); /* disable PTM2 */
+
+	/* Zero config bars */
+	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
+		early_write_config_dword(hose, hose->first_busno,
+					 PCI_FUNC(hose->first_busno), bar,
+					 0x00000000);
+		early_read_config_dword(hose, hose->first_busno,
+					PCI_FUNC(hose->first_busno), bar,
+					&bar_response);
+		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
+		    hose->first_busno, PCI_SLOT(hose->first_busno),
+		    PCI_FUNC(hose->first_busno), bar, bar_response);
+	}
+	/* end work arround */
+
+#ifdef DEBUG
+	printk(KERN_DEBUG "PCI bridge regs after fixup \n");
+	for (i = 0; i <= 3; i++) {
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
+		printk(KERN_DEBUG " pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
+	}
+	printk(KERN_DEBUG " ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
+	printk(KERN_DEBUG " ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
+	printk(KERN_DEBUG " ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
+	printk(KERN_DEBUG " ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
+
+#endif /* DEBUG */
+#endif /* CONFIG_BIOS_FIXUP */
+}
+
 void
 ppc4xx_find_bridges(void)
 {
@@ -143,10 +250,8 @@

 	pcip = ioremap((unsigned long) ocp_get_paddr(OCP_FUNC_PCI, 0), PAGE_SIZE);
 	if (pcip != NULL) {
+		configure_host_bridge(hose_a, pcip);

-#if defined(CONFIG_BIOS_FIXUP)
-		bios_fixup(hose_a, pcip);
-#endif
 		new_pmm_min = 0xffffffff;
 		for (reg_index = 0; reg_index < 3; reg_index++) {
 			tmp_size = in_le32((void *) &(pcip->pmm[reg_index].ma));	// *_PMM0MA
diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/ash.c linux-bluefish/arch/ppc/platforms/4xx/ash.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/ash.c	2002-10-04 10:36:17.000000000 +1000
+++ linux-bluefish/arch/ppc/platforms/4xx/ash.c	2002-10-04 11:30:04.000000000 +1000
@@ -95,137 +95,6 @@
 }

 void __init
-bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
-{
-
-	unsigned int bar_response, bar;
-	/*
-	 * Expected PCI mapping:
-	 *
-	 *  PLB addr             PCI memory addr
-	 *  ---------------------       ---------------------
-	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
-	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
-	 *
-	 *  PLB addr             PCI io addr
-	 *  ---------------------       ---------------------
-	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
-	 *
-	 * The following code is simplified by assuming that the bootrom
-	 * has been well behaved in following this mapping.
-	 */
-
-#ifdef DEBUG
-	int i;
-
-	printk("ioremap PCLIO_BASE = 0x%x\n", pcip);
-	printk("PCI bridge regs before fixup \n");
-	for (i = 0; i <= 2; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dla\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dpcila\t0x%x\n", i,
-		       in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dpciha\t0x%x\n", i,
-		       in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
-		early_read_config_dword(hose, hose->first_busno,
-					PCI_FUNC(hose->first_busno), bar,
-					&bar_response);
-		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
-		    hose->first_busno, PCI_SLOT(hose->first_busno),
-		    PCI_FUNC(hose->first_busno), bar, bar_response);
-	}
-
-#endif
-	if (ppc_md.progress)
-		ppc_md.progress("bios_fixup(): enter", 0x800);
-
-	/* added for IBM boot rom version 1.15 bios bar changes  -AK */
-
-	/* Disable region first */
-	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
-	/* PLB starting addr, PCI: 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
-	/* PCI start addr, 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
-	/* 512MB range of PLB to PCI */
-	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
-	/* Enable no pre-fetch, enable region */
-	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
-						(PPC405_PCI_UPPER_MEM -
-						 PPC405_PCI_MEM_BASE)) | 0x01));
-
-	/* Disable region one */
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-
-	/* Disable region two */
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-
-	/* Enable PTM1 and PTM2, mapped to PLB address 0. */
-
-	out_le32((void *) &(pcip->ptm1la), 0x00000000);
-	out_le32((void *) &(pcip->ptm1ms), 0x00000001);
-	out_le32((void *) &(pcip->ptm2la), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000001);
-
-	/* Write zero to PTM1 BAR. */
-
-	early_write_config_dword(hose, hose->first_busno,
-				 PCI_FUNC(hose->first_busno),
-				 PCI_BASE_ADDRESS_1,
-				 0x00000000);
-
-	/* Disable PTM2 (unused) */
-
-	out_le32((void *) &(pcip->ptm2la), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* end work arround */
-	if (ppc_md.progress)
-		ppc_md.progress("bios_fixup(): done", 0x800);
-
-#ifdef DEBUG
-	printk("PCI bridge regs after fixup \n");
-	for (i = 0; i <= 2; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dla\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dpcila\t0x%x\n", i,
-		       in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dpciha\t0x%x\n", i,
-		       in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
-		early_read_config_dword(hose, hose->first_busno,
-					PCI_FUNC(hose->first_busno), bar,
-					&bar_response);
-		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
-		    hose->first_busno, PCI_SLOT(hose->first_busno),
-		    PCI_FUNC(hose->first_busno), bar, bar_response);
-	}
-
-
-#endif
-}
-
-void __init
 board_io_mapping(void)
 {
 	io_block_mapping(ASH_RTC_VADDR, ASH_RTC_PADDR, ASH_RTC_SIZE, _PAGE_IO);
diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/ep405.c linux-bluefish/arch/ppc/platforms/4xx/ep405.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/ep405.c	2002-10-04 10:36:17.000000000 +1000
+++ linux-bluefish/arch/ppc/platforms/4xx/ep405.c	2002-10-04 11:30:26.000000000 +1000
@@ -69,73 +69,6 @@
 }

 void __init
-bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
-{
-	unsigned int bar_response, bar;
-	/*
-	 * Expected PCI mapping:
-	 *
-	 *  PLB addr             PCI memory addr
-	 *  ---------------------       ---------------------
-	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
-	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
-	 *
-	 *  PLB addr             PCI io addr
-	 *  ---------------------       ---------------------
-	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
-	 *
-	 */
-
-	/* Disable region zero first */
-	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
-	/* PLB starting addr, PCI: 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
-	/* PCI start addr, 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
-	/* 512MB range of PLB to PCI */
-	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
-	/* Enable no pre-fetch, enable region */
-	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
-						(PPC405_PCI_UPPER_MEM -
-						 PPC405_PCI_MEM_BASE)) | 0x01));
-
-	/* Disable region one */
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm1ms), 0x00000000);
-
-	/* Disable region two */
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* Configure PTM (PCI->PLB) region 1 */
-	out_le32((void *) &(pcip->ptm1la), 0x00000000); /* PLB base address */
-	/* Disable PTM region 2 */
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* Zero config bars */
-	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
-		early_write_config_dword(hose, hose->first_busno,
-					 PCI_FUNC(hose->first_busno), bar,
-					 0x00000000);
-		early_read_config_dword(hose, hose->first_busno,
-					PCI_FUNC(hose->first_busno), bar,
-					&bar_response);
-		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
-		    hose->first_busno, PCI_SLOT(hose->first_busno),
-		    PCI_FUNC(hose->first_busno), bar, bar_response);
-	}
-	/* end work arround */
-}
-
-void __init
 board_io_mapping(void)
 {
 	bd_t *bip = (bd_t *) __res;
diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/rainier.c linux-bluefish/arch/ppc/platforms/4xx/rainier.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/rainier.c	2002-09-19 16:08:06.000000000 +1000
+++ linux-bluefish/arch/ppc/platforms/4xx/rainier.c	2002-10-01 15:05:42.000000000 +1000
@@ -109,90 +109,6 @@
 }

 void __init
-bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
-{
-	/*
-	 * Expected PCI mapping:
-	 *
-	 *  PLB addr             PCI memory addr
-	 *  ---------------------       ---------------------
-	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
-	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
-	 *
-	 *  PLB addr             PCI io addr
-	 *  ---------------------       ---------------------
-	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
-	 *
-	 * The following code is simplified by assuming that the bootrom
-	 * has been well behaved in following this mapping.
-	 */
-
-#ifdef DEBUG
-	int i;
-
-	printk("ioremap PCLIO_BASE = 0x%x\n", pcip);
-	printk("PCI bridge regs before fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-
-	/* Disable region first */
-	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
-	/* PLB starting addr, PCI: 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
-	/* PCI start addr, 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
-	/* 512MB range of PLB to PCI */
-	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
-	/* Enable no pre-fetch, enable region */
-	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
-						(PPC405_PCI_UPPER_MEM -
-						 PPC405_PCI_MEM_BASE)) | 0x01));
-
-	/*region one used bu rainier*/
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].la), 0x80000000);
-	out_le32((void *) &(pcip->pmm[1].pcila), 0x80000000);
-	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].ma), 0xFFFF8001);
-	out_le32((void *) &(pcip->ptm1ms), 0x00000000);
-
-	/* Disable region two */
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* end work arround */
-
-#ifdef DEBUG
-	printk("PCI bridge regs after fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-}
-
-void __init
 board_io_mapping(void)
 {
 	io_block_mapping(RAINIER_IO_PAGE_INTERPOSER_PADDR,
diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/sycamore.c linux-bluefish/arch/ppc/platforms/4xx/sycamore.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/sycamore.c	2002-09-19 16:08:06.000000000 +1000
+++ linux-bluefish/arch/ppc/platforms/4xx/sycamore.c	2002-10-01 15:05:55.000000000 +1000
@@ -168,108 +168,6 @@
 }

 void __init
-bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
-{
-#ifdef CONFIG_PCI
-	unsigned int bar_response, bar;
-	/*
-	 * Expected PCI mapping:
-	 *
-	 *  PLB addr             PCI memory addr
-	 *  ---------------------       ---------------------
-	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
-	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
-	 *
-	 *  PLB addr             PCI io addr
-	 *  ---------------------       ---------------------
-	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
-	 *
-	 * The following code is simplified by assuming that the bootrom
-	 * has been well behaved in following this mapping.
-	 */
-
-#ifdef DEBUG
-	int i;
-
-	printk("ioremap PCLIO_BASE = 0x%x\n", pcip);
-	printk("PCI bridge regs before fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-
-	/* added for IBM boot rom version 1.15 bios bar changes  -AK */
-
-	/* Disable region first */
-	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
-	/* PLB starting addr, PCI: 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
-	/* PCI start addr, 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
-	/* 512MB range of PLB to PCI */
-	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
-	/* Enable no pre-fetch, enable region */
-	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
-						(PPC405_PCI_UPPER_MEM -
-						 PPC405_PCI_MEM_BASE)) | 0x01));
-
-	/* Disable region one */
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm1ms), 0x00000000);
-
-	/* Disable region two */
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* Zero config bars */
-	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
-		early_write_config_dword(hose, hose->first_busno,
-					 PCI_FUNC(hose->first_busno), bar,
-					 0x00000000);
-		early_read_config_dword(hose, hose->first_busno,
-					PCI_FUNC(hose->first_busno), bar,
-					&bar_response);
-		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
-		    hose->first_busno, PCI_SLOT(hose->first_busno),
-		    PCI_FUNC(hose->first_busno), bar, bar_response);
-	}
-	/* end work arround */
-
-#ifdef DEBUG
-	printk("PCI bridge regs after fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-#endif
-
-}
-
-void __init
 board_io_mapping(void)
 {
 	io_block_mapping(SYCAMORE_RTC_VADDR,
diff -urN /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/walnut.c linux-bluefish/arch/ppc/platforms/4xx/walnut.c
--- /home/dgibson/kernel/linuxppc-2.5/arch/ppc/platforms/4xx/walnut.c	2002-10-04 10:36:17.000000000 +1000
+++ linux-bluefish/arch/ppc/platforms/4xx/walnut.c	2002-10-04 11:30:53.000000000 +1000
@@ -128,107 +128,6 @@
 }

 void __init
-bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
-{
-#ifdef (CONFIG_PCI)
-	unsigned int bar_response, bar;
-	/*
-	 * Expected PCI mapping:
-	 *
-	 *  PLB addr             PCI memory addr
-	 *  ---------------------       ---------------------
-	 *  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
-	 *  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
-	 *
-	 *  PLB addr             PCI io addr
-	 *  ---------------------       ---------------------
-	 *  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
-	 *
-	 * The following code is simplified by assuming that the bootrom
-	 * has been well behaved in following this mapping.
-	 */
-
-#ifdef DEBUG
-	int i;
-
-	printk("ioremap PCLIO_BASE = 0x%x\n", pcip);
-	printk("PCI bridge regs before fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-
-	/* added for IBM boot rom version 1.15 bios bar changes  -AK */
-
-	/* Disable region first */
-	out_le32((void *) &(pcip->pmm[0].ma), 0x00000000);
-	/* PLB starting addr, PCI: 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].la), 0x80000000);
-	/* PCI start addr, 0x80000000 */
-	out_le32((void *) &(pcip->pmm[0].pcila), PPC405_PCI_MEM_BASE);
-	/* 512MB range of PLB to PCI */
-	out_le32((void *) &(pcip->pmm[0].pciha), 0x00000000);
-	/* Enable no pre-fetch, enable region */
-	out_le32((void *) &(pcip->pmm[0].ma), ((0xffffffff -
-						(PPC405_PCI_UPPER_MEM -
-						 PPC405_PCI_MEM_BASE)) | 0x01));
-
-	/* Disable region one */
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[1].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm1ms), 0x00000000);
-
-	/* Disable region two */
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].la), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pcila), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].pciha), 0x00000000);
-	out_le32((void *) &(pcip->pmm[2].ma), 0x00000000);
-	out_le32((void *) &(pcip->ptm2ms), 0x00000000);
-
-	/* Zero config bars */
-	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
-		early_write_config_dword(hose, hose->first_busno,
-					 PCI_FUNC(hose->first_busno), bar,
-					 0x00000000);
-		early_read_config_dword(hose, hose->first_busno,
-					PCI_FUNC(hose->first_busno), bar,
-					&bar_response);
-		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
-		    hose->first_busno, PCI_SLOT(hose->first_busno),
-		    PCI_FUNC(hose->first_busno), bar, bar_response);
-	}
-	/* end work arround */
-
-#ifdef DEBUG
-	printk("PCI bridge regs after fixup \n");
-	for (i = 0; i <= 3; i++) {
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].ma)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].la)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pcila)));
-		printk(" pmm%dma\t0x%x\n", i, in_le32(&(pcip->pmm[i].pciha)));
-	}
-	printk(" ptm1ms\t0x%x\n", in_le32(&(pcip->ptm1ms)));
-	printk(" ptm1la\t0x%x\n", in_le32(&(pcip->ptm1la)));
-	printk(" ptm2ms\t0x%x\n", in_le32(&(pcip->ptm2ms)));
-	printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
-
-#endif
-#endif
-}
-
-void __init
 board_io_mapping(void)
 {
 	io_block_mapping(WALNUT_RTC_VADDR,

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Todd Poynor]

David Gibson wrote:

> +	/* Now configure the PCI->PLB windows, we only use PTM1 */
> +	out_le32((void *) &(pcip->ptm1ms), 0x00000000); /* first disable */
> +	out_le32((void *) &(pcip->ptm1la), 0x00000000); /* base address */
> +	out_le32((void *) &(pcip->ptm1ms), 0x80000001); /* re-enable */
> +	out_le32((void *) &(pcip->ptm2ms), 0x00000000); /* disable PTM2 */
> +
> +	/* Zero config bars */
> +	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
> +		early_write_config_dword(hose, hose->first_busno,
> +					 PCI_FUNC(hose->first_busno), bar,
> +					 0x00000000);
> +		early_read_config_dword(hose, hose->first_busno,
> +					PCI_FUNC(hose->first_busno), bar,
> +					&bar_response);
> +		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is 0x%8.8x\n",
> +		    hose->first_busno, PCI_SLOT(hose->first_busno),
> +		    PCI_FUNC(hose->first_busno), bar, bar_response);
> +	}

Only PCI_BASE_ADDRESS_1 (aka PCIL0_PTM1BAR) needs to be set since PTM2
is disabled (Ash is already doing it this way).  My reading of the
manual would indicate that the BAR ought to be set before PTM1 is
enabled, but haven't seen any problems with this.

Could enclose the early_read_config_dword() in #ifdef DEBUG.

Rainier (NP4GS3) PMM1 is setup specially in the existing code, is this
no longer needed?

This code is fragile and tends to break on certain platforms in ways
that can't be explained by the available documentation.  I can help test
the unified version on Walnut/Sycamore/Ash if needed.


--
Todd


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Fri, Oct 04, 2002 at 11:33:13AM -0700, Todd Poynor wrote:
>
> David Gibson wrote:
>
> >+	/* Now configure the PCI->PLB windows, we only use PTM1 */
> >+	out_le32((void *) &(pcip->ptm1ms), 0x00000000); /* first disable */
> >+	out_le32((void *) &(pcip->ptm1la), 0x00000000); /* base address */
> >+	out_le32((void *) &(pcip->ptm1ms), 0x80000001); /* re-enable */
> >+	out_le32((void *) &(pcip->ptm2ms), 0x00000000); /* disable PTM2 */
> >+
> >+	/* Zero config bars */
> >+	for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
> >+		early_write_config_dword(hose, hose->first_busno,
> >+					 PCI_FUNC(hose->first_busno), bar,
> >+					 0x00000000);
> >+		early_read_config_dword(hose, hose->first_busno,
> >+					PCI_FUNC(hose->first_busno), bar,
> >+					&bar_response);
> >+		DBG("BUS %d, device %d, Function %d bar 0x%8.8x is
> >0x%8.8x\n",
> >+		    hose->first_busno, PCI_SLOT(hose->first_busno),
> >+		    PCI_FUNC(hose->first_busno), bar, bar_response);
> >+	}
>
> Only PCI_BASE_ADDRESS_1 (aka PCIL0_PTM1BAR) needs to be set since PTM2
> is disabled (Ash is already doing it this way).  My reading of the
> manual would indicate that the BAR ought to be set before PTM1 is
> enabled, but haven't seen any problems with this.

I guess that's true.  On the other hand, I wonder if there is merit in
setting the other BAR, just so that everything is in a known state.

> Could enclose the early_read_config_dword() in #ifdef DEBUG.

Yes, good idea.

> Rainier (NP4GS3) PMM1 is setup specially in the existing code, is this
> no longer needed?

Well, I don't know if it's necessary - it's not there, because I
didn't notice the difference in the Rainier code before.  Now that I
do look at it, I'm confused: it appears to be setting up both PMM0 and
PMM1 to map from the same PLB addresses, but the manual specifically
prohibits overlapping PMM ranges.

> This code is fragile and tends to break on certain platforms in ways
> that can't be explained by the available documentation.  I can help test
> the unified version on Walnut/Sycamore/Ash if needed.

Do you mean the existing code, or my proposed patch (or both).  That
would be great if you could test the code on those machines -  I don't
have a Sycamore or Ash, and I'd have to drag the Walnut out again to
test on it.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Todd Poynor]

David Gibson wrote:

>>Rainier (NP4GS3) PMM1 is setup specially in the existing code, is this
>>no longer needed?
>
>
> Well, I don't know if it's necessary - it's not there, because I
> didn't notice the difference in the Rainier code before.  Now that I
> do look at it, I'm confused: it appears to be setting up both PMM0 and
> PMM1 to map from the same PLB addresses, but the manual specifically
> prohibits overlapping PMM ranges.

And the code used for MontaVista's products has diverged somehow; it has
an empty bios_fixup but code in a different place that does something
different:

	/* plb address 0x8000 0000 will be set to pci address 0x8000 0000 which
	   corresponds to PCI 9030 Dev 0x10 BAR4 */
	out_le32((void*)PMM1LA,0x80000000);
	out_le32((void*)PMM1MA,0xFFFE0001);    /* PLB range is 128KB */
	out_le32((void*)PMM1PCILA,0x80000000);
	out_le32((void*)PMM1PCIHA,0x00000000);

I'll try to figure out the story on this, but everything NP4GS3-related
seems to be murky...  NP4GS3 will probably need a custom bios_fixup that
does the above (among other things), can worry about that platform later.

>>This code is fragile and tends to break on certain platforms in ways
>>that can't be explained by the available documentation.  I can help test
>>the unified version on Walnut/Sycamore/Ash if needed.
>
>
> Do you mean the existing code, or my proposed patch (or both).  That
> would be great if you could test the code on those machines -  I don't
> have a Sycamore or Ash, and I'd have to drag the Walnut out again to
> test on it.

Yes, I can test your proposed code on those machines.


--
Todd


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Tue, Oct 08, 2002 at 12:39:39PM -0700, Todd Poynor wrote:
>
> David Gibson wrote:
>
> >>Rainier (NP4GS3) PMM1 is setup specially in the existing code, is this
> >>no longer needed?
> >
> >
> >Well, I don't know if it's necessary - it's not there, because I
> >didn't notice the difference in the Rainier code before.  Now that I
> >do look at it, I'm confused: it appears to be setting up both PMM0 and
> >PMM1 to map from the same PLB addresses, but the manual specifically
> >prohibits overlapping PMM ranges.
>
> And the code used for MontaVista's products has diverged somehow; it has
> an empty bios_fixup but code in a different place that does something
> different:
>
> 	/* plb address 0x8000 0000 will be set to pci address 0x8000 0000
> 	which
> 	   corresponds to PCI 9030 Dev 0x10 BAR4 */
> 	out_le32((void*)PMM1LA,0x80000000);
> 	out_le32((void*)PMM1MA,0xFFFE0001);    /* PLB range is 128KB */
> 	out_le32((void*)PMM1PCILA,0x80000000);
> 	out_le32((void*)PMM1PCIHA,0x00000000);

Well, it may be in a different place, but it looks like it has the
same problem.  It is still establishing a PCI window at PLB address
0x80000000, which is the same address used for the PMM0 window - or is
that also different in the MV kernel?

> I'll try to figure out the story on this, but everything NP4GS3-related
> seems to be murky...  NP4GS3 will probably need a custom bios_fixup that
> does the above (among other things), can worry about that platform later.

I'd be trying to work out what that mapping's actually for, first.  I
still can't see how it can possibly work - if there are overlapping
PMM windows, what actually happens to accesses in that (PLB) range?

> >>This code is fragile and tends to break on certain platforms in ways
> >>that can't be explained by the available documentation.  I can help test
> >>the unified version on Walnut/Sycamore/Ash if needed.
> >
> >
> >Do you mean the existing code, or my proposed patch (or both).  That
> >would be great if you could test the code on those machines -  I don't
> >have a Sycamore or Ash, and I'd have to drag the Walnut out again to
> >test on it.
>
> Yes, I can test your proposed code on those machines.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Ralph Blach]

David,

Let me expain

On the 405gp, the PMM0 enable is hardwired 1 and  cannot be overwritten
by software.   This makes the PMM0 region permantly enabled on the
405GP.  I cannot be turned off.

When the technology port was done, the design of the PCI was changed
slightly because the designer made the PMM0 enable bit writable.  It is
still initalized to a 1, but it can written to a 0.

In the current software, the initialization software writes a 0 to PMM0
and to PMM1.  This was fine on the 405gp because the enable bit for PMM0
could not be changed.  On the 405GPr this disabled PMM0 and with PMM1
disabled, bad things happened.

The initialization software simply need to write a 1 to the PMM0 enable
bit and all will be well.

Chip




David Gibson wrote:
> On Tue, Oct 22, 2002 at 02:55:47PM -0700, Todd Poynor wrote:
>
>>David Gibson wrote (regarding Rainier PMM1 bios_fixup in MVL):
>>
>>
>>>Well, it may be in a different place, but it looks like it has the
>>>same problem.  It is still establishing a PCI window at PLB address
>>>0x80000000, which is the same address used for the PMM0 window - or is
>>>that also different in the MV kernel?
>>>
>>>I'd be trying to work out what that mapping's actually for, first.  I
>>>still can't see how it can possibly work - if there are overlapping
>>>PMM windows, what actually happens to accesses in that (PLB) range?
>>
>>Yes, it looks like MVL only sets up the one window using PMM1... we've
>>started an effort to have the Rainier-knowedgeable folks get the code
>>sync'ed up with the community and this should happen soon.
>
>
> Hang on, so just to clarify - MVL sets up PMM1 with the code you
> posted, but doesn't set up PMM0 anywhere?  From my reading of that
> code, it sets up a window at the same address as the "standard"
> (Walnut) mapping, except that it is only 128kB instead of 1GB.  Is
> there a reason that Rainier must have such a small window?
>
> --
> David Gibson			| For every complex problem there is a
> david@gibson.dropbear.id.au	| solution which is simple, neat and
> 				| wrong.
> http://www.ozlabs.org/people/dgibson
>
>
>
> .
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Thu, Oct 24, 2002 at 07:50:33PM -0400, Ralph Blach wrote:
> David,
>
> Let me expain
>
> On the 405gp, the PMM0 enable is hardwired 1 and  cannot be overwritten
> by software.   This makes the PMM0 region permantly enabled on the
> 405GP.  I cannot be turned off.

Yes, I realise this.

> When the technology port was done, the design of the PCI was changed
> slightly because the designer made the PMM0 enable bit writable.  It is
> still initalized to a 1, but it can written to a 0.
>
> In the current software, the initialization software writes a 0 to PMM0
> and to PMM1.  This was fine on the 405gp because the enable bit for PMM0
> could not be changed.  On the 405GPr this disabled PMM0 and with PMM1
> disabled, bad things happened.
>
> The initialization software simply need to write a 1 to the PMM0 enable
> bit and all will be well.

Yes, I know that's the problem that triggered this discussion, but
it's only part of what we're covering now.

Since I was looking at the code it seemed like a good idea to try to
consolidate this stuff for the various boards at the same time.
Otherwise we'll have to fix this in the code for every 405GPr board in
the tree, and every 405GP board too or people will copy the broken
code.  Then it will keep coming back as people merge board ports that
haven't caught up with the fix.

I'm trying to find out how the various boards are meaning to set up
the PCI mappings, and come up with the simplest scheme we can to
handle that.  At the moment this code (on most of the boards) is
confused and suggest to me that it was written without really
understanding what was intended and how to go about accomplishing it.

> David Gibson wrote:
> >On Tue, Oct 22, 2002 at 02:55:47PM -0700, Todd Poynor wrote:
> >
> >>David Gibson wrote (regarding Rainier PMM1 bios_fixup in MVL):
> >>
> >>
> >>>Well, it may be in a different place, but it looks like it has the
> >>>same problem.  It is still establishing a PCI window at PLB address
> >>>0x80000000, which is the same address used for the PMM0 window - or is
> >>>that also different in the MV kernel?
> >>>
> >>>I'd be trying to work out what that mapping's actually for, first.  I
> >>>still can't see how it can possibly work - if there are overlapping
> >>>PMM windows, what actually happens to accesses in that (PLB) range?
> >>
> >>Yes, it looks like MVL only sets up the one window using PMM1... we've
> >>started an effort to have the Rainier-knowedgeable folks get the code
> >>sync'ed up with the community and this should happen soon.
> >
> >
> >Hang on, so just to clarify - MVL sets up PMM1 with the code you
> >posted, but doesn't set up PMM0 anywhere?  From my reading of that
> >code, it sets up a window at the same address as the "standard"
> >(Walnut) mapping, except that it is only 128kB instead of 1GB.  Is
> >there a reason that Rainier must have such a small window?
> >
>
>
>

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

["David Müller (ELSOFT AG)"]

David Gibson wrote:
> On Tue, Oct 01, 2002 at 10:37:20AM +0200, "David M?ller (ELSOFT AG)" wrote:
>
[stuff deleted]
>>
>>In your proposed patch, i'm missing a way to install a board specify
>>mapping either by using special constants, callback functions to board
>>specific code, .... AFAICS all boards are forced to use the same mapping.
>
>
> That's right.  Is there a reason for boards to have different
> mappings?  I can well believe that there is, but the current tree
> doesn't show it - all the boards (in the tree) that have PCI appear to
> do the same initialisation of the windows.  It doesn't seem worthwhile
> to create board specific PCI initialisation hooks until we have a
> board that needs it.
>

Not all boards using LinuxPPC are in the offical tree (yet). I know at
least two boards which are using a "non-standard" PCI mapping.

Dave


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Wed, Oct 02, 2002 at 09:46:26AM +0200, "David M?ller (ELSOFT AG)" wrote:
>
> David Gibson wrote:
> >On Tue, Oct 01, 2002 at 10:37:20AM +0200, "David M?ller (ELSOFT AG)" wrote:
> >
> [stuff deleted]
> >>
> >>In your proposed patch, i'm missing a way to install a board specify
> >>mapping either by using special constants, callback functions to board
> >>specific code, .... AFAICS all boards are forced to use the same mapping.
> >
> >
> >That's right.  Is there a reason for boards to have different
> >mappings?  I can well believe that there is, but the current tree
> >doesn't show it - all the boards (in the tree) that have PCI appear to
> >do the same initialisation of the windows.  It doesn't seem worthwhile
> >to create board specific PCI initialisation hooks until we have a
> >board that needs it.
>
> Not all boards using LinuxPPC are in the offical tree (yet). I know at
> least two boards which are using a "non-standard" PCI mapping.

Fair enough.  I'm just trying to come up with the simplest approach
that still provides the flexibility we need.  Based on the evidence
immediately available, what I posted seemed like it.  How about you
tell me something about the non-standard PCI mappings, so I can come
up with something better.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

["David Müller (ELSOFT AG)"]

David Gibson wrote:
[stuff deleted]

> Fair enough.  I'm just trying to come up with the simplest approach
> that still provides the flexibility we need.  Based on the evidence
> immediately available, what I posted seemed like it.  How about you
> tell me something about the non-standard PCI mappings, so I can come
> up with something better.
>

Ok, here is the mapping i'm currently using . For the E000'0000 -
E0ff'ffff area i have to program PMM1 with "non-standard" values.


	/*  PCI mapping:
         **
         **  PLB addr                    PCI memory addr
         **  ---------------------       ---------------------
         **  0000'0000 - 7fff'ffff <---  0000'0000 - 7fff'ffff
         **  8000'0000 - Bfff'ffff --->  8000'0000 - Bfff'ffff
	**  E000'0000 - E0ff'ffff --->  0000'0000 - 00ff'ffff
         **
         **  PLB addr                    PCI io addr
         **  ---------------------       ---------------------
         **  e800'0000 - e800'ffff --->  0000'0000 - 0001'0000
         **
         */


I'm also thinking about splitting the 8000'0000 - Bfff'ffff area into a
prefetchable and a non-prefectable one, so i will be urged to programm
PMM2 as well.


Dave


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Andrew May]

On Thu, Oct 03, 2002 at 11:12:33AM +1000, David Gibson wrote:
>
> Fair enough.  I'm just trying to come up with the simplest approach
> that still provides the flexibility we need.  Based on the evidence
> immediately available, what I posted seemed like it.  How about you
> tell me something about the non-standard PCI mappings, so I can come
> up with something better.

It would be nice to have the option to let the boot loader set the
mapping. I have been happy with getting things done in PPCBoot and
ripping out the PCI scanning in the kernel.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Matt Porter]

On Sat, Oct 05, 2002 at 10:23:14PM -0700, Andrew May wrote:
>
> On Thu, Oct 03, 2002 at 11:12:33AM +1000, David Gibson wrote:
> >
> > Fair enough.  I'm just trying to come up with the simplest approach
> > that still provides the flexibility we need.  Based on the evidence
> > immediately available, what I posted seemed like it.  How about you
> > tell me something about the non-standard PCI mappings, so I can come
> > up with something better.
>
> It would be nice to have the option to let the boot loader set the
> mapping. I have been happy with getting things done in PPCBoot and
> ripping out the PCI scanning in the kernel.

Yes, that's the ideal situation and going to what David and I would
like to see makes that yet another simple fallout feature.

Your custom port using a good implementation of PPCBoot simply
would not call the pci macro init library nor would it use pci_auto.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Sun, Oct 06, 2002 at 06:31:20PM -0700, Matt Porter wrote:
>
> On Sat, Oct 05, 2002 at 10:23:14PM -0700, Andrew May wrote:
> >
> > On Thu, Oct 03, 2002 at 11:12:33AM +1000, David Gibson wrote:
> > >
> > > Fair enough.  I'm just trying to come up with the simplest approach
> > > that still provides the flexibility we need.  Based on the evidence
> > > immediately available, what I posted seemed like it.  How about you
> > > tell me something about the non-standard PCI mappings, so I can come
> > > up with something better.
> >
> > It would be nice to have the option to let the boot loader set the
> > mapping. I have been happy with getting things done in PPCBoot and
> > ripping out the PCI scanning in the kernel.
>
> Yes, that's the ideal situation and going to what David and I would
> like to see makes that yet another simple fallout feature.
>
> Your custom port using a good implementation of PPCBoot simply
> would not call the pci macro init library nor would it use pci_auto.

As Matt says, this would fall out naturally from a better control
structure.  Howeever, I tend to think that leaving things like this to
the bootloader/firmware is a bad idea:

The kernel has to know how PCI addresses are mapped anyway, so this
becomes yet another point at which the kernel and firmware are bound
together.  Why should the kernel have code to deal with umpteen
different cases of how PCI might have been set up, or not set up by
the firmware/bootloader, when it can just take control of the host
bridge and reprogram it how it wants?  Once the debugging cruft comes
out, it should only be a couple of hundred bytes of code.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Andrew May]

On Tue, Oct 08, 2002 at 02:14:19PM +1000, David Gibson wrote:
>
> On Sun, Oct 06, 2002 at 06:31:20PM -0700, Matt Porter wrote:
> >
> > On Sat, Oct 05, 2002 at 10:23:14PM -0700, Andrew May wrote:
> > >
> > > It would be nice to have the option to let the boot loader set the
> > > mapping. I have been happy with getting things done in PPCBoot and
> > > ripping out the PCI scanning in the kernel.
> >
> > Yes, that's the ideal situation and going to what David and I would
> > like to see makes that yet another simple fallout feature.
> >
> > Your custom port using a good implementation of PPCBoot simply
> > would not call the pci macro init library nor would it use pci_auto.
>
> As Matt says, this would fall out naturally from a better control
> structure.  Howeever, I tend to think that leaving things like this to
> the bootloader/firmware is a bad idea:

A full featured bootloader like PPCboot will need to setup the PCI bus
to work with PCI devices, so it is not like it is always an extra burden
on the bootloader or useless work.

> The kernel has to know how PCI addresses are mapped anyway, so this
> becomes yet another point at which the kernel and firmware are bound
> together.  Why should the kernel have code to deal with umpteen
> different cases of how PCI might have been set up, or not set up by
> the firmware/bootloader, when it can just take control of the host
> bridge and reprogram it how it wants?  Once the debugging cruft comes
> out, it should only be a couple of hundred bytes of code.

I wouldn't want to see the kernel deal with all the possible mapping
configurations. Right now with everything getting remapped a couple
of times it makes it hard to follow what the final mapping will be.
Then we also have the core Linux PCI code that will try to fixup things
again, if it thinks it is needed. PPCBoot knows how the kernel wants
things setup so there should be no need to fix it up.

So I just want you to keep in mind the PCI bus fixup can be a config
option that can be built out if desired. It really shouldn't be tied
to the board itself, since it is also common to load in PPCboot into
Walnut boards.

Then there is always the case of hot-plugs, and the kernel will always
have to do that mapping there.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Matt Porter]

On Mon, Oct 07, 2002 at 10:21:36PM -0700, Andrew May wrote:
> I wouldn't want to see the kernel deal with all the possible mapping
> configurations. Right now with everything getting remapped a couple
> of times it makes it hard to follow what the final mapping will be.
> Then we also have the core Linux PCI code that will try to fixup things
> again, if it thinks it is needed. PPCBoot knows how the kernel wants
> things setup so there should be no need to fix it up.
>
> So I just want you to keep in mind the PCI bus fixup can be a config
> option that can be built out if desired. It really shouldn't be tied
> to the board itself, since it is also common to load in PPCboot into
> Walnut boards.

Yes, that's one area we need to keep in mind that isn't well-handled
yet.

> Then there is always the case of hot-plugs, and the kernel will always
> have to do that mapping there.

I think we are all more or less in agreement.  Let me review a couple
scenarios so we all recall why we have a few different methodologies.
Here are the basic systems:

1) Systems that have _perfect_ implementations of firmware that have
   everything set up correct and enumerate the PCI bus properly.
   In embedded, this may mean that things are setup up for your
   specific application though it might not

2) Systems that attempt to have _good_ implementation of firmware.
   General purpose systems that have OF trying to provide infos
   to OS fall in this category.  Unfortunately, they often have
   braindead mistakes necessitating fixups (since most of the infos
   are correct).

3) Systems that have _total crap_ implementations of firmware
   that have things incomplete, set up incorrectly, and can't
   enumerate themselves out of a paper bag.

The kernel should support all of these methodologies...here's why:

In case #1, we may have XYZ COTS PPC vendor who wants to support
Linux and actually implements firmware (PPCboot, whatever) that
works properly.  By doing things correctly, they earn themselves
the privilege of having a Linux port that can work across a family
of boards by simply varying their firmware port to provide the
correct per-board infos to a common port (e.g. pplus_setup.c,
but infos provided in registers)...a modern approach might use
PPCboot and a common family port would just parse birecs specifying
board specific things to do the right thing.  A board port in
this case shouldn't have to do a thing to chip mappings...it's
all correct...thus minimizing the work to maintain the port over
time.  A birec can even contain the PCI host address space range
in order to seamlessly provide the info across the family of
COTS board.

In case #2, we have something similar to #1 but the bitter reality
is that firmware is always doing something wrong in an attempt to
punish kernel people. :)  We have plenty of examples with Mac
and even the embedded-like Briq that provide OF with a vast amount
of infos...some of which are wrong.  So, we look at that the
incorrect cases and fix them up since they are the exception rather
than the rule.

In case #3, we have the all-to-familiar case for me.  Vendor XYZ
produces a worthless hunk of bits that they call firmware.  The
worst ones may be known under such friendly names as PowerBoot,
PMON/2000, and even OpenBIOS.  The problem here is that they do
so many things wrong that fixup like in case #2 becomes a pointless
pile of board-specific code.  We wish we have a case like #1 but
the reality is that it is extremely time-consuming to do a good
firmware port for a general purpose COTS board.  We also don't
control the firmware and may even have a vendor that doesn't
realize that not having good Linux support is going to kill
them eventually.  So, we follow the approach set by people
that have run into this all too often on COTS 7xx/74xx boards,
optional libraries of code.

We can (and already do) support all three methodologies.  The
important thing is to keep supporting them and make it easy
to handle case #3 on 4xx stuff.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Andrew May]

> On Mon, Oct 07, 2002 at 10:21:36PM -0700, Andrew May wrote:
>
> I think we are all more or less in agreement.  Let me review a couple
> scenarios so we all recall why we have a few different methodologies.
> Here are the basic systems:

....

> We can (and already do) support all three methodologies.  The
> important thing is to keep supporting them and make it easy
> to handle case #3 on 4xx stuff.

Yes, I think we agree on this, but I am not sure it is that
easy to currently handle case #1 on a 4xx system. Not too hard,
but I did have to pull out some code to get things to work.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Matt Porter]

On Tue, Oct 08, 2002 at 10:31:56AM -0700, Andrew May wrote:
> > On Mon, Oct 07, 2002 at 10:21:36PM -0700, Andrew May wrote:
> >
> > I think we are all more or less in agreement.  Let me review a couple
> > scenarios so we all recall why we have a few different methodologies.
> > Here are the basic systems:
>
> ....
>
> > We can (and already do) support all three methodologies.  The
> > important thing is to keep supporting them and make it easy
> > to handle case #3 on 4xx stuff.
>
> Yes, I think we agree on this, but I am not sure it is that
> easy to currently handle case #1 on a 4xx system. Not too hard,
> but I did have to pull out some code to get things to work.

Absolutely.  It'll get fixed as one of the pieces of this 4xx
reorg that Paul mentioned.  Specifically, this will be possible
once the flow-through is no longer through the common file.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Mon, Oct 07, 2002 at 10:21:36PM -0700, Andrew May wrote:
>
> On Tue, Oct 08, 2002 at 02:14:19PM +1000, David Gibson wrote:
> >
> > On Sun, Oct 06, 2002 at 06:31:20PM -0700, Matt Porter wrote:
> > >
> > > On Sat, Oct 05, 2002 at 10:23:14PM -0700, Andrew May wrote:
> > > >
> > > > It would be nice to have the option to let the boot loader set the
> > > > mapping. I have been happy with getting things done in PPCBoot and
> > > > ripping out the PCI scanning in the kernel.
> > >
> > > Yes, that's the ideal situation and going to what David and I would
> > > like to see makes that yet another simple fallout feature.
> > >
> > > Your custom port using a good implementation of PPCBoot simply
> > > would not call the pci macro init library nor would it use pci_auto.
> >
> > As Matt says, this would fall out naturally from a better control
> > structure.  Howeever, I tend to think that leaving things like this to
> > the bootloader/firmware is a bad idea:
>
> A full featured bootloader like PPCboot will need to setup the PCI bus
> to work with PCI devices, so it is not like it is always an extra burden
> on the bootloader or useless work.

That's all very well if you've got PPCboot, but lots of boards have
firmware which is, lets face it, shite.  The kernel has to be able to
deal with this case.  And since it has to deal with it for the case of
crappy firmware, is there any point turning it off for the case of
decent firmware?

> > The kernel has to know how PCI addresses are mapped anyway, so this
> > becomes yet another point at which the kernel and firmware are bound
> > together.  Why should the kernel have code to deal with umpteen
> > different cases of how PCI might have been set up, or not set up by
> > the firmware/bootloader, when it can just take control of the host
> > bridge and reprogram it how it wants?  Once the debugging cruft comes
> > out, it should only be a couple of hundred bytes of code.
>
> I wouldn't want to see the kernel deal with all the possible mapping
> configurations. Right now with everything getting remapped a couple
> of times it makes it hard to follow what the final mapping will be.
> Then we also have the core Linux PCI code that will try to fixup things
> again, if it thinks it is needed. PPCBoot knows how the kernel wants
> things setup so there should be no need to fix it up.

Agreed, with decent firmware there's no need.  But is there any point
turning the code off, since we have to have it anyway to support less
decent firmware.  This also means that the PCI setup for the kernel is
in one place - if for some reason we want to change the default
mapping, only the kernel need by altered, not PPCboot as well.

> So I just want you to keep in mind the PCI bus fixup can be a config
> option that can be built out if desired. It really shouldn't be tied
> to the board itself, since it is also common to load in PPCboot into
> Walnut boards.

That's easy - in fact the patch I posted before allows this (it won't
do anything if CONFIG_BIOS_FIXUP is not defined).

> Then there is always the case of hot-plugs, and the kernel will always
> have to do that mapping there.

Another reason that there is little to be gained by dropping fixup
support on platforms that don't need it.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Kenneth Johansson]

On Wed, 2002-10-09 at 03:58, David Gibson wrote:
>
> That's all very well if you've got PPCboot, but lots of boards have
> firmware which is, lets face it, shite.  The kernel has to be able to
> deal with this case.  And since it has to deal with it for the case of
> crappy firmware, is there any point turning it off for the case of
> decent firmware?

I think it's a good idea to isolate the kernel as much as possible from
the bootloader. This way you cut down on strange bugs that could depend
not on the kernel but on the firmware.

What do we really gain by trusting the firmware for anything but the
most basic stuff like some timing values and dram setup.


--
Kenneth Johansson
Ericsson AB                       Tel: +46 8 404 71 83
Borgafjordsgatan 9                Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@etx.ericsson.se


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: very minor 405GP and 405GPr PCI difference

[Allen Curtis]

> I think it's a good idea to isolate the kernel as much as possible from
> the bootloader. This way you cut down on strange bugs that could depend
> not on the kernel but on the firmware.
>
> What do we really gain by trusting the firmware for anything but the
> most basic stuff like some timing values and dram setup.

Now that we have argued ourselves into putting everything back into the
kernel because all firmware is evil, let me make a suggestion and provide a
couple examples.

Recommendation:
Setup that is related to the "hardware" configuration of the processor
should be done in firmware or at least not assumed to be wrong by the
kernel. Note: PCI memory translation windows do not fall into this criteria.

Examples (8260 related):
- clock routing, what clock source is connected to what peripheral
- clock/baud rate configuration, there is probably a reason why a clock
source was configured with a specific frequency
- I/O port configuration, this needs more thought, there are reasons why
pins are configured as in/out/open drain... (chip selects, reset controls,
etc)

I am sure that I could come up with other examples but hopefully you get my
point.  :)


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Andrew May]

Sorry about the late reply but I wanted to check the 2.5 tree and I haven't
been looking at it before.

On Wed, Oct 09, 2002 at 11:58:28AM +1000, David Gibson wrote:
>
> On Mon, Oct 07, 2002 at 10:21:36PM -0700, Andrew May wrote:
> >
> > A full featured bootloader like PPCboot will need to setup the PCI bus
> > to work with PCI devices, so it is not like it is always an extra burden
> > on the bootloader or useless work.
>
> That's all very well if you've got PPCboot, but lots of boards have
> firmware which is, lets face it, shite.  The kernel has to be able to
> deal with this case.  And since it has to deal with it for the case of
> crappy firmware, is there any point turning it off for the case of
> decent firmware?

Yes there is a point. I am working on a new custum PCI device and the
hardware guy gives me silly requests to try differnt PCI bus settings.
And I would much rather make the changes in my small quick PPCBoot build
rather than a full kernel build.

> > So I just want you to keep in mind the PCI bus fixup can be a config
> > option that can be built out if desired. It really shouldn't be tied
> > to the board itself, since it is also common to load in PPCboot into
> > Walnut boards.
>
> That's easy - in fact the patch I posted before allows this (it won't
> do anything if CONFIG_BIOS_FIXUP is not defined).

Well you patch is only part of the issue, it is the rest of
arch/ppc/kernel/4xx/ppc405_pci.c that gets pulled in every build with PCI,
that remapps everything in _find_bridges.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Fri, Oct 11, 2002 at 12:37:20PM -0700, Andrew May wrote:
>
> Sorry about the late reply but I wanted to check the 2.5 tree and I haven't
> been looking at it before.
>
> On Wed, Oct 09, 2002 at 11:58:28AM +1000, David Gibson wrote:
> >
> > On Mon, Oct 07, 2002 at 10:21:36PM -0700, Andrew May wrote:
> > >
> > > A full featured bootloader like PPCboot will need to setup the PCI bus
> > > to work with PCI devices, so it is not like it is always an extra burden
> > > on the bootloader or useless work.
> >
> > That's all very well if you've got PPCboot, but lots of boards have
> > firmware which is, lets face it, shite.  The kernel has to be able to
> > deal with this case.  And since it has to deal with it for the case of
> > crappy firmware, is there any point turning it off for the case of
> > decent firmware?
>
> Yes there is a point. I am working on a new custum PCI device and the
> hardware guy gives me silly requests to try differnt PCI bus settings.
> And I would much rather make the changes in my small quick PPCBoot build
> rather than a full kernel build.

Well, for a fair few of the settings - the mapping addresses at least,
the kernel has to know what the settings are to workk, even if PPCBoot
has already set things up.

Incidentally the Makefiles in 2.5 are greatly improved, so kernel
builds with small changes are often a lot less painful than they used
to be.

> > > So I just want you to keep in mind the PCI bus fixup can be a config
> > > option that can be built out if desired. It really shouldn't be tied
> > > to the board itself, since it is also common to load in PPCboot into
> > > Walnut boards.
> >
> > That's easy - in fact the patch I posted before allows this (it won't
> > do anything if CONFIG_BIOS_FIXUP is not defined).
>
> Well you patch is only part of the issue, it is the rest of
> arch/ppc/kernel/4xx/ppc405_pci.c that gets pulled in every build with PCI,
> that remapps everything in _find_bridges.

True, but it's an even smaller subset of platforms that could do
without that code.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: very minor 405GP and 405GPr PCI difference

[Allen Curtis]

> As Matt says, this would fall out naturally from a better control
> structure.  Howeever, I tend to think that leaving things like this to
> the bootloader/firmware is a bad idea:
>
> The kernel has to know how PCI addresses are mapped anyway, so this
> becomes yet another point at which the kernel and firmware are bound
> together.  Why should the kernel have code to deal with umpteen
> different cases of how PCI might have been set up, or not set up by
> the firmware/bootloader, when it can just take control of the host
> bridge and reprogram it how it wants?  Once the debugging cruft comes
> out, it should only be a couple of hundred bytes of code.

I believe that there are many cases where the kernel code is much too
aggressive with configuration. Personally I believe that all BIOS code
should totally initialize the processor state so you always have a known
starting point. (whether you boot Linux or not) Many times I have had to
track down where the kernel thinks it "knows" the proper configuration and
unravels the work done by the BIOS. I am not sure how to solve this problem
but I believe the kernel should attempt to detect and use a configuration
before reconfiguring any hardware. I have implemented this technique in our
UART and Ethernet configuration stuff on the 8260 with good success.

Only a suggestion...


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Matt Porter]

On Mon, Oct 07, 2002 at 11:19:31PM -0700, Allen Curtis wrote:
> > As Matt says, this would fall out naturally from a better control
> > structure.  Howeever, I tend to think that leaving things like this to
> > the bootloader/firmware is a bad idea:
> >
> > The kernel has to know how PCI addresses are mapped anyway, so this
> > becomes yet another point at which the kernel and firmware are bound
> > together.  Why should the kernel have code to deal with umpteen
> > different cases of how PCI might have been set up, or not set up by
> > the firmware/bootloader, when it can just take control of the host
> > bridge and reprogram it how it wants?  Once the debugging cruft comes
> > out, it should only be a couple of hundred bytes of code.
>
> I believe that there are many cases where the kernel code is much too
> aggressive with configuration. Personally I believe that all BIOS code
> should totally initialize the processor state so you always have a known
> starting point. (whether you boot Linux or not) Many times I have had to
> track down where the kernel thinks it "knows" the proper configuration and
> unravels the work done by the BIOS. I am not sure how to solve this problem
> but I believe the kernel should attempt to detect and use a configuration
> before reconfiguring any hardware. I have implemented this technique in our
> UART and Ethernet configuration stuff on the 8260 with good success.
>
> Only a suggestion...

This is a good time to reiterate that *if* your processor family
code is designed with the proper flow, you can decide how to approach
this on a case-by-case basis.

I don't want to comment to heavily on 826x stuffs but I think the
approach may well be the by-product of Dan's methodology of a
minimal bootrom, thus necessitating chip-level setup.  The
code clearly follows the "flow through a common file" approach
which tends to make per-board/system changes a bit hacky if you
start having 8260-based systems that have attributes that are
less alike.  The approach is fine if every system using a particular
SoC is very similar (i.e. not much external I/O or custom strappings).

I laid out the three cases of firmware/kernel coupling that I
know of in a separate post.  I think you'll find that there
are many cases where it is not feasible or possible to control
the firmware.  Obviously, we would all like to have the firmware
be 100% correct but that is not reality.  In some ways, you folks
doing custom board bringup for you application have the ideal
situation compared to dealing with reference/COTS boards with
blackbox firmware.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Mon, Oct 07, 2002 at 11:19:31PM -0700, Allen Curtis wrote:
>
> > As Matt says, this would fall out naturally from a better control
> > structure.  Howeever, I tend to think that leaving things like this to
> > the bootloader/firmware is a bad idea:
> >
> > The kernel has to know how PCI addresses are mapped anyway, so this
> > becomes yet another point at which the kernel and firmware are bound
> > together.  Why should the kernel have code to deal with umpteen
> > different cases of how PCI might have been set up, or not set up by
> > the firmware/bootloader, when it can just take control of the host
> > bridge and reprogram it how it wants?  Once the debugging cruft comes
> > out, it should only be a couple of hundred bytes of code.
>
> I believe that there are many cases where the kernel code is much too
> aggressive with configuration. Personally I believe that all BIOS code
> should totally initialize the processor state so you always have a known
> starting point. (whether you boot Linux or not) Many times I have had to
> track down where the kernel thinks it "knows" the proper configuration and
> unravels the work done by the BIOS. I am not sure how to solve this problem
> but I believe the kernel should attempt to detect and use a configuration
> before reconfiguring any hardware. I have implemented this technique in our
> UART and Ethernet configuration stuff on the 8260 with good success.

This is a nice idea in principle, but IMO it is flawed in practice.
The unfortunate truth is that firmwares are all too frequently broken
in one or more ways (this is not only true for embedded - think APM or
ACPI, or the many buggy OF implementations).  So we need code to
handle (at least some) cases where the firmware setup is incomplete,
or the firmware provides incorrect information.  Worse, in many cases
a new revision of the firmware will remove some bugs but add some new
ones - which mean workarounds tailored to doing a minimum fixup for a
particular BIOS are very fragile.

Given that, how much is really to be gained by carefully tailoring a
kernel to the brokenness or lack thereof of a particular platform's
firmware - as opposed to just always handling the setup ourselves,
putting the device into a known state.

Incidentally the case of a UART is quite different from PCI: you can
use a UART without knowing how it is configured, that way you can
leave the selection of baud rate (for example) up to firmware
configuration and just use its setup - i.e. in this case there is a
tangible benefit from leaving the work up to the firmware.  In the
case of PCI we have to know what the windows are in order to use the
device, so we must know precisely how the firmware has set the bridge
up, in which case why don't we just set it up that way ourselves.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Todd Poynor]

David Gibson wrote (regarding Rainier PMM1 bios_fixup in MVL):

> Well, it may be in a different place, but it looks like it has the
> same problem.  It is still establishing a PCI window at PLB address
> 0x80000000, which is the same address used for the PMM0 window - or is
> that also different in the MV kernel?
>
> I'd be trying to work out what that mapping's actually for, first.  I
> still can't see how it can possibly work - if there are overlapping
> PMM windows, what actually happens to accesses in that (PLB) range?

Yes, it looks like MVL only sets up the one window using PMM1... we've
started an effort to have the Rainier-knowedgeable folks get the code
sync'ed up with the community and this should happen soon.


--
Todd


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[David Gibson]

On Tue, Oct 22, 2002 at 02:55:47PM -0700, Todd Poynor wrote:
>
> David Gibson wrote (regarding Rainier PMM1 bios_fixup in MVL):
>
> >Well, it may be in a different place, but it looks like it has the
> >same problem.  It is still establishing a PCI window at PLB address
> >0x80000000, which is the same address used for the PMM0 window - or is
> >that also different in the MV kernel?
> >
> >I'd be trying to work out what that mapping's actually for, first.  I
> >still can't see how it can possibly work - if there are overlapping
> >PMM windows, what actually happens to accesses in that (PLB) range?
>
> Yes, it looks like MVL only sets up the one window using PMM1... we've
> started an effort to have the Rainier-knowedgeable folks get the code
> sync'ed up with the community and this should happen soon.

Hang on, so just to clarify - MVL sets up PMM1 with the code you
posted, but doesn't set up PMM0 anywhere?  From my reading of that
code, it sets up a window at the same address as the "standard"
(Walnut) mapping, except that it is only 128kB instead of 1GB.  Is
there a reason that Rainier must have such a small window?

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: very minor 405GP and 405GPr PCI difference

[Ralph Blach]

The MontVista Linux disables disable PMM1, which is correct.  It then
writes a 0 PMM0 enable bit,
which on the 405gp is OK because the enable bit is hardwired to a 1.  ON
the 405gpr, the bit is writeable and
this then disables PMM0.  The correct action is to write a 1 to the PMM0
enable bit on both the 405 and the 405gpr
and the problem is solved.


Chip

David Gibson <david@gibson.dropbear.id.au>@lists.linuxppc.org on 10/23/2002
12:08:50 AM

Sent by:    owner-linuxppc-embedded@lists.linuxppc.org


To:    Todd Poynor <tpoynor@mvista.com>
cc:    linuxppc-embedded@lists.linuxppc.org
Subject:    Re: very minor 405GP and 405GPr PCI difference




On Tue, Oct 22, 2002 at 02:55:47PM -0700, Todd Poynor wrote:
>
> David Gibson wrote (regarding Rainier PMM1 bios_fixup in MVL):
>
> >Well, it may be in a different place, but it looks like it has the
> >same problem.  It is still establishing a PCI window at PLB address
> >0x80000000, which is the same address used for the PMM0 window - or is
> >that also different in the MV kernel?
> >
> >I'd be trying to work out what that mapping's actually for, first.  I
> >still can't see how it can possibly work - if there are overlapping
> >PMM windows, what actually happens to accesses in that (PLB) range?
>
> Yes, it looks like MVL only sets up the one window using PMM1... we've
> started an effort to have the Rainier-knowedgeable folks get the code
> sync'ed up with the community and this should happen soon.

Hang on, so just to clarify - MVL sets up PMM1 with the code you
posted, but doesn't set up PMM0 anywhere?  From my reading of that
code, it sets up a window at the same address as the "standard"
(Walnut) mapping, except that it is only 128kB instead of 1GB.  Is
there a reason that Rainier must have such a small window?

--
David Gibson                  | For every complex problem there is a
david@gibson.dropbear.id.au   | solution which is simple, neat and
    | wrong.
http://www.ozlabs.org/people/dgibson


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/