LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: Linux Kernel Issue: MPC8540 Errata (CPU29)
From: Kumar Gala @ 2005-04-27 18:36 UTC (permalink / raw)
  To: Chiradeep Vittal; +Cc: linuxppc-embedded
In-Reply-To: <F237EFC9919B064C8BF5A44CDA5DA0C212F678@matisse01.matissenetworks.com>

On Apr 27, 2005, at 12:46 PM, Chiradeep Vittal wrote:

> We're running Linux Kernel 2.4.26 on an 8540 ADS derivative. We're
>  seeing an
> "illegal instruction"=A0 (SIGILL) exception under some circumstances
> (during a pthread_create call). We were wondering if this could be a
> symptom of
> CPU29 and if there is a patch available for CPU29.
>
> "CPU29 L1 instruction cache gets multiple entries for same line after
>  change
> in MSR[IS] bit "
>
> www.freescale.com/files/32bit/doc/errata/MPC8540CE.pdf

The way the Linux kernel manages the MMU on e500 it doesn't actually=20
ever modify MSR[IS] or MSR[DS].  They are always zero so I dont believe=20=

you are hitting this errata.

Are you running with math emulation turned on?  Do you know what the=20
instruction is that causes the SIGILL?

- kumar

^ permalink raw reply

* Re: OLS 2005
From: Kumar Gala @ 2005-04-27 18:35 UTC (permalink / raw)
  To: Matt Porter; +Cc: David Ho, linuxppc-embedded
In-Reply-To: <20050427112218.E11404@cox.net>

> > I'm only worried about the weather. I was told it's pretty hot
> > there in July :).
>
> Haha...come visit us in Phoenix.=A0 Weather is definitely near
>  perfect in Ottawa, IMHO.

Agreed, I'd rather be in Ottawa in July.  Which was nice last year and=20=

hopefully this year as well.

> > If you can give more info about what to do in Ottawa in addition
> > to drinking beer and attending OLS it'd be great :P

I wondering if we can get a PPC BoF together, however not sure exactly=20=

what we would talk about.  Any ideas?

- kumar

^ permalink raw reply

* Re: OLS 2005
From: Matt Porter @ 2005-04-27 18:22 UTC (permalink / raw)
  To: David Ho, linuxppc-embedded
In-Reply-To: <20050427172320.GC440@gate.ebshome.net>

On Wed, Apr 27, 2005 at 10:23:20AM -0700, Eugene Surovegin wrote:
> On Wed, Apr 27, 2005 at 12:42:26PM -0400, David Ho wrote:
> > Is anyone interested in going to the OLS this year?  I've been working in
> > Ottawa for 4 years so if you are interested I can give anyone more
> > information about things to do in Ottawa.
> 
> I'm going to Ottawa this year.

See you there!

> I'm only worried about the weather. I was told it's pretty hot 
> there in July :).

Haha...come visit us in Phoenix.  Weather is definitely near
perfect in Ottawa, IMHO.

> If you can give more info about what to do in Ottawa in addition 
> to drinking beer and attending OLS it'd be great :P

Several of us did the Parliament building tour in '03. It was
pretty interesting. Drinking beer is always a big draw though.

-Matt

^ permalink raw reply

* Linux Kernel Issue: MPC8540 Errata (CPU29)
From: Chiradeep Vittal @ 2005-04-27 17:46 UTC (permalink / raw)
  To: linuxppc-embedded

We're running Linux Kernel 2.4.26 on an 8540 ADS derivative. We're
seeing an=20
"illegal instruction"  (SIGILL) exception under some circumstances=20
(during a pthread_create call). We were wondering if this could be a
symptom of=20
CPU29 and if there is a patch available for CPU29.

"CPU29 L1 instruction cache gets multiple entries for same line after
change=20
in MSR[IS] bit "

www.freescale.com/files/32bit/doc/errata/MPC8540CE.pdf


Thanks
--
Chiradeep Vittal
Matisse Networks Inc.=20

^ permalink raw reply

* Re: OLS 2005
From: Grant Likely @ 2005-04-27 17:40 UTC (permalink / raw)
  To: David Ho, linuxppc-embedded
In-Reply-To: <20050427172320.GC440@gate.ebshome.net>

On 4/27/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Wed, Apr 27, 2005 at 12:42:26PM -0400, David Ho wrote:
> > Is anyone interested in going to the OLS this year?  I've been working =
in
> > Ottawa for 4 years so if you are interested I can give anyone more
> > information about things to do in Ottawa.
>=20
> I'm going to Ottawa this year.
>=20
> I'm only worried about the weather. I was told it's pretty hot
> there in July :).
>=20
> If you can give more info about what to do in Ottawa in addition
> to drinking beer and attending OLS it'd be great :P
The National Gallery is just about next door as is the parliment
buildings.  Across the river in Hull is the Museum of Civilization.=20
I'm going to make damn sure that I get a meal at Darcy McGee's on
Sparks street (Irish pub; have the steak & mushroom crock).

g.

^ permalink raw reply

* Re: OLS 2005
From: Eugene Surovegin @ 2005-04-27 17:23 UTC (permalink / raw)
  To: David Ho; +Cc: linuxppc-embedded
In-Reply-To: <OF2BA91C3E.A4F6D7AD-ON85256FF0.005B6EFF-85256FF0.005BC6DE@nanometrics.ca>

On Wed, Apr 27, 2005 at 12:42:26PM -0400, David Ho wrote:
> Is anyone interested in going to the OLS this year?  I've been working in
> Ottawa for 4 years so if you are interested I can give anyone more
> information about things to do in Ottawa.

I'm going to Ottawa this year.

I'm only worried about the weather. I was told it's pretty hot 
there in July :).

If you can give more info about what to do in Ottawa in addition 
to drinking beer and attending OLS it'd be great :P

-- 
Eugene

^ permalink raw reply

* Re: OLS 2005
From: Grant Likely @ 2005-04-27 16:46 UTC (permalink / raw)
  To: David Ho; +Cc: linuxppc-embedded
In-Reply-To: <OF2BA91C3E.A4F6D7AD-ON85256FF0.005B6EFF-85256FF0.005BC6DE@nanometrics.ca>

On 4/27/05, David Ho <DavidHo@nanometrics.ca> wrote:
> Is anyone interested in going to the OLS this year?  I've been working in
> Ottawa for 4 years so if you are interested I can give anyone more
> information about things to do in Ottawa.
I'll be there this year.  Looking forward to meeting some of the
embedded hackers.  I'm new on the embedded ppc scene.

g.

^ permalink raw reply

* OLS 2005
From: David Ho @ 2005-04-27 16:42 UTC (permalink / raw)
  To: linuxppc-embedded

Is anyone interested in going to the OLS this year?  I've been working in
Ottawa for 4 years so if you are interested I can give anyone more
information about things to do in Ottawa.

Just heads up for those planning to go, the deadline for early bird
registration is May 1 I think.  You save CAN $150 (350 as opposed to 500).

http://www.linuxsymposium.org/2005/

David

^ permalink raw reply

* Re: MPC8xx Platformization
From: Jason McMullan @ 2005-04-27 16:38 UTC (permalink / raw)
  To: PPC_LINUX
In-Reply-To: <609724aa0424d00c851e3d085ce6d56f@freescale.com>

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On Wed, 2005-04-27 at 09:42 -0500, Kumar Gala wrote:
> Jason,
> 
> Two comments:
> 1. put mpc8xx_devices.c & mpc8xx_sys.c in arch/ppc/syslib (I moved the 
> 85xx ones here and its where 83xx & 52xx are)

Ok.

> 2. can we just use hard coded offsets for start & end values.  I really 
> hate assuming that the global immap_t structure is always correct.  I'm 
> assuming on 8xx these values really aren't changing, take a look at 
> mpc83xx_devices.c

No problem. I'll get another patch out soon.

-- 
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: Status of Linux 2.6 for 40x and 44x CPUs
From: Glenn Burkhardt @ 2005-04-27 16:33 UTC (permalink / raw)
  To: linuxppc-embedded

=46rom the looks of the benchmarks described here:

http://www.denx.de/twiki/bin/view/Know/Linux24vs26

and the results are basically confirmed here:

http://www.2cpu.com/articles/98_1.html

there are good reasons to avoid using the 2.6 kernel.  Frankly, I'm surpris=
ed=20
and would have thought that the changes in the scheduler would have brought=
=20
improvements, as did the report here:

http://www.lynuxworks.com/corporate/news/2004/linux-kernel-2.6.php

But it looks like the major improvements are in filesystem performance, so =
for=20
embedded use, 2.4 will be around for quite a while.

^ permalink raw reply

* Re: Booting linux for 405EP --> mem_pieces_find( ) nightmare
From: Conn Clark @ 2005-04-27  9:21 UTC (permalink / raw)
  To: Garcia Jérémie; +Cc: linuxppc-dev
In-Reply-To: <D4FDDD1349B5AC46B68FC26AD8AF42D6226B23@exnet.3il.fr>

Hi Jérémie,


Garcia Jérémie wrote:
> Hi everybody,
> I'm tryin to adapt a linux LSP deom Montavista (the one for the 405EP evaluation board) to a proprietary hardware using a 405EP.
> Unfortunately, it is not as easy as I thought. Here is my problem:
> To load our linux image (zImage.treeboot), we use the "VxWorks bootrom" bootloader which download the image via tftp.
> That works well except the fact that in the LSP, linux tried to get a board info structure in flash memory at an address where we have nothing. So we replace this behavior in "embed_config.c" with the following lines (note: I had to re-code the strcpy although there is the #include<string.h> because it cannot find the reference at the link level... why???):
> 

I would recomend using u-boot for a boot rom. It was a god send to us in 
getting our MPC850 board up and going the first time. On our 405EP board 
we did have to do some slight hacking but nothing really major.


> /* We use VxWorks bootrom, so we have to create ourselves the boot info structure */

<snip>


> Jérémie        \\ (°.°) //~ ~ ~ HELP ~ ~ ~ \\ (°.°) //
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 

-- Conn

*****************************************************************
Blessed be the heretic, for he causes some to think and unites
the rest against him.
*****************************************************************

Conn Clark
Engineering Assistant                clark@esteem.com
Electronic Systems Technology Inc.        www.esteem.com

Stock Ticker Symbol                ELST

^ permalink raw reply

* testing 2.6 kernel on 8xx/8260
From: Stephan Linke @ 2005-04-27 15:08 UTC (permalink / raw)
  To: linuxppc-dev

I like to test a 2.6 kernel on our 8xx and 8272 boards.
any adwise where to get good kernel sources for it?

Thanks, Stephan

^ permalink raw reply

* Re: Browsers that support javascript and Nano-X
From: David Ho @ 2005-04-27 14:40 UTC (permalink / raw)
  To: Vijesh VH; +Cc: linuxppc-embedded
In-Reply-To: <8e78982e05042706097427f3e0@mail.gmail.com>

Hi,

At Nanometrics, we have compiled Konqueror-embedded, kdenox, and
qt-embedded for our Motorola PowerPC 8xx platform.
Total memory usage of the browser is around 20Megs.
I don't believe ppc8xx is not too much different from the PowerPC 405, but
I might be wrong.
If you need help you can post questions at konq-e@kde.org

David



                                                                           
             Vijesh VH                                                     
             <vijesh.vh@gmail.                                             
             com>                                                       To 
             Sent by:                  linuxppc-embedded@ozlabs.org,       
             linuxppc-embedded         NanoGUI Mailing List                
             -bounces@ozlabs.o         <nanogui@linuxhacker.org>           
             rg                                                         cc 
                                                                           
                                                                   Subject 
             04/27/2005 09:09          Browsers that support javascript    
             AM                        and Nano-X                          
                                                                           
                                                                           
             Please respond to                                             
                 Vijesh VH                                                 
             <vijesh.vh@gmail.                                             
                   com>                                                    
                                                                           
                                                                           





Hi,
Has any one tried cross compiling (for PowerPc4 05)any javascript supported
browser. If so please help me out in selection of the open source browsers.

Architecture:PowerPC 405 Embedded Processor
GUI: NanoX

--
Thanks and Regards,
Vijesh V H _______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Re: USB Host on 8271 (A cry for help)
From: Kumar Gala @ 2005-04-27 14:44 UTC (permalink / raw)
  To: Pantelis Antoniou; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <426F5D1A.7050805@intracom.gr>

> PS. Please, would someone from freescale include this fine
>  point in the manual?

forwarded this on to one of our docs people, we will see what happens.

- kumar

^ permalink raw reply

* Re: MPC8xx Platformization
From: Kumar Gala @ 2005-04-27 14:42 UTC (permalink / raw)
  To: Jason McMullan; +Cc: PPC_LINUX
In-Reply-To: <1114609634.30649.14.camel@ad.doubleclick.net>

Jason,

Two comments:
1. put mpc8xx_devices.c & mpc8xx_sys.c in arch/ppc/syslib (I moved the 
85xx ones here and its where 83xx & 52xx are)
2. can we just use hard coded offsets for start & end values.  I really 
hate assuming that the global immap_t structure is always correct.  I'm 
assuming on 8xx these values really aren't changing, take a look at 
mpc83xx_devices.c

thanks

- kumar

On Apr 27, 2005, at 8:47 AM, Jason McMullan wrote:

> _______________________________________________
> Linuxppc-embedded mailing list
>  Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> Date: April 27, 2005 8:48:03 AM CDT
> Subject:
>
>
>
> Date: April 27, 2005 8:48:03 AM CDT
> Subject:
>
>
> <ATT520952.txt><mpc8xx-platformize.patch>
>
> <signature.asc>
>

^ permalink raw reply

* PCI IO_BASE
From: Marco Schramel @ 2005-04-27 14:59 UTC (permalink / raw)
  To: PPC_LINUX

Hi,

actually my system (2.4.25 on MPC8270 with PCI) runs fine and it will be tested. Thanks to all.
But one thing isn't really clear. The IO_BASE and memory windows for pci.

This is original taken from arch/ppc/plattforms/ads8260.h

/* window for a PCI master to access MPC8266 memory */
#define PCI_SLV_MEM_LOCAL	0x00000000	/* Local base */
#define PCI_SLV_MEM_BUS		0x00000000	/* PCI base */

/* window for the processor to access PCI memory with prefetching */
#define PCI_MSTR_MEM_LOCAL		0x80000000	/* Local base */
#define PCI_MSTR_MEM_BUS		0x80000000	/* PCI base   */
#define PCI_MSTR_MEM_SIZE		0x20000000	/* 512MB */

/* window for the processor to access PCI memory without prefetching */
#define PCI_MSTR_MEMIO_LOCAL	0xA0000000	/* Local base */
#define PCI_MSTR_MEMIO_BUS		0xA0000000	/* PCI base   */
#define PCI_MSTR_MEMIO_SIZE		0x20000000	/* 512MB */

/* window for the processor to access PCI I/O */
#define PCI_MSTR_IO_LOCAL	0xF4000000      /* Local base */
#define PCI_MSTR_IO_BUS         0x00000000	/* PCI base   */
#define PCI_MSTR_IO_SIZE        0x04000000	/* 64MB */

#define _IO_BASE				PCI_MSTR_IO_LOCAL
#define _ISA_MEM_BASE		PCI_MSTR_MEMIO_LOCAL
#define PCI_DRAM_OFFSET	PCI_SLV_MEM_BUS
#endif /* CONFIG_PCI */

These memory windows are not really clear to me. Which documentation can expand my theoretical background? Any comments are welcome.

If CONFIG_PCI is defined the io accesses will depend on the _IO_BASE (at example for ide accesses, now i know ;-)).
Why it depends on it ?
If i will adapt another chip with the standard io-accesses of /asm/io.h, which things i ve to know (offsets, windowsizes,etc..)?  

Thanks for your comments.

Marco



-- 
---------
Marco Schramel

^ permalink raw reply

* Re: [PATCH] make gcc -O1 in fs/reiserfs optional
From: Hans Reiser @ 2005-04-27 13:40 UTC (permalink / raw)
  To: Olaf Hering; +Cc: linuxppc-dev, reiserfs-dev, Jeff Mahoney
In-Reply-To: <20050426211019.GA11579@suse.de>

Olaf Hering wrote:

>Jeff,
>
>you added this EXTRA_CFLAGS= during 2.4 development, I think the broken
>compiler was gcc 3.2 on SLES8. Can we turn this -O1 into a .config
>option?
>
>
>Signed-off-by: Olaf Hering <olh@suse.de>
>
>Index: linux-2.6.12-rc3-olh/fs/reiserfs/Makefile
>===================================================================
>--- linux-2.6.12-rc3-olh.orig/fs/reiserfs/Makefile
>+++ linux-2.6.12-rc3-olh/fs/reiserfs/Makefile
>@@ -21,13 +21,7 @@ ifeq ($(CONFIG_REISERFS_FS_POSIX_ACL),y)
> reiserfs-objs += xattr_acl.o
> endif
> 
>-# gcc -O2 (the kernel default)  is overaggressive on ppc32 when many inline
>-# functions are used.  This causes the compiler to advance the stack
>-# pointer out of the available stack space, corrupting kernel space,
>-# and causing a panic. Since this behavior only affects ppc32, this ifeq
>-# will work around it. If any other architecture displays this behavior,
>-# add it here.
>-ifeq ($(CONFIG_PPC32),y)
>+ifeq ($(CONFIG_REISERFS_CC_REDUCE_OPTIMZE),y)
> EXTRA_CFLAGS := -O1
> endif
> 
>Index: linux-2.6.12-rc3-olh/fs/Kconfig
>===================================================================
>--- linux-2.6.12-rc3-olh.orig/fs/Kconfig
>+++ linux-2.6.12-rc3-olh/fs/Kconfig
>@@ -186,6 +186,18 @@ config REISERFS_FS
> 	  If you like it, you can pay us to add new features to it that you
> 	  need, buy a support contract, or pay us to port it to another OS.
> 
>+config REISERFS_CC_REDUCE_OPTIMZE
>+	bool "Reduce CC optimization level to workaround compiler bugs"
>+	depends on PPC32
>+	default n
>+	help
>+	  gcc -O2 (the kernel default) is overaggressive on ppc32 when many inline
>+	  functions are used.  This causes the compiler to advance the stack
>+	  pointer out of the available stack space, corrupting kernel space,
>+	  and causing a panic. Since this behavior only affects ppc32, this ifeq
>+	  will work around it. If any other architecture displays this behavior,
>+	  add it here.
>+
> config REISERFS_CHECK
> 	bool "Enable reiserfs debug mode"
> 	depends on REISERFS_FS
>
>
>  
>
Sounds reasonable.

^ permalink raw reply

* MPC8xx Platformization
From: Jason McMullan @ 2005-04-27 13:47 UTC (permalink / raw)
  To: PPC_LINUX


[-- Attachment #1.1: Type: text/plain, Size: 301 bytes --]


The following is a rough skeleton of platformization for the mpc8xx
series, in the same technique as Kumar's 85xx platformization.

This rough cut will be followed up later with specific
driver platformization fixes.


-- 
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation


[-- Attachment #1.2: mpc8xx-platformize.patch --]
[-- Type: text/x-patch, Size: 11907 bytes --]

Date:        Wed, 20 Apr 2005 11:11:23 -0400
Signed-Off-By:  Jason McMullan <jason.mcmullan@timesys.com>
Description: MPC8xx platformization

Index of changes:

 arch/ppc/Makefile                             |    2 
 arch/ppc/syslib/Makefile                      |    3 
 arch/ppc/syslib/m8xx_setup.c                  |    3 
 include/asm-ppc/mpc8xx.h                      |   31 ++
 include/asm-ppc/ppc_sys.h                     |    2 
 linux/arch/ppc/platforms/8xx/mpc8xx_ads.c     |   22 ++
 linux/arch/ppc/platforms/8xx/mpc8xx_devices.c |  282 ++++++++++++++++++++++++++
 linux/arch/ppc/platforms/8xx/mpc8xx_sys.c     |   39 +++
 8 files changed, 383 insertions(+), 1 deletion(-)


--- linux-orig/arch/ppc/Makefile
+++ linux/arch/ppc/Makefile
@@ -38,6 +38,7 @@
 cpu-as-$(CONFIG_6xx)		+= -Wa,-maltivec
 cpu-as-$(CONFIG_POWER4)		+= -Wa,-maltivec
 cpu-as-$(CONFIG_E500)		+= -Wa,-me500
+cpu-as-$(CONFIG_8xx)		+= -mcpu=860
 
 AFLAGS += $(cpu-as-y)
 CFLAGS += $(cpu-as-y)
@@ -57,6 +58,7 @@
 core-y				+= arch/ppc/kernel/ arch/ppc/platforms/ \
 				   arch/ppc/mm/ arch/ppc/lib/ arch/ppc/syslib/
 core-$(CONFIG_4xx)		+= arch/ppc/platforms/4xx/
+core-$(CONFIG_8xx)		+= arch/ppc/platforms/8xx/
 core-$(CONFIG_85xx)		+= arch/ppc/platforms/85xx/
 core-$(CONFIG_MATH_EMULATION)	+= arch/ppc/math-emu/
 core-$(CONFIG_XMON)		+= arch/ppc/xmon/
--- /dev/null
+++ linux/arch/ppc/platforms/8xx/mpc8xx_ads.c
@@ -0,0 +1,22 @@
+#include <linux/config.h>
+#include <linux/fec_8xx_pd.h>
+#include <asm/ppcboot.h>
+#include <asm/mpc8xx.h>
+#include <asm/ppc_sys.h>
+
+extern unsigned char __res[];
+
+void board_init(void)
+{
+	struct fec_platform_info *fec;
+	bd_t *bi = (void *)&__res[0];
+
+	/* Set up the MAC addresses for the FECs
+	 */
+	fec = ppc_sys_platform_devices[MPC8xx_CPM_FEC1].dev.platform_data;
+	memcpy(fec->macaddr,bi->bi_enetaddr,6);
+
+	fec = ppc_sys_platform_devices[MPC8xx_CPM_FEC2].dev.platform_data;
+	memcpy(fec->macaddr,bi->bi_enetaddr,6);
+	fec->macaddr[5] ^= 1;
+}

--- /dev/null
+++ linux/arch/ppc/platforms/8xx/mpc8xx_devices.c
@@ -0,0 +1,282 @@
+/*
+ * arch/ppc/platforms/8xx/mpc8xx_devices.c
+ *
+ * MPC8xx Device descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/serial_8250.h>
+#include <linux/fsl_devices.h>
+#include <linux/fec_8xx_pd.h>
+#include <asm/mpc8xx.h>
+#include <asm/8xx_immap.h>
+#include <asm/irq.h>
+#include <asm/ppc_sys.h>
+
+/* We use offsets for IORESOURCE_MEM since we do not know at compile time
+ * what CCSRBAR is, will get fixed up by mach_mpc8xx_fixup
+ */
+
+static struct fsl_i2c_platform_data mpc8xx_fsl_i2c_pdata = {
+	.device_flags = FSL_I2C_DEV_SEPARATE_DFSRR,
+};
+
+static struct fec_mii_bus_info mii_bus_info = {
+	.method			= fecmii_fec,
+	.id			= 0,
+};
+
+static struct fec_platform_info mpc8xx_fec_pdata[] = {
+	{
+		.rx_ring = 128,
+		.tx_ring = 16,
+		.rx_copybreak = 240,
+
+		.use_napi = 1,
+		.napi_weight = 17,
+
+		.bus_info = &mii_bus_info,
+	},{
+		.rx_ring = 128,
+		.tx_ring = 16,
+		.rx_copybreak = 240,
+
+		.use_napi = 1,
+		.napi_weight = 17,
+
+		.bus_info = &mii_bus_info,
+	}
+};
+
+#define IMMAP_STRUCT(x)	((((immap_t *)0)->x))
+#define IMMAP_OFFSET(x)	((unsigned long)&IMMAP_STRUCT(x))
+#define IMMAP_END(x)	(IMMAP_OFFSET(x) + sizeof(IMMAP_STRUCT(x)) - 1)
+
+#define CPM_OFFSET(x)	IMMAP_OFFSET(im_cpm.x)
+#define CPM_END(x)	IMMAP_END(im_cpm.x)
+
+struct platform_device ppc_sys_platform_devices[] = {
+#if 0
+	[MPC8xx_I2C] = {
+		.name = "fsl-i2c",
+		.id	= 1,
+		.dev.platform_data = &mpc8xx_fsl_i2c_pdata,
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.start	= IMMAP_OFFSET(im_i2c),
+				.end	= IMMAP_END(im_i2c),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= MPC8xx_IRQ_I2C,
+				.end	= MPC8xx_IRQ_I2C,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+#endif
+	[MPC8xx_CPM_FEC1] =	{
+		.name = "fsl-fec",
+		.id	= 0,
+		.dev.platform_data = &mpc8xx_fec_pdata[0],
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.start	= CPM_OFFSET(cp_fec1),
+				.end	= CPM_END(cp_fec1),
+				.flags	= IORESOURCE_MEM,
+
+			},
+			{
+				.start	= MPC8xx_INT_FEC1,
+				.end	= MPC8xx_INT_FEC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_FEC2] =	{
+		.name = "fsl-fec",
+		.id	= 1,
+		.dev.platform_data = &mpc8xx_fec_pdata[1],
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.start	= CPM_OFFSET(cp_fec2),
+				.end	= CPM_END(cp_fec2),
+				.flags	= IORESOURCE_MEM,
+
+			},
+			{
+				.start	= MPC8xx_INT_FEC2,
+				.end	= MPC8xx_INT_FEC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_SCC1] = {
+		.name = "fsl-cpm-scc",
+		.id	= 1,
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.start	= CPM_OFFSET(cp_scc[0]),
+				.end	= CPM_END(cp_scc[0]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= MPC8xx_INT_SCC1,
+				.end	= MPC8xx_INT_SCC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_SCC2] = {
+		.name = "fsl-cpm-scc",
+		.id	= 2,
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.start	= CPM_OFFSET(cp_scc[1]),
+				.end	= CPM_END(cp_scc[1]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= MPC8xx_INT_SCC2,
+				.end	= MPC8xx_INT_SCC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_SCC3] = {
+		.name = "fsl-cpm-scc",
+		.id	= 3,
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.start	= CPM_OFFSET(cp_scc[2]),
+				.end	= CPM_END(cp_scc[2]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= MPC8xx_INT_SCC3,
+				.end	= MPC8xx_INT_SCC3,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_SCC4] = {
+		.name = "fsl-cpm-scc",
+		.id	= 4,
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.start	= CPM_OFFSET(cp_scc[3]),
+				.end	= CPM_END(cp_scc[3]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= MPC8xx_INT_SCC4,
+				.end	= MPC8xx_INT_SCC4,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+#if 0
+	[MPC8xx_CPM_SPI] = {
+		.name = "fsl-cpm-spi",
+		.id	= 1,
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.start	= CPM_OFFSET(cp_spmode),
+				.end	= CPM_END(cp_spcom),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= MPC8xx_INT_SPI,
+				.end	= MPC8xx_INT_SPI,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+#endif
+	[MPC8xx_CPM_SMC1] = {
+		.name = "fsl-cpm-smc",
+		.id	= 1,
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.start	= CPM_OFFSET(cp_smc[0]),
+				.end	= CPM_END(cp_smc[0]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= MPC8xx_INT_SMC1,
+				.end	= MPC8xx_INT_SMC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_SMC2] = {
+		.name = "fsl-cpm-smc",
+		.id	= 2,
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.start	= CPM_OFFSET(cp_smc[1]),
+				.end	= CPM_END(cp_smc[1]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= MPC8xx_INT_SMC2,
+				.end	= MPC8xx_INT_SMC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+#if 0
+	[MPC8xx_CPM_USB] = {
+		.name = "fsl-cpm-usb",
+		.id	= 0,
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.start	= CPM_OFFSET(cp_scc[0]),
+				.end	= CPM_END(cp_scc[0]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= MPC8xx_INT_USB,
+				.end	= MPC8xx_INT_USB,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+#endif
+};
+
+static int __init mach_mpc8xx_fixup(struct platform_device *pdev)
+{
+	ppc_sys_fixup_mem_resource(pdev, IMAP_ADDR);
+	return 0;
+}
+
+static int __init mach_mpc8xx_init(void)
+{
+	ppc_sys_device_fixup = mach_mpc8xx_fixup;
+	return 0;
+}
+
+postcore_initcall(mach_mpc8xx_init);

--- /dev/null
+++ linux/arch/ppc/platforms/8xx/mpc8xx_sys.c
@@ -0,0 +1,39 @@
+/*
+ * arch/ppc/platforms/8xx/mpc8xx_sys.c
+ *
+ * MPC8xx System descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <asm/ppc_sys.h>
+
+struct ppc_sys_spec *cur_ppc_sys_spec;
+struct ppc_sys_spec ppc_sys_specs[] = {
+	{
+		.ppc_sys_name	= "MPC885",
+		.mask 		= 0xFFFF0000,
+		.value 		= 0x00500000,
+		.num_devices	= 2,
+		.device_list	= (enum ppc_sys_devices[])
+		{
+			MPC8xx_CPM_FEC1,
+			MPC8xx_CPM_SCC1,
+		},
+	},
+	{	/* default match */
+		.ppc_sys_name	= "",
+		.mask 		= 0x00000000,
+		.value 		= 0x00000000,
+	},
+};

--- linux-orig/arch/ppc/syslib/Makefile
+++ linux/arch/ppc/syslib/Makefile
@@ -33,7 +33,8 @@
 obj-$(CONFIG_PCI)		+= indirect_pci.o pci_auto.o ppc405_pci.o
 endif
 endif
-obj-$(CONFIG_8xx)		+= m8xx_setup.o ppc8xx_pic.o $(wdt-mpc8xx-y)
+obj-$(CONFIG_8xx)		+= m8xx_setup.o ppc8xx_pic.o $(wdt-mpc8xx-y) \
+				   ppc_sys.o
 ifeq ($(CONFIG_8xx),y)
 obj-$(CONFIG_PCI)		+= qspan_pci.o i8259.o
 endif
--- linux-orig/arch/ppc/syslib/m8xx_setup.c
+++ linux/arch/ppc/syslib/m8xx_setup.c
@@ -45,6 +45,7 @@
 #include <asm/bootinfo.h>
 #include <asm/time.h>
 #include <asm/xmon.h>
+#include <asm/ppc_sys.h>
 
 #include "ppc8xx_pic.h"
 
@@ -408,6 +409,8 @@
 		strcpy(cmd_line, (char *)(r6+KERNELBASE));
 	}
 
+	identify_ppc_sys_by_id(mfspr(PVR));
+
 	ppc_md.setup_arch		= m8xx_setup_arch;
 	ppc_md.show_percpuinfo		= m8xx_show_percpuinfo;
 	ppc_md.irq_canonicalize	= NULL;
--- linux-orig/include/asm-ppc/mpc8xx.h
+++ linux/include/asm-ppc/mpc8xx.h
@@ -90,6 +90,10 @@
 #endif
 
 #ifndef __ASSEMBLY__
+#include <asm/irq.h>
+#include <asm/mmu.h>
+#include <asm/commproc.h>
+
 /* The "residual" data board information structure the boot loader
  * hands to us.
  */
@@ -97,7 +101,34 @@
 
 struct pt_regs;
 
+/* Let modules/drivers get at CCSRBAR */
+extern phys_addr_t get_ccsrbar(void);
+
+#define MPC8xx_INT_FEC1		SIU_LEVEL1
+#define MPC8xx_INT_FEC2		SIU_LEVEL3
+#define MPC8xx_INT_SCC1		(CPM_IRQ_OFFSET + CPMVEC_SCC1)
+#define MPC8xx_INT_SCC2		(CPM_IRQ_OFFSET + CPMVEC_SCC2)
+#define MPC8xx_INT_SCC3		(CPM_IRQ_OFFSET + CPMVEC_SCC3)
+#define MPC8xx_INT_SCC4		(CPM_IRQ_OFFSET + CPMVEC_SCC4)
+#define MPC8xx_INT_SMC1		(CPM_IRQ_OFFSET + CPMVEC_SMC1)
+#define MPC8xx_INT_SMC2		(CPM_IRQ_OFFSET + CPMVEC_SMC2)
+
+enum ppc_sys_devices {
+	MPC8xx_I2C,
+	MPC8xx_CPM_FEC1,
+	MPC8xx_CPM_FEC2,
+	MPC8xx_CPM_SPI,
+	MPC8xx_CPM_USB,
+	MPC8xx_CPM_SCC1,
+	MPC8xx_CPM_SCC2,
+	MPC8xx_CPM_SCC3,
+	MPC8xx_CPM_SCC4,
+	MPC8xx_CPM_SMC1,
+	MPC8xx_CPM_SMC2,
+};
 #endif /* !__ASSEMBLY__ */
+
+
 #endif /* CONFIG_8xx */
 #endif /* __CONFIG_8xx_DEFS */
 #endif /* __KERNEL__ */
--- linux-orig/include/asm-ppc/ppc_sys.h
+++ linux/include/asm-ppc/ppc_sys.h
@@ -23,6 +23,8 @@
 
 #if defined(CONFIG_85xx)
 #include <asm/mpc85xx.h>
+#elif defined(CONFIG_8xx)
+#include <asm/mpc8xx.h>
 #else
 #error "need definition of ppc_sys_devices"
 #endif

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Browsers that support javascript and Nano-X
From: Vijesh VH @ 2005-04-27 13:09 UTC (permalink / raw)
  To: linuxppc-embedded, NanoGUI Mailing List

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

Hi,
Has any one tried cross compiling (for PowerPc4 05)any javascript supported 
browser. If so please help me out in selection of the open source browsers.

Architecture:PowerPC 405 Embedded Processor
GUI: NanoX

-- 
Thanks and Regards,
Vijesh V H

[-- Attachment #2: Type: text/html, Size: 290 bytes --]

^ permalink raw reply

* Re: USB Host on 8271 (A cry for help)
From: Pantelis Antoniou @ 2005-04-27  9:36 UTC (permalink / raw)
  To: Pantelis Antoniou; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <426F4598.6080009@intracom.gr>

Pantelis Antoniou wrote:
> Hi there
> 
> I'm trying to get USB host mode to work on 8271 and I'm
> stumped.
> 
> The major problem is that automatic SOF generation as mentioned
> in the manual appears to not work (or it's not clear how to
> enable it).
> 
> I'm trying to port the 8xx based driver, which works
> adequately after applying the microcode patch.
> 
> Sadly usb host mode on 82xx appears to suck even more.
> 
> If anyone has *any* code that works for host mode on 82xx please
> contact me.
> 
> Regards
> 
> Pantelis
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

Found it.

Now it works. RCCR[EIE] must be set.

But is this mentioned anywhere in the USB chapter of the manual?

NO! That would be too easy.

Regards

Pantelis.

PS. Please, would someone from freescale include this fine
point in the manual?

Thank you.

^ permalink raw reply

* USB Host on 8271 (A cry for help)
From: Pantelis Antoniou @ 2005-04-27  7:56 UTC (permalink / raw)
  To: Tom Rini, linuxppc-embedded, Dan Malek, Eugene Surovegin,
	Kumar Gala

Hi there

I'm trying to get USB host mode to work on 8271 and I'm
stumped.

The major problem is that automatic SOF generation as mentioned
in the manual appears to not work (or it's not clear how to
enable it).

I'm trying to port the 8xx based driver, which works
adequately after applying the microcode patch.

Sadly usb host mode on 82xx appears to suck even more.

If anyone has *any* code that works for host mode on 82xx please
contact me.

Regards

Pantelis

^ permalink raw reply

* Re: [RFC] [PATCH] ppc32: workaround for spurious IRQs on PQ2
From: Pantelis Antoniou @ 2005-04-27  7:39 UTC (permalink / raw)
  To: Wrobel Heinz-r39252; +Cc: linuxppc-embedded
In-Reply-To: <DF02D66C37C26B4C8018BF84F0E37FEC08440764@zwg18exm01.ea.freescale.net>

Wrobel Heinz-r39252 wrote:
> Eugene,
> 
> check slides 17, 20-22 out of my SNDF 2004 presentation H1125 found at
> http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=052577pzMPYZjg286165422098
> 
> ... and attend the June 2005 FTF in Orlando ...
> http://www.freescale.com/ftf *grin*
> 
> Heinz
>  

Heh, I *was* on SNDF 2004, but I didn't attend this presentation.

Heinz, try to get a supplement on the web site...

Regards

Pantelis

^ permalink raw reply

* Re: [RFC] [PATCH] ppc32: workaround for spurious IRQs on PQ2
From: Eugene Surovegin @ 2005-04-27  7:15 UTC (permalink / raw)
  To: Wrobel Heinz-r39252; +Cc: linuxppc-embedded
In-Reply-To: <DF02D66C37C26B4C8018BF84F0E37FEC08440764@zwg18exm01.ea.freescale.net>

On Wed, Apr 27, 2005 at 08:54:44AM +0200, Wrobel Heinz-r39252 wrote:
> Eugene,
> 
> check slides 17, 20-22 out of my SNDF 2004 presentation H1125 found at
> http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=052577pzMPYZjg286165422098
> 

Thanks a lot for the link, looks like my interpretation of events was 
correct.

As a side note, I'd be great if _User manual_ has all this 
information (and I always rant about Moto/Freescale manuals on 
#mklinux) :)

-- 
Eugene

^ permalink raw reply

* RE: [RFC] [PATCH] ppc32: workaround for spurious IRQs on PQ2
From: Wrobel Heinz-r39252 @ 2005-04-27  6:54 UTC (permalink / raw)
  To: Eugene Surovegin, linuxppc-embedded

Eugene,

check slides 17, 20-22 out of my SNDF 2004 presentation H1125 found at
http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=052577pzMPYZjg286165422098

... and attend the June 2005 FTF in Orlando ...
http://www.freescale.com/ftf *grin*

Heinz
 

> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org 
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of 
> Eugene Surovegin
> Sent: Tuesday, April 26, 2005 9:22 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: [RFC] [PATCH] ppc32: workaround for spurious IRQs on PQ2
> 
> Hi!
> 
> There is a problem with big amount of spurious IRQs on 8248-based 
> design I'm working on.
> 
> I observed this problem with 2.4.30 kernel, but it was reported to be
> still present on 2.6 as well.
> 
> Traces show that spurious IRQ happens right after handle_IRQ_events() 
> enables external interrupts and _before_ even calling real IRQ 
> handler.
> 
> I fixed this problem by adding sync at the end of cpm2_mask_and_ack. 
> Using out_XXX macros for accessing SIU register doesn't seem to help.
> Dan thinks there are some pipeline-related issues here, although I 
> failed to found any mentions of them in 8272 user manual.
> 
> Also, there is a possibility, that we need more explicit sync's in 
> cpm2_pic code.
> 
> Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
> 
> ===== arch/ppc/syslib/cpm2_pic.c 1.11 vs edited =====
> --- 1.11/arch/ppc/syslib/cpm2_pic.c	2005-03-31 02:59:05 -08:00
> +++ edited/arch/ppc/syslib/cpm2_pic.c	2005-04-26 11:55:51 -07:00
> @@ -90,6 +90,7 @@
>  	ppc_cached_irq_mask[word] &= ~(1 << bit);
>  	simr[word] = ppc_cached_irq_mask[word];
>  	sipnr[word] = 1 << bit;
> +	mb();
>  }
>  
>  static void cpm2_end_irq(unsigned int irq_nr)
> 
> 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

^ permalink raw reply

* Re: Booting linux for 405EP --> mem_pieces_find( ) nightmare
From: Frank @ 2005-04-27  4:54 UTC (permalink / raw)
  To: Garcia Jérémie, linuxppc-dev

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 704 bytes --]


--- Garcia Jérémie <GARCIAJ@3il.fr> wrote:
> Hi everybody,
> I'm tryin to adapt a linux LSP deom Montavista (the one for
> the 405EP evaluation board) to a proprietary hardware using a
> 405EP.
> Unfortunately, it is not as easy as I thought. Here is my
> problem:
> To load our linux image (zImage.treeboot), we use the "VxWorks
> bootrom" bootloader which download the image via tftp.
Why don't you do it the other way( use u-boot). I just replaced
a vxWorks rom with u-boot and now I can happily boot vxWorks or
Linux on an 8260 based board... 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox