Re: [PATCH 1/3] Add generic configuration option to enable all xilinx drivers.
On 8/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > From: Stephen Neuendorffer <[EMAIL PROTECTED]> > > In the future, this will be used to provide similar configuration > for PowerPC and Microblaze. I'm not convinced that this change is worth it since there is only one in-tree driver that uses it. I'd maintain it separately in your tree until other drivers or the microblaze stuff is ready for merging. > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 518d5d3..e5bc9af 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -219,3 +219,13 @@ config THINKPAD_ACPI_INPUT_ENABLED > > > endif # MISC_DEVICES > +endmenu Umm, this looks wrong. Where'd the 'endmenu' come from? Cheers, g -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 3/3] Add support for xupv2p and ml410 boards.
On 8/21/07, Robert Woodworth <[EMAIL PROTECTED]> wrote: > Should the xparameters.h file *really* be included in the tree? > > This file is completely board/EDK/ISE/synthesis specific. I'd rather it > not be included and have people copy theirs from EDK. > Or as I have done, sym-link it from my EDK project. Including xparams for the default xilinx reference designs seems reasonable to me. For custom designs, not so much. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Why dose system hangs after "Now booting the kernel" ?
Hi, all I am running linux-xilinx-26.git, a MontaVista embedded OS based on kernel 2.6.22, on ML403. I have made the kernel image and downloaded it into the board. But when it ran, the system stopped after printed the message "Now booting the kernel", and no other information was output. I have tried to modify the file "xparameters_ml403.h" because I suspected that the driver for serial port is the problem, but it did not fix the problem. I do not know where the problem is and how to solve it. Any help from you all is appreciated. Thank you! ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 3/3] Add support for xupv2p and ml410 boards.
Should the xparameters.h file *really* be included in the tree? This file is completely board/EDK/ISE/synthesis specific. I'd rather it not be included and have people copy theirs from EDK. Or as I have done, sym-link it from my EDK project. Woody. On Tue, 2007-08-21 at 17:53 -0700, [EMAIL PROTECTED] wrote: > From: Stephen Neuendorffer <[EMAIL PROTECTED]> > diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h > b/arch/ppc/platforms/4xx/xparameters/xparameters.h > index 01aa043..34d9844 100644 > --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h > +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h > @@ -15,8 +15,12 @@ > > #if defined(CONFIG_XILINX_ML300) >#include "xparameters_ml300.h" > +#elif defined(CONFIG_XILINX_XUPV2P) > + #include "xparameters_xupv2p.h" > #elif defined(CONFIG_XILINX_ML403) >#include "xparameters_ml403.h" > +#elif defined(CONFIG_XILINX_ML41x) > + #include "xparameters_ml41x.h" > #else >/* Add other board xparameter includes here before the #else */ >#error No xparameters_*.h file included > diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h > b/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h > new file mode 100644 > index 000..06dac67 > --- /dev/null > +++ b/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h > @@ -0,0 +1,277 @@ > + > +/*** > +* > +* CAUTION: This file is automatically generated by libgen. > +* Version: Xilinx EDK 8.2.02 EDK_Im_Sp2.4 > +* DO NOT EDIT. > +* > +* Copyright (c) 2005 Xilinx, Inc. All rights reserved. > +* > +* Description: Driver parameters > +* > +***/ > + ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OF /chosen/initrd,* variables - patch, official?
On Tue, Aug 21, 2007 at 03:24:52PM +0100, Matt Sealey wrote:
> David Gibson wrote:
> > On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
> >> David Gibson wrote:
> >>> Uh... no... this is in the bootwrapper, long before ppc_md even
> >>> exists. platform_init() is called from arch/powerpc/boot/crt0.S,
> >>> immediately before main().
> >> Oh *THAT* platform init.
> >>
> >> So I could just drop a
> >>
> >> } else {
> >>dt_find_initrd();
> >> }
> >>
> >> .. at the end and nobody would be too disgusted or have any problems?
> >
> > Err.. at the end of what? Each platform has it's own version of
> > platform_init().
>
> arch/powerpc/boot/of.c since it's not really relevant to me for non-OF
> platforms?
Err... it would have to be a somewhat strange OF implementation that
gives the linux,initrd-* properties sane values before entry... I
doubt we want to do this for all real OF systems.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 3/3] Add support for xupv2p and ml410 boards.
On Tue, 21 Aug 2007 17:53:13 -0700
[EMAIL PROTECTED] wrote:
> From: Stephen Neuendorffer <[EMAIL PROTECTED]>
>
> xupv2p support generates MAC addresses based on a silicon serial ID.
General reminder, no new code will be accepted in arch/ppc. It's in
bugfix state only.
I of course have no problems with people sending patches for new stuff,
but I don't want people to get the idea that it will wind up in tree.
> +#include
> +#include
> +
> +int virtex_device_fixup(struct platform_device *dev)
Could this be a static function?
> +{
> +#ifdef XPAR_ONEWIRE_0_BASEADDR
> + int i;
> + // Use the Silicon Serial ID attached on the onewire bus to
> + // generate sensible MAC addresses.
No C++ style comments please.
> + unsigned char *p_onewire = ioremap(XPAR_ONEWIRE_0_BASEADDR, 6);
What happens if ioremap fails?
> + struct xemac_platform_data *pdata = dev->dev.platform_data;
> + if (strcmp(dev->name, "xilinx_emac") == 0) {
> + printk(KERN_INFO "Fixup MAC address for %s:%d\n",
> +dev->name, dev->id);
> + // FIXME.. this doesn't seem to return data that is consistent
> + // with the self test... why not?
> + pdata->mac_addr[0] = 0x00;
> + pdata->mac_addr[1] = 0x0A;
> + pdata->mac_addr[2] = 0x35;
> + pdata->mac_addr[3] = dev->id;
> + pdata->mac_addr[4] = p_onewire[4];
> + pdata->mac_addr[5] = p_onewire[5];
> + pr_debug(KERN_INFO
> + "MAC address is now %2x:%2x:%2x:%2x:%2x:%2x\n",
> + pdata->mac_addr[0], pdata->mac_addr[1],
> + pdata->mac_addr[2], pdata->mac_addr[3],
> + pdata->mac_addr[4], pdata->mac_addr[5]);
> + }
> + iounmap(p_onewire);
> +#endif
> + return 0;
> +}
> --- /dev/null
> +++ b/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
> @@ -0,0 +1,277 @@
> +
> +/***
> +*
> +* CAUTION: This file is automatically generated by libgen.
> +* Version: Xilinx EDK 8.2.02 EDK_Im_Sp2.4
> +* DO NOT EDIT.
> +*
> +* Copyright (c) 2005 Xilinx, Inc. All rights reserved.
All rights reserved is not compatible with the GPL I don't think...
josh
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH 3/3] Add support for xupv2p and ml410 boards.
From: Stephen Neuendorffer <[EMAIL PROTECTED]>
xupv2p support generates MAC addresses based on a silicon serial ID.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
Signed-off-by: Wolfgang Reissnegger <[EMAIL PROTECTED]>
---
arch/ppc/platforms/4xx/Kconfig | 16 +
arch/ppc/platforms/4xx/Makefile|2 +
arch/ppc/platforms/4xx/xilinx_xupv2p.c | 42 +++
arch/ppc/platforms/4xx/xparameters/xparameters.h |4 +
.../platforms/4xx/xparameters/xparameters_ml41x.h | 277 +
.../platforms/4xx/xparameters/xparameters_xupv2p.h | 327
6 files changed, 668 insertions(+), 0 deletions(-)
create mode 100644 arch/ppc/platforms/4xx/xilinx_xupv2p.c
create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
index bc47ee7..8cc63a9 100644
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -61,6 +61,14 @@ config XILINX_ML300
help
This option enables support for the Xilinx ML300 evaluation board.
+config XILINX_XUPV2P
+ bool "Xilinx-XUPV2P"
+ select XILINX_VIRTEX_II_PRO
+ select EMBEDDEDBOOT
+ select XILINX_EMBED_CONFIG
+ help
+ This option enables support for the Xilinx University Program (XUP)
Virtex 2 Pro board.
+
config XILINX_ML403
bool "Xilinx-ML403"
select XILINX_VIRTEX_4_FX
@@ -69,6 +77,14 @@ config XILINX_ML403
help
This option enables support for the Xilinx ML403 evaluation board.
+config XILINX_ML41x
+ bool "Xilinx-ML41x"
+ select XILINX_VIRTEX_4_FX
+ select EMBEDDEDBOOT
+ select XILINX_EMBED_CONFIG
+ help
+ This option enables support for the Xilinx ML410/411 evaluation
boards.
+
endchoice
choice
diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
index 141f248..8c255ac 100644
--- a/arch/ppc/platforms/4xx/Makefile
+++ b/arch/ppc/platforms/4xx/Makefile
@@ -15,7 +15,9 @@ obj-$(CONFIG_SYCAMORE)+= sycamore.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_WALNUT) += walnut.o
obj-$(CONFIG_XILINX_ML300) += xilinx_generic_ppc.o
+obj-$(CONFIG_XILINX_XUPV2P)+= xilinx_generic_ppc.o xilinx_xupv2p.o
obj-$(CONFIG_XILINX_ML403) += xilinx_generic_ppc.o
+obj-$(CONFIG_XILINX_ML41x) += xilinx_generic_ppc.o
obj-$(CONFIG_405GP)+= ibm405gp.o
obj-$(CONFIG_REDWOOD_5)+= ibmstb4.o
diff --git a/arch/ppc/platforms/4xx/xilinx_xupv2p.c
b/arch/ppc/platforms/4xx/xilinx_xupv2p.c
new file mode 100644
index 000..bf1645a
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xilinx_xupv2p.c
@@ -0,0 +1,42 @@
+/*
+ * Xilinx XUPV2P board initialization
+ *
+ * Author: [EMAIL PROTECTED]
+ *
+ * 2007 (c) Xilinx, Inc. This file is licensed under the
+ * terms of the GNU General Public License version 2. This program is licensed
+ * "as is" without any warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+
+int virtex_device_fixup(struct platform_device *dev)
+{
+#ifdef XPAR_ONEWIRE_0_BASEADDR
+ int i;
+ // Use the Silicon Serial ID attached on the onewire bus to
+ // generate sensible MAC addresses.
+ unsigned char *p_onewire = ioremap(XPAR_ONEWIRE_0_BASEADDR, 6);
+ struct xemac_platform_data *pdata = dev->dev.platform_data;
+ if (strcmp(dev->name, "xilinx_emac") == 0) {
+ printk(KERN_INFO "Fixup MAC address for %s:%d\n",
+ dev->name, dev->id);
+ // FIXME.. this doesn't seem to return data that is consistent
+ // with the self test... why not?
+ pdata->mac_addr[0] = 0x00;
+ pdata->mac_addr[1] = 0x0A;
+ pdata->mac_addr[2] = 0x35;
+ pdata->mac_addr[3] = dev->id;
+ pdata->mac_addr[4] = p_onewire[4];
+ pdata->mac_addr[5] = p_onewire[5];
+ pr_debug(KERN_INFO
+"MAC address is now %2x:%2x:%2x:%2x:%2x:%2x\n",
+pdata->mac_addr[0], pdata->mac_addr[1],
+pdata->mac_addr[2], pdata->mac_addr[3],
+pdata->mac_addr[4], pdata->mac_addr[5]);
+ }
+ iounmap(p_onewire);
+#endif
+ return 0;
+}
diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h
b/arch/ppc/platforms/4xx/xparameters/xparameters.h
index 01aa043..34d9844 100644
--- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
+++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
@@ -15,8 +15,12 @@
#if defined(CONFIG_XILINX_ML300)
#include "xparameters_ml300.h"
+#elif defined(CONFIG_XILINX_XUPV2P)
+ #include "xparameters_xupv2p.h"
#elif defined(CONFIG_XILINX_ML403)
#include "xparameters_ml403.h"
+#elif defined(CONFIG_XILINX_ML41x)
+
[PATCH 1/3] Add generic configuration option to enable all xilinx drivers.
From: Stephen Neuendorffer <[EMAIL PROTECTED]> In the future, this will be used to provide similar configuration for PowerPC and Microblaze. Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]> Signed-off-by: Wolfgang Reissnegger <[EMAIL PROTECTED]> --- arch/ppc/platforms/4xx/Kconfig |1 + drivers/misc/Kconfig | 10 ++ drivers/video/Kconfig |2 +- 3 files changed, 12 insertions(+), 1 deletions(-) diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig index 76551b6..d7db7e4 100644 --- a/arch/ppc/platforms/4xx/Kconfig +++ b/arch/ppc/platforms/4xx/Kconfig @@ -228,6 +228,7 @@ config XILINX_VIRTEX_4_FX config XILINX_VIRTEX bool + select XILINX_DRIVERS config STB03xxx bool diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 518d5d3..e5bc9af 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -219,3 +219,13 @@ config THINKPAD_ACPI_INPUT_ENABLED endif # MISC_DEVICES +endmenu + + +# +# Xilinx devices and common device driver infrastructure +# + +config XILINX_DRIVERS + bool + diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 5216c11..69e7240 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -1824,7 +1824,7 @@ config FB_PS3_DEFAULT_SIZE_M config FB_XILINX tristate "Xilinx frame buffer support" - depends on FB && XILINX_VIRTEX + depends on FB && XILINX_DRIVERS select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 1.5.2.1 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH 2/3] Consolidate XILINX_VIRTEX board support.
From: Stephen Neuendorffer <[EMAIL PROTECTED]>
Make support for Xilinx boards more generic, making it easier
to add new boards. ML300 and ML403 now use this. Added
CONFIG_XILINX_EMBED_CONFIG to do the consolidation, while still
allowing boards not in the tree to avoid embed_config.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
Signed-off-by: Wolfgang Reissnegger <[EMAIL PROTECTED]>
---
arch/ppc/boot/simple/Makefile |3 +-
arch/ppc/boot/simple/embed_config.c |4 +-
arch/ppc/platforms/4xx/Kconfig |6 +
arch/ppc/platforms/4xx/Makefile |4 +-
arch/ppc/platforms/4xx/xilinx_generic_ppc.c | 133 +++
arch/ppc/platforms/4xx/xilinx_ml300.c | 118
arch/ppc/platforms/4xx/xilinx_ml403.c | 120
7 files changed, 144 insertions(+), 244 deletions(-)
create mode 100644 arch/ppc/platforms/4xx/xilinx_generic_ppc.c
delete mode 100644 arch/ppc/platforms/4xx/xilinx_ml300.c
delete mode 100644 arch/ppc/platforms/4xx/xilinx_ml403.c
diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
index 5b87779..8581bea 100644
--- a/arch/ppc/boot/simple/Makefile
+++ b/arch/ppc/boot/simple/Makefile
@@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6)+= embed_config.o
boot-$(CONFIG_8xx) += embed_config.o
boot-$(CONFIG_8260)+= embed_config.o
boot-$(CONFIG_EP405) += embed_config.o
-boot-$(CONFIG_XILINX_ML300)+= embed_config.o
-boot-$(CONFIG_XILINX_ML403)+= embed_config.o
+boot-$(CONFIG_XILINX_EMBED_CONFIG) += embed_config.o
boot-$(CONFIG_BSEIP) += iic.o
boot-$(CONFIG_MBX) += iic.o pci.o qspan_pci.o
boot-$(CONFIG_MV64X60) += misc-mv64x60.o
diff --git a/arch/ppc/boot/simple/embed_config.c
b/arch/ppc/boot/simple/embed_config.c
index 840bff2..b0e599b 100644
--- a/arch/ppc/boot/simple/embed_config.c
+++ b/arch/ppc/boot/simple/embed_config.c
@@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
}
#endif /* WILLOW */
-#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
+#if defined(CONFIG_XILINX_EMBED_CONFIG)
void
embed_config(bd_t ** bdp)
{
@@ -781,7 +781,7 @@ embed_config(bd_t ** bdp)
timebase_period_ns = 10 / bd->bi_tbfreq;
/* see bi_tbfreq definition in arch/ppc/platforms/4xx/xilinx_ml300.h */
}
-#endif /* CONFIG_XILINX_ML300 || CONFIG_XILINX_ML403 */
+#endif /* CONFIG_XILINX_EMBED_CONFIG */
#ifdef CONFIG_IBM_OPENBIOS
/* This could possibly work for all treeboot roms.
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
index 76551b6..60fcfc1 100644
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -57,6 +57,7 @@ config XILINX_ML300
bool "Xilinx-ML300"
select XILINX_VIRTEX_II_PRO
select EMBEDDEDBOOT
+ select XILINX_EMBED_CONFIG
help
This option enables support for the Xilinx ML300 evaluation board.
@@ -64,8 +65,10 @@ config XILINX_ML403
bool "Xilinx-ML403"
select XILINX_VIRTEX_4_FX
select EMBEDDEDBOOT
+ select XILINX_EMBED_CONFIG
help
This option enables support for the Xilinx ML403 evaluation board.
+
endchoice
choice
@@ -229,6 +232,9 @@ config XILINX_VIRTEX_4_FX
config XILINX_VIRTEX
bool
+config XILINX_EMBED_CONFIG
+ bool
+
config STB03xxx
bool
depends on REDWOOD_5 || REDWOOD_6
diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
index 723ad79..141f248 100644
--- a/arch/ppc/platforms/4xx/Makefile
+++ b/arch/ppc/platforms/4xx/Makefile
@@ -14,8 +14,8 @@ obj-$(CONFIG_REDWOOD_6) += redwood6.o
obj-$(CONFIG_SYCAMORE) += sycamore.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_WALNUT) += walnut.o
-obj-$(CONFIG_XILINX_ML300) += xilinx_ml300.o
-obj-$(CONFIG_XILINX_ML403) += xilinx_ml403.o
+obj-$(CONFIG_XILINX_ML300) += xilinx_generic_ppc.o
+obj-$(CONFIG_XILINX_ML403) += xilinx_generic_ppc.o
obj-$(CONFIG_405GP)+= ibm405gp.o
obj-$(CONFIG_REDWOOD_5)+= ibmstb4.o
diff --git a/arch/ppc/platforms/4xx/xilinx_generic_ppc.c
b/arch/ppc/platforms/4xx/xilinx_generic_ppc.c
new file mode 100644
index 000..fd8bd40
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xilinx_generic_ppc.c
@@ -0,0 +1,133 @@
+/*
+ * Xilinx Generic PPC evaluation board initialization
+ *
+ * Author: MontaVista Software, Inc.
+ * [EMAIL PROTECTED]
+ *
+ * 2002-2004 (c) MontaVista Software, Inc. This file is licensed under the
+ * terms of the GNU General Public License version 2. This program is licensed
+ * "as is" without any warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/*
+ * As an overview of how the following functions (platform_init,
Re: Xilinx Virtex4 FX PPC
Hi, Robert, Josh >>> Question 1: >>> Do I need a special glibc for the Xilinx PPC 405 >>> Does a normal PPC glibc have more "advanced" instructions compiled in >>> that will not work on a Xilinx PPC 405?? Have a look at the eglibc project (embedded glibc) at http://www.eglibc.org I think they support all kind of soft-fp configurations. (i.e. The stuff seems to work fine on my MPC8540 e500 core with soft-fp) >> Make sure you're building glibc with soft-fp, or make sure you have >> CONFIG_MATH_EMULATION enabled in your kernel. The PPC 405 doesn't have >> an FPU. >> >> josh > > CONFIG_MATH_EMULATION fixed it!! > > What are the opinions out there? > Kernel fp or glibc soft-fp?? AFAICT: soft-fp in (e)glibc. They should be faster / hopefully more optimized to your specific cpu. Regards, -- Clemens Koller ___ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
C67x00 Driver IRQ Problem.
Hi all. I got the driver registered and have spent some time tracking down a IRQ problem. It just ignores me when it gets to 'request_irq' with a 'nobody cared' response. The memory appears right and the test IRQ of 3 is supposed to be correct. I never see the HCD driver load up, does that have to startup first? I tried also waking the c67300 chip by writing a Interrupt Enable Reg (0xC00E) a value to enable the ints. Do I need a /dev/usb device tree of some kind? I have a fixed dev tree since we are a embedded sys. I added some printk messages to help us out... Any helpful info would be much appreciated. Kernel code is 2.6.17.3, much hacked and maligned by me. I made a module of the c67x00, heres the load results. Load Results - c67x00 init.<6>bus platform: add driver c67x00 before kset = bus->drivers. c67x00 drv probing... c67x00 drv get mem resource. platform_get_resource, num resources=2. dev->resource[0]=512 c67x00 drv get irq resource. platform_get_resource, num resources=2. dev->resource[0]=512 dev->resource[1]=1024 c67x00 drv get platform data. c67x00 drv setup sies. c67x00 c67x00.0: USB OTG controller, p:0x43e0, v:0xc5058000, irq:3 irq 3: nobody cared (try booting with the "irqpoll" option) Call Trace: [C0F0FA50] [C0009BC0] show_stack+0x44/0x194 (unreliable) [C0F0FA90] [C004A118] __report_bad_irq+0x34/0xac [C0F0FAB0] [C004A268] note_interrupt+0xbc/0x13c [C0F0FAE0] [C00498E8] __do_IRQ+0x1a8/0x1c0 [C0F0FB10] [C0007360] do_IRQ+0x48/0x78 [C0F0FB30] [C00033FC] ret_from_except+0x0/0x18 [C0F0FBF0] [C0F0FC90] 0xc0f0fc90 [C0F0FC20] [C00073F4] do_softirq+0x64/0x74 [C0F0FC40] [C0028358] irq_exit+0x60/0x64 [C0F0FC60] [C0007364] do_IRQ+0x4c/0x78 [C0F0FC80] [C00033FC] ret_from_except+0x0/0x18 [C0F0FD40] [C5058000] 0xc5058000 [C0F0FD70] [C0049EC0] request_irq+0x94/0xc8 [C0F0FDA0] [C50715B4] usb_c67x00_drv_probe+0x240/0x2f4 [c67x00] [C0F0FDF0] [C0142124] platform_drv_probe+0x20/0x30 [C0F0FE00] [C013FA58] driver_probe_device+0x7c/0x110 [C0F0FE20] [C013EE70] bus_for_each_drv+0x74/0xa4 [C0F0FE60] [C013FB98] device_attach+0xa8/0xb8 [C0F0FE80] [C013F004] bus_add_device+0x34/0xa0 [C0F0FEA0] [C013D900] device_add+0x128/0x188 [C0F0FED0] [C0141EDC] platform_device_add+0xd4/0x194 [C0F0FF00] [C502D074] c67x00_init+0x74/0x118 [c67x00] [C0F0FF20] [C00433A8] sys_init_module+0x188/0x240 [C0F0FF40] [C0002DB4] ret_from_syscall+0x0/0x3c handlers: [] (c67x00_irq+0x0/0x154 [c67x00]) Disabling IRQ #3 Badness in ll_recv_msg at drivers/usb/c67x00/c67x00-ll-hpi.c:246 Call Trace: [C0F0FC50] [C0009BC0] show_stack+0x44/0x194 (unreliable) [C0F0FC90] [C0003F64] check_bug_trap+0x84/0xac [C0F0FCA0] [C0004130] program_check_exception+0x1a4/0x1f8 [C0F0FCC0] [C00033B0] ret_from_except_full+0x0/0x4c [C0F0FD80] [C5072A6C] c67x00_ll_reset+0x84/0xe0 [c67x00] [C0F0FDA0] [C50715FC] usb_c67x00_drv_probe+0x288/0x2f4 [c67x00] [C0F0FDF0] [C0142124] platform_drv_probe+0x20/0x30 [C0F0FE00] [C013FA58] driver_probe_device+0x7c/0x110 [C0F0FE20] [C013EE70] bus_for_each_drv+0x74/0xa4 [C0F0FE60] [C013FB98] device_attach+0xa8/0xb8 [C0F0FE80] [C013F004] bus_add_device+0x34/0xa0 [C0F0FEA0] [C013D900] device_add+0x128/0x188 [C0F0FED0] [C0141EDC] platform_device_add+0xd4/0x194 [C0F0FF00] [C502D074] c67x00_init+0x74/0x118 [c67x00] [C0F0FF20] [C00433A8] sys_init_module+0x188/0x240 [C0F0FF40] [C0002DB4] ret_from_syscall+0x0/0x3c c67x00 c67x00.0: Device reset failed c67x00: probe of c67x00.0 failed with error 65531 c67x00 udc init. ECAU-:# End Load Results - Memory Check- ECAU-:# cat /proc/iomem 40401003-40401022 : serial 40421003-40421022 : serial 43e0-43ef : c67x00.0 End Memory CHeck-- Many Thanks, Joe Robertson [EMAIL PROTECTED] CONFIDENTIALITY This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof. ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/lis
Re: OF /chosen/initrd,* variables - patch, official?
David Gibson wrote:
> On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
>> David Gibson wrote:
>>> Uh... no... this is in the bootwrapper, long before ppc_md even
>>> exists. platform_init() is called from arch/powerpc/boot/crt0.S,
>>> immediately before main().
>> Oh *THAT* platform init.
>>
>> So I could just drop a
>>
>> } else {
>> dt_find_initrd();
>> }
>>
>> .. at the end and nobody would be too disgusted or have any problems?
>
> Err.. at the end of what? Each platform has it's own version of
> platform_init().
arch/powerpc/boot/of.c since it's not really relevant to me for non-OF
platforms?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OF /chosen/initrd,* variables - patch, official?
On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
>
> David Gibson wrote:
> > Uh... no... this is in the bootwrapper, long before ppc_md even
> > exists. platform_init() is called from arch/powerpc/boot/crt0.S,
> > immediately before main().
>
> Oh *THAT* platform init.
>
> So I could just drop a
>
> } else {
> dt_find_initrd();
> }
>
> .. at the end and nobody would be too disgusted or have any problems?
Err.. at the end of what? Each platform has it's own version of
platform_init().
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx Virtex4 FX PPC
On Tue, 21 Aug 2007 11:52:35 +0300 "Stelios Koroneos" <[EMAIL PROTECTED]> wrote: > > Question 1: > > Do I need a special glibc for the Xilinx PPC 405 > > FYI we are at the last stage of implementing OpenEmbedded support for the > Xilinx ml403 (and hopefully other Xilinx boards in the near future) Cool. > It also handles the EDK header copying procedure "automagically" i.e you > point to your EDK project dir and pulls the file(s) it needs for the kernel. > We will be working to "automate" the generation of ACE files also, since OE > generates a full image (kernel+fs) and not just the toolchain. > Currently toolchain is gcc 4.1.1 with glibc 2.5 and/or uclibc 0.9.28. > There is some work done by other OE developers to get eglibc going (omap > works according to the latest info i have) > > OpenEmbedded supports a number of ppc targets currently walnut > (405),sequoia(440e),efika(603e) just to mention a few > > I will be speaking at the Power.org dev conference about OE and power > architecure so if anyone will be there and wishes to get some knowledge > about OE in "advance" , feel free to drop me a mail, as we will releasing a > beta of our OE based distro soon. I'm hoping to attend as well. Should be interesting. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OF /chosen/initrd,* variables - patch, official?
David Gibson wrote:
> Uh... no... this is in the bootwrapper, long before ppc_md even
> exists. platform_init() is called from arch/powerpc/boot/crt0.S,
> immediately before main().
Oh *THAT* platform init.
So I could just drop a
} else {
dt_find_initrd();
}
.. at the end and nobody would be too disgusted or have any problems?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Linux 2.6.23.rc3 boot issues on XUPV2P
On 8/21/07, Computer - Service <[EMAIL PROTECTED]> wrote: > Hi all. > > I try to port Linux 2.6 on my XUPV2P Board which is based on ML300. > > It runs sometimes, but for the usual case it just doesn't. > My problem is the initialization. > I have no clue why I get different values almost every time. > This is a log from the same zImage.elf, which is just loaded certain > times in the row: Check that the Virtex support code in arch/ppc/boot/simple/embed_config.c is getting compiled in (hint: search for ML403). If it's configured out, then your board info structure won't get setup correctly. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OF /chosen/initrd,* variables - patch, official?
On Tue, Aug 21, 2007 at 01:36:49PM +0100, Matt Sealey wrote: > David Gibson wrote: > > On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote: > >> Damn, I should use patchwork more efficiently; > >> > >> http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168 > >> > >> Does anyone have any suggestion on the best way to integrate this so that > >> it "just works" on OF platforms? It seems only to be usable way too late > >> in boot to work, this code would have to be called in boot/main.c which > >> seems > >> relatively.. impossible to achieve.. or called in some specialised platform > >> init code.. > > > > It would have to be called from platform_init(). If called in main() > > it would clobber any other platform-specific initialization of the > > initrd parameters in loader_info. > > So just to get this straight.. platform_init would be the function > called from md.init or would be better at md.setup_arch? Uh... no... this is in the bootwrapper, long before ppc_md even exists. platform_init() is called from arch/powerpc/boot/crt0.S, immediately before main(). > My goal right now is get something for CHRP (Pegasos) and Efika and try not > to cause problems for anything else, but also really try not to clutter the > thing with config checks, platform checks etc. > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OF /chosen/initrd,* variables - patch, official?
David Gibson wrote: > On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote: >> Damn, I should use patchwork more efficiently; >> >> http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168 >> >> Does anyone have any suggestion on the best way to integrate this so that >> it "just works" on OF platforms? It seems only to be usable way too late >> in boot to work, this code would have to be called in boot/main.c which seems >> relatively.. impossible to achieve.. or called in some specialised platform >> init code.. > > It would have to be called from platform_init(). If called in main() > it would clobber any other platform-specific initialization of the > initrd parameters in loader_info. So just to get this straight.. platform_init would be the function called from md.init or would be better at md.setup_arch? My goal right now is get something for CHRP (Pegasos) and Efika and try not to cause problems for anything else, but also really try not to clutter the thing with config checks, platform checks etc. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Linux 2.6.23.rc3 boot issues on XUPV2P
Hi all. I try to port Linux 2.6 on my XUPV2P Board which is based on ML300. It runs sometimes, but for the usual case it just doesn't. My problem is the initialization. I have no clue why I get different values almost every time. This is a log from the same zImage.elf, which is just loaded certain times in the row: loaded at: 0040 005331A0 board data at: 000E 008A relocated to: 00404084 00404100 zimage at: 00404EB9 00530A50 avail ram: 00534000 3B784800 Linux/PPC load: console=ttyS0,9600 Uncompressing Linux...done. Now booting the kernel loaded at: 0040 005331A0 board data at: 007C relocated to: 00404084 00404100 zimage at: 00404EB9 00530A50 avail ram: 00534000 7C9E2378 Linux/PPC load: console=ttyS0,9600 Uncompressing Linux...done. Now booting the kernel loaded at: 0040 005331A0 board data at: 4000 407C relocated to: 00404084 00404100 zimage at: 00404EB9 00530A50 avail ram: 00534000 Linux/PPC load: console=ttyS0,9600 Uncompressing Linux...oops... out of memory pause loaded at: 0040 005331A0 board data at: 0001 007D relocated to: 00404084 00404100 zimage at: 00404EB9 00530A50 avail ram: 00534000 9E23787C Linux/PPC load: console=ttyS0,9600 Uncompressing Linux...done. Now booting the kernel [0.00] Linux version 2.6.23-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.1) #1 Tue Aug 21 14:01:45 CEST 2007 [0.00] Xilinx ML300 Reference System (Virtex-II Pro) [0.00] Zone PFN ranges: [0.00] DMA 0 -> 196608 and just if the "avial ram" is about 1000 it boots. Anyone some idea why it could happens? ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[no subject]
Hai, I am using the kernel 2.6.21. In the file (arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan(). In this function it will skip the host birdge. But in the arch/powepc directory we don't have that types of file and the function pciauto_bus_scan() also removed. I want to know where the function was moved in arch/powerpc directory ? How the host bridge was skip in the arch/powerpc directory. Thanks and Regards Ramesh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OF /chosen/initrd,* variables - patch, official?
On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote: > Damn, I should use patchwork more efficiently; > > http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168 > > Does anyone have any suggestion on the best way to integrate this so that > it "just works" on OF platforms? It seems only to be usable way too late > in boot to work, this code would have to be called in boot/main.c which seems > relatively.. impossible to achieve.. or called in some specialised platform > init code.. It would have to be called from platform_init(). If called in main() it would clobber any other platform-specific initialization of the initrd parameters in loader_info. > I hacked up a patch initially before I saw Milton's work and did it all > in main.c (and did the same to mkvmlinuz..) and it seemed to work okay > there. > > I'm really curious as to the status and usefulness of this here.. :( > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OF /chosen/initrd,* variables - patch, official?
Damn, I should use patchwork more efficiently; http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168 Does anyone have any suggestion on the best way to integrate this so that it "just works" on OF platforms? It seems only to be usable way too late in boot to work, this code would have to be called in boot/main.c which seems relatively.. impossible to achieve.. or called in some specialised platform init code.. I hacked up a patch initially before I saw Milton's work and did it all in main.c (and did the same to mkvmlinuz..) and it seemed to work okay there. I'm really curious as to the status and usefulness of this here.. :( -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Matt Sealey wrote: > Hi guys, > > Just a query here, there was a patch for /chosen/initrd,start and initrd,end > variables gained from firmware or so, which allowed booting without getting > those values into r3/r4, does anyone know the maintainer/author of that > patch? > > Also, what are the chances of pushing it for 2.6.23 or 2.6.24? I can imagine > it's fairly useful (at least it is to me).. > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
OF /chosen/initrd,* variables - patch, official?
Hi guys, Just a query here, there was a patch for /chosen/initrd,start and initrd,end variables gained from firmware or so, which allowed booting without getting those values into r3/r4, does anyone know the maintainer/author of that patch? Also, what are the chances of pushing it for 2.6.23 or 2.6.24? I can imagine it's fairly useful (at least it is to me).. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Driver for device behind a PCI-VME bridge
Hi again, I also work with devices on the VME bus. The approach we took is to map > all the devices into userspace, and use Xenomai for RT performance. This > avoids the need to write drivers for all the devices. The RT-performance > of Xenomai is quite good: the jitter on a timer-interrupt is always less > than 20usec, even under high load, where standard Linux only achieves > this in a no load situatieo, under high load standard Linux has a jitter > of over 10 msec. Good advice, I will investigate in this direction. The setup we choose was to have a RT-interrupt handler and a RT IOCTL > call "WAIT_FOR_INTERRUPT". This is a slightly modified version from the > Motorola driver (I guess that you also use the Tundra chipset to access > the VME-bus). Yes, I do. It is the Tsi148 in fact. I'll be interested to see some sample code of yours, if it doesn't violate some restrictions ofcourse. Here you can wait for a specific VME interrupt-level, and > it returns the vector number. So you can have several applications > connect to the same VME driver, but all on different levels. So, if I understand you correctly, you altered the Motorola driver in order for it to be able to communicate with user spae programms through Xenomai. Which version of Xenomai ws that? I tried to test Xemonai 2.0 on my setup but it iterfred somehow with SSH configuration and thats why i dropped it. Many thanks, Konstantin ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Xilinx Virtex4 FX PPC
> Question 1: > Do I need a special glibc for the Xilinx PPC 405 FYI we are at the last stage of implementing OpenEmbedded support for the Xilinx ml403 (and hopefully other Xilinx boards in the near future) It also handles the EDK header copying procedure "automagically" i.e you point to your EDK project dir and pulls the file(s) it needs for the kernel. We will be working to "automate" the generation of ACE files also, since OE generates a full image (kernel+fs) and not just the toolchain. Currently toolchain is gcc 4.1.1 with glibc 2.5 and/or uclibc 0.9.28. There is some work done by other OE developers to get eglibc going (omap works according to the latest info i have) OpenEmbedded supports a number of ppc targets currently walnut (405),sequoia(440e),efika(603e) just to mention a few I will be speaking at the Power.org dev conference about OE and power architecure so if anyone will be there and wishes to get some knowledge about OE in "advance" , feel free to drop me a mail, as we will releasing a beta of our OE based distro soon. Stelios S. Koroneos Digital OPSiS - Embedded Intelligence http://www.digital-opsis.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Driver for device behind a PCI-VME bridge
Konstantin Boyanov wrote: > > Hi again, > > After some googling I came to the conclusion that the best approach to > understanding how to write a driver for a device behind a PCI-XXX > bridge is to look at the source for the USB subsystem, although the > USB subsystem is actually a bus subssytem and not a class. I also work with devices on the VME bus. The approach we took is to map all the devices into userspace, and use Xenomai for RT performance. This avoids the need to write drivers for all the devices. The RT-performance of Xenomai is quite good: the jitter on a timer-interrupt is always less than 20usec, even under high load, where standard Linux only achieves this in a no load situatieo, under high load standard Linux has a jitter of over 10 msec. The setup we choose was to have a RT-interrupt handler and a RT IOCTL call "WAIT_FOR_INTERRUPT". This is a slightly modified version from the Motorola driver (I guess that you also use the Tundra chipset to access the VME-bus). Here you can wait for a specific VME interrupt-level, and it returns the vector number. So you can have several applications connect to the same VME driver, but all on different levels. Kind regards, Johan Borkhuis ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Driver for device behind a PCI-VME bridge
Hi again, After some googling I came to the conclusion that the best approach to understanding how to write a driver for a device behind a PCI-XXX bridge is to look at the source for the USB subsystem, although the USB subsystem is actually a bus subssytem and not a class. Correct me if I'm wrong. Regards, Konstantin ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
