* [PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
From: Vitaly Bordug @ 2005-11-16 12:04 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded list
This adds board-specific files needed to utilize fs_enet Ethernet driver
for MPC885ADS and MPC866ADS.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
arch/ppc/Kconfig | 47 ++++
arch/ppc/platforms/Makefile | 2
arch/ppc/platforms/fads.h | 2
arch/ppc/platforms/mpc866ads_setup.c | 290 ++++++++++++++++++++++++
arch/ppc/platforms/mpc885ads_setup.c | 408 ++++++++++++++++++++++++++++++++++
5 files changed, 748 insertions(+), 1 deletions(-)
create mode 100644 arch/ppc/platforms/mpc866ads_setup.c
create mode 100644 arch/ppc/platforms/mpc885ads_setup.c
applies-to: f358a802ba9f62bb4777d5f626f2972d1b0fa43b
4c4f454bd8e79fd67bc86aa9a22604f66d682d3b
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
index 8fa51b0..8e6fcb2 100644
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -506,6 +506,53 @@ config WINCEPT
endchoice
+menu "Freescale Ethernet driver platform-specific options"
+ depends on FS_ENET
+
+ config MPC8xx_SECOND_ETH
+ bool "Second Ethernet channel"
+ depends on (MPC885ADS || MPC86XADS)
+ default y
+ help
+ This enables support for second Ethernet on MPC885ADS and MPC86xADS boards.
+ The latter will use SCC1, for 885ADS you can select it below.
+
+ choice
+ prompt "Second Ethernet channel"
+ depends on MPC8xx_SECOND_ETH
+ default MPC8xx_SECOND_ETH_FEC2
+
+ config MPC8xx_SECOND_ETH_FEC2
+ bool "FEC2"
+ depends on MPC885ADS
+ help
+ Enable FEC2 to serve as 2-nd Ethernet channel. Note that SMC2
+ (often 2-nd UART) will not work if this is enabled.
+
+ config MPC8xx_SECOND_ETH_SCC1
+ bool "SCC1"
+ depends on MPC86XADS
+ select MPC8xx_SCC_ENET_FIXED
+ help
+ Enable SCC1 to serve as 2-nd Ethernet channel. Note that SMC1
+ (often 1-nd UART) will not work if this is enabled.
+
+ config MPC8xx_SECOND_ETH_SCC3
+ bool "SCC3"
+ depends on MPC885ADS
+ help
+ Enable SCC3 to serve as 2-nd Ethernet channel. Note that SMC1
+ (often 1-nd UART) will not work if this is enabled.
+
+ endchoice
+
+ config MPC8xx_SCC_ENET_FIXED
+ depends on MPC8xx_SECOND_ETH_SCC
+ default n
+ bool "Use fixed MII-less mode for SCC Ethernet"
+
+endmenu
+
choice
prompt "Machine Type"
depends on 6xx || POWER3 || POWER4
diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
index 7c5cdab..cce6487 100644
--- a/arch/ppc/platforms/Makefile
+++ b/arch/ppc/platforms/Makefile
@@ -45,6 +45,8 @@ obj-$(CONFIG_SBC82xx) += sbc82xx.o
obj-$(CONFIG_SPRUCE) += spruce.o
obj-$(CONFIG_LITE5200) += lite5200.o
obj-$(CONFIG_EV64360) += ev64360.o
+obj-$(CONFIG_MPC86XADS) += mpc866ads_setup.o
+obj-$(CONFIG_MPC885ADS) += mpc885ads_setup.o
ifeq ($(CONFIG_SMP),y)
obj-$(CONFIG_PPC_PMAC) += pmac_smp.o
diff --git a/arch/ppc/platforms/fads.h b/arch/ppc/platforms/fads.h
index a48fb8d..e1c0b1b 100644
--- a/arch/ppc/platforms/fads.h
+++ b/arch/ppc/platforms/fads.h
@@ -112,7 +112,7 @@
/* CPM Ethernet through SCC1 or SCC2 */
-#ifdef CONFIG_SCC1_ENET /* Probably 860 variant */
+#if defined(CONFIG_SCC1_ENET) || defined(CONFIG_MPC8xx_SECOND_ETH_SCC1) /* Probably 860
variant */
/* Bits in parallel I/O port registers that have to be set/cleared
* to configure the pins for SCC1 use.
* TCLK - CLK1, RCLK - CLK2.
diff --git a/arch/ppc/platforms/mpc866ads_setup.c b/arch/ppc/platforms/mpc866ads_setup.c
new file mode 100644
index 0000000..6ffdb0e
--- /dev/null
+++ b/arch/ppc/platforms/mpc866ads_setup.c
@@ -0,0 +1,290 @@
+/*arch/ppc/platforms/mpc885ads-setup.c
+ *
+ * Platform setup for the Freescale mpc885ads board
+ *
+ * Vitaly Bordug <vbordug@ru.mvista.com>
+ *
+ * Copyright 2005 MontaVista Software Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/param.h>
+#include <linux/string.h>
+#include <linux/ioport.h>
+#include <linux/device.h>
+
+#include <linux/fs_enet_pd.h>
+#include <linux/mii.h>
+
+#include <asm/delay.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/page.h>
+#include <asm/processor.h>
+#include <asm/system.h>
+#include <asm/time.h>
+#include <asm/ppcboot.h>
+#include <asm/8xx_immap.h>
+#include <asm/commproc.h>
+#include <asm/ppc_sys.h>
+#include <asm/mpc8xx.h>
+
+extern unsigned char __res[];
+
+/* access ports */
+#define setbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) | (_v))
+#define clrbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) & ~(_v))
+
+#define setbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) | (_v))
+#define clrbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) & ~(_v))
+
+static struct fs_mii_bus_info fec_mii_bus_info = {
+ .method = fsmii_fec,
+ .id = 0,
+};
+
+static struct fs_mii_bus_info scc_mii_bus_info = {
+ .method = fsmii_fixed,
+ .id = 0,
+ .i.fixed.speed = 10,
+ .i.fixed.duplex = 0,
+};
+
+static struct fs_platform_info mpc8xx_fec_pdata[] = {
+ {
+ .rx_ring = 128,
+ .tx_ring = 16,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = 15,
+ .phy_irq = -1,
+
+ .use_rmii = 0,
+
+ .bus_info = &fec_mii_bus_info,
+ }
+};
+
+static struct fs_platform_info mpc8xx_scc_pdata = {
+ .rx_ring = 64,
+ .tx_ring = 8,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = -1,
+ .phy_irq = -1,
+
+ .bus_info = &scc_mii_bus_info,
+};
+
+static void mpc866_nonplatform_device_init(void)
+{
+ volatile cpm8xx_t *cp = cpmp;
+ unsigned *bcsr_io;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR1\n");
+ return;
+ }
+#ifdef CONFIG_SERIAL_CPM_SMC1
+ cp->cp_simode &= ~(0xe0000000 >> 17); /* brg1 */
+ out_be32(bcsr_io, in_be32(bcsr_io) & ~(0x80000000 >> 7));
+#else
+ out_be32(bcsr_io, in_be32(bcsr_io) | (0x80000000 >> 7));
+ cp->cp_pbpar &= ~(0x000000c0);
+ cp->cp_pbdir |= 0x000000c0;
+ cp->cp_smc[0].smc_smcmr = 0;
+ cp->cp_smc[0].smc_smce = 0;
+#endif
+
+#ifdef CONFIG_SERIAL_CPM_SMC2
+ cp->cp_simode &= ~(0xe0000000 >> 1);
+ cp->cp_simode |= (0x20000000 >> 1); /* brg2 */
+ out_be32(bcsr_io, in_be32(bcsr_io) & ~(0x80000000 >> 13));
+#else
+ out_be32(bcsr_io, in_be32(bcsr_io) | (0x80000000 >> 13));
+ cp->cp_pbpar &= ~(0x00000c00);
+ cp->cp_pbdir |= 0x00000c00;
+ cp->cp_smc[1].smc_smcmr = 0;
+ cp->cp_smc[1].smc_smce = 0;
+#endif
+ iounmap(bcsr_io);
+}
+
+static void setup_fec1_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+
+ setbits16(immap->im_ioport.iop_pdpar, 0x1fff);
+ setbits16(immap->im_ioport.iop_pddir, 0x1fff);
+}
+
+static void setup_scc1_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+ unsigned *bcsr_io;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR1\n");
+ return;
+ }
+
+ /* Enable the PHY.
+ */
+ out_be32(bcsr_io, in_be32(bcsr_io) & ~BCSR1_ETHEN);
+
+ /* Configure port A pins for Txd and Rxd.
+ */
+ /* Disable receive and transmit in case EPPC-Bug started it.
+ */
+ setbits16(immap->im_ioport.iop_papar, PA_ENET_RXD | PA_ENET_TXD);
+ clrbits16(immap->im_ioport.iop_padir, PA_ENET_RXD | PA_ENET_TXD);
+ clrbits16(immap->im_ioport.iop_paodr, PA_ENET_TXD);
+
+ /* Configure port C pins to enable CLSN and RENA.
+ */
+ clrbits16(immap->im_ioport.iop_pcpar, PC_ENET_CLSN | PC_ENET_RENA);
+ clrbits16(immap->im_ioport.iop_pcdir, PC_ENET_CLSN | PC_ENET_RENA);
+ setbits16(immap->im_ioport.iop_pcso, PC_ENET_CLSN | PC_ENET_RENA);
+ /* Configure port A for TCLK and RCLK.
+ */
+ setbits16(immap->im_ioport.iop_papar, PA_ENET_TCLK | PA_ENET_RCLK);
+ clrbits16(immap->im_ioport.iop_padir, PA_ENET_TCLK | PA_ENET_RCLK);
+ clrbits32(immap->im_cpm.cp_pbpar, PB_ENET_TENA);
+ clrbits32(immap->im_cpm.cp_pbdir, PB_ENET_TENA);
+
+ /* Configure Serial Interface clock routing.
+ * First, clear all SCC bits to zero, then set the ones we want.
+ */
+ clrbits32(immap->im_cpm.cp_sicr, SICR_ENET_MASK);
+ setbits32(immap->im_cpm.cp_sicr, SICR_ENET_CLKRT);
+
+ /* In the original SCC enet driver the following code is placed at the end of the
initialization */
+ setbits32(immap->im_cpm.cp_pbpar, PB_ENET_TENA);
+ setbits32(immap->im_cpm.cp_pbdir, PB_ENET_TENA);
+
+}
+
+static void mpc866ads_fixup_enet_pdata(struct platform_device *pdev,
+ int fs_no)
+{
+ struct fs_platform_info *fpi = pdev->dev.platform_data;
+
+ volatile cpm8xx_t *cp;
+ bd_t *bd = (bd_t *) __res;
+ char *e;
+ int i;
+
+ /* Get pointer to Communication Processor */
+ cp = cpmp;
+ switch (fs_no) {
+ case fsid_fec1:
+ fpi = &mpc8xx_fec_pdata[0];
+ fpi->init_ioports = &setup_fec1_ioports;
+
+ break;
+ case fsid_scc1:
+ fpi = &mpc8xx_scc_pdata;
+ fpi->init_ioports = &setup_scc1_ioports;
+
+ break;
+ default:
+ break;
+ }
+
+ pdev->dev.platform_data = fpi;
+ fpi->fs_no = fs_no;
+
+ e = (unsigned char *)&bd->bi_enetaddr;
+ for (i = 0; i < 6; i++)
+ fpi->macaddr[i] = *e++;
+
+ fpi->macaddr[5 - pdev->id]++;
+
+}
+
+static void mpc866ads_fixup_fec_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for FEC devices only */
+ if (strcmp(pdev->name, "fsl-cpm-fec"))
+ return;
+ mpc866ads_fixup_enet_pdata(pdev, fsid_fec1 + pdev->id - 1);
+}
+
+static void mpc866ads_fixup_scc_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for SCC devices only */
+ if (strcmp(pdev->name, "fsl-cpm-scc"))
+ return;
+
+ mpc866ads_fixup_enet_pdata(pdev, fsid_scc1 + pdev->id - 1);
+}
+
+static int mpc866ads_platform_notify(struct device *dev)
+{
+ static struct {
+ const char *bus_id;
+ void (*rtn) (struct platform_device * pdev, int idx);
+ } dev_map[] = {
+ {
+ "fsl-cpm-fec", mpc866ads_fixup_fec_enet_pdata}, {
+ "fsl-cpm-scc", mpc866ads_fixup_scc_enet_pdata},};
+ struct platform_device *pdev;
+ int i, j, idx;
+ const char *s;
+ if (dev && dev->bus_id)
+ for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
+ idx = -1;
+
+ if ((s = strrchr(dev->bus_id, '.')) != NULL)
+ idx = (int)simple_strtol(s + 1, NULL, 10);
+ else
+ s = dev->bus_id;
+ j = s - dev->bus_id;
+ if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
+ pdev =
+ container_of(dev, struct platform_device,
+ dev);
+ dev_map[i].rtn(pdev, idx);
+ }
+ }
+ return 0;
+}
+
+int __init mpc866ads_init(void)
+{
+ printk(KERN_NOTICE "mpc866ads: Init\n");
+
+ mpc866_nonplatform_device_init();
+ platform_notify = mpc866ads_platform_notify;
+
+ identify_ppc_sys_by_name(BOARD_CHIP_NAME);
+
+ ppc_sys_device_remove(MPC8xx_CPM_FEC2);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC3);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC2);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC4);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC1);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC2);
+
+ return 0;
+}
+
+arch_initcall(mpc866ads_init);
diff --git a/arch/ppc/platforms/mpc885ads_setup.c b/arch/ppc/platforms/mpc885ads_setup.c
new file mode 100644
index 0000000..37c5c7b
--- /dev/null
+++ b/arch/ppc/platforms/mpc885ads_setup.c
@@ -0,0 +1,408 @@
+/*arch/ppc/platforms/mpc885ads-setup.c
+ *
+ * Platform setup for the Freescale mpc885ads board
+ *
+ * Vitaly Bordug <vbordug@ru.mvista.com>
+ *
+ * Copyright 2005 MontaVista Software Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/param.h>
+#include <linux/string.h>
+#include <linux/ioport.h>
+#include <linux/device.h>
+
+#include <linux/fs_enet_pd.h>
+#include <linux/mii.h>
+
+#include <asm/delay.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/page.h>
+#include <asm/processor.h>
+#include <asm/system.h>
+#include <asm/time.h>
+#include <asm/ppcboot.h>
+#include <asm/8xx_immap.h>
+#include <asm/commproc.h>
+#include <asm/ppc_sys.h>
+
+extern unsigned char __res[];
+
+/* access ports */
+#define setbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) | (_v))
+#define clrbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) & ~(_v))
+
+#define setbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) | (_v))
+#define clrbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) & ~(_v))
+
+void __init mpc885ads_scc_phy_init(char);
+
+static struct fs_mii_bus_info fec_mii_bus_info = {
+ .method = fsmii_fec,
+ .id = 0,
+};
+
+static struct fs_mii_bus_info scc_mii_bus_info = {
+#ifdef CONFIG_SCC_ENET_8xx_FIXED
+ .method = fsmii_fixed,
+#else
+ .method = fsmii_fec,
+#endif
+
+ .id = 0,
+};
+
+static struct fs_platform_info mpc8xx_fec_pdata[] = {
+ {
+ .rx_ring = 128,
+ .tx_ring = 16,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = 0,
+ .phy_irq = SIU_IRQ7,
+
+ .bus_info = &fec_mii_bus_info,
+ }, {
+ .rx_ring = 128,
+ .tx_ring = 16,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = 1,
+ .phy_irq = SIU_IRQ7,
+
+ .bus_info = &fec_mii_bus_info,
+ }
+};
+
+static struct fs_platform_info mpc8xx_scc_pdata = {
+ .rx_ring = 64,
+ .tx_ring = 8,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = 2,
+#ifdef CONFIG_MPC8xx_SCC_ENET_FIXED
+ .phy_irq = -1,
+#else
+ .phy_irq = SIU_IRQ7,
+#endif
+
+ .bus_info = &scc_mii_bus_info,
+};
+
+static void mpc885_nonplatform_device_init(void)
+{
+ volatile cpm8xx_t *cp = cpmp;
+ unsigned *bcsr_io;
+
+#ifdef CONFIG_FS_ENET
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+#endif
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR\n");
+ return;
+ }
+#ifdef CONFIG_SERIAL_CPM_SMC1
+ cp->cp_simode &= ~(0xe0000000 >> 17); /* brg1 */
+ out_be32(bcsr_io, in_be32(bcsr_io) & ~BCSR1_RS232EN_1);
+#else
+ out_be32(bcsr_io, in_be32(bcsr_io) | BCSR1_RS232EN_1);
+ cp->cp_smc[0].smc_smcmr = 0;
+ cp->cp_smc[0].smc_smce = 0;
+#endif
+
+#ifdef CONFIG_SERIAL_CPM_SMC2
+ cp->cp_simode &= ~(0xe0000000 >> 1);
+ cp->cp_simode |= (0x20000000 >> 1); /* brg2 */
+ out_be32(bcsr_io, in_be32(bcsr_io) & ~BCSR1_RS232EN_2);
+#else
+ out_be32(bcsr_io, in_be32(bcsr_io) | BCSR1_RS232EN_2);
+ cp->cp_smc[1].smc_smcmr = 0;
+ cp->cp_smc[1].smc_smce = 0;
+#endif
+ iounmap(bcsr_io);
+
+#ifdef CONFIG_FS_ENET
+ /* use MDC for MII (common) */
+ setbits16(immap->im_ioport.iop_pdpar, 0x0080);
+ clrbits16(immap->im_ioport.iop_pddir, 0x0080);
+#endif
+}
+
+static void setup_fec1_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+
+ /* configure FEC1 pins */
+ setbits16(immap->im_ioport.iop_papar, 0xf830);
+ setbits16(immap->im_ioport.iop_padir, 0x0830);
+ clrbits16(immap->im_ioport.iop_padir, 0xf000);
+ setbits32(immap->im_cpm.cp_pbpar, 0x00001001);
+
+ clrbits32(immap->im_cpm.cp_pbdir, 0x00001001);
+ setbits16(immap->im_ioport.iop_pcpar, 0x000c);
+ clrbits16(immap->im_ioport.iop_pcdir, 0x000c);
+ setbits32(immap->im_cpm.cp_pepar, 0x00000003);
+
+ setbits32(immap->im_cpm.cp_pedir, 0x00000003);
+ clrbits32(immap->im_cpm.cp_peso, 0x00000003);
+ clrbits32(immap->im_cpm.cp_cptr, 0x00000100);
+}
+
+static void setup_fec2_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+
+ /* configure FEC2 pins */
+ setbits32(immap->im_cpm.cp_pepar, 0x0003fffc);
+ setbits32(immap->im_cpm.cp_pedir, 0x0003fffc);
+ setbits32(immap->im_cpm.cp_peso, 0x00037800);
+ clrbits32(immap->im_cpm.cp_peso, 0x000087fc);
+ clrbits32(immap->im_cpm.cp_cptr, 0x00000080);
+}
+
+static void setup_scc3_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+ unsigned *bcsr_io;
+
+ bcsr_io = ioremap(BCSR_ADDR, BCSR_SIZE);
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR\n");
+ return;
+ }
+
+ /* Enable the PHY.
+ */
+ out_be32(bcsr_io + 4, in_be32(bcsr_io + 4) | BCSR4_ETH10_RST);
+
+ /* Configure port A pins for Txd and Rxd.
+ */
+ setbits16(immap->im_ioport.iop_papar, PA_ENET_RXD | PA_ENET_TXD);
+ clrbits16(immap->im_ioport.iop_padir, PA_ENET_RXD | PA_ENET_TXD);
+
+ /* Configure port C pins to enable CLSN and RENA.
+ */
+ clrbits16(immap->im_ioport.iop_pcpar, PC_ENET_CLSN | PC_ENET_RENA);
+ clrbits16(immap->im_ioport.iop_pcdir, PC_ENET_CLSN | PC_ENET_RENA);
+ setbits16(immap->im_ioport.iop_pcso, PC_ENET_CLSN | PC_ENET_RENA);
+
+ /* Configure port E for TCLK and RCLK.
+ */
+ setbits32(immap->im_cpm.cp_pepar, PE_ENET_TCLK | PE_ENET_RCLK);
+ clrbits32(immap->im_cpm.cp_pepar, PE_ENET_TENA);
+ clrbits32(immap->im_cpm.cp_pedir,
+ PE_ENET_TCLK | PE_ENET_RCLK | PE_ENET_TENA);
+ clrbits32(immap->im_cpm.cp_peso, PE_ENET_TCLK | PE_ENET_RCLK);
+ setbits32(immap->im_cpm.cp_peso, PE_ENET_TENA);
+
+ /* Configure Serial Interface clock routing.
+ * First, clear all SCC bits to zero, then set the ones we want.
+ */
+ clrbits32(immap->im_cpm.cp_sicr, SICR_ENET_MASK);
+ setbits32(immap->im_cpm.cp_sicr, SICR_ENET_CLKRT);
+
+ /* Disable Rx and Tx. SMC1 sshould be stopped if SCC3 eternet are used.
+ */
+ immap->im_cpm.cp_smc[0].smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
+ /* On the MPC885ADS SCC ethernet PHY is initialized in the full duplex mode
+ * by H/W setting after reset. SCC ethernet controller support only half duplex.
+ * This discrepancy of modes causes a lot of carrier lost errors.
+ */
+
+ /* In the original SCC enet driver the following code is placed at the end of the
initialization */
+ setbits32(immap->im_cpm.cp_pepar, PE_ENET_TENA);
+ clrbits32(immap->im_cpm.cp_pedir, PE_ENET_TENA);
+ setbits32(immap->im_cpm.cp_peso, PE_ENET_TENA);
+
+ out_be32(bcsr_io + 1, in_be32(bcsr_io + 1) | BCSR1_ETHEN);
+ iounmap(bcsr_io);
+}
+
+static void mpc885ads_fixup_enet_pdata(struct platform_device *pdev,
+ int fs_no)
+{
+ struct fs_platform_info *fpi = pdev->dev.platform_data;
+
+ volatile cpm8xx_t *cp;
+ bd_t *bd = (bd_t *) __res;
+ char *e;
+ int i;
+
+ /* Get pointer to Communication Processor */
+ cp = cpmp;
+ switch (fs_no) {
+ case fsid_fec1:
+ fpi = &mpc8xx_fec_pdata[0];
+ fpi->init_ioports = &setup_fec1_ioports;
+ break;
+ case fsid_fec2:
+ fpi = &mpc8xx_fec_pdata[1];
+ fpi->init_ioports = &setup_fec2_ioports;
+ break;
+ case fsid_scc3:
+ fpi = &mpc8xx_scc_pdata;
+ fpi->init_ioports = &setup_scc3_ioports;
+ mpc885ads_scc_phy_init(fpi->phy_addr);
+ break;
+ default:
+ break;
+ }
+
+ pdev->dev.platform_data = fpi;
+ fpi->fs_no = fs_no;
+
+ e = (unsigned char *)&bd->bi_enetaddr;
+ for (i = 0; i < 6; i++)
+ fpi->macaddr[i] = *e++;
+
+ fpi->macaddr[5 - pdev->id]++;
+
+}
+
+static void mpc885ads_fixup_fec_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for FEC devices only */
+ if (!strstr(pdev->name, "fsl-cpm-fec"))
+ return;
+ mpc885ads_fixup_enet_pdata(pdev, fsid_fec1 + pdev->id - 1);
+}
+
+static void __init mpc885ads_fixup_scc_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for SCC devices only */
+ if (!strstr(pdev->name, "fsl-cpm-scc"))
+ return;
+
+ mpc885ads_fixup_enet_pdata(pdev, fsid_scc1 + pdev->id - 1);
+}
+
+/* SCC ethernet controller does not have MII management channel. FEC1 MII
+ * channel is used to communicate with the 10Mbit PHY.
+ */
+
+#define MII_ECNTRL_PINMUX 0x4
+#define FEC_ECNTRL_PINMUX 0x00000004
+#define FEC_RCNTRL_MII_MODE 0x00000004
+
+/* Make MII read/write commands.
+ */
+#define mk_mii_write(REG, VAL, PHY_ADDR) (0x50020000 | (((REG) & 0x1f) << 18) | \
+ ((VAL) & 0xffff) | ((PHY_ADDR) << 23))
+
+static void mpc885ads_scc_phy_init(char phy_addr)
+{
+ volatile immap_t *immap;
+ volatile fec_t *fecp;
+ bd_t *bd;
+
+ bd = (bd_t *) __res;
+ immap = (immap_t *) IMAP_ADDR; /* pointer to internal registers */
+ fecp = &(immap->im_cpm.cp_fec);
+
+ /* Enable MII pins of the FEC1
+ */
+ setbits16(immap->im_ioport.iop_pdpar,0x0080);
+ clrbits16(immap->im_ioport.iop_pddir,0x0080);
+ /* Set MII speed to 2.5 MHz
+ */
+ out_be32(&fecp->fec_mii_speed,
+ ((((bd->bi_intfreq + 4999999) / 2500000) / 2) & 0x3F) << 1);
+
+ /* Enable FEC pin MUX
+ */
+ setbits32(fecp->fec_ecntrl, MII_ECNTRL_PINMUX);
+ setbits32(fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
+
+ out_be32(&fecp->fec_mii_data, mk_mii_write(MII_BMCR, BMCR_ISOLATE, phy_addr));
+ udelay(100);
+ out_be32(&fecp->fec_mii_data,
+ mk_mii_write(MII_ADVERTISE,
+ ADVERTISE_10HALF | ADVERTISE_CSMA,phy_addr));
+ udelay(100);
+
+ /* Disable FEC MII settings
+ */
+ clrbits32(fecp->fec_ecntrl, MII_ECNTRL_PINMUX);
+ clrbits32(fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
+ out_be32(&fecp->fec_mii_speed, 0);
+}
+
+static int mpc885ads_platform_notify(struct device *dev)
+{
+ static struct {
+ const char *bus_id;
+ void (*rtn) (struct platform_device * pdev, int idx);
+ } dev_map[] = {
+ {
+ "fsl-cpm-fec", mpc885ads_fixup_fec_enet_pdata}, {
+ "fsl-cpm-scc", mpc885ads_fixup_scc_enet_pdata},};
+ struct platform_device *pdev;
+ int i, j, idx;
+ const char *s;
+ if (dev && dev->bus_id)
+ for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
+ idx = -1;
+
+ if ((s = strrchr(dev->bus_id, '.')) != NULL)
+ idx = (int)simple_strtol(s + 1, NULL, 10);
+ else
+ s = dev->bus_id;
+ j = s - dev->bus_id;
+ if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
+ pdev =
+ container_of(dev, struct platform_device,
+ dev);
+ dev_map[i].rtn(pdev, idx);
+ }
+ }
+ return 0;
+}
+
+int __init mpc885ads_init(void)
+{
+ printk(KERN_NOTICE "mpc885ads: Init\n");
+
+ mpc885_nonplatform_device_init();
+ platform_notify = mpc885ads_platform_notify;
+
+ identify_ppc_sys_by_name(BOARD_CHIP_NAME);
+
+#ifdef CONFIG_MPC8xx_SECOND_ETH_SCC3
+ ppc_sys_device_remove(MPC8xx_CPM_FEC2);
+#endif
+#ifdef CONFIG_MPC8xx_SECOND_ETH_FEC2
+ ppc_sys_device_remove(MPC8xx_CPM_SCC3);
+#endif
+
+ ppc_sys_device_remove(MPC8xx_CPM_SCC1);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC2);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC4);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC1);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC2);
+
+ return 0;
+}
+
+arch_initcall(mpc885ads_init);
---
Sincerely,
Vitaly
^ permalink raw reply related
* Re: [PATCH] m8xx_wdt: software watchdog reset/interrupt select
From: Florian Schirmer @ 2005-11-16 11:47 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: obi, carjay, linux-ppc-embedded
In-Reply-To: <20051115142147.GD32373@logos.cnet>
Hi,
>> The SYPCR register can be set only _once_ at machine startup and the
>> bootloader in question does not have an option to change the mode. Many
>> bootloaders probably dont.
Okay, i was asuming you have control over the bootloader.
> Updated patch addresses code duplication issue you mentioned and also
> adds an error message in case timer interrupt frequency is higher
> than the watchdog frequency.
>
> Can I add your Signed-off-by in case you're OK with it?
Maybe i'm missing something obvious, but why is the interrupt driven
reaming code not working for your configuration. Are you using the PIT
for something else?
Otherwise i'm fine with the patch. Feel free to add my Signed-off-by line.
Best,
Florian
^ permalink raw reply
* Denx linux 2.4.25 on RPXLITE
From: Alexey Dyatchkov @ 2005-11-16 11:14 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: 'Ami Levi'
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
Hi,
I'm trying to bring up Denx linux-2.4.25, latest found on
ftp.denx.de/pub/linux, on our proprietary board.
Our board is very much similar to RPXLITE. In fact it is RPXLITE with few
minor changes.
We did such works before, and all we usualy needed was to tune the io
mapping.
I did so with this kernel and it stucks in calibrate_delay() on "while
(ticks==jiffies)", row 207.
And it seems that no interrupts are coming to kernel (breakpoint in do_irq
is never achieved).
(No printk's on console, btw)
I'm not experienced enough in kernel debugging and feel stuck.
Please help!
Thanks in advance,
Alexey
[-- Attachment #2: Type: text/html, Size: 4276 bytes --]
^ permalink raw reply
* Test
From: Alan Carvalho @ 2005-11-16 11:15 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 29 bytes --]
Just a test, ignore
Alan
[-- Attachment #2: Type: text/html, Size: 41 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: David Woodhouse @ 2005-11-16 10:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <17274.63508.501761.748278@cargo.ozlabs.ibm.com>
On Wed, 2005-11-16 at 20:12 +1100, Paul Mackerras wrote:
> Yes, it works on newworld (at least it does on my G4 powerbook). It
> should work on 32-bit CHRP with any luck, but for oldworld we'll have
> to generate a COFF file.
I'll try it on Pegasos some time tonight or tomorrow. AFAICT I'm going
to need the patch which started this thread, if I want any serial ports
on my Pegasos. The newly-created asm-powerpc/serial.h file is devoid of
serial port definitions.
Here it is again, with Tom's three criticisms addressed, deliberately
ignored, and addressed. In that order.
It no longer touches asm-ppc/serial.h, so doesn't break the legacy
zImage.
---
[PATCH] Fix 8250 probe on ppc32
There are no serial ports defined in the new asm-powerpc/serial.h, and
rightly so. The 64-bit setup code has a routine to look in the device
tree for them and register a platform_device for any we find there; this
patch steals that routine and makes it available on 32-bit machines
too...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
--- linux-2.6.14/drivers/serial/Makefile~ 2005-11-07 22:17:27.000000000 -0500
+++ linux-2.6.14/drivers/serial/Makefile 2005-11-07 22:17:35.000000000 -0500
@@ -22,6 +22,7 @@ obj-$(CONFIG_SERIAL_8250_ACCENT) += 8250
obj-$(CONFIG_SERIAL_8250_BOCA) += 8250_boca.o
obj-$(CONFIG_SERIAL_8250_HUB6) += 8250_hub6.o
obj-$(CONFIG_SERIAL_8250_MCA) += 8250_mca.o
+obj-$(CONFIG_SERIAL_8250_OF) += 8250_of.o
obj-$(CONFIG_SERIAL_8250_AU1X00) += 8250_au1x00.o
obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
--- linux-2.6.13/drivers/serial/8250_of.c.sof 2005-10-20 13:19:07.000000000 +0100
+++ linux-2.6.13/drivers/serial/8250_of.c 2005-10-20 13:19:26.000000000 +0100
@@ -0,0 +1,206 @@
+/*
+ * Search OpenFirmware device tree for 8250-compatible serial ports
+ *
+ * Moved from arch/powerpc/kernel/setup_64.c:
+ *
+ * Copyright (C) 2001 PPC64, IBM Corp
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#undef DEBUG
+
+#include <linux/kernel.h>
+#include <linux/serial.h>
+#include <linux/serial_8250.h>
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <asm/serial.h>
+#include <asm/prom.h>
+
+/*
+ * This function can be used by platforms to "find" legacy serial ports.
+ * It works for "serial" nodes under an "isa" node, and will try to
+ * respect the "ibm,aix-loc" property if any. It works with up to 8
+ * ports.
+ */
+
+#define MAX_LEGACY_SERIAL_PORTS 8
+static int ports_probed = 0;
+
+static struct plat_serial8250_port serial_ports[MAX_LEGACY_SERIAL_PORTS+1];
+static unsigned int old_serial_count;
+
+void __init generic_find_legacy_serial_ports(u64 *physport,
+ unsigned int *default_speed)
+{
+ struct device_node *np;
+ u32 *sizeprop;
+
+ struct isa_reg_property {
+ u32 space;
+ u32 address;
+ u32 size;
+ };
+
+ pr_debug(" -> generic_find_legacy_serial_port()\n");
+ ports_probed = 1;
+
+ *physport = 0;
+ if (default_speed)
+ *default_speed = 0;
+
+ np = of_find_node_by_path("/");
+ if (!np)
+ return;
+
+ /* First fill our array */
+ for (np = NULL; (np = of_find_node_by_type(np, "serial"));) {
+ struct device_node *isa, *pci;
+ struct isa_reg_property *reg;
+ unsigned long phys_size, addr_size;
+ u64 io_base;
+ u32 *rangesp;
+ u32 *interrupts, *clk, *spd;
+ char *typep;
+ int index, rlen, rentsize;
+
+ /* Ok, first check if it's under an "isa" parent */
+ isa = of_get_parent(np);
+ if (!isa || strcmp(isa->name, "isa")) {
+ pr_debug("%s: no isa parent found\n", np->full_name);
+ continue;
+ }
+
+ /* Now look for an "ibm,aix-loc" property that gives us ordering
+ * if any...
+ */
+ typep = (char *)get_property(np, "ibm,aix-loc", NULL);
+
+ /* Get the ISA port number */
+ reg = (struct isa_reg_property *)get_property(np, "reg", NULL);
+ if (reg == NULL)
+ goto next_port;
+ /* We assume the interrupt number isn't translated ... */
+ interrupts = (u32 *)get_property(np, "interrupts", NULL);
+ /* get clock freq. if present */
+ clk = (u32 *)get_property(np, "clock-frequency", NULL);
+ /* get default speed if present */
+ spd = (u32 *)get_property(np, "current-speed", NULL);
+ /* Default to locate at end of array */
+ index = old_serial_count; /* end of the array by default */
+
+ /* If we have a location index, then use it */
+ if (typep && *typep == 'S') {
+ index = simple_strtol(typep+1, NULL, 0) - 1;
+ /* if index is out of range, use end of array instead */
+ if (index >= MAX_LEGACY_SERIAL_PORTS)
+ index = old_serial_count;
+ /* if our index is still out of range, that mean that
+ * array is full, we could scan for a free slot but that
+ * make little sense to bother, just skip the port
+ */
+ if (index >= MAX_LEGACY_SERIAL_PORTS)
+ goto next_port;
+ if (index >= old_serial_count)
+ old_serial_count = index + 1;
+ /* Check if there is a port who already claimed our slot */
+ if (serial_ports[index].iobase != 0) {
+ /* if we still have some room, move it, else override */
+ if (old_serial_count < MAX_LEGACY_SERIAL_PORTS) {
+ pr_debug("Moved legacy port %d -> %d\n", index,
+ old_serial_count);
+ serial_ports[old_serial_count++] =
+ serial_ports[index];
+ } else {
+ pr_debug("Replacing legacy port %d\n", index);
+ }
+ }
+ }
+ if (index >= MAX_LEGACY_SERIAL_PORTS)
+ goto next_port;
+ if (index >= old_serial_count)
+ old_serial_count = index + 1;
+
+ /* Now fill the entry */
+ memset(&serial_ports[index], 0, sizeof(struct plat_serial8250_port));
+ serial_ports[index].uartclk = (clk && *clk) ? *clk : BASE_BAUD * 16;
+ serial_ports[index].iobase = reg->address;
+ serial_ports[index].irq = interrupts ? interrupts[0] : 0;
+ serial_ports[index].flags = ASYNC_BOOT_AUTOCONF;
+
+ pr_debug("Added legacy port, index: %d, port: %x, irq: %d, clk: %d\n",
+ index,
+ serial_ports[index].iobase,
+ serial_ports[index].irq,
+ serial_ports[index].uartclk);
+
+ /* Get phys address of IO reg for port 1 */
+ if (index != 0)
+ goto next_port;
+
+ pci = of_get_parent(isa);
+ if (!pci) {
+ pr_debug("%s: no pci parent found\n", np->full_name);
+ goto next_port;
+ }
+
+ rangesp = (u32 *)get_property(pci, "ranges", &rlen);
+ if (rangesp == NULL) {
+ of_node_put(pci);
+ goto next_port;
+ }
+ rlen /= 4;
+
+ /* we need the #size-cells of the PCI bridge node itself */
+ phys_size = 1;
+ sizeprop = (u32 *)get_property(pci, "#size-cells", NULL);
+ if (sizeprop != NULL)
+ phys_size = *sizeprop;
+ /* we need the parent #addr-cells */
+ addr_size = prom_n_addr_cells(pci);
+ rentsize = 3 + addr_size + phys_size;
+ io_base = 0;
+ for (;rlen >= rentsize; rlen -= rentsize,rangesp += rentsize) {
+ if (((rangesp[0] >> 24) & 0x3) != 1)
+ continue; /* not IO space */
+ io_base = rangesp[3];
+ if (addr_size == 2)
+ io_base = (io_base << 32) | rangesp[4];
+ }
+ if (io_base != 0) {
+ *physport = io_base + reg->address;
+ if (default_speed && spd)
+ *default_speed = *spd;
+ }
+ of_node_put(pci);
+ next_port:
+ of_node_put(isa);
+ }
+
+ pr_debug(" <- generic_find_legacy_serial_port()\n");
+}
+
+static struct platform_device serial_device = {
+ .name = "serial8250",
+ .id = PLAT8250_DEV_PLATFORM,
+ .dev = {
+ .platform_data = serial_ports,
+ },
+};
+
+static int __init serial_dev_init(void)
+{
+ u64 phys;
+ unsigned int spd;
+
+ if (!ports_probed)
+ generic_find_legacy_serial_ports(&phys, &spd);
+ return platform_device_register(&serial_device);
+}
+arch_initcall(serial_dev_init);
--- linux-2.6.13/drivers/serial/Kconfig.sof 2005-10-20 12:54:48.000000000 +0100
+++ linux-2.6.13/drivers/serial/Kconfig 2005-10-20 13:05:39.000000000 +0100
@@ -77,6 +77,11 @@ config SERIAL_8250_CS
If unsure, say N.
+config SERIAL_8250_OF
+ bool
+ default y
+ depends on PPC_OF && SERIAL_8250 && PPC_MERGE
+
config SERIAL_8250_ACPI
bool "8250/16550 device discovery via ACPI namespace"
default y if IA64
--- linux-2.6.13/arch/powerpc/kernel/setup_64.c.sof 2005-10-20 13:13:08.000000000 +0100
+++ linux-2.6.13/arch/powerpc/kernel/setup_64.c 2005-10-20 13:16:28.000000000 +0100
@@ -31,8 +31,6 @@
#include <linux/notifier.h>
#include <linux/cpu.h>
#include <linux/unistd.h>
-#include <linux/serial.h>
-#include <linux/serial_8250.h>
#include <asm/io.h>
#include <asm/prom.h>
#include <asm/processor.h>
@@ -52,7 +50,6 @@
#include <asm/system.h>
#include <asm/rtas.h>
#include <asm/iommu.h>
-#include <asm/serial.h>
#include <asm/cache.h>
#include <asm/page.h>
#include <asm/mmu.h>
@@ -1104,187 +1101,6 @@ void __init setup_default_decr(void)
lpaca->next_jiffy_update_tb = get_tb() + tb_ticks_per_jiffy;
}
-#ifndef CONFIG_PPC_ISERIES
-/*
- * This function can be used by platforms to "find" legacy serial ports.
- * It works for "serial" nodes under an "isa" node, and will try to
- * respect the "ibm,aix-loc" property if any. It works with up to 8
- * ports.
- */
-
-#define MAX_LEGACY_SERIAL_PORTS 8
-static struct plat_serial8250_port serial_ports[MAX_LEGACY_SERIAL_PORTS+1];
-static unsigned int old_serial_count;
-
-void __init generic_find_legacy_serial_ports(u64 *physport,
- unsigned int *default_speed)
-{
- struct device_node *np;
- u32 *sizeprop;
-
- struct isa_reg_property {
- u32 space;
- u32 address;
- u32 size;
- };
- struct pci_reg_property {
- struct pci_address addr;
- u32 size_hi;
- u32 size_lo;
- };
-
- DBG(" -> generic_find_legacy_serial_port()\n");
-
- *physport = 0;
- if (default_speed)
- *default_speed = 0;
-
- np = of_find_node_by_path("/");
- if (!np)
- return;
-
- /* First fill our array */
- for (np = NULL; (np = of_find_node_by_type(np, "serial"));) {
- struct device_node *isa, *pci;
- struct isa_reg_property *reg;
- unsigned long phys_size, addr_size, io_base;
- u32 *rangesp;
- u32 *interrupts, *clk, *spd;
- char *typep;
- int index, rlen, rentsize;
-
- /* Ok, first check if it's under an "isa" parent */
- isa = of_get_parent(np);
- if (!isa || strcmp(isa->name, "isa")) {
- DBG("%s: no isa parent found\n", np->full_name);
- continue;
- }
-
- /* Now look for an "ibm,aix-loc" property that gives us ordering
- * if any...
- */
- typep = (char *)get_property(np, "ibm,aix-loc", NULL);
-
- /* Get the ISA port number */
- reg = (struct isa_reg_property *)get_property(np, "reg", NULL);
- if (reg == NULL)
- goto next_port;
- /* We assume the interrupt number isn't translated ... */
- interrupts = (u32 *)get_property(np, "interrupts", NULL);
- /* get clock freq. if present */
- clk = (u32 *)get_property(np, "clock-frequency", NULL);
- /* get default speed if present */
- spd = (u32 *)get_property(np, "current-speed", NULL);
- /* Default to locate at end of array */
- index = old_serial_count; /* end of the array by default */
-
- /* If we have a location index, then use it */
- if (typep && *typep == 'S') {
- index = simple_strtol(typep+1, NULL, 0) - 1;
- /* if index is out of range, use end of array instead */
- if (index >= MAX_LEGACY_SERIAL_PORTS)
- index = old_serial_count;
- /* if our index is still out of range, that mean that
- * array is full, we could scan for a free slot but that
- * make little sense to bother, just skip the port
- */
- if (index >= MAX_LEGACY_SERIAL_PORTS)
- goto next_port;
- if (index >= old_serial_count)
- old_serial_count = index + 1;
- /* Check if there is a port who already claimed our slot */
- if (serial_ports[index].iobase != 0) {
- /* if we still have some room, move it, else override */
- if (old_serial_count < MAX_LEGACY_SERIAL_PORTS) {
- DBG("Moved legacy port %d -> %d\n", index,
- old_serial_count);
- serial_ports[old_serial_count++] =
- serial_ports[index];
- } else {
- DBG("Replacing legacy port %d\n", index);
- }
- }
- }
- if (index >= MAX_LEGACY_SERIAL_PORTS)
- goto next_port;
- if (index >= old_serial_count)
- old_serial_count = index + 1;
-
- /* Now fill the entry */
- memset(&serial_ports[index], 0, sizeof(struct plat_serial8250_port));
- serial_ports[index].uartclk = clk ? *clk : BASE_BAUD * 16;
- serial_ports[index].iobase = reg->address;
- serial_ports[index].irq = interrupts ? interrupts[0] : 0;
- serial_ports[index].flags = ASYNC_BOOT_AUTOCONF;
-
- DBG("Added legacy port, index: %d, port: %x, irq: %d, clk: %d\n",
- index,
- serial_ports[index].iobase,
- serial_ports[index].irq,
- serial_ports[index].uartclk);
-
- /* Get phys address of IO reg for port 1 */
- if (index != 0)
- goto next_port;
-
- pci = of_get_parent(isa);
- if (!pci) {
- DBG("%s: no pci parent found\n", np->full_name);
- goto next_port;
- }
-
- rangesp = (u32 *)get_property(pci, "ranges", &rlen);
- if (rangesp == NULL) {
- of_node_put(pci);
- goto next_port;
- }
- rlen /= 4;
-
- /* we need the #size-cells of the PCI bridge node itself */
- phys_size = 1;
- sizeprop = (u32 *)get_property(pci, "#size-cells", NULL);
- if (sizeprop != NULL)
- phys_size = *sizeprop;
- /* we need the parent #addr-cells */
- addr_size = prom_n_addr_cells(pci);
- rentsize = 3 + addr_size + phys_size;
- io_base = 0;
- for (;rlen >= rentsize; rlen -= rentsize,rangesp += rentsize) {
- if (((rangesp[0] >> 24) & 0x3) != 1)
- continue; /* not IO space */
- io_base = rangesp[3];
- if (addr_size == 2)
- io_base = (io_base << 32) | rangesp[4];
- }
- if (io_base != 0) {
- *physport = io_base + reg->address;
- if (default_speed && spd)
- *default_speed = *spd;
- }
- of_node_put(pci);
- next_port:
- of_node_put(isa);
- }
-
- DBG(" <- generic_find_legacy_serial_port()\n");
-}
-
-static struct platform_device serial_device = {
- .name = "serial8250",
- .id = PLAT8250_DEV_PLATFORM,
- .dev = {
- .platform_data = serial_ports,
- },
-};
-
-static int __init serial_dev_init(void)
-{
- return platform_device_register(&serial_device);
-}
-arch_initcall(serial_dev_init);
-
-#endif /* CONFIG_PPC_ISERIES */
-
int check_legacy_ioport(unsigned long base_port)
{
if (ppc_md.check_legacy_ioport == NULL)
--
dwmw2
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Gabriel Paubert @ 2005-11-16 9:36 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <00eecfdbd5bccc7b293d847033121eee@freescale.com>
On Tue, Nov 15, 2005 at 08:19:58PM -0600, Becky Bruce wrote:
> Ben,
>
> Yeah, I clearly shouldn't run testcases at 11pm, because I got in a
> rush and only confirmed that lmw/stmw were actually taking the
> exception. Those 2 are working beautifully. To test the others, I
> need to run on a different board which, of course, isn't bootable at
> the moment. As soon as I can get that up and running, I'll try some of
> the other cases and let you know how it goes......
>
> BTW, Based on the pile of docs I have here, I think the list of
> alignment-exception-causing events on FSL's current parts (603, 603e,
> 750, 74x, 74xx, e500) is:
The 603 is still in production? And is the upcoming 8641 exactly
the same as the 74xx series in this respect?
>
> - lmw/stmw (all procs, non-word aligned)
Do we really want to emulate these instructions?
Their purpose is to minimize code size in functions prologue and
epilogue. If you hit an alignment execption with lwm/stmw, your
stack is probably misaligned for some stupid reason or bug (back
chain pointer corrrupted because of some buffer overflow comes to
mind, and you want to know ASAP).
> - single and double precision floating point ld/st ops (non-E500, non
> data size aligned)
Hmm, you can load a double from any 4 byte aligned address AFAIR.
> - dcbz to WT or CI memory (all procs)
> - dcbz with cache disabled (all procs but 603e?)
> - misaligned little endian accesses (603e)
I understand that you mention it for completeness since we
don't care about LE mode AFAICT. But I believe that there
were some differences between 603 and 603e in this area.
However we do care about byte reversal instructions, which
probably believe like the corresponding normal instruction
(i.e., lwbrx has the same rules as lwzx, etc.)
> - lwarx/stwcx (all procs)
And ldarx/stdcx. on 64 bit, but these ones should not
be emulated. So it's easy ;-)
> - multiple/string with LE set (750, 603e, 7450, 7400)
Again LE mode is probably irrelevant.
> - eciwx/ecowx (750, 7450, 7400)
Have these instructions ever been used for something
under Linux?
> - a couple of others related to vector processing
Which ones? The Altivec load and store instructions
simply mask the low order bits AFAIR.
> If anybody knows offhand of something missing there, let me know.
Nothing, but did you check when crossing a segment (256MB) boundary.
I seem to remember that some processors performed misaligned
load/store across pages but not across segments.
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: Paul Mackerras @ 2005-11-16 9:12 UTC (permalink / raw)
To: David Woodhouse; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <1132131116.28963.75.camel@baythorne.infradead.org>
David Woodhouse writes:
> .... except that it seems to have been done already -- the code which
> just landed in arch/powerpc/boot can already load a 32-bit kernel.
Yes, it works on newworld (at least it does on my G4 powerbook). It
should work on 32-bit CHRP with any luck, but for oldworld we'll have
to generate a COFF file.
Paul.
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: David Woodhouse @ 2005-11-16 8:51 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <1131382971.27347.79.camel@baythorne.infradead.org>
On Mon, 2005-11-07 at 17:02 +0000, David Woodhouse wrote:
> Or do you just mean the trivial patch to make arch/ppc64/boot/ capable
> of loading a 32-bit kernel? That'll make sense if that code gets moved
> to arch/powerpc/boot, and I'll do so then.
.... except that it seems to have been done already -- the code which
just landed in arch/powerpc/boot can already load a 32-bit kernel.
--
dwmw2
^ permalink raw reply
* Re: powerpc.git tree now on kernel.org
From: Paul Mackerras @ 2005-11-16 8:31 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: akpm, linuxppc-dev, linuxppc64-dev
In-Reply-To: <20051116082456.GA24802@lst.de>
Christoph Hellwig writes:
> Please make sure at least all patches required to kill arch/ppc64 and
> include/asm-ppc64 go to Linus. If 2.6.15 released with the include3
> hack that would mean endless pain to people building external modules
> and the distributions trying to support that.
Yes, that is my intention. For 2.6.15, at this stage, some of the
header files might end up looking like:
#ifdef CONFIG_PPC32
#include <asm-ppc/foo.h>
#else
/* contents of asm-ppc64/foo.h */
#endif
if it looks like doing a proper merge will require too many changes.
But at least it gets the files out of include/asm-ppc64.
Paul.
^ permalink raw reply
* Re: powerpc.git tree now on kernel.org
From: Christoph Hellwig @ 2005-11-16 8:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, linuxppc64-dev
In-Reply-To: <17274.51251.591579.8751@cargo.ozlabs.ibm.com>
On Wed, Nov 16, 2005 at 04:48:35PM +1100, Paul Mackerras wrote:
> Although some of these patches may go to Linus before 2.6.15 is
> released, I won't be asking Linus to pull this tree directly, since it
> is likely to get a bit messy as patches are updated. I expect that
> Andrew Morton will pull this tree periodically and include it in his
> -mm releases.
Please make sure at least all patches required to kill arch/ppc64 and
include/asm-ppc64 go to Linus. If 2.6.15 released with the include3
hack that would mean endless pain to people building external modules
and the distributions trying to support that.
^ permalink raw reply
* Fwd: powerpc.git tree now on kernel.org
From: Kumar Gala @ 2005-11-16 6:17 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org list
In-Reply-To: <17274.51251.591579.8751@cargo.ozlabs.ibm.com>
For those that only read linuxppc-embedded (and shame on you :)
- kumar
Begin forwarded message:
> From: Paul Mackerras <paulus@samba.org>
> Date: November 15, 2005 11:48:35 PM CST
> To: linuxppc-dev@ozlabs.org, linuxppc64-dev@ozlabs.org, akpm@osdl.org
> Subject: powerpc.git tree now on kernel.org
>
> I have just created a git tree for ppc/powerpc patches that are
> candidates for 2.6.16. The tree is at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
>
> Currently, besides the patches that are in the powerpc-merge.git tree,
> there are the following patches in there:
>
> Adrian Bunk:
> PPC_PREP: remove unneeded exports
>
> Benjamin Herrenschmidt:
> powerpc: Merge align.c (#2)
>
> David Gibson:
> powerpc: Remove imalloc.h
>
> David Woodhouse:
> syscall entry/exit revamp
>
> Kumar Gala:
> powerpc: moved ipic code to arch/powerpc
>
> Michael Ellerman:
> powerpc: Merge kexec
>
> Mike Kravetz:
> Remove SPAN_OTHER_NODES config definition
>
> Although some of these patches may go to Linus before 2.6.15 is
> released, I won't be asking Linus to pull this tree directly, since it
> is likely to get a bit messy as patches are updated. I expect that
> Andrew Morton will pull this tree periodically and include it in his
> -mm releases.
>
> Paul.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Benjamin Herrenschmidt @ 2005-11-16 6:13 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <324befe15b30886e86b0110c30334c8f@embeddededge.com>
On Wed, 2005-11-16 at 00:35 -0500, Dan Malek wrote:
> On Nov 16, 2005, at 12:00 AM, Benjamin Herrenschmidt wrote:
>
> > Oh well, I suppose I'll have to dig out paulus' 601 based mac :)
>
> If we don't have any contemporary processors that need
> this solution, can we just put on aside until someone
> has hardware that requires it?
I do not want to break an existing functionality with the merged file,
though for now, I suppose the merged file will only apply to
ARCH=powerpc, I can keep the old align.c in arch/ppc/kernel until it has
been properly tested on old machines.
Ben.
^ permalink raw reply
* powerpc.git tree now on kernel.org
From: Paul Mackerras @ 2005-11-16 5:48 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev, akpm
I have just created a git tree for ppc/powerpc patches that are
candidates for 2.6.16. The tree is at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
Currently, besides the patches that are in the powerpc-merge.git tree,
there are the following patches in there:
Adrian Bunk:
PPC_PREP: remove unneeded exports
Benjamin Herrenschmidt:
powerpc: Merge align.c (#2)
David Gibson:
powerpc: Remove imalloc.h
David Woodhouse:
syscall entry/exit revamp
Kumar Gala:
powerpc: moved ipic code to arch/powerpc
Michael Ellerman:
powerpc: Merge kexec
Mike Kravetz:
Remove SPAN_OTHER_NODES config definition
Although some of these patches may go to Linus before 2.6.15 is
released, I won't be asking Linus to pull this tree directly, since it
is likely to get a bit messy as patches are updated. I expect that
Andrew Morton will pull this tree periodically and include it in his
-mm releases.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Dan Malek @ 2005-11-16 5:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <1132117236.5646.75.camel@gaston>
On Nov 16, 2005, at 12:00 AM, Benjamin Herrenschmidt wrote:
> Oh well, I suppose I'll have to dig out paulus' 601 based mac :)
If we don't have any contemporary processors that need
this solution, can we just put on aside until someone
has hardware that requires it?
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Benjamin Herrenschmidt @ 2005-11-16 5:00 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <02de724e66fe23fd23a3635c8b6f049f@embeddededge.com>
On Tue, 2005-11-15 at 23:26 -0500, Dan Malek wrote:
> On Nov 15, 2005, at 9:34 PM, Benjamin Herrenschmidt wrote:
>
> > What about lwz/stw cropssing page boundaries ? Is this handled in HW ?
>
> Yep. All of these hardware alignment support features on
> the Freescale processors are the reasons they are used
> so extensively in data communication processing (where
> unaligned data can sometimes occur). All of the load/store
> alignment issues are handled in the cache subsystem, so
> to the external world all you really see are cache line
> operations. In the event of uncached data operations, you
> get the performance penalty of two bus accesses, where
> some of the data is discarded.
Oh well, I suppose I'll have to dig out paulus' 601 based mac :)
Becky, can you send me a copy of your testcase ?
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Dan Malek @ 2005-11-16 4:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <1132108490.5646.67.camel@gaston>
On Nov 15, 2005, at 9:34 PM, Benjamin Herrenschmidt wrote:
> What about lwz/stw cropssing page boundaries ? Is this handled in HW ?
Yep. All of these hardware alignment support features on
the Freescale processors are the reasons they are used
so extensively in data communication processing (where
unaligned data can sometimes occur). All of the load/store
alignment issues are handled in the cache subsystem, so
to the external world all you really see are cache line
operations. In the event of uncached data operations, you
get the performance penalty of two bus accesses, where
some of the data is discarded.
-- Dan
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Becky Bruce @ 2005-11-16 3:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <1132108490.5646.67.camel@gaston>
On Nov 15, 2005, at 8:34 PM, Benjamin Herrenschmidt wrote:
> >
> > BTW, Based on the pile of docs I have here, I think the list of
> > alignment-exception-causing events on FSL's current parts (603, 603e,
> > 750, 74x, 74xx, e500) is:
> >
> > - lmw/stmw (all procs, non-word aligned)
> > - single and double precision floating point ld/st ops (non-E500, non
> > data size aligned)
> > - dcbz to WT or CI memory (all procs)
> > - dcbz with cache disabled (all procs but 603e?)
> > - misaligned little endian accesses (603e)
> > - lwarx/stwcx (all procs)
> > - multiple/string with LE set (750, 603e, 7450, 7400)
> > - eciwx/ecowx (750, 7450, 7400)
> > - a couple of others related to vector processing
> >
> > If anybody knows offhand of something missing there, let me know.
>
> What about lwz/stw cropssing page boundaries ? Is this handled in HW ?
>
> Ben.
Apparently so, much to my surprise - I ran the testcase with those
instructions misaligned across a page boundary last night and got no
alignment exception. I was surprised, and asked my husband about it
(he worked on the load/store units for a bunch of our parts), and he
says these guys never cause an exception for any of FSL's current parts
as far as he knows. This is supported by our documentation as well -
the only place I see these listed is on 603e, where they can cause an
exception if the page is mapped little endian.
-B
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Benjamin Herrenschmidt @ 2005-11-16 2:34 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <00eecfdbd5bccc7b293d847033121eee@freescale.com>
On Tue, 2005-11-15 at 20:19 -0600, Becky Bruce wrote:
> Ben,
>
> Yeah, I clearly shouldn't run testcases at 11pm, because I got in a
> rush and only confirmed that lmw/stmw were actually taking the
> exception. Those 2 are working beautifully. To test the others, I
> need to run on a different board which, of course, isn't bootable at
> the moment. As soon as I can get that up and running, I'll try some of
> the other cases and let you know how it goes......
>
> BTW, Based on the pile of docs I have here, I think the list of
> alignment-exception-causing events on FSL's current parts (603, 603e,
> 750, 74x, 74xx, e500) is:
>
> - lmw/stmw (all procs, non-word aligned)
> - single and double precision floating point ld/st ops (non-E500, non
> data size aligned)
> - dcbz to WT or CI memory (all procs)
> - dcbz with cache disabled (all procs but 603e?)
> - misaligned little endian accesses (603e)
> - lwarx/stwcx (all procs)
> - multiple/string with LE set (750, 603e, 7450, 7400)
> - eciwx/ecowx (750, 7450, 7400)
> - a couple of others related to vector processing
>
> If anybody knows offhand of something missing there, let me know.
What about lwz/stw cropssing page boundaries ? Is this handled in HW ?
Ben.
^ permalink raw reply
* how to use the system call in the module ?
From: zjznliang @ 2005-11-16 2:19 UTC (permalink / raw)
To: linuxppc-embedded
SGkgbGludXhwcGMtZW1iZWRkZWSjoQ0KDQoJICAgICBJbiB0aGUgZGV2aWNlIGRyaXZlciwgd2Ug
YWx3YXlzIHdhbnQgdG8gc2VuZCBzb21lIGRhdGEgdG8gdGhlIGFwcGxpY2F0aW9uIC4gU28gSSB3
YXMgIHRoaW5raW5nICwgdGhlIElQQyB3b3VsZCAgZG8gbWUgYSBmYXZvciAuIEkgdXNlZCB0aGUg
c3lzX21zZ2dldCBhbmQgc3lzX21zZ3NuZCBpbiB0aGUgbW9kdWxlICxidXQgSSBnb3QgdGhpcyB3
aGVuIEkgdHlwZSB0aGUgImluc21vZCAgbW9kdWxlIiBjb21tYW5kIDoNCgkJaW5zbW9kOiB1bnJl
c29sdmVkIHN5bWJvbCBzeXNfbXNnZ2V0IA0KCQlpbnNtb2Q6IHVucmVzb2x2ZWQgc3ltYm9sIHN5
c19tc2dzbmQgDQoNCgkJSW4gbXkgb3BpbmlvbiAsdGhlIHN5c3RlbSBjYWxsIGlzIHRoZSBzeXN0
ZW0gY2FsbCB0byB0aGUgdXNlciBhcHBsaWNhdGlvbiBhbmQgdGhlIGZ1bmN0aW9uIHRvIHRoZSBr
ZXJuZWwgbW9kZSAoZWc6IG1vZHVsZSApLHNvIGhvdyB0byB1c2UgdGhlIHN5c3RlbSBjYWxsIGlu
IGtlcm5lbCBtb2RlIGlzIHRoZSB3YXkgdGhhdCBob3cgdG8gcmVjb2duaXNlIHRoZSBmdW5jdGlv
biBvZiBzeXN0ZW0gY2FsbCBpbiB0aGUgbW9kdWxlIC4NCiANCgkJQXQgdGhlIGJlZ2lubmluZywg
SSBoYWQgdG8gb3BlbiBhbmQgcmVhZCBhIGZpbGUgaW4gdGhlIG1vZHVsZSAsIHNvIEkgdXNlZCAg
dGhpcyB3YXkgdG8gYWRkIHRoZSBzeXN0ZW0gY2FsbCA6DQoNCgkJI2RlZmluZSBfS0VSTkVMX1NZ
U0NBTExTXw0KCQkjaW5jbHVkZSA8bGludXgvdW5pc3RkLmg+DQoNCgkJV2hlbiBJIHR5cGVkIHRo
ZSAiaW5zbW9kIG1vZHVsZSAiLHRoZSBzeW1ib2wgb3BlbiBhbmQgcmVhZCBjb3VsZCBiZSBmb3Vu
ZCAsYnV0IHRoZSBmdW5jdGlvbiB3YXMgbm90IGF2YWlsYWJpbGl0eS5TbyBJIGNoZWNrZWQgdGhl
IC9wcm9jL2tzeW1zIGZvciB0aGUgZnVuY3Rpb24gd2hpY2ggdGhlIGtlcm5lbCBjb3VsZCBjYWxs
ICwgYW5kIHVzZWQgdGhlIGZpbHBfb3BlbiAoKSBhbmQga2VybmVsX3JlYWQgKCkgZm9yIGluc3Rl
YWQgLg0KCQkNCgkJTm93ICwgSSBkaWQgYSB0ZXN0ICwgY29tcGlsZSB0aGUgbW9kdWxlIHdpdGgg
dGhlIGxpbnV4IGtlcm5lbCwgdGhlIHN5c19tc2dnZXQgYW5kIHN5c19tc2dzbmQgY291bGQgd29y
ayBmaW5lIC4gSSB0aG91Z2h0IHRoZSByZWFzb24gaXMgdGhhdCB0aGUgc3lzX21zZ2dldCBpcyBh
biBleHRlcm4gZnVuY3Rpb24gd2hlbiBjb21waWxpbmcgd2l0aCB0aGUga2VybmVsLlNvIHBlcmhh
cHMgLCB3aGVuIEkgZG8gaW5zbW9kIHRoZSBtb2R1bGUsIEkgZGlkIG5vdCBleHBvcnRlIHRoZSBz
eXNfbXNnZ2V0IGFuZCBzeXNfbXNnc25kIGFzIHRoZSBrZXJuZWwgc3ltYm9scy4NCg0KCQlIb3cg
dG8gZXhwb3J0ZSB0aGUgc3lzdGVtIGNhbGwgYXMgdGhlIGtlcm5lbCBzeW1ib2xzPz8gDQoNCiAg
ICAgICBBbnkgaGVscCBvbiB0aGlzIHdvdWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuIFRoYW5r
cyBmb3IgeW91ciBwYXRpZW5jZS4gDQoNCiAJCQkJDQoNCqGhoaF6anpubGlhbmcNCqGhoaGhoaGh
emp6bmxpYW5nX3BvcG9AMTYzLmNvbQ0KoaGhoaGhoaGhoaGhMjAwNS0xMS0xNg0K
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Becky Bruce @ 2005-11-16 2:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <1132032910.23979.6.camel@gaston>
Ben,
Yeah, I clearly shouldn't run testcases at 11pm, because I got in a=20
rush and only confirmed that lmw/stmw were actually taking the=20
exception. Those 2 are working beautifully. To test the others, I=20
need to run on a different board which, of course, isn't bootable at=20
the moment. As soon as I can get that up and running, I'll try some of=20=
the other cases and let you know how it goes......
BTW, Based on the pile of docs I have here, I think the list of=20
alignment-exception-causing events on FSL's current parts (603, 603e,=20
750, 74x, 74xx, e500) is:
- lmw/stmw (all procs, non-word aligned)
- single and double precision floating point ld/st ops (non-E500, non=20
data size aligned)
- dcbz to WT or CI memory (all procs)
- dcbz with cache disabled (all procs but 603e?)
- misaligned little endian accesses (603e)
- lwarx/stwcx (all procs)
- multiple/string with LE set (750, 603e, 7450, 7400)
- eciwx/ecowx (750, 7450, 7400)
- a couple of others related to vector processing
If anybody knows offhand of something missing there, let me know.
Cheers,
B
On Nov 14, 2005, at 11:35 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2005-11-14 at 23:10 -0600, Becky Bruce wrote:
> > Ben,
> >
> > I've just done some basic testing of lmw/stmw, lwz/stw, lhx/sth,
> > lfs/stfs, and lfd/stfd misaligned across a doubleword boundary, and
> > everything looks good so far.=A0=A0 I'll check out the byte =
reversals=20
> and a
> > few other forms tomorrow.
>
> Excellent, thanks ! BTW. Make sure you test these one CPUs that=20
> actually
> trap on misaligned accesses :) Best is probably to do the misaligned
> access accross a page boundary, that's what most CPUs can do.
>
> Ben.
>
^ permalink raw reply
* Re: U-Boot
From: Wolfgang Denk @ 2005-11-16 1:06 UTC (permalink / raw)
To: mcnernbm; +Cc: linuxppc-embedded
In-Reply-To: <OF3D06561E.1EB2655E-ON852570BB.00015870-852570BB.00016F3F@notes.udayton.edu>
In message <OF3D06561E.1EB2655E-ON852570BB.00015870-852570BB.00016F3F@notes.udayton.edu> you wrote:
>
> I have a question about U-Boot. I have a board with no flash capability
> at all. Will u-boot work on a xilinx board with no flash and only sdram?
> Can uboot be downloaded into sdram and used to boot linux?
> Thanks
> Brett
> --=_alternative 00016F3D852570BB_=
> Content-Type: text/html; charset="US-ASCII"
One questions, three goof-ups.
1) This is the linuxppc-embedded list. U-Boot related questions are
off topic here and should be posted to u-boot-users instead.
2) The answers to your questions are "yes" and "yes", but you posted
without reading the FAQ. See especially
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
3) Please don't post HTML to public mailing lists.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Today is the yesterday you worried about tomorrow.
^ permalink raw reply
* U-Boot
From: mcnernbm @ 2005-11-16 0:15 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
I have a question about U-Boot. I have a board with no flash capability
at all. Will u-boot work on a xilinx board with no flash and only sdram?
Can uboot be downloaded into sdram and used to boot linux?
Thanks
Brett
[-- Attachment #2: Type: text/html, Size: 361 bytes --]
^ permalink raw reply
* Re: Problem:-BDI(u-boot) programming on MPC 8272ADS
From: Federico Lucifredi @ 2005-11-16 0:00 UTC (permalink / raw)
To: srideep.devireddy; +Cc: linuxppc-embedded
In-Reply-To: <6AD9F6A5F6E096408F0B703773355A0751AC41@CHN-SNR-MBX01.wipro.com>
Srideep,
I have never used the BDI 2000 with the MPC8272, however, I can tell
you that configuring your emulator for your specific board, if the
manufacturer does not provide a *verified* configuration for it, is
something that takes some time and a few variables to tweak.
Maybe you can expect to find a configuration ready made for some
Motorola prototype board like the ADS 8272, *but* it would be a mistake
to assume that that maps directly to your hardware in a workable manner.
Bottom line, you need to know exactly what all of the emulator knobs
are, and, if this is new hardware, keep in mind that it [the new
hardware] could be malfunctioning. Do not assume the hardware is
operating as a reliable computer unless you have positive proof that is
the case - my personal experience is that I tried to make an emulator
work on hardware that someone above me kept insisting "had to be
working" - which was not the case. I got plenty of frustration and
nothing to show for it - I should have defended the case that the
hardware was not working much harder than I did 8)
Anyway.. I am digressing. How is your BDI 2000 behaving ? I was using
an "Embedded Toolsmiths" emulator, by the way.
-f
On Wed, 2005-10-12 at 17:14 +0530, srideep.devireddy@wipro.com wrote:
> Hi ,
>
> I am srideep , we have problem in programming flash on MPC 8272
> ADS file using BDI 2000 with linux as host. As I am new to this I
> need your help in this regard.
>
>
>
> We have connected the BDI2000 to MPC8272ADS board. We are working on
> linux & I have attached configuration file for 8272 ADS board .
>
> BDI 2000 could recognize the processor type.
>
> But when we try to program the flash (with uboot binary image ) at
> location 0xff800000 on MPC 8272ADS evaluation board, it failed to
> program,
>
> We tried to unlock and do the same but still left with the same error.
>
> But when we tried to program in any other location it programmed but
> it doesnt boot .
>
> Can you kindly send us the working configuration file.
>
>
>
>
>
> Thanks & Regards
>
> Srideep Reddy D
>
> Software Engineer
>
> Telecom solutions
>
> Wipro Technologies
>
> 91-44-30691952
>
>
>
>
>
>
> Confidentiality Notice
>
> The information contained in this electronic message and any
> attachments to this message are intended
> for the exclusive use of the addressee(s) and may contain confidential
> or privileged information. If
> you are not the intended recipient, please notify the sender at Wipro
> or Mailadmin@wipro.com immediately
> and destroy all copies of this message and any attachments.
>
^ permalink raw reply
* Re: Platform device model drawback
From: Greg KH @ 2005-11-15 22:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
In-Reply-To: <Pine.LNX.4.44.0511151332310.28098-100000@gate.crashing.org>
On Tue, Nov 15, 2005 at 01:34:47PM -0600, Kumar Gala wrote:
> > You only register the driver once. The individual devices can be bound
> > to the same driver, right?
> >
> > > Not registering it in CPM_UART, how the pdev could be obtained?
> > >
> > > Maybe this is clear, but platform stuff is cumbersome some times...
> >
> > Then make it cleaner :)
>
> This is where the confusion is. We have two instances of device A. We
> want instance 1 of device A bound to driver "enet" and instance 2 of
> device A bound to "serial".
That's different from what was described earlier :)
In this case, you need two different struct devices.
> Today both instances are called "deviceA". However we can't register two
> different drivers as "deviceA".
Nor would you want to.
> Not sure if that clarifies the issue any.
A bit. I think it still sounds messy...
thanks,
greg k-h
^ permalink raw reply
* Re: modify the cache-inhibit and guard bits from userspace?
From: Christopher Friesen @ 2005-11-15 23:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc64-dev, linuxppc-embedded
In-Reply-To: <200511152338.53238.arnd@arndb.de>
Arnd Bergmann wrote:
> I have seen an earlier patch that modifies madvise to do this, which seems
> a little saner than mprotect, although they can probably both be implemented
> in a similar way.
Ah, that would make sense. It does fit the intent of the function a bit
better.
> Alternatively, you could write a new file system similar to hugetlbfs and set
> the cache-inhibit bit in its mmap function.
Also a possibility. I think the madvise method is a bit cleaner for the
apps.
Chris
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox