* [PATCH / RFC 2/2] ISP1760: bus glue code
From: Sebastian Siewior @ 2008-04-01 19:52 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linuxppc-dev, Thomas Gleixner, linux-usb
In-Reply-To: <20080401195158.657955430@linutronix.de>
This patch contains the entry for the build system and glue code for the
platform bus. Currently OpenFirmware and PCI is supported.
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -95,6 +95,32 @@ config USB_ISP116X_HCD
To compile this driver as a module, choose M here: the
module will be called isp116x-hcd.
+config USB_ISP1760_HCD
+ tristate "ISP 1760 HCD support"
+ depends on USB && EXPERIMENTAL
+ ---help---
+ The ISP1760 chip is a USB 2.0 host controller.
+
+ This driver does not support isochronous transfers or OTG.
+
+ To compile this driver as a module, choose M here: the
+ module will be called isp1760-hcd.
+
+config USB_ISP1760_PCI
+ bool "Support for the PCI bus"
+ depends on USB_ISP1760_HCD && PCI
+ ---help---
+ Enables support for the device present on the PCI bus.
+ This should only be required if you happen to have the eval kit from
+ NXP and you are going to test it.
+
+config USB_ISP1760_OF
+ bool "Support for the OF platform bus"
+ depends on USB_ISP1760_HCD && OF
+ ---help---
+ Enables support for the device present on the PowerPC
+ OpenFirmware platform bus.
+
config USB_OHCI_HCD
tristate "OHCI HCD support"
depends on USB && USB_ARCH_HAS_OHCI
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -6,6 +6,8 @@ ifeq ($(CONFIG_USB_DEBUG),y)
EXTRA_CFLAGS += -DDEBUG
endif
+isp1760-objs := isp1760-hcd.o isp1760-if.o
+
obj-$(CONFIG_PCI) += pci-quirks.o
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
@@ -16,4 +18,4 @@ obj-$(CONFIG_USB_SL811_HCD) += sl811-hcd
obj-$(CONFIG_USB_SL811_CS) += sl811_cs.o
obj-$(CONFIG_USB_U132_HCD) += u132-hcd.o
obj-$(CONFIG_USB_R8A66597_HCD) += r8a66597-hcd.o
-
+obj-$(CONFIG_USB_ISP1760_HCD) += isp1760.o
--- /dev/null
+++ b/drivers/usb/host/isp1760-if.c
@@ -0,0 +1,294 @@
+/*
+ * Glue code for the ISP1760 driver and bus
+ * Currently there is support for
+ * - OpenFirmware
+ * - PCI
+ *
+ * (c) 2007 Sebastian Siewior <bigeasy@linutronix.de>
+ *
+ */
+
+#include <linux/usb.h>
+#include <linux/io.h>
+
+#include "../core/hcd.h"
+#include "isp1760-hcd.h"
+
+#ifdef CONFIG_USB_ISP1760_OF
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#endif
+
+#ifdef CONFIG_USB_ISP1760_PCI
+#include <linux/pci.h>
+#endif
+
+#ifdef CONFIG_USB_ISP1760_OF
+static int of_isp1760_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ struct usb_hcd *hcd;
+ struct device_node *dp = dev->node;
+ struct resource *res;
+ struct resource memory;
+ struct of_irq oirq;
+ int virq;
+ u64 res_len;
+ int ret;
+
+ ret = of_address_to_resource(dp, 0, &memory);
+ if (ret)
+ return -ENXIO;
+
+ res = request_mem_region(memory.start, memory.end - memory.start + 1,
+ dev->dev.bus_id);
+ if (!res)
+ return -EBUSY;
+
+ res_len = memory.end - memory.start + 1;
+
+ if (of_irq_map_one(dp, 0, &oirq)) {
+ ret = -ENODEV;
+ goto release_reg;
+ }
+
+ virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
+ oirq.size);
+
+ hcd = isp1760_register(memory.start, res_len, virq,
+ IRQF_SHARED | IRQF_DISABLED, &dev->dev, dev->dev.bus_id);
+ if (IS_ERR(hcd)) {
+ ret = PTR_ERR(hcd);
+ goto release_reg;
+ }
+
+ dev_set_drvdata(&dev->dev, hcd);
+ return ret;
+
+release_reg:
+ release_mem_region(memory.start, memory.end - memory.start + 1);
+ return ret;
+}
+
+static int of_isp1760_remove(struct of_device *dev)
+{
+ struct usb_hcd *hcd = dev_get_drvdata(&dev->dev);
+
+ dev_set_drvdata(&dev->dev, NULL);
+
+ usb_remove_hcd(hcd);
+ iounmap(hcd->regs);
+ release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
+ usb_put_hcd(hcd);
+ return 0;
+}
+
+static struct of_device_id of_isp1760_match[] = {
+ {
+ .compatible = "nxp,usb-isp1760",
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_isp1760_match);
+
+static struct of_platform_driver isp1760_of_driver = {
+ .name = "nxp-isp1760",
+ .match_table = of_isp1760_match,
+ .probe = of_isp1760_probe,
+ .remove = of_isp1760_remove,
+};
+#endif
+
+#ifdef CONFIG_USB_ISP1760_PCI
+static u32 nxp_pci_io_base;
+static u32 iolength;
+static u32 pci_mem_phy0;
+static u32 length;
+static u8 *chip_addr;
+static u8 *iobase;
+
+static int __devinit isp1761_pci_probe(struct pci_dev *dev,
+ const struct pci_device_id *id)
+{
+ u8 latency, limit;
+ __u32 reg_data;
+ int retry_count;
+ int length;
+ int status = 1;
+ struct usb_hcd *hcd;
+
+ if (usb_disabled())
+ return -ENODEV;
+
+ if (pci_enable_device(dev) < 0)
+ return -ENODEV;
+
+ if (!dev->irq)
+ return -ENODEV;
+
+ /* Grab the PLX PCI mem maped port start address we need */
+ nxp_pci_io_base = pci_resource_start(dev, 0);
+ iolength = pci_resource_len(dev, 0);
+
+ if (!request_mem_region(nxp_pci_io_base, iolength, "ISP1761 IO MEM")) {
+ printk(KERN_ERR "request region #1\n");
+ return -EBUSY;
+ }
+
+ iobase = ioremap_nocache(nxp_pci_io_base, iolength);
+ if (!iobase) {
+ printk(KERN_ERR "ioremap #1\n");
+ release_mem_region(nxp_pci_io_base, iolength);
+ return -ENOMEM;
+ }
+ /* Grab the PLX PCI shared memory of the ISP 1761 we need */
+ pci_mem_phy0 = pci_resource_start(dev, 3);
+ length = pci_resource_len(dev, 3);
+
+ if (length < 0xffff) {
+ printk(KERN_ERR "memory length for this resource is less than "
+ "required\n");
+ release_mem_region(nxp_pci_io_base, iolength);
+ iounmap(iobase);
+ return -ENOMEM;
+ }
+
+ if (!request_mem_region(pci_mem_phy0, length, "ISP-PCI")) {
+ printk(KERN_ERR "host controller already in use\n");
+ release_mem_region(nxp_pci_io_base, iolength);
+ iounmap(iobase);
+ return -EBUSY;
+ }
+
+ /* bad pci latencies can contribute to overruns */
+ pci_read_config_byte(dev, PCI_LATENCY_TIMER, &latency);
+ if (latency) {
+ pci_read_config_byte(dev, PCI_MAX_LAT, &limit);
+ if (limit && limit < latency)
+ pci_write_config_byte(dev, PCI_LATENCY_TIMER, limit);
+ }
+
+ /* Try to check whether we can access Scratch Register of
+ * Host Controller or not. The initial PCI access is retried until
+ * local init for the PCI bridge is completed
+ */
+ retry_count = 20;
+ reg_data = 0;
+ while ((reg_data != 0xFACE) && retry_count) {
+ /*by default host is in 16bit mode, so
+ * io operations at this stage must be 16 bit
+ * */
+ writel(0xface, chip_addr + HC_SCRATCH_REG);
+ udelay(100);
+ reg_data = readl(chip_addr + HC_SCRATCH_REG);
+ retry_count--;
+ }
+
+ /* Host Controller presence is detected by writing to scratch register
+ * and reading back and checking the contents are same or not
+ */
+ if (reg_data != 0xFACE) {
+ err("scratch register mismatch %x", reg_data);
+ goto clean;
+ }
+
+ pci_set_master(dev);
+
+ status = readl(iobase + 0x68);
+ status |= 0x900;
+ writel(status, iobase + 0x68);
+
+ dev->dev.dma_mask = NULL;
+ hcd = isp1760_register(pci_mem_phy0, length, dev->irq,
+ IRQF_SHARED | IRQF_DISABLED, &dev->dev, dev->dev.bus_id);
+ pci_set_drvdata(dev, hcd);
+ if (!hcd)
+ return 0;
+clean:
+ status = -ENODEV;
+ iounmap(iobase);
+ release_mem_region(pci_mem_phy0, length);
+ release_mem_region(nxp_pci_io_base, iolength);
+ return status;
+}
+static void isp1761_pci_remove(struct pci_dev *dev)
+{
+ struct usb_hcd *hcd;
+
+ hcd = pci_get_drvdata(dev);
+
+ usb_remove_hcd(hcd);
+ iounmap(hcd->regs);
+ release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
+ usb_put_hcd(hcd);
+
+ pci_disable_device(dev);
+
+ iounmap(iobase);
+ iounmap(chip_addr);
+
+ release_mem_region(nxp_pci_io_base, iolength);
+ release_mem_region(pci_mem_phy0, length);
+}
+
+static void ips1761_pci_shutdown(struct pci_dev *dev)
+{
+ printk(KERN_ERR "ips1761_pci_shutdown\n");
+}
+
+static const struct pci_device_id ips1760_plx [] = { {
+ /* handle any USB 2.0 EHCI controller */
+ PCI_DEVICE_CLASS(((PCI_CLASS_BRIDGE_OTHER << 8) | (0x06 << 16)), ~0),
+ .driver_data = 0,
+},
+{ /* end: all zeroes */ }
+};
+MODULE_DEVICE_TABLE(pci, ips1760_plx);
+
+static struct pci_driver isp1761_pci_driver = {
+ .name = "isp1760",
+ .id_table = ips1760_plx,
+ .probe = isp1761_pci_probe,
+ .remove = isp1761_pci_remove,
+ .shutdown = ips1761_pci_shutdown,
+};
+#endif
+
+static int __init isp1760_init(void)
+{
+ int ret;
+
+ init_kmem_once();
+
+#ifdef CONFIG_USB_ISP1760_OF
+ ret = of_register_platform_driver(&isp1760_of_driver);
+ if (ret) {
+ deinit_kmem_cache();
+ return ret;
+ }
+#endif
+
+#ifdef CONFIG_USB_ISP1760_PCI
+ ret = pci_register_driver(&isp1761_pci_driver);
+ if (ret) {
+#ifdef CONFIG_USB_ISP1760_OF
+ of_unregister_platform_driver(&isp1760_of_driver);
+#endif
+ deinit_kmem_cache();
+ }
+#endif
+ return ret;
+}
+module_init(isp1760_init);
+
+static void __exit isp1760_exit(void)
+{
+#ifdef CONFIG_USB_ISP1760_OF
+ of_unregister_platform_driver(&isp1760_of_driver);
+#endif
+#ifdef CONFIG_USB_ISP1760_PCI
+ pci_unregister_driver(&isp1761_pci_driver);
+#endif
+ deinit_kmem_cache();
+}
+module_exit(isp1760_exit);
--
^ permalink raw reply
* Re: [PATCH] RTAS - adapt procfs interface
From: Nathan Lynch @ 2008-04-01 20:04 UTC (permalink / raw)
To: Jens Osterkamp; +Cc: maxim, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <20080401163504.GP7137@localdomain>
Nathan Lynch wrote:
>
> One could argue that the real problem is using the proc_dir_entry's
> reference count to enforce exclusive open.
I think this is better... the way these files are used is lame, but
this should preserve the existing behavior. I haven't yet tested
this, can you?
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index f227659..00bc308 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -139,7 +139,7 @@ struct rtas_validate_flash_t
unsigned int update_results; /* Update results token */
};
-static DEFINE_SPINLOCK(flash_file_open_lock);
+static atomic_t open_count = ATOMIC_INIT(0);
static struct proc_dir_entry *firmware_flash_pde;
static struct proc_dir_entry *firmware_update_pde;
static struct proc_dir_entry *validate_pde;
@@ -216,7 +216,7 @@ static int rtas_flash_release(struct inode *inode, struct file *file)
uf->flist = NULL;
}
- atomic_dec(&dp->count);
+ atomic_dec(&open_count);
return 0;
}
@@ -352,26 +352,17 @@ static ssize_t rtas_flash_write(struct file *file, const char __user *buffer,
static int rtas_excl_open(struct inode *inode, struct file *file)
{
- struct proc_dir_entry *dp = PDE(inode);
-
- /* Enforce exclusive open with use count of PDE */
- spin_lock(&flash_file_open_lock);
- if (atomic_read(&dp->count) > 1) {
- spin_unlock(&flash_file_open_lock);
+ if (atomic_inc_return(&open_count) > 1) {
+ atomic_dec(&open_count);
return -EBUSY;
}
- atomic_inc(&dp->count);
- spin_unlock(&flash_file_open_lock);
-
return 0;
}
static int rtas_excl_release(struct inode *inode, struct file *file)
{
- struct proc_dir_entry *dp = PDE(inode);
-
- atomic_dec(&dp->count);
+ atomic_dec(&open_count);
return 0;
}
@@ -580,7 +571,7 @@ static int validate_flash_release(struct inode *inode, struct file *file)
}
/* The matching atomic_inc was in rtas_excl_open() */
- atomic_dec(&dp->count);
+ atomic_dec(&open_count);
return 0;
}
^ permalink raw reply related
* RE: [PATCH 1/5] [v2][POWERPC] refactor dcr code
From: Stephen Neuendorffer @ 2008-04-01 20:16 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1206914576.10388.132.camel@pasglop>
I considered function pointers as well, but I think something like
dcr-generic.h is still required in order to get the specialization if
only one is selected.
Also note that I neglected to change the patch description: The
dcr-access-method attribute is applied to the dcr-controller node, not
the dcr slave.
I'd particularly appreciate it if someone with access to PPC64 would
test this...
Steve
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Sunday, March 30, 2008 3:03 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/5] [v2][POWERPC] refactor dcr code
>=20
>=20
> On Fri, 2008-03-28 at 09:23 -0700, Stephen Neuendorffer wrote:
> > Previously, dcr support was configured at compile time to either
using
> > MMIO or native dcr instructions. Although this works for most
> > platforms, it fails on FPGA platforms:
> >
> > 1) Systems may include more than one dcr bus.
> > 2) Systems may be native dcr capable and still use memory mapped dcr
interface.
> >
> > This patch provides runtime support based on the device trees for
the
> > case where CONFIG_PPC_DCR_MMIO and CONFIG_PPC_DCR_NATIVE are both
> > selected. Previously, this was a poorly defined configuration,
which
> > happened to provide NATIVE support. The runtime selection is made
> > based on the dcr slave device having a 'dcr-access-method' attribute
> > in the device tree. If only one of the above options is selected,
> > then the code uses #defines to select only the used code in order to
> > avoid interoducing overhead in existing usage.
> >
> > Signed-off-by: Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com>
>=20
> Looks good. Haven't had a chance to test it yet, but tentatively
>=20
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>=20
> Initially, I thought about using function pointers but the if/else
will
> probably end up being more efficient. The only thing maybe to ponder
> is whether we could avoid the dcr-generic.h file completely, and have
> the generic wrappers be inline, though considering how slow DCRs are,
> it may not be that useful in practice and less clean...
>=20
> Cheers,
> Ben.
>=20
>=20
> > ---
> > arch/powerpc/sysdev/dcr.c | 91
++++++++++++++++++++++++++++++++-----
> > include/asm-powerpc/dcr-generic.h | 49 ++++++++++++++++++++
> > include/asm-powerpc/dcr-mmio.h | 20 +++++---
> > include/asm-powerpc/dcr-native.h | 16 ++++---
> > include/asm-powerpc/dcr.h | 36 ++++++++++++++-
> > 5 files changed, 186 insertions(+), 26 deletions(-)
> > create mode 100644 include/asm-powerpc/dcr-generic.h
> >
> > diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
> > index 437e48d..d3de0ff 100644
> > --- a/arch/powerpc/sysdev/dcr.c
> > +++ b/arch/powerpc/sysdev/dcr.c
> > @@ -23,6 +23,68 @@
> > #include <asm/prom.h>
> > #include <asm/dcr.h>
> >
> > +#if defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO)
> > +
> > +bool dcr_map_ok_generic(dcr_host_t host)
> > +{
> > + if (host.type =3D=3D INVALID)
> > + return 0;
> > + else if (host.type =3D=3D NATIVE)
> > + return dcr_map_ok_native(host.host.native);
> > + else
> > + return dcr_map_ok_mmio(host.host.mmio);
> > +}
> > +EXPORT_SYMBOL_GPL(dcr_map_ok_generic);
> > +
> > +dcr_host_t dcr_map_generic(struct device_node *dev,
> > + unsigned int dcr_n,
> > + unsigned int dcr_c)
> > +{
> > + dcr_host_t host;
> > + const char *prop =3D of_get_property(dev, "dcr-access-method",
NULL);
> > +
> > + if (!strcmp(prop, "native")) {
> > + host.type =3D NATIVE;
> > + host.host.native =3D dcr_map_native(dev, dcr_n, dcr_c);
> > + } else if (!strcmp(prop, "mmio")) {
> > + host.type =3D MMIO;
> > + host.host.mmio =3D dcr_map_mmio(dev, dcr_n, dcr_c);
> > + } else
> > + host.type =3D INVALID;
> > +
> > + return host;
> > +}
> > +EXPORT_SYMBOL_GPL(dcr_map_generic);
> > +
> > +void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c)
> > +{
> > + if (host.type =3D=3D NATIVE)
> > + dcr_unmap_native(host.host.native, dcr_c);
> > + else
> > + dcr_unmap_mmio(host.host.mmio, dcr_c);
> > +}
> > +EXPORT_SYMBOL_GPL(dcr_unmap_generic);
> > +
> > +u32 dcr_read_generic(dcr_host_t host, unsigned int dcr_n)
> > +{
> > + if (host.type =3D=3D NATIVE)
> > + return dcr_read_native(host.host.native, dcr_n);
> > + else
> > + return dcr_read_mmio(host.host.mmio, dcr_n);
> > +}
> > +EXPORT_SYMBOL_GPL(dcr_read_generic);
> > +
> > +void dcr_write_generic(dcr_host_t host, unsigned int dcr_n, u32
value)
> > +{
> > + if (host.type =3D=3D NATIVE)
> > + dcr_write_native(host.host.native, dcr_n, value);
> > + else
> > + dcr_write_mmio(host.host.mmio, dcr_n, value);
> > +}
> > +EXPORT_SYMBOL_GPL(dcr_write_generic);
> > +
> > +#endif /* defined(CONFIG_PPC_DCR_NATIVE) &&
defined(CONFIG_PPC_DCR_MMIO) */
> > +
> > unsigned int dcr_resource_start(struct device_node *np, unsigned
int index)
> > {
> > unsigned int ds;
> > @@ -47,7 +109,7 @@ unsigned int dcr_resource_len(struct device_node
*np, unsigned int index)
> > }
> > EXPORT_SYMBOL_GPL(dcr_resource_len);
> >
> > -#ifndef CONFIG_PPC_DCR_NATIVE
> > +#ifdef CONFIG_PPC_DCR_MMIO
> >
> > static struct device_node * find_dcr_parent(struct device_node *
node)
> > {
> > @@ -101,18 +163,19 @@ u64 of_translate_dcr_address(struct
device_node *dev,
> > return ret;
> > }
> >
> > -dcr_host_t dcr_map(struct device_node *dev, unsigned int dcr_n,
> > - unsigned int dcr_c)
> > +dcr_host_mmio_t dcr_map_mmio(struct device_node *dev,
> > + unsigned int dcr_n,
> > + unsigned int dcr_c)
> > {
> > - dcr_host_t ret =3D { .token =3D NULL, .stride =3D 0, .base =3D =
dcr_n };
> > + dcr_host_mmio_t ret =3D { .token =3D NULL, .stride =3D 0, .base =
=3D
dcr_n };
> > u64 addr;
> >
> > pr_debug("dcr_map(%s, 0x%x, 0x%x)\n",
> > dev->full_name, dcr_n, dcr_c);
> >
> > addr =3D of_translate_dcr_address(dev, dcr_n, &ret.stride);
> > - pr_debug("translates to addr: 0x%lx, stride: 0x%x\n",
> > - addr, ret.stride);
> > + pr_debug("translates to addr: 0x%llx, stride: 0x%x\n",
> > + (unsigned long long) addr, ret.stride);
> > if (addr =3D=3D OF_BAD_ADDR)
> > return ret;
> > pr_debug("mapping 0x%x bytes\n", dcr_c * ret.stride);
> > @@ -124,11 +187,11 @@ dcr_host_t dcr_map(struct device_node *dev,
unsigned int dcr_n,
> > ret.token -=3D dcr_n * ret.stride;
> > return ret;
> > }
> > -EXPORT_SYMBOL_GPL(dcr_map);
> > +EXPORT_SYMBOL_GPL(dcr_map_mmio);
> >
> > -void dcr_unmap(dcr_host_t host, unsigned int dcr_c)
> > +void dcr_unmap_mmio(dcr_host_mmio_t host, unsigned int dcr_c)
> > {
> > - dcr_host_t h =3D host;
> > + dcr_host_mmio_t h =3D host;
> >
> > if (h.token =3D=3D NULL)
> > return;
> > @@ -136,7 +199,11 @@ void dcr_unmap(dcr_host_t host, unsigned int
dcr_c)
> > iounmap(h.token);
> > h.token =3D NULL;
> > }
> > -EXPORT_SYMBOL_GPL(dcr_unmap);
> > -#else /* defined(CONFIG_PPC_DCR_NATIVE) */
> > +EXPORT_SYMBOL_GPL(dcr_unmap_mmio);
> > +
> > +#endif /* defined(CONFIG_PPC_DCR_MMIO) */
> > +
> > +#ifdef CONFIG_PPC_DCR_NATIVE
> > DEFINE_SPINLOCK(dcr_ind_lock);
> > -#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
> > +#endif /* defined(CONFIG_PPC_DCR_NATIVE) */
> > +
> > diff --git a/include/asm-powerpc/dcr-generic.h
b/include/asm-powerpc/dcr-generic.h
> > new file mode 100644
> > index 0000000..0ee74fb
> > --- /dev/null
> > +++ b/include/asm-powerpc/dcr-generic.h
> > @@ -0,0 +1,49 @@
> > +/*
> > + * (c) Copyright 2006 Benjamin Herrenschmidt, IBM Corp.
> > + * <benh@kernel.crashing.org>
> > + *
> > + * 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.
> > + *
> > + * This program is distributed in the hope that it will be
useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty
of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
> > + * the GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public
License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
> > + */
> > +
> > +#ifndef _ASM_POWERPC_DCR_GENERIC_H
> > +#define _ASM_POWERPC_DCR_GENERIC_H
> > +#ifdef __KERNEL__
> > +#ifndef __ASSEMBLY__
> > +
> > +enum host_type_t {MMIO, NATIVE, INVALID};
> > +
> > +typedef struct {
> > + enum host_type_t type;
> > + union {
> > + dcr_host_mmio_t mmio;
> > + dcr_host_native_t native;
> > + } host;
> > +} dcr_host_t;
> > +
> > +extern bool dcr_map_ok_generic(dcr_host_t host);
> > +
> > +extern dcr_host_t dcr_map_generic(struct device_node *dev, unsigned
int dcr_n,
> > + unsigned int dcr_c);
> > +extern void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c);
> > +
> > +extern u32 dcr_read_generic(dcr_host_t host, unsigned int dcr_n);
> > +
> > +extern void dcr_write_generic(dcr_host_t host, unsigned int dcr_n,
u32 value);
> > +
> > +#endif /* __ASSEMBLY__ */
> > +#endif /* __KERNEL__ */
> > +#endif /* _ASM_POWERPC_DCR_GENERIC_H */
> > +
> > +
> > diff --git a/include/asm-powerpc/dcr-mmio.h
b/include/asm-powerpc/dcr-mmio.h
> > index 08532ff..acd491d 100644
> > --- a/include/asm-powerpc/dcr-mmio.h
> > +++ b/include/asm-powerpc/dcr-mmio.h
> > @@ -27,20 +27,26 @@ typedef struct {
> > void __iomem *token;
> > unsigned int stride;
> > unsigned int base;
> > -} dcr_host_t;
> > +} dcr_host_mmio_t;
> >
> > -#define DCR_MAP_OK(host) ((host).token !=3D NULL)
> > +static inline bool dcr_map_ok_mmio(dcr_host_mmio_t host)
> > +{
> > + return host.token !=3D NULL;
> > +}
> >
> > -extern dcr_host_t dcr_map(struct device_node *dev, unsigned int
dcr_n,
> > - unsigned int dcr_c);
> > -extern void dcr_unmap(dcr_host_t host, unsigned int dcr_c);
> > +extern dcr_host_mmio_t dcr_map_mmio(struct device_node *dev,
> > + unsigned int dcr_n,
> > + unsigned int dcr_c);
> > +extern void dcr_unmap_mmio(dcr_host_mmio_t host, unsigned int
dcr_c);
> >
> > -static inline u32 dcr_read(dcr_host_t host, unsigned int dcr_n)
> > +static inline u32 dcr_read_mmio(dcr_host_mmio_t host, unsigned int
dcr_n)
> > {
> > return in_be32(host.token + ((host.base + dcr_n) *
host.stride));
> > }
> >
> > -static inline void dcr_write(dcr_host_t host, unsigned int dcr_n,
u32 value)
> > +static inline void dcr_write_mmio(dcr_host_mmio_t host,
> > + unsigned int dcr_n,
> > + u32 value)
> > {
> > out_be32(host.token + ((host.base + dcr_n) * host.stride),
value);
> > }
> > diff --git a/include/asm-powerpc/dcr-native.h
b/include/asm-powerpc/dcr-native.h
> > index be6c879..67832e5 100644
> > --- a/include/asm-powerpc/dcr-native.h
> > +++ b/include/asm-powerpc/dcr-native.h
> > @@ -26,14 +26,18 @@
> >
> > typedef struct {
> > unsigned int base;
> > -} dcr_host_t;
> > +} dcr_host_native_t;
> >
> > -#define DCR_MAP_OK(host) (1)
> > +static inline bool dcr_map_ok_native(dcr_host_native_t host)
> > +{
> > + return 1;
> > +}
> >
> > -#define dcr_map(dev, dcr_n, dcr_c) ((dcr_host_t){ .base =3D (dcr_n)
})
> > -#define dcr_unmap(host, dcr_c) do {} while (0)
> > -#define dcr_read(host, dcr_n) mfdcr(dcr_n + host.base)
> > -#define dcr_write(host, dcr_n, value) mtdcr(dcr_n + host.base,
value)
> > +#define dcr_map_native(dev, dcr_n, dcr_c) \
> > + ((dcr_host_native_t){ .base =3D (dcr_n) })
> > +#define dcr_unmap_native(host, dcr_c) do {} while (0)
> > +#define dcr_read_native(host, dcr_n) mfdcr(dcr_n +
host.base)
> > +#define dcr_write_native(host, dcr_n, value) mtdcr(dcr_n +
host.base, value)
> >
> > /* Device Control Registers */
> > void __mtdcr(int reg, unsigned int val);
> > diff --git a/include/asm-powerpc/dcr.h b/include/asm-powerpc/dcr.h
> > index 9338d50..6b86322 100644
> > --- a/include/asm-powerpc/dcr.h
> > +++ b/include/asm-powerpc/dcr.h
> > @@ -20,14 +20,47 @@
> > #ifndef _ASM_POWERPC_DCR_H
> > #define _ASM_POWERPC_DCR_H
> > #ifdef __KERNEL__
> > +#ifndef __ASSEMBLY__
> > #ifdef CONFIG_PPC_DCR
> >
> > #ifdef CONFIG_PPC_DCR_NATIVE
> > #include <asm/dcr-native.h>
> > -#else
> > +#endif
> > +
> > +#ifdef CONFIG_PPC_DCR_MMIO
> > #include <asm/dcr-mmio.h>
> > #endif
> >
> > +#if defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO)
> > +
> > +#include <asm/dcr-generic.h>
> > +
> > +#define DCR_MAP_OK(host) dcr_map_ok_generic(host)
> > +#define dcr_map(dev, dcr_n, dcr_c) dcr_map_generic(dev, dcr_n,
dcr_c)
> > +#define dcr_unmap(host, dcr_c) dcr_unmap_generic(host, dcr_c)
> > +#define dcr_read(host, dcr_n) dcr_read_generic(host, dcr_n)
> > +#define dcr_write(host, dcr_n, value) dcr_write_generic(host,
dcr_n, value)
> > +
> > +#else
> > +
> > +#ifdef CONFIG_PPC_DCR_NATIVE
> > +typedef dcr_host_native_t dcr_host_t;
> > +#define DCR_MAP_OK(host) dcr_map_ok_native(host)
> > +#define dcr_map(dev, dcr_n, dcr_c) dcr_map_native(dev, dcr_n,
dcr_c)
> > +#define dcr_unmap(host, dcr_c) dcr_unmap_native(host, dcr_c)
> > +#define dcr_read(host, dcr_n) dcr_read_native(host, dcr_n)
> > +#define dcr_write(host, dcr_n, value) dcr_write_native(host, dcr_n,
value)
> > +#else
> > +typedef dcr_host_mmio_t dcr_host_t;
> > +#define DCR_MAP_OK(host) dcr_map_ok_mmio(host)
> > +#define dcr_map(dev, dcr_n, dcr_c) dcr_map_mmio(dev, dcr_n, dcr_c)
> > +#define dcr_unmap(host, dcr_c) dcr_unmap_mmio(host, dcr_c)
> > +#define dcr_read(host, dcr_n) dcr_read_mmio(host, dcr_n)
> > +#define dcr_write(host, dcr_n, value) dcr_write_mmio(host, dcr_n,
value)
> > +#endif
> > +
> > +#endif /* defined(CONFIG_PPC_DCR_NATIVE) &&
defined(CONFIG_PPC_DCR_MMIO) */
> > +
> > /*
> > * On CONFIG_PPC_MERGE, we have additional helpers to read the DCR
> > * base from the device-tree
> > @@ -41,5 +74,6 @@ extern unsigned int dcr_resource_len(struct
device_node *np,
> > #endif /* CONFIG_PPC_MERGE */
> >
> > #endif /* CONFIG_PPC_DCR */
> > +#endif /* __ASSEMBLY__ */
> > #endif /* __KERNEL__ */
> > #endif /* _ASM_POWERPC_DCR_H */
>=20
^ permalink raw reply
* RE: xilinx Ml405 NFS mount problem
From: MingLiu @ 2008-04-01 20:42 UTC (permalink / raw)
To: Robert Woodworth; +Cc: John Linn, linuxppc-embedded
In-Reply-To: <1207068618.4830.60.camel@PisteOff>
[-- Attachment #1: Type: text/plain, Size: 13008 bytes --]
Dear Robert and all friends,
A little more progress on my problem. I just found that if I disable the hardware check-sum offloading options, the root file system could be mounted then. In combination with the previous information of "UDP bad checksum" I mentioned, it seems that you are absolutely right! The problem is on the hardware checksum logic!
For this problem, maybe it will be better if xilinx could solve it. I am not pretty sure if we can rely on a stricter timing constraint. After all, we are not the original designer of the LL_TEMAC control logic.
Any other idea or suggestion? Thanks in advance.
BR
Ming
> Subject: RE: xilinx Ml405 NFS mount problem> From: rwoodworth@securics.com> To: eemingliu@hotmail.com> CC: john.linn@xilinx.com; linuxppc-embedded@ozlabs.org> Date: Tue, 1 Apr 2008 10:50:18 -0600> > I think you may be suffering from the latest LL_TEMAC packet loss> problem. (NFS/UDP really does not like packet loss)> > > Let me guess. > You are using a base system from "Base System Builder Wizard"?> EDK 9.2i. Default syntheses/P&R options.> > I have seen a massive packet loss problems on my ML403 and two other> boards I have with an FX60.> > This is probably a hardware problem.> Xilinx has acknowledged an LL_TEMAC problem to me but has not provided a> fix. I have heard that things are better with EDK/ISE-10.1 but I have> not tested it.> > > The vendor of one of my boards (Pico) has fixed the problem on the FX60> by highly constraining the timing of the LL_TEMAC in map/PR. On my> ML403 I used similar constraints and it fixed the problem, but only if> the device is plugged into a GigE switch. The problem is still there> with the same .bit file on a 100-T switch. > > > Are you on a GigE switch?> > > > Rob.> > > > > > > On Tue, 2008-04-01 at 16:15 +0000, MingLiu wrote:> > Dear John,> > > > Thank you for your replying. > > > > >It’s not obvious to me what the problem is as I don’t see any driver> > failures. Have you >tried using a ramdisk and then seeing if the> > network is working before using NFS root? > > > > Not yet. I will try it soon. However from the information on the> > LL_TEMAC, it seems everything is fine and it should work. > > > > > > > > >And I’m assuming you have used the NFS root before so you know that> > it’s good for sure.> > > > > > > > >I test on the ML405 with NFS root and haven’t seen this problem, but> > my setup is a little different. I use DHCP rather than >a static IP,> > but other than that it’s similar.> > > > > > > > Yes. I used NFS before. I can make sure my NFS server works well. Also> > in principle, static IP should get a same result as DHCP, I think. > > > > > > > > >How long has it been since you pulled from the Xilinx Git tree?> > > > > > > > I just pulled the Xilinx tree quite recently. I am using a latest> > kernel.> > > > > > > > BR > > > > Ming> > > > > > > > > > > > And I’m assuming you have used the NFS root before so you know> > that it’s good for sure.> > > > > > > > I test on the ML405 with NFS root and haven’t seen this> > problem, but my setup is a little different. I use DHCP> > rather than a static IP, but other than that it’s similar.> > > > > > > > I’m assuming that you accidentally got 2 different powerup> > outputs in the message below as the 1st stops and a 2nd starts> > in the middle.> > > > > > > > How long has it been since you pulled from the Xilinx Git> > tree?> > > > > > > > Thanks,> > > > John> > > > > > > > > > ______________________________________________________________> > From: linuxppc-embedded-bounces> > +john.linn=xilinx.com@ozlabs.org> > [mailto:linuxppc-embedded-bounces> > +john.linn=xilinx.com@ozlabs.org] On Behalf Of MingLiu> > Sent: Tuesday, April 01, 2008 8:12 AM> > To: linuxppc-embedded@ozlabs.org> > Subject: xilinx Ml405 NFS mount problem> > > > > > > > > > Dear friends,> > > > I am bringing up my kernel from Xilinx git tree. Unfortunately I met some> > problem when mounting the root file system. Here is the information> > listed. I will appreciate a lot if someone can help me out of the trouble. > > Thanks a lot!> > > > > > loaded at: 00400000 0059F19C> > board data at: 0059D120 0059D19C> > relocated to: 004050C8 00405144> > zimage at: 00405F3F 0059C025> > avail ram: 005A0000 08000000> > > > Linux/PPC load: root=/dev/nfs> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400> > mem=32M> > Uncompressing Linux...done.> > Now booting the kernel> > Linux version 2.6.24-rc8-xlnx-g1db182b8-dirty (mingliu@cca01) (gcc version> > 3.4.1) #7 Tue Apr 1 14:55:25 CEST 2008> > Xilinx Generic PowerPC board support package (Xilinx ML405) (Virtex-4 FX)> > Zone PFN ranges:> > DMA 0 -> 8192> > > > Normal 8192 -> 8192> > > > HighMem 8192 -> 8192> > Movable zone start PFN for each node> > early_node_map[1] active PFN ranges> > 0: 0 -> 8192> > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128> > Kernel command line: root=/de v/nfs> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400> > mem=32M> > Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000> > PID hash table entries: 128 (order: 7, 512 bytes)> > Console: colour dummy device 80x25> > Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)> > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)> > Memory: 28884k available (2552k kernel code, 944k data, 84k init, 0k highmem)> > SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1> > Mount-cache hash table entries: 512> > net_namespace: 64 bytes> > NET: Registered protocol family 16> > Registering device uartlite:0> > Fixup MAC address for xilinx_lltemac:0> > Regis tering device xilinx_lltemac:0> > NET: Registered protocol family 2> > IP route cache hash table entries: 1024 (order: 0, 4096 bytes)> > TCP established hash table entries: 1024 (order: 1, 8192 bytes)> > TCP bind hash table entries: 1024 (order: 0, 4096 bytes)> > TCP: Hash tables configured (established 1024 bind 1024)> > TCP reno registered> > sysctl table check failed: /kernel/l2cr .1.31 Missing strategy> > Call Trace:> > [c1c0fe50] [c0008b70] show_stack+0x40/0x194 (unreliable)> > [c1c0fe90] [c003aed4] set_fail+0x68/0x80> > [c1c0feb0] [c003b4ec] sysctl_check_table+0x600/0x77c> > [c1c0fef0] [c003b4d4] sysctl_check_table+0x5e8/0x77c> > [c1c0ff30] [c002605c] register_sysctl_table+0x64/0xb4> > [c1c0ff50] [c034579c] register_ppc_htab_sysctl+0x18/0x2c> > [c1c0ff60] [c034482c] kernel_init+0x94/0x2bc> > [c1c0fff0] [c0004d58] kernel_thread+0x44/0x60> > Installing knfsd (copyright (C) 1996 okir@monad.swb.de).> > fuse init (API version 7.9)> > io scheduler noop registered> > io scheduler anticipatory registered> > io scheduler deadline registered> > io scheduler cfq registered (default)> > uartlite.0: ttyUL0 at MM IO 0x84000003 (irq = 3) is a uartlite> > console [ttyUL0] enabled> > loop: module loaded> > nbd: registered device at major 43> > xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: a:35: 1: 2: 3> > xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode.> > XLlTemac: Dma base address: phy: 0x84600100, virt: 0xc3008100> > XLlTemac: buffer descriptor size: 32768 (0x8000)> > XLlTemac: Allocating DMA descriptors with kmalloc<6>XLlTemac:> > (buffer_descriptor_init) phy: 0x1d18000, virt: 0xc1d18000, size: 0x8000> > XTemac: PHY detected at address 7.> > xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at 0x81C00000 mapped> > to 0xC3004000, irq=2> > console [netcon0] enabled> > Linux version 2.6.24-rc8-xlnx-g1db182b8-dirty (mingliu@cca01) (gcc version> > 3.4.1) #7 Tue Apr 1 14:55:25 CEST 2008> > > > Xilinx Generic PowerPC board support package (Xilinx ML405)> > (Virtex-4 FX)> > > > Zone PFN ranges:> > DMA 0 -> 8192> > Normal 8192 -> 8192> > HighMem 8192 -> 8192> > Movable zone start PFN for each node> > early_node_map[1] active PFN range> > s> > 0: 0 -> 8192> > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128> > Kernel command line: root=/dev/nfs> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400> > mem=32M> > Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000> > PID hash table entries: 128 (order: 7, 512 bytes)> > Console: colour dummy device 80x25> > Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)> > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)> > Memory: 28884k available (2552k kernel code, 944k data, 84k init, 0k highmem)> > SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1> > Mount-cache hash table entries: 512> > n> > et_namespace: 64 bytes> > NET: Registered protocol family 16> > Registering device uartlite:0> > Fixup MAC address for xilinx_lltemac:0> > Registering device xilinx_lltemac:0> > NET: Registered protocol family 2> > IP route cache hash table entries: 1024 (order: 0, 4096 bytes)> > TCP established hash table entries: 1024 (order: 1, 8192 bytes)> > TCP bind hash table entries: 1024> > (order: 0, 4096 bytes)> > TCP: Hash tables configured (established 1024 bind 1024)> > TCP reno registered> > sysctl table check failed: /kernel/l2cr .1.31 Missing strategy> > Call Trace:> > [c1c0fe50] [c0008b70] show_stack+0x40/0x194 (unreliable)> > [c1c0fe90] [c003aed4] set_fail+0x68/0x80> > [c1c0feb0] [c003b4ec] sysctl_check_table+0x600/0x77c> > [c1c0fef0] [c003b4d4] sysctl_c> > heck_table+0x5e8/0x77c> > [c1c0ff30] [c002605c] register_sysctl_table+0x64/0xb4> > [c1c0ff50] [c034579c] register_ppc_htab_sysctl+0x18/0x2c> > [c1c0ff60] [c034482c] kernel_init+0x94/0x2bc> > [c1c0fff0] [c0004d58] kernel_thread+0x44/0x60> > Installing knfsd (copyright (C) 1996 okir@monad.swb.de).> > fuse init (API version 7.9)> > io scheduler noop registered<> > /SPAN>> > io scheduler anticipatory registered> > io scheduler deadline registered> > io scheduler cfq registered (default)> > uartlite.0: ttyUL0 at MMIO 0x84000003 (irq = 3) is a uartlite> > console [ttyUL0] enabled> > loop: module loaded> > nbd: registered device at major 43> > xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: a:35: 1: 2: 3> > xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode.> > XLlTemac: Dma base address: phy: 0x84600100, virt: 0xc3008100> > XLlTemac: buffer descriptor size: 32768 (0x8000)> > XLlTemac: Allocating DMA descriptors with kmalloc<6>XLlTemac:> > (buffer_descriptor_init) phy: 0x1d18000, virt: 0xc1d18000, size: 0x8000> > XTemac: PHY detected at address 7.> > xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at 0x81C00000 mapped> > <> > SPAN style="FONT-SIZE: 12pt">to 0xC3004000, irq=2> > console [netcon0] enabled> > netconsole: network logging started> > Generic platform RAM MTD, (c) 2004 Simtec Electronics> > mice: PS/2 mouse device common for all mice> > TCP cubic registered> > NET: Registered protocol family 1> > NET: Registered protocol family 17> > RPC: Registered udp transport module.> > RPC: Registered tcp transport module.> > eth0: XLlTemac: Options: 0x3fa> > eth0: XLlTemac: allocating interrupt 0 for dma mode tx.> > eth0: XLlTemac: allocating interrupt 1 for dma mode rx.> > eth0: XLlTemac: speed set to 1000Mb/s> > eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4> > eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254> > IP-Config: Complete:> > > > device=eth0, addr=192.168.0.4, mask=255.255.255.0, gw=192.168.0.3,> > host=192.168.0.4, domain=, nis-domain=(none),> > bootserver=192.168.0.3, rootserver=192.168.0.3, rootpath=> > Looking up port of RPC 100003/2 on 192.168.0.3> > rpcbind: server 192.168.0.3 not responding, timed out> > Root-NFS: Unable to get nfsd port number from server, using default> > Looking up port of RPC 10000> > 5/1 on 192.168.0.3> > rpcbind: server 192.168.0.3 not responding, timed out> > Root-NFS: Unable to get mountd port number from server, using default> > mount: server 192.168.0.3 not responding, timed out> > Root-NFS: Server returned error -5 while mounting /home/mingliu/ml403_rootfs> > VFS: Unable to mount root fs via NFS, trying floppy.> > VFS: Cannot open root device "nfs" or unknown-block(2,0)> > Please append a correct "root=" boot option; here are > > the available> > partitions:> > Kernel panic - not syncing: VFS: Unable to mount root fs on> > unknown-block(2,0)> > Rebooting in 180 seconds..> > > > > > BR> > Ming> > > > > > > > > > ______________________________________________________________> > Windows Live Writer,支持离线撰写博客内容,随时随地想写就写。> > 立即使用!> > > > > > > > > > ______________________________________________________________________> > 使用新一代 Windows Live Messenger 轻松交流和共享! 立即体验! > > _______________________________________________> > Linuxppc-embedded mailing list> > Linuxppc-embedded@ozlabs.org> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
_________________________________________________________________
MSN 中文网,最新时尚生活资讯,白领聚集门户。
http://cn.msn.com
[-- Attachment #2: Type: text/html, Size: 16652 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2 v5] Add DIU platform code for MPC8610HPCD
From: Andrew Morton @ 2008-04-01 21:00 UTC (permalink / raw)
To: York Sun
Cc: timur, linux-fbdev-devel, a.p.zijlstra, linux-kernel,
linuxppc-dev, scottwood, yorksun
In-Reply-To: <12069806051291-git-send-email-yorksun@freescale.com>
On Mon, 31 Mar 2008 11:23:25 -0500
York Sun <yorksun@freescale.com> wrote:
> Add platform code to support Freescale DIU. The platform code includes
> framebuffer memory allocation, pixel format, monitor port, etc.
>
> Signed-off-by: York Sun <yorksun@freescale.com>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> This patch addes platform support for Freescale DIU driver, targeting 2.6.26 kernel.
>
> arch/powerpc/configs/mpc8610_hpcd_defconfig | 198 +++++++++++++++++++++++----
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 190 ++++++++++++++++++++++++--
> arch/powerpc/sysdev/fsl_soc.c | 41 ++++++
> arch/powerpc/sysdev/fsl_soc.h | 23 +++
> 4 files changed, 413 insertions(+), 39 deletions(-)
The defconfig change gets almost 100% rejects and probably isn't
appropriate here and isn't very important. I dropped that part of the
patch.
^ permalink raw reply
* Access physical memory via mmap() on ppc440epx.
From: Leonid @ 2008-04-01 21:12 UTC (permalink / raw)
To: linuxppc-embedded
Hi:
I am trying to read from NOR flash, located on address 0xfc000000, on my
ppc440epx board (similar to Sequoia) from user space. Mmap call returns
fine, but actual access fails - here is GDB output:
Breakpoint 1, f_EVLOG_GetSectorInfo (sector=3D18, si=3D0x1004a398)
at
/home/leonid/LM300/software/u-boot/apps/diags/common/event_log.c:1580
1580
/home/leonid/LM300/software/u-boot/apps/diags/common/event_log.c: No
such file or di.
in
/home/leonid/LM300/software/u-boot/apps/diags/common/event_log.c
(gdb) p sector
$1 =3D 18
(gdb) p/x buf
$2 =3D 0x30028000
(gdb) x/10 0x30028000
0x30028000: Cannot access memory at address 0x30028000
(gdb) x/10 0x30028200
0x30028200: Cannot access memory at address 0x30028200
(gdb)
0x30028200 is mmap() result, next step leads to crash:
(gdb)
Machine check in kernel mode.
Data Read PLB Error
OPB to PLB3: BSTAT=3D 0x00000000
PLB3 to PLB4: BEAR=3D0x5c00819442310a80 BESR0=3D0x00000000 =
BESR1=3D0x00000000
PLB4 to PLB3: BEAR=3D0xa5876840c012269b BESR0=3D0x00000000 =
BESR1=3D0x00000000
PLB3 to OPB: BEAR=3D0xf0dffd99 BESR0=3D0x00000000 BESR1=3D0x00000000
PLB3 arbiter: BEAR=3D0xc1fcef0c ACR=3D0x90000000 BESR=3D0x00000000
PLB4 to OPB1: BEAR=3D0x0000000b9fbdfdb8 BESR0=3D0x00000000 =
BESR1=3D0x00000000
PLB40 Arbiter: BEAR=3D0x00000000fc240000 ACR=3D0xde000000 =
BESR0=3D0x0f000000
PLB41 Arbiter: BEAR=3D0xe7fb1dfdf3820fcb ACR=3D0xdf000000 =
BESR0=3D0x00000000
POB0: BEAR=3D0xc27e3194f0dffd99 BESR0=3D0x00000000 BESR1=3D0x00000000
OPB0: BEAR=3D0x0000000000000000 BSTAT=3D0x00000000
Oops: machine check, sig: 7 [#6]
NIP: C0000DF8 LR: 10010474 CTR: 00000000
REGS: c02acf50 TRAP: 0202 Not tainted (2.6.19)
MSR: 00001000 <ME> CR: 40000044 XER: 20000000
TASK =3D cfc00bf0[77] 'diags_server' THREAD: cf9de000
GPR00: 00000000 CF9DFF40 3001F040 30028000 7FB5FA00 00000000 61736800
FEFEFEFF
GPR08: 00000000 0002D200 10010474 CF9DFF40 10010494 1004B074 10360000
44004042
GPR16: 10413BFC 7FAF1F5F 7FAF1F5F 00000000 00000001 10440000 00000000
00000000
GPR24: 1016B924 00000002 00000000 30026E5C 30027A18 10027B4C 0FFEA73C
7FB5FA20
NIP [C0000DF8] Debug+0x78/0x130
LR [10010474] 0x10010474
Call Trace:
[CF9DFF40] [C00026EC] do_user_signal+0x74/0xc4 (unreliable)
Instruction dump:
7d4802a6 914b00a0 7d9d0aa6 918b00b4 7d3e0aa6 912b00b8 7d9a0aa6 902b0014
7d3b0aa6 902b0000 7d615b78 55290398 <900b0010> 906b001c 908b0020
90ab0024
Program terminated with signal SIGBUS, Bus error.
The program no longer exists.
I suspect it has something to do with memory configiration. Note that
Linux kernel is loaded by u-boot where all peripherals (NOR flash
included) configured properly and work.
I have BDI2000 connected and can (after stopping the board) see
registers and TLB entries:
440EPx>rd ebc0_b0cr
ebc0_b0cr: 0xfc0da000 -66215936
BUS configuration looks OK.
TLB entries look strange though. That what it was on u-boot stage:
440EPx>tlb 0 10
IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
0 : 00 40000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
2 : 00 c0000000 256MB V0 -> 1_c0000000 U:0000 -I-G- XWRXWR
3 : 00 f0000000 256MB V0 -> 1_f0000000 U:0000 WI-G- XWRXWR
4 : 00 80000000 256MB V0 -> 1_80000000 U:0000 -I-G- -WR-WR
5 : 00 90000000 256MB V0 -> 1_90000000 U:0000 -I-G- -WR-WR
6 : 00 a0000000 256MB V0 -> 1_a0000000 U:0000 -I-G- -WR-WR
7 : 00 b0000000 256MB V0 -> 1_b0000000 U:0000 -I-G- -WR-WR
8 : 00 d0000000 1KB V0 -> 1_d0000000 U:0000 -I-G- XWRXWR
9 : 00 e0000000 16MB V0 -> 0_e0000000 U:0000 -I--- XWRXWR
10 : 00 ea000000 1MB V0 -> 1_ea000000 U:0000 -I-G- XWRXWR
On Linux stage it looks rather different:
440EPx>tlb 0 40
IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
0 : 26 0ff9d000 4KB V0 -> 0_0fdc8000 U:0000 --MG- X-RX-R
1 : 26 30017000 4KB V0 -> 0_0fe3e000 U:0000 --MG- --R-WR
2 : 2a 10165000 4KB V0 -> 0_0028d000 U:0000 --MG- -WR-WR
3 : 2a 100a4000 4KB V0 -> 0_00767000 U:0000 ---G- X-RX-R
4 : 2a 1016b000 4KB V0 -> 0_00290000 U:0000 --MG- -WR-WR
5 : 2a 10077000 4KB V0 -> 0_007ac000 U:0000 ---G- X-RX-R
6 : 2a 10164000 4KB V0 -> 0_00295000 U:0000 --MG- --R-WR
7 : 2a 1019c000 4KB V0 -> 0_00536000 U:0000 --MG- -WR-WR
8 : 2a 100be000 4KB V0 -> 0_00774000 U:0000 ---G- X-RX-R
9 : 2a 10114000 4KB V0 -> 0_007b7000 U:0000 ---G- --R--R
10 : 2a 00000000 1KB -0 -> 0_007ef000 U:0000 ---G- --R--R
11 : 2a 10057000 4KB V0 -> 0_007ef000 U:0000 ---G- X-RX-R
12 : 2a 10117000 4KB V0 -> 0_007ba000 U:0000 ---G- --R--R
13 : 2a 10097000 4KB V0 -> 0_00792000 U:0000 ---G- X-RX-R
14 : 2a 10048000 4KB V0 -> 0_0fc27000 U:0000 ---G- X-RX-R
15 : 2a 10087000 4KB V0 -> 0_007db000 U:0000 ---G- X-RX-R
16 : 2a 10166000 4KB V0 -> 0_00299000 U:0000 --MG- -WR-WR
17 : 2a 10086000 4KB V0 -> 0_007da000 U:0000 ---G- X-RX-R
18 : 2a 1013c000 4KB V0 -> 0_00754000 U:0000 ---G- --R--R
19 : 2a 1008e000 4KB V0 -> 0_007a9000 U:0000 ---G- X-RX-R
20 : 2a 30000000 4KB V0 -> 0_00704000 U:0000 --MG- -WR-WR
21 : 2a 7fa1c000 4KB V0 -> 0_0fe37000 U:0000 --MG- -WR-WR
22 : 2a 1008d000 4KB V0 -> 0_007a8000 U:0000 ---G- X-RX-R
23 : 2a 1008c000 4KB V0 -> 0_007a7000 U:0000 ---G- X-RX-R
24 : 2a 100bd000 4KB V0 -> 0_00773000 U:0000 ---G- X-RX-R
25 : 00 fdfec000 4KB V0 -> 1_ef600000 U:0000 -IMG- ----WR
26 : 00 d1050000 4KB V0 -> 1_ef600000 U:0000 -IMG- ----WR
27 : 00 d1054000 4KB V0 -> 1_ef600000 U:0000 -IMG- ----WR
28 : 00 d1056000 4KB V0 -> 0_e0000000 U:0000 -IMG- ----WR
29 : 00 ff100000 4KB V0 -> 0_006b0000 U:0000 -IMG- ---XWR
30 : 26 10027000 4KB V0 -> 0_0fe80000 U:0000 --MG- --R-WR
...........................
Probably under MMU it should look this way? How to use mmap() then?
Thanks,
Leonid.
^ permalink raw reply
* Re: [PATCH 2/8] powerpc: replace `__attribute' by `__attribute__'
From: Paul Mackerras @ 2008-04-01 21:36 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, trivial, lkml
In-Reply-To: <47F27155.1000103@tiscali.nl>
Roel Kluin writes:
> replace `__attribute' by `__attribute__'
Why? Your commit message doesn't give any motivation.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2 v5] Add DIU platform code for MPC8610HPCD
From: Timur Tabi @ 2008-04-01 21:36 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev-devel, a.p.zijlstra, linux-kernel, linuxppc-dev,
scottwood, York Sun
In-Reply-To: <20080401140029.be918d87.akpm@linux-foundation.org>
Andrew Morton wrote:
> The defconfig change gets almost 100% rejects and probably isn't
> appropriate here and isn't very important.
It's weird that you get rejects, but otherwise you're correct. defconfigs are
just a convenience, anyway.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 04/11 v2] [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
From: Kumar Gala @ 2008-04-01 21:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18418.4984.671485.346817@cargo.ozlabs.ibm.com>
On Apr 1, 2008, at 5:50 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> For the sub-arches that support relocatable interrupt vectors (book-
>> e) its
>> reasonable to have memory start at a non-zero physical address.
>> For those
>> cases use the variable memstart_addr instead of the #define
>> PPC_MEMSTART
>> since the only uses of PPC_MEMSTART are for initialization and in the
>> future we can set memstart_addr at runtime to have a relocatable
>> kernel.
>
> In those cases, is it still true that the kernel sits at the start of
> the usable memory, or might there be usable memory before _stext?
> In other words, is PAGE_OFFSET == KERNELBASE still true or not?
Both cases are possible.
Here are the four cases I see:
* Normal kernel (kernel at physical 0)
* kexec kernel (kernel at physical 32M, but still has access to memory
from physical 0 to 32M)
* cAMP kernel (kernel at non-zero offset) [eg. 256M offset]
* kexec cAMP kernel (kernel at 256M+32M, but has access to 256M + size)
- k
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Kumar Gala @ 2008-04-01 21:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18418.2460.594352.712502@cargo.ozlabs.ibm.com>
On Apr 1, 2008, at 5:08 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Normally we assume kernel images will be loaded at offset 0. However
>> there are situations, like when the kernel itself is running at a
>> non-zero
>> physical address, that we don't want to load it at 0.
>>
>> Allow the wrapper to take an offset. We use this when building u-
>> boot images.
>
> This makes it a bit harder to build a kernel and then wrap it later
> on, since one would have to know what -m value to give. Would it
> possible for either the wrapper script or mkimage to peek in the ELF
> header of the vmlinux to work out what physical address to use?
Hmm, need to think about that. But my initial reaction is two fold.
One I don't think this information would be around and two don't we
already have this problem with a kdump kernel?
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Move phys_addr_t definition into asm/types.h
From: Kumar Gala @ 2008-04-01 22:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18417.44855.137234.450478@cargo.ozlabs.ibm.com>
On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use
>> it in
>> places that before would have caused recursive includes.
>>
>> For example to use phys_addr_t in <asm/page.h> we would have included
>> <asm/mmu.h> which would have possibly included <asm/mmu-hash64.h>
>> which
>> includes <asm/page.h>. Wheeee recursive include.
>
> In general this looks fine. I wonder if you should use u64 rather
> than unsigned long long. Since CONFIG_PHYS_64BIT=n on 64-bit machines
> (which is itself somewhat counterintuitive) we will actually use
> unsigned long on 64-bit machines, so it matters less than I originally
> thought, but it would be worth explaining that in a comment and/or the
> commit message.
We could change it to be:
/* Physical address used by some IO functions */
#if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
This seems a bit more self documenting which is always nice (and I can
add a comment in the commit message about CONFIG_PHYS_64BIT only
making sense on ppc32).
- k
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-04-01 23:12 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel
In-Reply-To: <47ED6BE5.9060807@semihalf.com>
Bartlomiej Sieka writes:
> What about http://patchwork.ozlabs.org/linuxppc/patch?id=17525 ? I don't
> see it in the merge branch of your repository, and it would be nice to
> get it upstream as it fixes boot problems on some MPC5200-based boards.
It needs a proper stand-alone commit message and an acked-by from
Grant. The commit message should explain why you are making the
changes you are making rather than just saying "the bulk of this patch
is taken from http://...".
Paul.
^ permalink raw reply
* Virtex V5FX PPC 440 Support In Xilinx Git Tree
From: John Linn @ 2008-04-01 23:41 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]
I pushed PowerPC 440 support to the Xilinx Git server with support for
ppc arch and with powerpc arch support coming in the near future.
A default kernel configuration file, ml507_defconfig, is provided in the
kernel tree to support the Xilinx ML507 board with the PowerPC 440.
Thanks,
John
[-- Attachment #2: Type: text/html, Size: 7503 bytes --]
^ permalink raw reply
* RE: xilinx Ml405 NFS mount problem
From: Robert Woodworth @ 2008-04-01 23:43 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-embedded
In-Reply-To: <20080401165329.D31E3AA008E@mail29-dub.bigfish.com>
Can you test your packet loss with your setup??
GigE or 100T??
Do you have hardware checksum turned on in your bitfile?
I strongly believe that there is a timing problem in the MPMC3/LL_TEMAC.
I think the smaller FX12 does not suffer as much as the larger FX60. My
FX12 is fairly good, my FX60 is very bad. Guessing. The FX20 in the
ML405 is somewhere between.
When I make small changes to my bit file (I'm currently working on an
image processing HDL module) the quality of my LL_TEMAC changes
dramatically. If I take out one of my custom modules and re-synthesize
the LL_TEMAC packet loss goes way up. Add another module, re-synthesize
and packet loss is down.
I would *really* like a Xilinx EDK expert give me some advise on this
issue.
Rob.
On Tue, 2008-04-01 at 10:53 -0600, John Linn wrote:
> Now that you say that, I have been running TCP with my NFS mount as I'm mounting across a corporate network.
>
> I am also using the latest LL TEMAC with EDK 10.1.
>
> Thanks,
> John
>
> -----Original Message-----
> From: Robert Woodworth [mailto:rwoodworth@securics.com]
> Sent: Tuesday, April 01, 2008 10:50 AM
> To: MingLiu
> Cc: John Linn; linuxppc-embedded@ozlabs.org
> Subject: RE: xilinx Ml405 NFS mount problem
>
> I think you may be suffering from the latest LL_TEMAC packet loss
> problem. (NFS/UDP really does not like packet loss)
>
>
> Let me guess.
> You are using a base system from "Base System Builder Wizard"?
> EDK 9.2i. Default syntheses/P&R options.
>
> I have seen a massive packet loss problems on my ML403 and two other
> boards I have with an FX60.
>
> This is probably a hardware problem.
> Xilinx has acknowledged an LL_TEMAC problem to me but has not provided a
> fix. I have heard that things are better with EDK/ISE-10.1 but I have
> not tested it.
>
>
> The vendor of one of my boards (Pico) has fixed the problem on the FX60
> by highly constraining the timing of the LL_TEMAC in map/PR. On my
> ML403 I used similar constraints and it fixed the problem, but only if
> the device is plugged into a GigE switch. The problem is still there
> with the same .bit file on a 100-T switch.
>
>
> Are you on a GigE switch?
>
>
>
> Rob.
>
>
>
>
>
>
> On Tue, 2008-04-01 at 16:15 +0000, MingLiu wrote:
> > Dear John,
> >
> > Thank you for your replying.
> >
> > >It’s not obvious to me what the problem is as I don’t see any driver
> > failures. Have you >tried using a ramdisk and then seeing if the
> > network is working before using NFS root?
> >
> > Not yet. I will try it soon. However from the information on the
> > LL_TEMAC, it seems everything is fine and it should work.
> >
> >
> >
> > >And I’m assuming you have used the NFS root before so you know that
> > it’s good for sure.
> >
> >
> >
> > >I test on the ML405 with NFS root and haven’t seen this problem, but
> > my setup is a little different. I use DHCP rather than >a static IP,
> > but other than that it’s similar.
> >
> >
> >
> > Yes. I used NFS before. I can make sure my NFS server works well. Also
> > in principle, static IP should get a same result as DHCP, I think.
> >
> >
> >
> > >How long has it been since you pulled from the Xilinx Git tree?
> >
> >
> >
> > I just pulled the Xilinx tree quite recently. I am using a latest
> > kernel.
> >
> >
> >
> > BR
> >
> > Ming
> >
> >
> >
> >
> >
> > And I’m assuming you have used the NFS root before so you know
> > that it’s good for sure.
> >
> >
> >
> > I test on the ML405 with NFS root and haven’t seen this
> > problem, but my setup is a little different. I use DHCP
> > rather than a static IP, but other than that it’s similar.
> >
> >
> >
> > I’m assuming that you accidentally got 2 different powerup
> > outputs in the message below as the 1st stops and a 2nd starts
> > in the middle.
> >
> >
> >
> > How long has it been since you pulled from the Xilinx Git
> > tree?
> >
> >
> >
> > Thanks,
> >
> > John
> >
> >
> >
> >
> > ______________________________________________________________
> > From: linuxppc-embedded-bounces
> > +john.linn=xilinx.com@ozlabs.org
> > [mailto:linuxppc-embedded-bounces
> > +john.linn=xilinx.com@ozlabs.org] On Behalf Of MingLiu
> > Sent: Tuesday, April 01, 2008 8:12 AM
> > To: linuxppc-embedded@ozlabs.org
> > Subject: xilinx Ml405 NFS mount problem
> >
> >
> >
> >
> > Dear friends,
> >
> > I am bringing up my kernel from Xilinx git tree. Unfortunately I met some
> > problem when mounting the root file system. Here is the information
> > listed. I will appreciate a lot if someone can help me out of the trouble.
> > Thanks a lot!
> >
> >
> > loaded at: 00400000 0059F19C
> > board data at: 0059D120 0059D19C
> > relocated to: 004050C8 00405144
> > zimage at: 00405F3F 0059C025
> > avail ram: 005A0000 08000000
> >
> > Linux/PPC load: root=/dev/nfs
> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400
> > mem=32M
> > Uncompressing Linux...done.
> > Now booting the kernel
> > Linux version 2.6.24-rc8-xlnx-g1db182b8-dirty (mingliu@cca01) (gcc version
> > 3.4.1) #7 Tue Apr 1 14:55:25 CEST 2008
> > Xilinx Generic PowerPC board support package (Xilinx ML405) (Virtex-4 FX)
> > Zone PFN ranges:
> > DMA 0 -> 8192
> >
> > Normal 8192 -> 8192
> >
> > HighMem 8192 -> 8192
> > Movable zone start PFN for each node
> > early_node_map[1] active PFN ranges
> > 0: 0 -> 8192
> > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
> > Kernel command line: root=/de v/nfs
> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400
> > mem=32M
> > Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
> > PID hash table entries: 128 (order: 7, 512 bytes)
> > Console: colour dummy device 80x25
> > Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
> > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > Memory: 28884k available (2552k kernel code, 944k data, 84k init, 0k highmem)
> > SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
> > Mount-cache hash table entries: 512
> > net_namespace: 64 bytes
> > NET: Registered protocol family 16
> > Registering device uartlite:0
> > Fixup MAC address for xilinx_lltemac:0
> > Regis tering device xilinx_lltemac:0
> > NET: Registered protocol family 2
> > IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> > TCP established hash table entries: 1024 (order: 1, 8192 bytes)
> > TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> > TCP: Hash tables configured (established 1024 bind 1024)
> > TCP reno registered
> > sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
> > Call Trace:
> > [c1c0fe50] [c0008b70] show_stack+0x40/0x194 (unreliable)
> > [c1c0fe90] [c003aed4] set_fail+0x68/0x80
> > [c1c0feb0] [c003b4ec] sysctl_check_table+0x600/0x77c
> > [c1c0fef0] [c003b4d4] sysctl_check_table+0x5e8/0x77c
> > [c1c0ff30] [c002605c] register_sysctl_table+0x64/0xb4
> > [c1c0ff50] [c034579c] register_ppc_htab_sysctl+0x18/0x2c
> > [c1c0ff60] [c034482c] kernel_init+0x94/0x2bc
> > [c1c0fff0] [c0004d58] kernel_thread+0x44/0x60
> > Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> > fuse init (API version 7.9)
> > io scheduler noop registered
> > io scheduler anticipatory registered
> > io scheduler deadline registered
> > io scheduler cfq registered (default)
> > uartlite.0: ttyUL0 at MM IO 0x84000003 (irq = 3) is a uartlite
> > console [ttyUL0] enabled
> > loop: module loaded
> > nbd: registered device at major 43
> > xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: a:35: 1: 2: 3
> > xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode.
> > XLlTemac: Dma base address: phy: 0x84600100, virt: 0xc3008100
> > XLlTemac: buffer descriptor size: 32768 (0x8000)
> > XLlTemac: Allocating DMA descriptors with kmalloc<6>XLlTemac:
> > (buffer_descriptor_init) phy: 0x1d18000, virt: 0xc1d18000, size: 0x8000
> > XTemac: PHY detected at address 7.
> > xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at 0x81C00000 mapped
> > to 0xC3004000, irq=2
> > console [netcon0] enabled
> > Linux version 2.6.24-rc8-xlnx-g1db182b8-dirty (mingliu@cca01) (gcc version
> > 3.4.1) #7 Tue Apr 1 14:55:25 CEST 2008
> >
> > Xilinx Generic PowerPC board support package (Xilinx ML405)
> > (Virtex-4 FX)
> >
> > Zone PFN ranges:
> > DMA 0 -> 8192
> > Normal 8192 -> 8192
> > HighMem 8192 -> 8192
> > Movable zone start PFN for each node
> > early_node_map[1] active PFN range
> > s
> > 0: 0 -> 8192
> > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
> > Kernel command line: root=/dev/nfs
> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400
> > mem=32M
> > Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
> > PID hash table entries: 128 (order: 7, 512 bytes)
> > Console: colour dummy device 80x25
> > Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
> > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > Memory: 28884k available (2552k kernel code, 944k data, 84k init, 0k highmem)
> > SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
> > Mount-cache hash table entries: 512
> > n
> > et_namespace: 64 bytes
> > NET: Registered protocol family 16
> > Registering device uartlite:0
> > Fixup MAC address for xilinx_lltemac:0
> > Registering device xilinx_lltemac:0
> > NET: Registered protocol family 2
> > IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> > TCP established hash table entries: 1024 (order: 1, 8192 bytes)
> > TCP bind hash table entries: 1024
> > (order: 0, 4096 bytes)
> > TCP: Hash tables configured (established 1024 bind 1024)
> > TCP reno registered
> > sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
> > Call Trace:
> > [c1c0fe50] [c0008b70] show_stack+0x40/0x194 (unreliable)
> > [c1c0fe90] [c003aed4] set_fail+0x68/0x80
> > [c1c0feb0] [c003b4ec] sysctl_check_table+0x600/0x77c
> > [c1c0fef0] [c003b4d4] sysctl_c
> > heck_table+0x5e8/0x77c
> > [c1c0ff30] [c002605c] register_sysctl_table+0x64/0xb4
> > [c1c0ff50] [c034579c] register_ppc_htab_sysctl+0x18/0x2c
> > [c1c0ff60] [c034482c] kernel_init+0x94/0x2bc
> > [c1c0fff0] [c0004d58] kernel_thread+0x44/0x60
> > Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> > fuse init (API version 7.9)
> > io scheduler noop registered<
> > /SPAN>
> > io scheduler anticipatory registered
> > io scheduler deadline registered
> > io scheduler cfq registered (default)
> > uartlite.0: ttyUL0 at MMIO 0x84000003 (irq = 3) is a uartlite
> > console [ttyUL0] enabled
> > loop: module loaded
> > nbd: registered device at major 43
> > xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: a:35: 1: 2: 3
> > xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode.
> > XLlTemac: Dma base address: phy: 0x84600100, virt: 0xc3008100
> > XLlTemac: buffer descriptor size: 32768 (0x8000)
> > XLlTemac: Allocating DMA descriptors with kmalloc<6>XLlTemac:
> > (buffer_descriptor_init) phy: 0x1d18000, virt: 0xc1d18000, size: 0x8000
> > XTemac: PHY detected at address 7.
> > xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at 0x81C00000 mapped
> > <
> > SPAN style="FONT-SIZE: 12pt">to 0xC3004000, irq=2
> > console [netcon0] enabled
> > netconsole: network logging started
> > Generic platform RAM MTD, (c) 2004 Simtec Electronics
> > mice: PS/2 mouse device common for all mice
> > TCP cubic registered
> > NET: Registered protocol family 1
> > NET: Registered protocol family 17
> > RPC: Registered udp transport module.
> > RPC: Registered tcp transport module.
> > eth0: XLlTemac: Options: 0x3fa
> > eth0: XLlTemac: allocating interrupt 0 for dma mode tx.
> > eth0: XLlTemac: allocating interrupt 1 for dma mode rx.
> > eth0: XLlTemac: speed set to 1000Mb/s
> > eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4
> > eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254
> > IP-Config: Complete:
> >
> > device=eth0, addr=192.168.0.4, mask=255.255.255.0, gw=192.168.0.3,
> > host=192.168.0.4, domain=, nis-domain=(none),
> > bootserver=192.168.0.3, rootserver=192.168.0.3, rootpath=
> > Looking up port of RPC 100003/2 on 192.168.0.3
> > rpcbind: server 192.168.0.3 not responding, timed out
> > Root-NFS: Unable to get nfsd port number from server, using default
> > Looking up port of RPC 10000
> > 5/1 on 192.168.0.3
> > rpcbind: server 192.168.0.3 not responding, timed out
> > Root-NFS: Unable to get mountd port number from server, using default
> > mount: server 192.168.0.3 not responding, timed out
> > Root-NFS: Server returned error -5 while mounting /home/mingliu/ml403_rootfs
> > VFS: Unable to mount root fs via NFS, trying floppy.
> > VFS: Cannot open root device "nfs" or unknown-block(2,0)
> > Please append a correct "root=" boot option; here are
> > the available
> > partitions:
> > Kernel panic - not syncing: VFS: Unable to mount root fs on
> > unknown-block(2,0)
> > Rebooting in 180 seconds..
> >
> >
> > BR
> > Ming
> >
> >
> >
> >
> > ______________________________________________________________
> > Windows Live Writer,支持离线撰写博客内容,随时随地想写就写。
> > 立即使用!
> >
> >
> >
> >
> > ______________________________________________________________________
> > 使用新一代 Windows Live Messenger 轻松交流和共享! 立即体验!
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
^ permalink raw reply
* RE: xilinx Ml405 NFS mount problem
From: Rick Moleres @ 2008-04-01 23:54 UTC (permalink / raw)
To: Robert Woodworth, John Linn; +Cc: linuxppc-embedded
In-Reply-To: <1207093428.4830.79.camel@PisteOff>
Robert,
I saw an earlier email regarding v1.00b of xps_ll_temac. Besides the =
checksum offload issue in this version of the core, there is also an =
issue when receiving multicast packets where we've seen some ping =
packets lost around receipt of a multicast packets. So for example, we =
saw this issue when attached to a switch/router that sends out STP =
packets. When attached directly between target and host the issue =
disappeared. I believe this issue is fixed in v1.01a of the core being =
released in EDK 10.1. I also think there's an answer record on how to =
work around this issue, but I don't have that AR number handy (search =
the Xilinx website and let me know if you don't find it - if you think =
this applies to you at all).
The issue you describe below doesn't appear to match the multicast =
issue, as you should see that regardless of which part you're in. You =
may want to talk to your FAE as to possible hw timing issues.
Thanks,
Rick
-----Original Message-----
From: linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org] On =
Behalf Of Robert Woodworth
Sent: Tuesday, April 01, 2008 5:44 PM
To: John Linn
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: xilinx Ml405 NFS mount problem
Can you test your packet loss with your setup??
GigE or 100T??
Do you have hardware checksum turned on in your bitfile?
I strongly believe that there is a timing problem in the MPMC3/LL_TEMAC.
I think the smaller FX12 does not suffer as much as the larger FX60. My
FX12 is fairly good, my FX60 is very bad. Guessing. The FX20 in the
ML405 is somewhere between.
When I make small changes to my bit file (I'm currently working on an
image processing HDL module) the quality of my LL_TEMAC changes
dramatically. If I take out one of my custom modules and re-synthesize
the LL_TEMAC packet loss goes way up. Add another module, re-synthesize
and packet loss is down.
I would *really* like a Xilinx EDK expert give me some advise on this
issue.
Rob.
On Tue, 2008-04-01 at 10:53 -0600, John Linn wrote:
> Now that you say that, I have been running TCP with my NFS mount as =
I'm mounting across a corporate network.
>=20
> I am also using the latest LL TEMAC with EDK 10.1.
>=20
> Thanks,
> John
>=20
> -----Original Message-----
> From: Robert Woodworth [mailto:rwoodworth@securics.com]=20
> Sent: Tuesday, April 01, 2008 10:50 AM
> To: MingLiu
> Cc: John Linn; linuxppc-embedded@ozlabs.org
> Subject: RE: xilinx Ml405 NFS mount problem
>=20
> I think you may be suffering from the latest LL_TEMAC packet loss
> problem. (NFS/UDP really does not like packet loss)
>=20
>=20
> Let me guess. =20
> You are using a base system from "Base System Builder Wizard"?
> EDK 9.2i. Default syntheses/P&R options.
>=20
> I have seen a massive packet loss problems on my ML403 and two other
> boards I have with an FX60.
>=20
> This is probably a hardware problem.
> Xilinx has acknowledged an LL_TEMAC problem to me but has not provided =
a
> fix. I have heard that things are better with EDK/ISE-10.1 but I have
> not tested it.
>=20
>=20
> The vendor of one of my boards (Pico) has fixed the problem on the =
FX60
> by highly constraining the timing of the LL_TEMAC in map/PR. On my
> ML403 I used similar constraints and it fixed the problem, but only if
> the device is plugged into a GigE switch. The problem is still there
> with the same .bit file on a 100-T switch.=20
>=20
>=20
> Are you on a GigE switch?
>=20
>=20
>=20
> Rob.
>=20
>=20
>=20
>=20
>=20
>=20
> On Tue, 2008-04-01 at 16:15 +0000, MingLiu wrote:
> > Dear John,
> > =20
> > Thank you for your replying.=20
> >=20
> > >It=A1=AFs not obvious to me what the problem is as I don=A1=AFt see =
any driver
> > failures. Have you >tried using a ramdisk and then seeing if the
> > network is working before using NFS root? =20
> > =20
> > Not yet. I will try it soon. However from the information on the
> > LL_TEMAC, it seems everything is fine and it should work.=20
> > =20
> >=20
> >=20
> > >And I=A1=AFm assuming you have used the NFS root before so you know =
that
> > it=A1=AFs good for sure.
> >=20
> > =20
> >=20
> > >I test on the ML405 with NFS root and haven=A1=AFt seen this =
problem, but
> > my setup is a little different. I use DHCP rather than >a static =
IP,
> > but other than that it=A1=AFs similar.
> >=20
> > =20
> >=20
> > Yes. I used NFS before. I can make sure my NFS server works well. =
Also
> > in principle, static IP should get a same result as DHCP, I think.=20
> >=20
> > =20
> >=20
> > >How long has it been since you pulled from the Xilinx Git tree?
> >=20
> > =20
> >=20
> > I just pulled the Xilinx tree quite recently. I am using a latest
> > kernel.
> >=20
> > =20
> >=20
> > BR=20
> >=20
> > Ming
> >=20
> > =20
> >=20
> > =20
> > =20
> > And I=A1=AFm assuming you have used the NFS root before so =
you know
> > that it=A1=AFs good for sure.
> > =20
> > =20
> > =20
> > I test on the ML405 with NFS root and haven=A1=AFt seen this
> > problem, but my setup is a little different. I use DHCP
> > rather than a static IP, but other than that it=A1=AFs =
similar.
> > =20
> > =20
> > =20
> > I=A1=AFm assuming that you accidentally got 2 different =
powerup
> > outputs in the message below as the 1st stops and a 2nd =
starts
> > in the middle.
> > =20
> > =20
> > =20
> > How long has it been since you pulled from the Xilinx Git
> > tree?
> > =20
> > =20
> > =20
> > Thanks,
> > =20
> > John
> > =20
> > =20
> > =20
> > =20
> > =
______________________________________________________________
> > From: linuxppc-embedded-bounces
> > +john.linn=3Dxilinx.com@ozlabs.org
> > [mailto:linuxppc-embedded-bounces
> > +john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of MingLiu
> > Sent: Tuesday, April 01, 2008 8:12 AM
> > To: linuxppc-embedded@ozlabs.org
> > Subject: xilinx Ml405 NFS mount problem
> > =20
> > =20
> > =20
> > =20
> > Dear friends,
> > =20
> > I am bringing up my kernel from Xilinx git tree. =
Unfortunately I met some
> > problem when mounting the root file system. Here is the =
information
> > listed. I will appreciate a lot if someone can help me out =
of the trouble.=20
> > Thanks a lot!
> > =20
> > =20
> > loaded at: 00400000 0059F19C
> > board data at: 0059D120 0059D19C
> > relocated to: 004050C8 00405144
> > zimage at: 00405F3F 0059C025
> > avail ram: 005A0000 08000000
> > =20
> > Linux/PPC load: root=3D/dev/nfs
> > ip=3D192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=3D192.168.0.3:/home/mingliu/ml403_rootfs =
console=3DttyUL0,38400
> > mem=3D32M
> > Uncompressing Linux...done.
> > Now booting the kernel
> > Linux version 2.6.24-rc8-xlnx-g1db182b8-dirty =
(mingliu@cca01) (gcc version
> > 3.4.1) #7 Tue Apr 1 14:55:25 CEST 2008
> > Xilinx Generic PowerPC board support package (Xilinx ML405) =
(Virtex-4 FX)
> > Zone PFN ranges:
> > DMA 0 -> 8192
> > =20
> > Normal 8192 -> 8192
> > =20
> > HighMem 8192 -> 8192
> > Movable zone start PFN for each node
> > early_node_map[1] active PFN ranges
> > 0: 0 -> 8192
> > Built 1 zonelists in Zone order, mobility grouping on. =
Total pages: 8128
> > Kernel command line: root=3D/de v/nfs
> > ip=3D192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=3D192.168.0.3:/home/mingliu/ml403_rootfs =
console=3DttyUL0,38400
> > mem=3D32M
> > Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
> > PID hash table entries: 128 (order: 7, 512 bytes)
> > Console: colour dummy device 80x25
> > Dentry cache hash table entries: 4096 (order: 2, 16384 =
bytes)
> > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > Memory: 28884k available (2552k kernel code, 944k data, 84k =
init, 0k highmem)
> > SLUB: Genslabs=3D11, HWalign=3D32, Order=3D0-1, =
MinObjects=3D4, CPUs=3D1, Nodes=3D1
> > Mount-cache hash table entries: 512
> > net_namespace: 64 bytes
> > NET: Registered protocol family 16
> > Registering device uartlite:0
> > Fixup MAC address for xilinx_lltemac:0
> > Regis tering device xilinx_lltemac:0
> > NET: Registered protocol family 2
> > IP route cache hash table entries: 1024 (order: 0, 4096 =
bytes)
> > TCP established hash table entries: 1024 (order: 1, 8192 =
bytes)
> > TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> > TCP: Hash tables configured (established 1024 bind 1024)
> > TCP reno registered
> > sysctl table check failed: /kernel/l2cr .1.31 Missing =
strategy
> > Call Trace:
> > [c1c0fe50] [c0008b70] show_stack+0x40/0x194 (unreliable)
> > [c1c0fe90] [c003aed4] set_fail+0x68/0x80
> > [c1c0feb0] [c003b4ec] sysctl_check_table+0x600/0x77c
> > [c1c0fef0] [c003b4d4] sysctl_check_table+0x5e8/0x77c
> > [c1c0ff30] [c002605c] register_sysctl_table+0x64/0xb4
> > [c1c0ff50] [c034579c] register_ppc_htab_sysctl+0x18/0x2c
> > [c1c0ff60] [c034482c] kernel_init+0x94/0x2bc
> > [c1c0fff0] [c0004d58] kernel_thread+0x44/0x60
> > Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> > fuse init (API version 7.9)
> > io scheduler noop registered
> > io scheduler anticipatory registered
> > io scheduler deadline registered
> > io scheduler cfq registered (default)
> > uartlite.0: ttyUL0 at MM IO 0x84000003 (irq =3D 3) is a =
uartlite
> > console [ttyUL0] enabled
> > loop: module loaded
> > nbd: registered device at major 43
> > xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: =
a:35: 1: 2: 3
> > xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode.
> > XLlTemac: Dma base address: phy: 0x84600100, virt: =
0xc3008100
> > XLlTemac: buffer descriptor size: 32768 (0x8000)
> > XLlTemac: Allocating DMA descriptors with =
kmalloc<6>XLlTemac:
> > (buffer_descriptor_init) phy: 0x1d18000, virt: 0xc1d18000, =
size: 0x8000
> > XTemac: PHY detected at address 7.
> > xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at =
0x81C00000 mapped
> > to 0xC3004000, irq=3D2
> > console [netcon0] enabled
> > Linux version 2.6.24-rc8-xlnx-g1db182b8-dirty =
(mingliu@cca01) (gcc version
> > 3.4.1) #7 Tue Apr 1 14:55:25 CEST 2008
> > =20
> > Xilinx Generic PowerPC board support package (Xilinx ML405)
> > (Virtex-4 FX)
> > =20
> > Zone PFN ranges:
> > DMA 0 -> 8192
> > Normal 8192 -> 8192
> > HighMem 8192 -> 8192
> > Movable zone start PFN for each node
> > early_node_map[1] active PFN range
> > s
> > 0: 0 -> 8192
> > Built 1 zonelists in Zone order, mobility grouping on. =
Total pages: 8128
> > Kernel command line: root=3D/dev/nfs
> > ip=3D192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=3D192.168.0.3:/home/mingliu/ml403_rootfs =
console=3DttyUL0,38400
> > mem=3D32M
> > Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
> > PID hash table entries: 128 (order: 7, 512 bytes)
> > Console: colour dummy device 80x25
> > Dentry cache hash table entries: 4096 (order: 2, 16384 =
bytes)
> > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > Memory: 28884k available (2552k kernel code, 944k data, 84k =
init, 0k highmem)
> > SLUB: Genslabs=3D11, HWalign=3D32, Order=3D0-1, =
MinObjects=3D4, CPUs=3D1, Nodes=3D1
> > Mount-cache hash table entries: 512
> > n
> > et_namespace: 64 bytes
> > NET: Registered protocol family 16
> > Registering device uartlite:0
> > Fixup MAC address for xilinx_lltemac:0
> > Registering device xilinx_lltemac:0
> > NET: Registered protocol family 2
> > IP route cache hash table entries: 1024 (order: 0, 4096 =
bytes)
> > TCP established hash table entries: 1024 (order: 1, 8192 =
bytes)
> > TCP bind hash table entries: 1024
> > (order: 0, 4096 bytes)
> > TCP: Hash tables configured (established 1024 bind 1024)
> > TCP reno registered
> > sysctl table check failed: /kernel/l2cr .1.31 Missing =
strategy
> > Call Trace:
> > [c1c0fe50] [c0008b70] show_stack+0x40/0x194 (unreliable)
> > [c1c0fe90] [c003aed4] set_fail+0x68/0x80
> > [c1c0feb0] [c003b4ec] sysctl_check_table+0x600/0x77c
> > [c1c0fef0] [c003b4d4] sysctl_c
> > heck_table+0x5e8/0x77c
> > [c1c0ff30] [c002605c] register_sysctl_table+0x64/0xb4
> > [c1c0ff50] [c034579c] register_ppc_htab_sysctl+0x18/0x2c
> > [c1c0ff60] [c034482c] kernel_init+0x94/0x2bc
> > [c1c0fff0] [c0004d58] kernel_thread+0x44/0x60
> > Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> > fuse init (API version 7.9)
> > io scheduler noop registered<
> > /SPAN>
> > io scheduler anticipatory registered
> > io scheduler deadline registered
> > io scheduler cfq registered (default)
> > uartlite.0: ttyUL0 at MMIO 0x84000003 (irq =3D 3) is a =
uartlite
> > console [ttyUL0] enabled
> > loop: module loaded
> > nbd: registered device at major 43
> > xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: =
a:35: 1: 2: 3
> > xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode.
> > XLlTemac: Dma base address: phy: 0x84600100, virt: =
0xc3008100
> > XLlTemac: buffer descriptor size: 32768 (0x8000)
> > XLlTemac: Allocating DMA descriptors with =
kmalloc<6>XLlTemac:
> > (buffer_descriptor_init) phy: 0x1d18000, virt: 0xc1d18000, =
size: 0x8000
> > XTemac: PHY detected at address 7.
> > xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at =
0x81C00000 mapped
> > <
> > SPAN style=3D"FONT-SIZE: 12pt">to 0xC3004000, irq=3D2
> > console [netcon0] enabled
> > netconsole: network logging started
> > Generic platform RAM MTD, (c) 2004 Simtec Electronics
> > mice: PS/2 mouse device common for all mice
> > TCP cubic registered
> > NET: Registered protocol family 1
> > NET: Registered protocol family 17
> > RPC: Registered udp transport module.
> > RPC: Registered tcp transport module.
> > eth0: XLlTemac: Options: 0x3fa
> > eth0: XLlTemac: allocating interrupt 0 for dma mode tx.
> > eth0: XLlTemac: allocating interrupt 1 for dma mode rx.
> > eth0: XLlTemac: speed set to 1000Mb/s
> > eth0: XLlTemac: Send Threshold =3D 24, Receive Threshold =3D =
4
> > eth0: XLlTemac: Send Wait bound =3D 254, Receive Wait bound =
=3D 254
> > IP-Config: Complete:
> > =20
> > device=3Deth0, addr=3D192.168.0.4, =
mask=3D255.255.255.0, gw=3D192.168.0.3,
> > host=3D192.168.0.4, domain=3D, nis-domain=3D(none),
> > bootserver=3D192.168.0.3, rootserver=3D192.168.0.3, =
rootpath=3D
> > Looking up port of RPC 100003/2 on 192.168.0.3
> > rpcbind: server 192.168.0.3 not responding, timed out
> > Root-NFS: Unable to get nfsd port number from server, using =
default
> > Looking up port of RPC 10000
> > 5/1 on 192.168.0.3
> > rpcbind: server 192.168.0.3 not responding, timed out
> > Root-NFS: Unable to get mountd port number from server, =
using default
> > mount: server 192.168.0.3 not responding, timed out
> > Root-NFS: Server returned error -5 while mounting =
/home/mingliu/ml403_rootfs
> > VFS: Unable to mount root fs via NFS, trying floppy.
> > VFS: Cannot open root device "nfs" or unknown-block(2,0)
> > Please append a correct "root=3D" boot option; here are=20
> > the available
> > partitions:
> > Kernel panic - not syncing: VFS: Unable to mount root fs on
> > unknown-block(2,0)
> > Rebooting in 180 seconds..
> > =20
> > =20
> > BR
> > Ming
> > =20
> > =20
> > =20
> > =20
> > =
______________________________________________________________
> > Windows Live =
Writer=A3=AC=D6=A7=B3=D6=C0=EB=CF=DF=D7=AB=D0=B4=B2=A9=BF=CD=C4=DA=C8=DD=A3=
=AC=CB=E6=CA=B1=CB=E6=B5=D8=CF=EB=D0=B4=BE=CD=D0=B4=A1=A3
> > =C1=A2=BC=B4=CA=B9=D3=C3=A3=A1
> > =20
> > =20
> >=20
> >=20
> > =
______________________________________________________________________
> > =CA=B9=D3=C3=D0=C2=D2=BB=B4=FA Windows Live Messenger =
=C7=E1=CB=C9=BD=BB=C1=F7=BA=CD=B9=B2=CF=ED=A3=A1 =
=C1=A2=BC=B4=CC=E5=D1=E9=A3=A1=20
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
>=20
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: xilinx Ml405 NFS mount problem
From: John Linn @ 2008-04-01 23:55 UTC (permalink / raw)
To: Robert Woodworth; +Cc: linuxppc-embedded
In-Reply-To: <1207093428.4830.79.camel@PisteOff>
Hi Rob,
I am using GigE and no checksum offload.
I don't have a quick way to test packet loss.
EDK 10.1 may help your problem.
-- John
-----Original Message-----
From: Robert Woodworth [mailto:rwoodworth@securics.com]=20
Sent: Tuesday, April 01, 2008 5:44 PM
To: John Linn
Cc: MingLiu; linuxppc-embedded@ozlabs.org
Subject: RE: xilinx Ml405 NFS mount problem
Can you test your packet loss with your setup??
GigE or 100T??
Do you have hardware checksum turned on in your bitfile?
I strongly believe that there is a timing problem in the MPMC3/LL_TEMAC.
I think the smaller FX12 does not suffer as much as the larger FX60. My
FX12 is fairly good, my FX60 is very bad. Guessing. The FX20 in the
ML405 is somewhere between.
When I make small changes to my bit file (I'm currently working on an
image processing HDL module) the quality of my LL_TEMAC changes
dramatically. If I take out one of my custom modules and re-synthesize
the LL_TEMAC packet loss goes way up. Add another module, re-synthesize
and packet loss is down.
I would *really* like a Xilinx EDK expert give me some advise on this
issue.
Rob.
On Tue, 2008-04-01 at 10:53 -0600, John Linn wrote:
> Now that you say that, I have been running TCP with my NFS mount as =
I'm mounting across a corporate network.
>=20
> I am also using the latest LL TEMAC with EDK 10.1.
>=20
> Thanks,
> John
>=20
> -----Original Message-----
> From: Robert Woodworth [mailto:rwoodworth@securics.com]=20
> Sent: Tuesday, April 01, 2008 10:50 AM
> To: MingLiu
> Cc: John Linn; linuxppc-embedded@ozlabs.org
> Subject: RE: xilinx Ml405 NFS mount problem
>=20
> I think you may be suffering from the latest LL_TEMAC packet loss
> problem. (NFS/UDP really does not like packet loss)
>=20
>=20
> Let me guess. =20
> You are using a base system from "Base System Builder Wizard"?
> EDK 9.2i. Default syntheses/P&R options.
>=20
> I have seen a massive packet loss problems on my ML403 and two other
> boards I have with an FX60.
>=20
> This is probably a hardware problem.
> Xilinx has acknowledged an LL_TEMAC problem to me but has not provided =
a
> fix. I have heard that things are better with EDK/ISE-10.1 but I have
> not tested it.
>=20
>=20
> The vendor of one of my boards (Pico) has fixed the problem on the =
FX60
> by highly constraining the timing of the LL_TEMAC in map/PR. On my
> ML403 I used similar constraints and it fixed the problem, but only if
> the device is plugged into a GigE switch. The problem is still there
> with the same .bit file on a 100-T switch.=20
>=20
>=20
> Are you on a GigE switch?
>=20
>=20
>=20
> Rob.
>=20
>=20
>=20
>=20
>=20
>=20
> On Tue, 2008-04-01 at 16:15 +0000, MingLiu wrote:
> > Dear John,
> > =20
> > Thank you for your replying.=20
> >=20
> > >It=A1=AFs not obvious to me what the problem is as I don=A1=AFt see =
any driver
> > failures. Have you >tried using a ramdisk and then seeing if the
> > network is working before using NFS root? =20
> > =20
> > Not yet. I will try it soon. However from the information on the
> > LL_TEMAC, it seems everything is fine and it should work.=20
> > =20
> >=20
> >=20
> > >And I=A1=AFm assuming you have used the NFS root before so you know =
that
> > it=A1=AFs good for sure.
> >=20
> > =20
> >=20
> > >I test on the ML405 with NFS root and haven=A1=AFt seen this =
problem, but
> > my setup is a little different. I use DHCP rather than >a static =
IP,
> > but other than that it=A1=AFs similar.
> >=20
> > =20
> >=20
> > Yes. I used NFS before. I can make sure my NFS server works well. =
Also
> > in principle, static IP should get a same result as DHCP, I think.=20
> >=20
> > =20
> >=20
> > >How long has it been since you pulled from the Xilinx Git tree?
> >=20
> > =20
> >=20
> > I just pulled the Xilinx tree quite recently. I am using a latest
> > kernel.
> >=20
> > =20
> >=20
> > BR=20
> >=20
> > Ming
> >=20
> > =20
> >=20
> > =20
> > =20
> > And I=A1=AFm assuming you have used the NFS root before so =
you know
> > that it=A1=AFs good for sure.
> > =20
> > =20
> > =20
> > I test on the ML405 with NFS root and haven=A1=AFt seen this
> > problem, but my setup is a little different. I use DHCP
> > rather than a static IP, but other than that it=A1=AFs =
similar.
> > =20
> > =20
> > =20
> > I=A1=AFm assuming that you accidentally got 2 different =
powerup
> > outputs in the message below as the 1st stops and a 2nd =
starts
> > in the middle.
> > =20
> > =20
> > =20
> > How long has it been since you pulled from the Xilinx Git
> > tree?
> > =20
> > =20
> > =20
> > Thanks,
> > =20
> > John
> > =20
> > =20
> > =20
> > =20
> > =
______________________________________________________________
> > From: linuxppc-embedded-bounces
> > +john.linn=3Dxilinx.com@ozlabs.org
> > [mailto:linuxppc-embedded-bounces
> > +john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of MingLiu
> > Sent: Tuesday, April 01, 2008 8:12 AM
> > To: linuxppc-embedded@ozlabs.org
> > Subject: xilinx Ml405 NFS mount problem
> > =20
> > =20
> > =20
> > =20
> > Dear friends,
> > =20
> > I am bringing up my kernel from Xilinx git tree. =
Unfortunately I met some
> > problem when mounting the root file system. Here is the =
information
> > listed. I will appreciate a lot if someone can help me out =
of the trouble.=20
> > Thanks a lot!
> > =20
> > =20
> > loaded at: 00400000 0059F19C
> > board data at: 0059D120 0059D19C
> > relocated to: 004050C8 00405144
> > zimage at: 00405F3F 0059C025
> > avail ram: 005A0000 08000000
> > =20
> > Linux/PPC load: root=3D/dev/nfs
> > ip=3D192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=3D192.168.0.3:/home/mingliu/ml403_rootfs =
console=3DttyUL0,38400
> > mem=3D32M
> > Uncompressing Linux...done.
> > Now booting the kernel
> > Linux version 2.6.24-rc8-xlnx-g1db182b8-dirty =
(mingliu@cca01) (gcc version
> > 3.4.1) #7 Tue Apr 1 14:55:25 CEST 2008
> > Xilinx Generic PowerPC board support package (Xilinx ML405) =
(Virtex-4 FX)
> > Zone PFN ranges:
> > DMA 0 -> 8192
> > =20
> > Normal 8192 -> 8192
> > =20
> > HighMem 8192 -> 8192
> > Movable zone start PFN for each node
> > early_node_map[1] active PFN ranges
> > 0: 0 -> 8192
> > Built 1 zonelists in Zone order, mobility grouping on. =
Total pages: 8128
> > Kernel command line: root=3D/de v/nfs
> > ip=3D192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=3D192.168.0.3:/home/mingliu/ml403_rootfs =
console=3DttyUL0,38400
> > mem=3D32M
> > Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
> > PID hash table entries: 128 (order: 7, 512 bytes)
> > Console: colour dummy device 80x25
> > Dentry cache hash table entries: 4096 (order: 2, 16384 =
bytes)
> > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > Memory: 28884k available (2552k kernel code, 944k data, 84k =
init, 0k highmem)
> > SLUB: Genslabs=3D11, HWalign=3D32, Order=3D0-1, =
MinObjects=3D4, CPUs=3D1, Nodes=3D1
> > Mount-cache hash table entries: 512
> > net_namespace: 64 bytes
> > NET: Registered protocol family 16
> > Registering device uartlite:0
> > Fixup MAC address for xilinx_lltemac:0
> > Regis tering device xilinx_lltemac:0
> > NET: Registered protocol family 2
> > IP route cache hash table entries: 1024 (order: 0, 4096 =
bytes)
> > TCP established hash table entries: 1024 (order: 1, 8192 =
bytes)
> > TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> > TCP: Hash tables configured (established 1024 bind 1024)
> > TCP reno registered
> > sysctl table check failed: /kernel/l2cr .1.31 Missing =
strategy
> > Call Trace:
> > [c1c0fe50] [c0008b70] show_stack+0x40/0x194 (unreliable)
> > [c1c0fe90] [c003aed4] set_fail+0x68/0x80
> > [c1c0feb0] [c003b4ec] sysctl_check_table+0x600/0x77c
> > [c1c0fef0] [c003b4d4] sysctl_check_table+0x5e8/0x77c
> > [c1c0ff30] [c002605c] register_sysctl_table+0x64/0xb4
> > [c1c0ff50] [c034579c] register_ppc_htab_sysctl+0x18/0x2c
> > [c1c0ff60] [c034482c] kernel_init+0x94/0x2bc
> > [c1c0fff0] [c0004d58] kernel_thread+0x44/0x60
> > Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> > fuse init (API version 7.9)
> > io scheduler noop registered
> > io scheduler anticipatory registered
> > io scheduler deadline registered
> > io scheduler cfq registered (default)
> > uartlite.0: ttyUL0 at MM IO 0x84000003 (irq =3D 3) is a =
uartlite
> > console [ttyUL0] enabled
> > loop: module loaded
> > nbd: registered device at major 43
> > xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: =
a:35: 1: 2: 3
> > xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode.
> > XLlTemac: Dma base address: phy: 0x84600100, virt: =
0xc3008100
> > XLlTemac: buffer descriptor size: 32768 (0x8000)
> > XLlTemac: Allocating DMA descriptors with =
kmalloc<6>XLlTemac:
> > (buffer_descriptor_init) phy: 0x1d18000, virt: 0xc1d18000, =
size: 0x8000
> > XTemac: PHY detected at address 7.
> > xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at =
0x81C00000 mapped
> > to 0xC3004000, irq=3D2
> > console [netcon0] enabled
> > Linux version 2.6.24-rc8-xlnx-g1db182b8-dirty =
(mingliu@cca01) (gcc version
> > 3.4.1) #7 Tue Apr 1 14:55:25 CEST 2008
> > =20
> > Xilinx Generic PowerPC board support package (Xilinx ML405)
> > (Virtex-4 FX)
> > =20
> > Zone PFN ranges:
> > DMA 0 -> 8192
> > Normal 8192 -> 8192
> > HighMem 8192 -> 8192
> > Movable zone start PFN for each node
> > early_node_map[1] active PFN range
> > s
> > 0: 0 -> 8192
> > Built 1 zonelists in Zone order, mobility grouping on. =
Total pages: 8128
> > Kernel command line: root=3D/dev/nfs
> > ip=3D192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=3D192.168.0.3:/home/mingliu/ml403_rootfs =
console=3DttyUL0,38400
> > mem=3D32M
> > Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
> > PID hash table entries: 128 (order: 7, 512 bytes)
> > Console: colour dummy device 80x25
> > Dentry cache hash table entries: 4096 (order: 2, 16384 =
bytes)
> > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > Memory: 28884k available (2552k kernel code, 944k data, 84k =
init, 0k highmem)
> > SLUB: Genslabs=3D11, HWalign=3D32, Order=3D0-1, =
MinObjects=3D4, CPUs=3D1, Nodes=3D1
> > Mount-cache hash table entries: 512
> > n
> > et_namespace: 64 bytes
> > NET: Registered protocol family 16
> > Registering device uartlite:0
> > Fixup MAC address for xilinx_lltemac:0
> > Registering device xilinx_lltemac:0
> > NET: Registered protocol family 2
> > IP route cache hash table entries: 1024 (order: 0, 4096 =
bytes)
> > TCP established hash table entries: 1024 (order: 1, 8192 =
bytes)
> > TCP bind hash table entries: 1024
> > (order: 0, 4096 bytes)
> > TCP: Hash tables configured (established 1024 bind 1024)
> > TCP reno registered
> > sysctl table check failed: /kernel/l2cr .1.31 Missing =
strategy
> > Call Trace:
> > [c1c0fe50] [c0008b70] show_stack+0x40/0x194 (unreliable)
> > [c1c0fe90] [c003aed4] set_fail+0x68/0x80
> > [c1c0feb0] [c003b4ec] sysctl_check_table+0x600/0x77c
> > [c1c0fef0] [c003b4d4] sysctl_c
> > heck_table+0x5e8/0x77c
> > [c1c0ff30] [c002605c] register_sysctl_table+0x64/0xb4
> > [c1c0ff50] [c034579c] register_ppc_htab_sysctl+0x18/0x2c
> > [c1c0ff60] [c034482c] kernel_init+0x94/0x2bc
> > [c1c0fff0] [c0004d58] kernel_thread+0x44/0x60
> > Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> > fuse init (API version 7.9)
> > io scheduler noop registered<
> > /SPAN>
> > io scheduler anticipatory registered
> > io scheduler deadline registered
> > io scheduler cfq registered (default)
> > uartlite.0: ttyUL0 at MMIO 0x84000003 (irq =3D 3) is a =
uartlite
> > console [ttyUL0] enabled
> > loop: module loaded
> > nbd: registered device at major 43
> > xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: =
a:35: 1: 2: 3
> > xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode.
> > XLlTemac: Dma base address: phy: 0x84600100, virt: =
0xc3008100
> > XLlTemac: buffer descriptor size: 32768 (0x8000)
> > XLlTemac: Allocating DMA descriptors with =
kmalloc<6>XLlTemac:
> > (buffer_descriptor_init) phy: 0x1d18000, virt: 0xc1d18000, =
size: 0x8000
> > XTemac: PHY detected at address 7.
> > xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at =
0x81C00000 mapped
> > <
> > SPAN style=3D"FONT-SIZE: 12pt">to 0xC3004000, irq=3D2
> > console [netcon0] enabled
> > netconsole: network logging started
> > Generic platform RAM MTD, (c) 2004 Simtec Electronics
> > mice: PS/2 mouse device common for all mice
> > TCP cubic registered
> > NET: Registered protocol family 1
> > NET: Registered protocol family 17
> > RPC: Registered udp transport module.
> > RPC: Registered tcp transport module.
> > eth0: XLlTemac: Options: 0x3fa
> > eth0: XLlTemac: allocating interrupt 0 for dma mode tx.
> > eth0: XLlTemac: allocating interrupt 1 for dma mode rx.
> > eth0: XLlTemac: speed set to 1000Mb/s
> > eth0: XLlTemac: Send Threshold =3D 24, Receive Threshold =3D =
4
> > eth0: XLlTemac: Send Wait bound =3D 254, Receive Wait bound =
=3D 254
> > IP-Config: Complete:
> > =20
> > device=3Deth0, addr=3D192.168.0.4, =
mask=3D255.255.255.0, gw=3D192.168.0.3,
> > host=3D192.168.0.4, domain=3D, nis-domain=3D(none),
> > bootserver=3D192.168.0.3, rootserver=3D192.168.0.3, =
rootpath=3D
> > Looking up port of RPC 100003/2 on 192.168.0.3
> > rpcbind: server 192.168.0.3 not responding, timed out
> > Root-NFS: Unable to get nfsd port number from server, using =
default
> > Looking up port of RPC 10000
> > 5/1 on 192.168.0.3
> > rpcbind: server 192.168.0.3 not responding, timed out
> > Root-NFS: Unable to get mountd port number from server, =
using default
> > mount: server 192.168.0.3 not responding, timed out
> > Root-NFS: Server returned error -5 while mounting =
/home/mingliu/ml403_rootfs
> > VFS: Unable to mount root fs via NFS, trying floppy.
> > VFS: Cannot open root device "nfs" or unknown-block(2,0)
> > Please append a correct "root=3D" boot option; here are=20
> > the available
> > partitions:
> > Kernel panic - not syncing: VFS: Unable to mount root fs on
> > unknown-block(2,0)
> > Rebooting in 180 seconds..
> > =20
> > =20
> > BR
> > Ming
> > =20
> > =20
> > =20
> > =20
> > =
______________________________________________________________
> > Windows Live =
Writer=A3=AC=D6=A7=B3=D6=C0=EB=CF=DF=D7=AB=D0=B4=B2=A9=BF=CD=C4=DA=C8=DD=A3=
=AC=CB=E6=CA=B1=CB=E6=B5=D8=CF=EB=D0=B4=BE=CD=D0=B4=A1=A3
> > =C1=A2=BC=B4=CA=B9=D3=C3=A3=A1
> > =20
> > =20
> >=20
> >=20
> > =
______________________________________________________________________
> > =CA=B9=D3=C3=D0=C2=D2=BB=B4=FA Windows Live Messenger =
=C7=E1=CB=C9=BD=BB=C1=F7=BA=CD=B9=B2=CF=ED=A3=A1 =
=C1=A2=BC=B4=CC=E5=D1=E9=A3=A1=20
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
>=20
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Paul Mackerras @ 2008-04-02 0:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <5DBEA342-7674-414B-A666-B8FBEED34814@kernel.crashing.org>
Kumar Gala writes:
> Hmm, need to think about that. But my initial reaction is two fold.
> One I don't think this information would be around and two don't we
> already have this problem with a kdump kernel?
I'm just concerned that we have two things that have to match up - the
compiled-in physical address that the kernel assumes it is running at,
and the physical address where it is actually loaded. While those two
things were both always 0 for embedded processors, there wasn't a
problem, but now we can have a situation where a kernel binary has to
be loaded at some nonzero address to work correctly, but there is no
way to work out what that address is for an existing vmlinux binary.
Or have I missed something?
For a kdump kernel, at least for 64-bit, the physical address has to
be 32MB. There is no other choice, so there is no possibility of
confusion.
For 85xx, would it be possible to have the kernel figure out what
physical address it has been loaded at, and use that as the base
address, rather than having the base address set at compile time?
That would solve my objection since it would mean that there would no
longer be two things that had to be kept in sync. You could pass any
value to wrapper/mkimage (subject to constraints such as it has to be
a multiple of 256M) and it would work. That value could even come
from a config option in the case where wrapper is invoked as part of
the kernel build, but that config option shouldn't affect anything at
all in the vmlinux.
Paul.
^ permalink raw reply
* Re: Access physical memory via mmap() on ppc440epx.
From: Josh Boyer @ 2008-04-02 1:44 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C033A981B@ehost011-3.exch011.intermedia.net>
On Tue, 2008-04-01 at 14:12 -0700, Leonid wrote:
> Hi:
>
> I am trying to read from NOR flash, located on address 0xfc000000, on my
It's at 0x1fc000000 IIRC.
> TLB entries look strange though. That what it was on u-boot stage:
>
> 440EPx>tlb 0 10
> IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
> 0 : 00 40000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 2 : 00 c0000000 256MB V0 -> 1_c0000000 U:0000 -I-G- XWRXWR
> 3 : 00 f0000000 256MB V0 -> 1_f0000000 U:0000 WI-G- XWRXWR
See. Virtual is 0xf0000000, physical is 0x1f0000000.
> On Linux stage it looks rather different:
I don't even see your entry in here. Likely because the TLB is small
and it's gone by the time you do the dump
> Probably under MMU it should look this way? How to use mmap() then?
Try mmap64 on the real physical address and see if that helps.
josh
^ permalink raw reply
* Re: [PATCH] Make #include <sysdev/foo.h> work for 64-bit powerpc
From: Michael Ellerman @ 2008-04-02 1:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <0A4216BD-1505-46DE-B08E-23E9B7E51AD2@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
On Tue, 2008-04-01 at 08:18 -0500, Kumar Gala wrote:
> On Apr 1, 2008, at 1:54 AM, Stephen Rothwell wrote:
> > Hi Michael,
> >
> > On Tue, 1 Apr 2008 17:39:11 +1100 (EST) Michael Ellerman <michael@ellerman.id.au
> > > wrote:
> >>
> >> We currently have inconsistent settings between 32 & 64-bit which
> >> means
> >> 32-bit code can #include <sysdev/foo.h> but 64-bit code can't.
> >
> > Kumar sent a very similar (if not identical) patch earlier today.
>
> I actually sent it several days ago, but reposted as part of the
> series of work I was doing. ;)
OK, I missed it. I'm not fussed who's goes in, I just needed it for some
other work.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Please pull from 'for-2.6.25' branch
From: Kumar Gala @ 2008-04-02 2:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev list, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0803311156160.4549@blarg.am.freescale.net>
On Mar 31, 2008, at 11:57 AM, Kumar Gala wrote:
> Please pull from 'for-2.6.25' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
> for-2.6.25
>
> I'd like to get these minor fixes into 2.6.25. They aren't critical
> but
> extremely convenient at this point.
Paul, any comments on sending this onto linus. I was hoping to avoid
2.6.25 coming up not support the proper device bindings for DMA and
SATA.
- k
>
>
> to receive the following updates:
>
> arch/powerpc/boot/dts/mpc8377_mds.dts | 4 ++--
> arch/powerpc/boot/dts/mpc8377_rdb.dts | 3 +--
> arch/powerpc/boot/dts/mpc8378_rdb.dts | 3 +--
> arch/powerpc/boot/dts/mpc8379_mds.dts | 8 ++++----
> arch/powerpc/boot/dts/mpc8379_rdb.dts | 3 +--
> arch/powerpc/configs/mpc832x_mds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc834x_mds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc836x_mds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc837x_rdb_defconfig | 24 ++++++++++++++++++
> +++++-
> arch/powerpc/configs/mpc83xx_defconfig | 24 ++++++++++++++++++
> +++++-
> arch/powerpc/configs/mpc8544_ds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc8568mds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc8572_ds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc85xx_defconfig | 11 +++--------
> arch/powerpc/configs/mpc8641_hpcn_defconfig | 11 +++--------
> arch/powerpc/configs/prpmc2800_defconfig | 11 +++--------
> arch/powerpc/configs/storcenter_defconfig | 11 +++--------
> drivers/ata/sata_fsl.c | 5 +----
> drivers/dma/fsldma.c | 8 ++++----
> 19 files changed, 90 insertions(+), 102 deletions(-)
>
> Anton Vorontsov (1):
> [POWERPC] 83xx: Fix wrong USB phy type in mpc837xrdb dts
>
> Kim Phillips (2):
> [POWERPC] 83xx: enable usb in 837x rdb and 83xx defconfigs
> [POWERPC] sata_fsl: reduce compatibility to fsl,pq-sata
>
> Kumar Gala (2):
> [POWERPC] fsldma: Use compatiable binding as spec
> [POWERPC] Fix defconfigs so we dont set both GENRTC and RTCLIB
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Virtex V5FX PPC 440 Support In Xilinx Git Tree
From: Grant Likely @ 2008-04-02 4:09 UTC (permalink / raw)
To: John Linn; +Cc: git, linuxppc-embedded
In-Reply-To: <20080401234142.41B13191804A@mail111-sin.bigfish.com>
On Tue, Apr 1, 2008 at 5:41 PM, John Linn <John.Linn@xilinx.com> wrote:
>
>
>
>
> I pushed PowerPC 440 support to the Xilinx Git server with support for ppc
> arch and with powerpc arch support coming in the near future.
Cool, I look forward to playing with it...
/me just needs to find a client who needs him to do V5 work. :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: mpc52xx_mmap_ctl access
From: Grant Likely @ 2008-04-02 4:15 UTC (permalink / raw)
To: Marcelo Dalmas; +Cc: linuxppc-embedded
In-Reply-To: <132281.10315.qm@web50302.mail.re2.yahoo.com>
On Tue, Apr 1, 2008 at 11:03 AM, Marcelo Dalmas <m_dalmas@yahoo.com.br> wrote:
> Hi all!
>
> I'm updating a device driver from linux 2.6.16 ppc
> tree to linux 2.6.24 powerpc in a lite5200 based
> board.
>
> I need to access mpc52xx_mmap_ctl and mpc52xx_cslpc.
>
> In ppc tree I do:
>
> mmap_ctl =
> ioremap(MPC52xx_PA(MPC52xx_MMAP_CTL_OFFSET),
> MPC52xx_MMAP_CTL_SIZE)
>
> How can I access it in powerpc tree?
1) In your device tree, add a new node for the local plus bus control
registers with the correct base address.
2) Use of_find_compatible_node() to get a pointer to the node in your
platform init code.
3) Use of_iomap() to map the registers into the kernel address space.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: SecretLab Git Server
From: Grant Likely @ 2008-04-02 4:17 UTC (permalink / raw)
To: Sam Karp; +Cc: linuxppc-embedded
In-Reply-To: <800687fe0803311912w6da7e8d0i6567a824b7065bdf@mail.gmail.com>
On Mon, Mar 31, 2008 at 8:12 PM, Sam Karp <sam.d.karp@gmail.com> wrote:
> Any idea of other sources where else I could get either a kernel with the
> USB driver or a standalone driver for the Xilinx ML403 board?
Look on the powerpc mailing list archives for Peter Korsgaard's patch
set for the c67x00. (I believe v10 is the latest patch set).
You need to use the mailing list archive instead of patchwork. For
some reason patchwork doesn't recognize Peter's patches.
I'll try to get my git server up and running again ASAP.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Grant Likely @ 2008-04-02 4:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel
In-Reply-To: <18418.49494.457893.866627@cargo.ozlabs.ibm.com>
On Tue, Apr 1, 2008 at 5:12 PM, Paul Mackerras <paulus@samba.org> wrote:
> Bartlomiej Sieka writes:
>
> > What about http://patchwork.ozlabs.org/linuxppc/patch?id=17525 ? I don't
> > see it in the merge branch of your repository, and it would be nice to
> > get it upstream as it fixes boot problems on some MPC5200-based boards.
>
> It needs a proper stand-alone commit message and an acked-by from
> Grant. The commit message should explain why you are making the
> changes you are making rather than just saying "the bulk of this patch
> is taken from http://...".
Total Ack. I just missed it when it was sent. But Paul is right, it
needs a real commit message. Feel free to add my Acked-by: line when
you resend.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Access physical memory via mmap() on ppc440epx.
From: Leonid @ 2008-04-02 4:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <1207100665.12155.100.camel@vader.jdub.homelinux.org>
Hi, Josh:
Thank you for your suggestion. Somehow it didn't work with mmap (may be,
my mistake, I'll double check), however it partially helped me with my
another problem.
I have kernel driver where I need read/write some HW device, connected
on address 0xea000000, chip select 4. This chip select configured
properly, here are EBC registers:
440EPx>rd ebc0_b4cr
ebc0_b4cr: 0xea01a000 -368992256
440EPx>rd ebc0_b4ap
ebc0_b4ap: 0x03037000 50556928
>From u-boot I can read/write this address with no problem (I use md/mw
commands).
In my driver I tried to ioremap() this address and any attempt to access
led to crash, same as with mmap().
When, following your suggestion, I used address 0x1ea00000 and
ioremap64(), crashes disappeared!
I even can write, but when I read data back I see least significant byte
of each 16 bits word only (bus is configured 16 bits width).=20
What can it be?
Thanks,
Leonid.=20
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@gmail.com]=20
Sent: Tuesday, April 01, 2008 6:44 PM
To: Leonid
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Access physical memory via mmap() on ppc440epx.
On Tue, 2008-04-01 at 14:12 -0700, Leonid wrote:
> Hi:
>=20
> I am trying to read from NOR flash, located on address 0xfc000000, on
my
It's at 0x1fc000000 IIRC.
> TLB entries look strange though. That what it was on u-boot stage:
>=20
> 440EPx>tlb 0 10
> IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
> 0 : 00 40000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 2 : 00 c0000000 256MB V0 -> 1_c0000000 U:0000 -I-G- XWRXWR
> 3 : 00 f0000000 256MB V0 -> 1_f0000000 U:0000 WI-G- XWRXWR
See. Virtual is 0xf0000000, physical is 0x1f0000000.
> On Linux stage it looks rather different:
I don't even see your entry in here. Likely because the TLB is small
and it's gone by the time you do the dump
> Probably under MMU it should look this way? How to use mmap() then?
Try mmap64 on the real physical address and see if that helps.
josh
^ 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