* Re: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Tom Rini @ 2005-01-12 14:06 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <JPEALJAFNGDDLOPNDIEEMEPMCPAA.joakim.tjernlund@lumentis.se>
On Wed, Jan 12, 2005 at 08:53:17AM +0100, Joakim Tjernlund wrote:
> > As the code stands currently, there is a bug in the 2.4 and 2.6 handling
> > of I-TLB Miss and Error exceptions on 8xx. The problem is that since we
> > treat both of them as the same exception when we hit do_page_fault,
> > there is a case where we can incorrectly find that a protection fault
> > has occured, when it hasn't. This is because we check bit 4 of SRR1 in
> > both cases, but in the case of an I-TLB Miss, this bit is always set,
> > and it only indicates a protection fault on an I-TLB Error.
>
> Patch looks good to me, but I want to ask when this error
> can be triggered in practice?
It is possible to see this in the real world, as we (<hat=mvista>) found
this with a customers app.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: Some issues with kernel 2.6 for MPC8260 target
From: Steven Blakeslee @ 2005-01-12 13:55 UTC (permalink / raw)
To: Vijay Padiyar, LinuxPPC Support
I would suggest going to the latest 2.6.10 kernel. I have it running
with several ethernets running on all the 82xx processors.=20
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> Vijay Padiyar
> Sent: Wednesday, January 12, 2005 5:37 AM
> To: LinuxPPC Support
> Subject: Some issues with kernel 2.6 for MPC8260 target
>=20
> Hi all
>=20
> I wish to discuss some strange issues that I faced with=20
> respect to the Linux
> 2.6.8 kernel (downloaded from kernel.org). Firstly, I wish to=20
> know whether this has been known to work on an MPC8260 PowerPC target.
>=20
> Secondly, when I tried to compile the Linux kernel with my=20
> toolchain (built with Dan Kegel's crosstool for the PowerPC=20
> 603e core, which is what my processor has), I got some errors=20
> which I found to rather queer after investigation. Firstly,=20
> let me state the errors that I got:
>=20
> ------------------------------------------------------
>=20
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/ppc/8260_io/built-in.o(.text+0x103c): In function=20
> `mii_queue_relink':
> arch/ppc/8260_io/fcc_enet.c:1254: undefined reference to=20
> `schedule_task'
> arch/ppc/8260_io/built-in.o(.text+0x1074): In function=20
> `mii_queue_config':
> arch/ppc/8260_io/fcc_enet.c:1263: undefined reference to=20
> `schedule_task'
>=20
> ------------------------------------------------------
>=20
> On further investigation, I find that 'schedule_task()' is=20
> simply not defined anywhere in the 2.6.8 kernel sources. This=20
> is quite wierd! However, it is defined in a file 'context.c'=20
> (linux-src/kernel) in the 2.4.27 kernel sources, which we=20
> were using earlier. How is it that a function is being called=20
> but its definition has been removed from the sources?
>=20
> Another such example is with the structure 'tq_struct'. It is=20
> referred to in the file 'fcc_enet.c'=20
> (linux-src/arch/ppc/8260_io) but it's not defined anywhere!=20
> Again, after checking in the 2.4.27 sources, I find that it's=20
> defined in the file 'tqueue.h' (linux-src/include/linux)!
>=20
> A third thing is that the 2.4.27 kernel source file 'uart.c'
> (linux-src/arch/ppc/cpm2_io) is not present in the=20
> corresponding folder in the 2.6.8 source=20
> (linux-src/arch/ppc/8260_io). There is one 'uart.c' in the=20
> folder '8xx_io', but it doesn't get compiled during the=20
> kernel build process. Will my UART work correctly with this build?
>=20
> Can someone please tell me if there's some explanation for=20
> this that I'm unaware of? Which would be the proper forum to=20
> report this? Again I would like to ask: Has the 2.6.8 kernel=20
> been tested successfully on the MPC8260 PowerPC platform?
>=20
> Lastly, where can I get the latest stable Linux kernel source=20
> for the PowerPC platform?
>=20
> Regards
>=20
> Vijay Padiyar
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: email message sizes
From: Lorenzo Pivetta @ 2005-01-12 12:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <78DE72FE-631B-11D9-AD26-000A95A0560C@penguinppc.org>
On Mon, 10 Jan 2005 09:22:42 -0600
Hollis Blanchard <hollis@penguinppc.org> wrote:
[snip]
> So are any of you on modems, or operate near the limits of your mail
> quotas? I'd like to hear comments either way: how large is ok to post
> to these mailing lists?
IMHO 100K should be enough...
Regards, Lorenzo.
^ permalink raw reply
* Re: MPC8xx: Using SCM/SCC and standard 16C550 Uarts together...
From: Yuli Barcohen @ 2005-01-12 12:18 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200501121255.56374.david.jander@protonic.nl>
>>>>> David Jander writes:
David> On Wednesday 12 January 2005 10:59, Demke Torsten-atd012
David> wrote:
Demke> I dont know exactly the state of the DENX kernel, but in the
Demke> standard kernel the 8xx UART driver and the 16550 driver are
Demke> using the same device numbers (TTY_MAJOR) and device names
Demke> (/dev/ttySx). You have to change one of them.
David> You are right! What now? I cannot go around and change
David> TTY_MAJOR! Is it true then, that you normally cannot have a
David> mix of non-16550 uarts and 16550 uarts on the same system,
David> without doing nonstandard things with major numbers?
We've got such a mix but we use completely different MPC8xx support
infrastructure. Our SCC/SMC UART driver takes care of possible external
UARTs (it uses the same major number but configurable minor).
David> Should maybe arch/ppc/8xx_io/uart.c use another major number?
Then you'll have to change all applications using standard device names
(ttySx).
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli@arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
========================================================================
^ permalink raw reply
* Re: MPC8xx: Using SCM/SCC and standard 16C550 Uarts together...
From: David Jander @ 2005-01-12 11:55 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43395BE65409D911B9FF00110A9BFFDC9F851C@zwg57exm01.ea.mot.com>
On Wednesday 12 January 2005 10:59, Demke Torsten-atd012 wrote:
> I dont know exactly the state of the DENX kernel, but in the standard
> kernel the 8xx UART driver and the 16550 driver are using the same
> device numbers (TTY_MAJOR) and device names (/dev/ttySx).
> You have to change one of them.
You are right! What now? I cannot go around and change TTY_MAJOR!
Is it true then, that you normally cannot have a mix of non-16550 uarts and
16550 uarts on the same system, without doing nonstandard things with major
numbers?
Should maybe arch/ppc/8xx_io/uart.c use another major number?
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: Help with PPC440GX + MontaVista + uBoot
From: Wolfgang Denk @ 2005-01-12 11:37 UTC (permalink / raw)
To: Howard, Marc; +Cc: linuxppc-embedded
In-Reply-To: <91B22F93A880FA48879475E134D6F0BE316B8C@CA1EXCLV02.adcorp.kla-tencor.com>
In message <91B22F93A880FA48879475E134D6F0BE316B8C@CA1EXCLV02.adcorp.kla-tencor.com> you wrote:
>
> PIBS isn't what we want to use long term, we'd rather use uBoot. I've
> downloaded and built the latest version of uBoot (1.1.2). I then
> created a multi-file image with mkimage. I can download it via TFTP but
> when I start to run it strange/bad things happen:
>
> Kernel command line: ip=3Don console=3DttyS0,115200 root=3D/dev/ram rw
> Warning: real time clock seems stuck!
> Calibrating delay loop... 37.27 BogoMIPS
>
> ...now the RTC is know to work and the mips calculation is seriously
> off. Then...
That's a FAQ. Please see the part about "Bad definition of the
bd_info structure" in
http://www.denx.de/twiki/bin/view/DULG/LinuxHangsAfterUncompressingKernel
> I realize that ocotea.c will have to be modified to grab command line
> options from NVRAM (uBoot) instead of FLASH (PIBS) but that doesn't seem
Wrong. U-Boot (please mind the spelling) does not pass command line
options in NVRAM. They get passed in RAM.
> to explain why the internal timer is way off and the ethernet PHYs can't
> be found.
Because you use a wrong definition of bd_info. Delete the existing
definition and include asm/ppcboot.h in your board config file.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Bradley's Bromide: If computers get too powerful, we can organize
them into a committee - that will do them in.
^ permalink raw reply
* Some issues with kernel 2.6 for MPC8260 target
From: Vijay Padiyar @ 2005-01-12 10:37 UTC (permalink / raw)
To: LinuxPPC Support
Hi all
I wish to discuss some strange issues that I faced with respect to the Linux
2.6.8 kernel (downloaded from kernel.org). Firstly, I wish to know whether
this has been known to work on an MPC8260 PowerPC target.
Secondly, when I tried to compile the Linux kernel with my toolchain (built
with Dan Kegel's crosstool for the PowerPC 603e core, which is what my
processor has), I got some errors which I found to rather queer after
investigation. Firstly, let me state the errors that I got:
------------------------------------------------------
LD init/built-in.o
LD .tmp_vmlinux1
arch/ppc/8260_io/built-in.o(.text+0x103c): In function `mii_queue_relink':
arch/ppc/8260_io/fcc_enet.c:1254: undefined reference to `schedule_task'
arch/ppc/8260_io/built-in.o(.text+0x1074): In function `mii_queue_config':
arch/ppc/8260_io/fcc_enet.c:1263: undefined reference to `schedule_task'
------------------------------------------------------
On further investigation, I find that 'schedule_task()' is simply not
defined anywhere in the 2.6.8 kernel sources. This is quite wierd! However,
it is defined in a file 'context.c' (linux-src/kernel) in the 2.4.27 kernel
sources, which we were using earlier. How is it that a function is being
called but its definition has been removed from the sources?
Another such example is with the structure 'tq_struct'. It is referred to in
the file 'fcc_enet.c' (linux-src/arch/ppc/8260_io) but it's not defined
anywhere! Again, after checking in the 2.4.27 sources, I find that it's
defined in the file 'tqueue.h' (linux-src/include/linux)!
A third thing is that the 2.4.27 kernel source file 'uart.c'
(linux-src/arch/ppc/cpm2_io) is not present in the corresponding folder in
the 2.6.8 source (linux-src/arch/ppc/8260_io). There is one 'uart.c' in the
folder '8xx_io', but it doesn't get compiled during the kernel build
process. Will my UART work correctly with this build?
Can someone please tell me if there's some explanation for this that I'm
unaware of? Which would be the proper forum to report this? Again I would
like to ask: Has the 2.6.8 kernel been tested successfully on the MPC8260
PowerPC platform?
Lastly, where can I get the latest stable Linux kernel source for the
PowerPC platform?
Regards
Vijay Padiyar
^ permalink raw reply
* Re: Kernel boot hangs by parallel flood pings
From: Stefan Nickl @ 2005-01-12 10:29 UTC (permalink / raw)
To: Steffen Rumler; +Cc: linuxppc-embedded
In-Reply-To: <41E4E1EB.6080903@siemens.com>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
On Wed, 2005-01-12 at 09:38 +0100, Steffen Rumler wrote:
> I'm using a 2.4.20 kernel (PPC).
>
> When I run multiple 'ping -f' directed to my board
> during the kernel boots, sometimes it hangs with
> the following messages:
> I have checked this with the BDI2000 and found that the
> kernel loops anywhere inside ip_route_input().
This is a long-standing bug in the cpm and cmp2 drivers.
I think it's also present in 2.6 as far as I remember.
I sent my own fix some time ago, you may find it in the
archives as "[patch] Race condition #2 in arch/ppc/cpm2_io/fcc_enet.c".
Greetings,
--
Stefan Nickl
Kontron Modular Computers
[-- Attachment #2: fcc_enet-mdio_race.patch --]
[-- Type: text/x-patch, Size: 412 bytes --]
--- linuxppc-2.4/arch/ppc/cpm2_io/fcc_enet.c 2004-08-09 08:32:28.000000000 +0200
+++ fcc_enet.c 2004-11-25 18:28:56.000000000 +0100
@@ -2095,10 +2095,10 @@ mii_send_receive(fcc_info_t *fip, uint c
for (i = 0, off = 15; i < 16; i++, off--)
{
FCC_PDATC_MDC(1);
+ udelay(1);
retval <<= 1;
if (io->iop_pdatc & fip->fc_mdio)
retval++;
- udelay(1);
FCC_PDATC_MDC(0);
udelay(1);
}
[-- Attachment #3: fcc_enet-startup_race.patch --]
[-- Type: text/x-patch, Size: 969 bytes --]
--- linuxppc-2.4/arch/ppc/cpm2_io/fcc_enet.c 2004-08-09 08:32:28.000000000 +0200
+++ fcc_enet.c 2004-11-25 18:41:22.000000000 +0100
@@ -2008,16 +2008,6 @@ init_fcc_startup(fcc_info_t *fip, struct
*(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_FETHIEN;
*(volatile uint *)(BCSR_ADDR + 4) |= BCSR1_FETH_RST;
#endif
-
-#if defined(CONFIG_USE_MDIO) || defined(CONFIG_TQM8260)
- /* start in full duplex mode, and negotiate speed
- */
- fcc_restart (dev, 1);
-#else
- /* start in half duplex mode
- */
- fcc_restart (dev, 0);
-#endif
}
#ifdef CONFIG_USE_MDIO
@@ -2155,6 +2145,16 @@ fcc_enet_open(struct net_device *dev)
{
struct fcc_enet_private *fep = dev->priv;
+#if defined(CONFIG_USE_MDIO) || defined(CONFIG_TQM8260)
+ /* start in full duplex mode, and negotiate speed
+ */
+ fcc_restart (dev, 1);
+#else
+ /* start in half duplex mode
+ */
+ fcc_restart (dev, 0);
+#endif
+
#ifdef CONFIG_USE_MDIO
fep->sequence_done = 0;
fep->link = 0;
^ permalink raw reply
* RE: MPC8xx: Using SCM/SCC and standard 16C550 Uarts together...
From: Demke Torsten-atd012 @ 2005-01-12 9:59 UTC (permalink / raw)
To: David Jander, linuxppc-embedded
Hi David,
I dont know exactly the state of the DENX kernel, but in the standard
kernel the 8xx UART driver and the 16550 driver are using the same
device numbers (TTY_MAJOR) and device names (/dev/ttySx).
You have to change one of them.
Regards,
Torsten
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org
> [mailto:linuxppc-embedded-bounces@ozlabs.org]On Behalf Of David Jander
> Sent: Mittwoch, 12. Januar 2005 10:52
> To: linuxppc-embedded@ozlabs.org
> Subject: MPC8xx: Using SCM/SCC and standard 16C550 Uarts together...
>
>
>
> Hi all,
>
> The situation is:
> Our custom board needs to use SCM1 as console, and has an
> external quad uart
> chip (16C554) connected to the external bus, mapped at 0xf8100000.
> I am using the ppclinux_2_4_devel tree from Denx.
> I ioremapped that address space, and it seems to work. Right
> now I don't have
> the daughterboard with the quad-uarts working (as in
> hardware), so I can't
> fully test that.
>
> The problem is:
> Apparently arch/ppc/8xx_io/uart.c doesn't take into account
> other serial
> drivers that may initialize later, and uses a serial_state
> struct statically.
> Shouldn't this be visible to the outside? Shouldn't there be a global
> serial_state structure somewhere that lists all serial ports?
> Right now, I get this:
>
> -----------------------------------
> ...
> CPM UART driver version 0.04
> ttyS0 at 0x0280 is on SMC1 using BRG1
> ttyS1 at 0x0200 is on SCC3 using BRG2
> ttyS2 at 0x0300 is on SCC4 using BRG3
> pty: 256 Unix98 ptys configured
> Serial driver version 5.05c (2001-07-08) with MANY_PORTS
> SHARE_IRQ enabled
> ...
> VFS: Mounted root (jffs2 filesystem).
> Mounted devfs on /dev
> Freeing unused kernel memory: 56k init
> ------------------------------------
>
> And then nothing more. I assume, at that point init opens
> /dev/console (ttyS0)
> and that device doesn't exist, since drivers/char/serial.c
> doesn't detect any
> uart at the moment.
> If it did, maybe I would get console stuff out of the first
> 16c554 port.
>
> Has anybody else tried this?
> What would be the right way to fix this?
>
> Greetings,
>
> --
> David Jander
> Protonic Holland.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* MPC8xx: Using SCM/SCC and standard 16C550 Uarts together...
From: David Jander @ 2005-01-12 9:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
The situation is:
Our custom board needs to use SCM1 as console, and has an external quad uart
chip (16C554) connected to the external bus, mapped at 0xf8100000.
I am using the ppclinux_2_4_devel tree from Denx.
I ioremapped that address space, and it seems to work. Right now I don't have
the daughterboard with the quad-uarts working (as in hardware), so I can't
fully test that.
The problem is:
Apparently arch/ppc/8xx_io/uart.c doesn't take into account other serial
drivers that may initialize later, and uses a serial_state struct statically.
Shouldn't this be visible to the outside? Shouldn't there be a global
serial_state structure somewhere that lists all serial ports?
Right now, I get this:
-----------------------------------
...
CPM UART driver version 0.04
ttyS0 at 0x0280 is on SMC1 using BRG1
ttyS1 at 0x0200 is on SCC3 using BRG2
ttyS2 at 0x0300 is on SCC4 using BRG3
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ enabled
...
VFS: Mounted root (jffs2 filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 56k init
------------------------------------
And then nothing more. I assume, at that point init opens /dev/console (ttyS0)
and that device doesn't exist, since drivers/char/serial.c doesn't detect any
uart at the moment.
If it did, maybe I would get console stuff out of the first 16c554 port.
Has anybody else tried this?
What would be the right way to fix this?
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Kernel boot hangs by parallel flood pings
From: Steffen Rumler @ 2005-01-12 8:38 UTC (permalink / raw)
To: linuxppc
I'm using a 2.4.20 kernel (PPC).
When I run multiple 'ping -f' directed to my board
during the kernel boots, sometimes it hangs with
the following messages:
Memory BAT mapping: BAT2=64Mb, BAT3=32Mb, residual: 84Mb
Linux version 2.4.20-rthal5 (ru@styx) (gcc version 2.95.3 20010111 (prerelease/franzo/20010111))
#9 Tue Jan 11 17:09:22 CET 2005
On node 0 totalpages: 29859
zone(0): 29859 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: bootdev=aps0 ip=218.1.36.70:218.1.36.47:218.1.36.254:255.255.255.0::eth0:off
panic=1 mem=119436k
Calibrating delay loop... 194.15 BogoMIPS
...
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache ha
^^^^^^^
the kernel boot hangs here
I have checked this with the BDI2000 and found that the
kernel loops anywhere inside ip_route_input().
I think this is because the ethernet driver (fcc_enet.c)
enables the hardware too already inside it's init routine (fec_enet_init()).
In this way, frames may be received and forwarded to the upper
layers with netif_rx(), before the TCP/IP was initialized.
I suggest to delay the lines
/* Enable transmit/receive */
fccp->fcc_gfmr |= FCC_GFMR_ENR | FCC_GFMR_ENT;
to the open entry point (fcc_enet_open()), which is
triggered by 'ifconfig up' in the following way:
if(!((fccp->fcc_gfmr) & FCC_GFMR_ENR))
fccp->fcc_gfmr |= (FCC_GFMR_ENR | FCC_GFMR_ENT);
By the way, fcc_enet_close() does _NOT_ stop the hardware.
Hopefully, this is not a real problem.
Steffen
--
--------------------------------------------------------------
Steffen Rumler
ICN CP D NT SW 3
Siemens AG
Hofmannstr. 51 Email: Steffen.Rumler@siemens.com
D-81359 Munich Phone: +49 89 722-44061
Germany Fax : +49 89 722-36703
--------------------------------------------------------------
^ permalink raw reply
* Re: RFC: [PATCH] platform device driver model support
From: Eugene Surovegin @ 2005-01-12 8:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0501120133080.21665@blarg.somerset.sps.mot.com>
On Wed, Jan 12, 2005 at 01:43:09AM -0600, Kumar Gala wrote:
>
> Please take a look at the following patch. It adds driver model support
> via platform devices to 85xx. This is originally based on patches from
> Jason M.
>
> The idea behind the code is that for a give family: 4xx, 8xx, 82xx, 83xx,
> 85xx, 86xx we will have structure defns for the following:
>
> enum ppc_soc_devices
> in asm-ppc/<family.h>:
> list of all unique devices in the family
>
> struct platform_device soc_platform_devices[]
> in arch/ppc/platforms/<family>/<family>_devices.c:
> describes all platform devices that exist in the family
>
> struct soc_spec soc_specs[]
> in arch/ppc/platforms/<family>/<family>_soc.c:
> describes each unique chip in the family and what devices it has
Well, there is a problem right here at least for 4xx.
Current OCP implementation is much more flexible IMHO.
For 4xx is not uncommon when you have the same "logical" device at the
different places with different "properties" (e.h. different channel,
etc).
Your case (85xx) looks simpler - all you need is a list of devices
which particular SoC supports, without significant differences in
"properties". This will not work that easy for 4xx.
In fact, I don't see any gain (at least for 4xx) in all these changes.
It makes 4xx much more tangled IMHO, because we'll still need all
those ibm405gp.c, ibm405ep.c, ibm440gp.c etc.
Please note, using platform_device is orthogonal to the way we
describe each SoC (this is what I don't quite like in your patch), and
I don't have any strong objections to using platform_device instead of
OCP or feature_call or whatever for communication with device drivers.
> Plus the following functions:
>
> identify_soc_by_id() -- determine soc by an int id
> identify_soc_by_name() -- determin soc by name (useful in some 82xx cases)
> ppc_soc_get_pdata() -- get platform_data pointer so board code can modify
> ppc_soc_update_paddr() -- update iomem resources with a given paddr
IMHO, ppc_soc_update_paddr - is a very confusing name, in fact, from
first read I though it _changes_ paddr to the new value, not _adds_ it
:)
Probably this function should be made 85xx specific as I cannot come
up with any use for it in 4xx (we don't have anything similar to
CCSRBAR ;).
[snip]
> +
> +struct platform_device soc_platform_devices[] = {
> + [MPC85xx_TSEC1] = {
> + .name = "fsl-gianfar",
> + .id = 1,
> + .dev.platform_data = &mpc85xx_tsec1_pdata,
> + .num_resources = 4,
> + .resource = (struct resource[]) {
> + {
> + .start = MPC85xx_ENET1_OFFSET,
> + .end = MPC85xx_ENET1_OFFSET +
> + MPC85xx_ENET1_SIZE - 1,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "tx",
> + .start = MPC85xx_IRQ_TSEC1_TX,
> + .end = MPC85xx_IRQ_TSEC1_TX,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .name = "rx",
> + .start = MPC85xx_IRQ_TSEC1_RX,
> + .end = MPC85xx_IRQ_TSEC1_RX,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .name = "error",
> + .start = MPC85xx_IRQ_TSEC1_ERROR,
> + .end = MPC85xx_IRQ_TSEC1_ERROR,
> + .flags = IORESOURCE_IRQ,
> + },
[snip]
I already wrote about this but repeat again :(.
Why put all these defines (e.g. for memory regions) into header when
the only user is this particular file. It doesn't help readability and
only obfuscates sources (and 4xx is a very good example of such mess
:)
--
Eugene
^ permalink raw reply
* Re: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Joakim Tjernlund @ 2005-01-12 7:53 UTC (permalink / raw)
To: Tom Rini, Linuxppc-Embedded@Ozlabs. Org
> As the code stands currently, there is a bug in the 2.4 and 2.6 handling
> of I-TLB Miss and Error exceptions on 8xx. The problem is that since we
> treat both of them as the same exception when we hit do_page_fault,
> there is a case where we can incorrectly find that a protection fault
> has occured, when it hasn't. This is because we check bit 4 of SRR1 in
> both cases, but in the case of an I-TLB Miss, this bit is always set,
> and it only indicates a protection fault on an I-TLB Error.
Patch looks good to me, but I want to ask when this error
can be triggered in practice?
I have never seen it happen and it makes me wonder if the test
for a null pte in the I-TLB Miss handler is needed?
In linuxppc-2.4 there is a special case for pinned tlbs were
one could remove 4 instructions if the test for null ptes is removed.
I belive SPRG2 is free in 2.6 and if combined with the special case for pinned
tlbs in linuxppc-2.4 one can remove all memory references used for temporary
storage in the I-TLB Miss handler. That will save a cache line load&store.
Jocke
^ permalink raw reply
* RFC: [PATCH] platform device driver model support
From: Kumar Gala @ 2005-01-12 7:43 UTC (permalink / raw)
To: trini, linuxppc-embedded, mporter, jason.mcmullan, ebs
All,
Please take a look at the following patch. It adds driver model support
via platform devices to 85xx. This is originally based on patches from
Jason M.
The idea behind the code is that for a give family: 4xx, 8xx, 82xx, 83xx,
85xx, 86xx we will have structure defns for the following:
enum ppc_soc_devices
in asm-ppc/<family.h>:
list of all unique devices in the family
struct platform_device soc_platform_devices[]
in arch/ppc/platforms/<family>/<family>_devices.c:
describes all platform devices that exist in the family
struct soc_spec soc_specs[]
in arch/ppc/platforms/<family>/<family>_soc.c:
describes each unique chip in the family and what devices it has
Plus the following functions:
identify_soc_by_id() -- determine soc by an int id
identify_soc_by_name() -- determin soc by name (useful in some 82xx cases)
ppc_soc_get_pdata() -- get platform_data pointer so board code can modify
ppc_soc_update_paddr() -- update iomem resources with a given paddr
Please provide feedback, I want to get this into 2.6.11 for 85xx.
thanks
- kumar
--
diff -Nru a/arch/ppc/platforms/85xx/Makefile b/arch/ppc/platforms/85xx/Makefile
--- a/arch/ppc/platforms/85xx/Makefile 2005-01-12 01:31:07 -06:00
+++ b/arch/ppc/platforms/85xx/Makefile 2005-01-12 01:31:07 -06:00
@@ -1,6 +1,7 @@
#
# Makefile for the PowerPC 85xx linux kernel.
#
+obj-$(CONFIG_85xx) += mpc85xx_soc.o mpc85xx_devices.o
obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads_common.o mpc8540_ads.o
obj-$(CONFIG_MPC8555_CDS) += mpc85xx_cds_common.o
diff -Nru a/arch/ppc/platforms/85xx/mpc8540_ads.c b/arch/ppc/platforms/85xx/mpc8540_ads.c
--- a/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-01-12 01:31:07 -06:00
+++ b/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-01-12 01:31:07 -06:00
@@ -32,6 +32,7 @@
#include <linux/serial_core.h>
#include <linux/initrd.h>
#include <linux/module.h>
+#include <linux/fsl_devices.h>
#include <asm/system.h>
#include <asm/pgtable.h>
@@ -49,45 +50,12 @@
#include <asm/immap_85xx.h>
#include <asm/kgdb.h>
#include <asm/ocp.h>
+#include <asm/soctable.h>
#include <mm/mmu_decl.h>
#include <syslib/ppc85xx_common.h>
#include <syslib/ppc85xx_setup.h>
-struct ocp_gfar_data mpc85xx_tsec1_def = {
- .interruptTransmit = MPC85xx_IRQ_TSEC1_TX,
- .interruptError = MPC85xx_IRQ_TSEC1_ERROR,
- .interruptReceive = MPC85xx_IRQ_TSEC1_RX,
- .interruptPHY = MPC85xx_IRQ_EXT5,
- .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR
- | GFAR_HAS_RMON
- | GFAR_HAS_PHY_INTR | GFAR_HAS_COALESCE),
- .phyid = 0,
- .phyregidx = 0,
-};
-
-struct ocp_gfar_data mpc85xx_tsec2_def = {
- .interruptTransmit = MPC85xx_IRQ_TSEC2_TX,
- .interruptError = MPC85xx_IRQ_TSEC2_ERROR,
- .interruptReceive = MPC85xx_IRQ_TSEC2_RX,
- .interruptPHY = MPC85xx_IRQ_EXT5,
- .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR
- | GFAR_HAS_RMON
- | GFAR_HAS_PHY_INTR | GFAR_HAS_COALESCE),
- .phyid = 1,
- .phyregidx = 0,
-};
-
-struct ocp_gfar_data mpc85xx_fec_def = {
- .interruptTransmit = MPC85xx_IRQ_FEC,
- .interruptError = MPC85xx_IRQ_FEC,
- .interruptReceive = MPC85xx_IRQ_FEC,
- .interruptPHY = MPC85xx_IRQ_EXT5,
- .flags = 0,
- .phyid = 3,
- .phyregidx = 0,
-};
-
struct ocp_fs_i2c_data mpc85xx_i2c1_def = {
.flags = FS_I2C_SEPARATE_DFSRR,
};
@@ -100,10 +68,11 @@
static void __init
mpc8540ads_setup_arch(void)
{
- struct ocp_def *def;
- struct ocp_gfar_data *einfo;
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
+ struct gianfar_platform_data *pdata;
+
+ identify_soc_by_id(mfspr(SVR));
/* get the core frequency */
freq = binfo->bi_intfreq;
@@ -130,23 +99,30 @@
invalidate_tlbcam_entry(NUM_TLBCAMS - 1);
#endif
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 0);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enetaddr, 6);
- }
-
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 1);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enet1addr, 6);
- }
-
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 2);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enet2addr, 6);
- }
+ /* setup the board related information for the enet controllers */
+ pdata = (struct gianfar_platform_data *) ppc_soc_get_pdata(MPC85xx_TSEC1);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+ pdata->phyid = 0;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
+
+ pdata = (struct gianfar_platform_data *) ppc_soc_get_pdata(MPC85xx_TSEC2);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+ pdata->phyid = 1;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
+
+ pdata = (struct gianfar_platform_data *) ppc_soc_get_pdata(MPC85xx_FEC);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+ pdata->phyid = 3;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enet2addr, 6);
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start)
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_devices.c b/arch/ppc/platforms/85xx/mpc85xx_devices.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/platforms/85xx/mpc85xx_devices.c 2005-01-12 01:31:07 -06:00
@@ -0,0 +1,245 @@
+/*
+ * arch/ppc/platforms/85xx/mpc85xx_devices.c
+ *
+ * MPC85xx 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/fsl_devices.h>
+#include <asm/mpc85xx.h>
+#include <asm/soctable.h>
+
+/* We use offsets for IORESOURCE_MEM since we do not know at compile time
+ * what CCSRBAR is, platform code should fix this up in setup_arch
+ */
+
+static struct gianfar_platform_data mpc85xx_tsec1_pdata = {
+ .device_flags = FSL_GIANFAR_DEV_HAS_GIGABIT |
+ FSL_GIANFAR_DEV_HAS_COALESCE | FSL_GIANFAR_DEV_HAS_RMON |
+ FSL_GIANFAR_DEV_HAS_MULTI_INTR,
+ .phy_reg_addr = MPC85xx_ENET1_OFFSET,
+};
+
+static struct gianfar_platform_data mpc85xx_tsec2_pdata = {
+ .device_flags = FSL_GIANFAR_DEV_HAS_GIGABIT |
+ FSL_GIANFAR_DEV_HAS_COALESCE | FSL_GIANFAR_DEV_HAS_RMON |
+ FSL_GIANFAR_DEV_HAS_MULTI_INTR,
+ .phy_reg_addr = MPC85xx_ENET1_OFFSET,
+};
+
+static struct gianfar_platform_data mpc85xx_fec_pdata = {
+ .phy_reg_addr = MPC85xx_ENET1_OFFSET,
+};
+
+static struct fsl_i2c_platform_data mpc85xx_fsl_i2c_pdata = {
+ .device_flags = FSL_I2C_DEV_SEPARATE_DFSRR,
+};
+
+struct platform_device soc_platform_devices[] = {
+ [MPC85xx_TSEC1] = {
+ .name = "fsl-gianfar",
+ .id = 1,
+ .dev.platform_data = &mpc85xx_tsec1_pdata,
+ .num_resources = 4,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_ENET1_OFFSET,
+ .end = MPC85xx_ENET1_OFFSET +
+ MPC85xx_ENET1_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "tx",
+ .start = MPC85xx_IRQ_TSEC1_TX,
+ .end = MPC85xx_IRQ_TSEC1_TX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "rx",
+ .start = MPC85xx_IRQ_TSEC1_RX,
+ .end = MPC85xx_IRQ_TSEC1_RX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "error",
+ .start = MPC85xx_IRQ_TSEC1_ERROR,
+ .end = MPC85xx_IRQ_TSEC1_ERROR,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_TSEC2] = {
+ .name = "fsl-gianfar",
+ .id = 2,
+ .dev.platform_data = &mpc85xx_tsec2_pdata,
+ .num_resources = 4,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_ENET2_OFFSET,
+ .end = MPC85xx_ENET2_OFFSET +
+ MPC85xx_ENET2_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "tx",
+ .start = MPC85xx_IRQ_TSEC2_TX,
+ .end = MPC85xx_IRQ_TSEC2_TX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "rx",
+ .start = MPC85xx_IRQ_TSEC2_RX,
+ .end = MPC85xx_IRQ_TSEC2_RX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "error",
+ .start = MPC85xx_IRQ_TSEC2_ERROR,
+ .end = MPC85xx_IRQ_TSEC2_ERROR,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_FEC] = {
+ .name = "fsl-gianfar",
+ .id = 3,
+ .dev.platform_data = &mpc85xx_fec_pdata,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_ENET3_OFFSET,
+ .end = MPC85xx_ENET3_OFFSET +
+ MPC85xx_ENET3_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+
+ },
+ {
+ .start = MPC85xx_IRQ_FEC,
+ .end = MPC85xx_IRQ_FEC,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_IIC1] = {
+ .name = "fsl-i2c",
+ .id = 1,
+ .dev.platform_data = &mpc85xx_fsl_i2c_pdata,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_IIC1_OFFSET,
+ .end = MPC85xx_IIC1_OFFSET +
+ MPC85xx_IIC1_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_IIC1,
+ .end = MPC85xx_IRQ_IIC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA0] = {
+ .name = "fsl-dma",
+ .id = 0,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA0_OFFSET,
+ .end = MPC85xx_DMA0_OFFSET +
+ MPC85xx_DMA0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_DMA0,
+ .end = MPC85xx_IRQ_DMA0,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA1] = {
+ .name = "fsl-dma",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA1_OFFSET,
+ .end = MPC85xx_DMA1_OFFSET +
+ MPC85xx_DMA1_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_DMA1,
+ .end = MPC85xx_IRQ_DMA1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA2] = {
+ .name = "fsl-dma",
+ .id = 2,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA2_OFFSET,
+ .end = MPC85xx_DMA2_OFFSET +
+ MPC85xx_DMA2_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_DMA2,
+ .end = MPC85xx_IRQ_DMA2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA3] = {
+ .name = "fsl-dma",
+ .id = 3,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA3_OFFSET,
+ .end = MPC85xx_DMA3_OFFSET +
+ MPC85xx_DMA3_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_DMA3,
+ .end = MPC85xx_IRQ_DMA3,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+};
+
+static int __init mach_mpc85xx_init(void)
+{
+ unsigned int i, dev_id, ret = 0;
+
+ BUG_ON(cur_soc_spec == NULL);
+
+ for (i = 0; i < cur_soc_spec->num_devices; i++) {
+ dev_id = cur_soc_spec->device_list[i];
+ ppc_soc_update_paddr(&soc_platform_devices[dev_id], CCSRBAR);
+ if (platform_device_register(&soc_platform_devices[dev_id])) {
+ ret = 1;
+ printk (KERN_ERR "unable to register device %d\n", dev_id);
+ }
+ };
+
+ return ret;
+}
+
+subsys_initcall(mach_mpc85xx_init);
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_soc.c b/arch/ppc/platforms/85xx/mpc85xx_soc.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/platforms/85xx/mpc85xx_soc.c 2005-01-12 01:31:07 -06:00
@@ -0,0 +1,50 @@
+/*
+ * arch/ppc/platforms/85xx/mpc85xx_soc.c
+ *
+ * MPC85xx SOC 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/soctable.h>
+
+struct soc_spec* cur_soc_spec;
+struct soc_spec soc_specs[] = {
+ {
+ .soc_name = "MPC8540",
+ .soc_mask = 0xFFFF0000,
+ .soc_value = 0x80300000,
+ .num_devices = 8,
+ .device_list = (enum ppc_soc_devices[])
+ {
+ MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_FEC, MPC85xx_IIC1,
+ MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
+ },
+ },
+ {
+ .soc_name = "MPC8560",
+ .soc_mask = 0xFFFF0000,
+ .soc_value = 0x80700000,
+ .num_devices = 7,
+ .device_list = (enum ppc_soc_devices[])
+ {
+ MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
+ MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
+ },
+ },
+ { /* default match */
+ .soc_name = "",
+ .soc_mask = 0x00000000,
+ .soc_value = 0x00000000,
+ },
+};
diff -Nru a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile 2005-01-12 01:31:07 -06:00
+++ b/arch/ppc/syslib/Makefile 2005-01-12 01:31:07 -06:00
@@ -92,7 +92,8 @@
obj-$(CONFIG_MPC10X_OPENPIC) += open_pic.o
obj-$(CONFIG_40x) += dcr.o
obj-$(CONFIG_BOOKE) += dcr.o
-obj-$(CONFIG_85xx) += open_pic.o ppc85xx_common.o ppc85xx_setup.o
+obj-$(CONFIG_85xx) += open_pic.o ppc85xx_common.o ppc85xx_setup.o \
+ soc.o
ifeq ($(CONFIG_85xx),y)
obj-$(CONFIG_PCI) += indirect_pci.o pci_auto.o
endif
diff -Nru a/arch/ppc/syslib/soc.c b/arch/ppc/syslib/soc.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/syslib/soc.c 2005-01-12 01:31:07 -06:00
@@ -0,0 +1,59 @@
+/*
+ * arch/ppc/syslib/soc.c
+ *
+ * System-on-chip (SOC) library functions
+ *
+ * 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 <asm/soctable.h>
+
+void __init
+identify_soc_by_id(unsigned int id)
+{
+ unsigned int i = 0;
+ while (1) {
+ if ((soc_specs[i].soc_mask & id) == soc_specs[i].soc_value)
+ break;
+ i++;
+ };
+
+ cur_soc_spec = &soc_specs[i];
+
+ return;
+}
+
+void __init
+identify_soc_by_name(char *name)
+{
+ /* TODO */
+ return;
+}
+
+/* Update all memory resources by paddr, call before platform_device_register */
+void __init
+ppc_soc_update_paddr(struct platform_device *pdev, phys_addr_t paddr)
+{
+ int i;
+ for (i = 0; i < pdev->num_resources; i++) {
+ struct resource *r = &pdev->resource[i];
+ if ((r->flags & IORESOURCE_MEM) == IORESOURCE_MEM) {
+ r->start += paddr;
+ r->end += paddr;
+ };
+ };
+}
+
+/* Get platform_data pointer out of platform device, call before platform_device_register */
+void * __init
+ppc_soc_get_pdata(enum ppc_soc_devices dev)
+{
+ return soc_platform_devices[dev].dev.platform_data;
+}
diff -Nru a/include/asm-ppc/mpc85xx.h b/include/asm-ppc/mpc85xx.h
--- a/include/asm-ppc/mpc85xx.h 2005-01-12 01:31:07 -06:00
+++ b/include/asm-ppc/mpc85xx.h 2005-01-12 01:31:07 -06:00
@@ -103,6 +103,14 @@
#define MPC85xx_CPM_SIZE (0x40000)
#define MPC85xx_DMA_OFFSET (0x21000)
#define MPC85xx_DMA_SIZE (0x01000)
+#define MPC85xx_DMA0_OFFSET (0x21100)
+#define MPC85xx_DMA0_SIZE (0x00080)
+#define MPC85xx_DMA1_OFFSET (0x21180)
+#define MPC85xx_DMA1_SIZE (0x00080)
+#define MPC85xx_DMA2_OFFSET (0x21200)
+#define MPC85xx_DMA2_SIZE (0x00080)
+#define MPC85xx_DMA3_OFFSET (0x21280)
+#define MPC85xx_DMA3_SIZE (0x00080)
#define MPC85xx_ENET1_OFFSET (0x24000)
#define MPC85xx_ENET1_SIZE (0x01000)
#define MPC85xx_ENET2_OFFSET (0x25000)
@@ -138,6 +146,17 @@
#else
#define CCSRBAR BOARD_CCSRBAR
#endif
+
+enum ppc_soc_devices {
+ MPC85xx_TSEC1,
+ MPC85xx_TSEC2,
+ MPC85xx_FEC,
+ MPC85xx_IIC1,
+ MPC85xx_DMA0,
+ MPC85xx_DMA1,
+ MPC85xx_DMA2,
+ MPC85xx_DMA3,
+};
#endif /* CONFIG_85xx */
#endif /* __ASM_MPC85xx_H__ */
diff -Nru a/include/asm-ppc/soctable.h b/include/asm-ppc/soctable.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/include/asm-ppc/soctable.h 2005-01-12 01:31:07 -06:00
@@ -0,0 +1,56 @@
+/*
+ * include/asm-ppc/soctable.h
+ *
+ * SOC definitions and library functions
+ *
+ * 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.
+ */
+
+#ifdef __KERNEL__
+#ifndef __ASM_PPC_SOCTABLE_H
+#define __ASM_PPC_SOCTABLE_H
+
+#include <linux/init.h>
+#include <linux/device.h>
+#if defined(CONFIG_85xx)
+#include <asm/mpc85xx.h>
+#else
+#error "need definition of ppc_soc_devices"
+#endif
+
+struct soc_spec {
+ /* SOC is matched via (ID & soc_mask) == soc_value, id could be
+ * PVR, SVR, IMMR, * etc. */
+ unsigned int soc_mask;
+ unsigned int soc_value;
+ unsigned int num_devices;
+ char *soc_name;
+ enum ppc_soc_devices *device_list;
+};
+
+/* describes all specific chips and which devices they have on them */
+extern struct soc_spec soc_specs[];
+extern struct soc_spec *cur_soc_spec;
+
+/* determine which specific SOC we are */
+extern void identify_soc_by_id(unsigned int id) __init;
+extern void identify_soc_by_name(char *name) __init;
+
+/* describes all devices that may exist in a given family of processors */
+extern struct platform_device soc_platform_devices[];
+
+/* Update all memory resources by paddr, call before platform_device_register */
+extern void ppc_soc_update_paddr(struct platform_device *pdev, phys_addr_t paddr) __init;
+
+/* Get platform_data pointer out of platform device, call before platform_device_register */
+extern void * ppc_soc_get_pdata(enum ppc_soc_devices dev) __init;
+
+#endif /* __ASM_PPC_SOCTABLE_H */
+#endif /* __KERNEL__ */
diff -Nru a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/include/linux/fsl_devices.h 2005-01-12 01:31:07 -06:00
@@ -0,0 +1,77 @@
+/*
+ * include/linux/fsl_devices.h
+ *
+ * Definitions for any platform device related flags or structures for
+ * Freescale processor devices
+ *
+ * Maintainer: Kumar Gala (kumar.gala@freescale.com)
+ *
+ * Copyright 2004 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.
+ */
+
+#ifdef __KERNEL__
+#ifndef _FSL_DEVICE_H_
+#define _FSL_DEVICE_H_
+
+/*
+ * Some conventions on how we handle peripherals on Freescale chips
+ *
+ * unique device: a platform_device entry in fsl_plat_devs[] plus
+ * associated device information in its platform_data structure.
+ *
+ * A chip is described by a set of unique devices.
+ *
+ * Each sub-arch has its own master list of unique devices and
+ * enumerates them by enum fsl_devices in a sub-arch specific header
+ *
+ * The platform data structure is broken into two parts. The
+ * first is device specific information that help identify any
+ * unique features of a peripheral. The second is any
+ * information that may be defined by the board or how the device
+ * is connected externally of the chip.
+ *
+ * naming conventions:
+ * - platform data structures: <driver>_platform_data
+ * - platform data device flags: FSL_<driver>_DEV_<FLAG>
+ * - platform data board flags: FSL_<driver>_BRD_<FLAG>
+ *
+ *
+ */
+
+struct gianfar_platform_data {
+ /* device specific information */
+ u32 device_flags;
+ u32 phy_reg_addr;
+
+ /* board specific information */
+ u32 board_flags;
+ u32 phyid;
+ u32 interruptPHY;
+ u8 mac_addr[6];
+};
+
+/* Flags related to gianfar device features */
+#define FSL_GIANFAR_DEV_HAS_GIGABIT 0x00000001
+#define FSL_GIANFAR_DEV_HAS_COALESCE 0x00000002
+#define FSL_GIANFAR_DEV_HAS_RMON 0x00000004
+#define FSL_GIANFAR_DEV_HAS_MULTI_INTR 0x00000008
+
+/* Flags in gianfar_platform_data */
+#define FSL_GIANFAR_BRD_HAS_PHY_INTR 0x00000001 /* if not set use a timer */
+
+struct fsl_i2c_platform_data {
+ /* device specific information */
+ u32 device_flags;
+};
+
+/* Flags related to I2C device features */
+#define FSL_I2C_DEV_SEPARATE_DFSRR 0x00000001
+#define FSL_I2C_DEV_CLOCK_5200 0x00000002
+
+#endif /* _FSL_DEVICE_H_ */
+#endif /* __KERNEL__ */
^ permalink raw reply
* Content violation
From: mailadmin2 @ 2005-01-12 5:31 UTC (permalink / raw)
To: linuxppc-embedded
Content violation found in email message.
From: linuxppc-embedded@ozlabs.org
To: ajith.pai@lntinfotech.com
File(s): message.scr
Matching filename: *.scr
^ permalink raw reply
* Help with PPC440GX + MontaVista + uBoot
From: Howard, Marc @ 2005-01-12 2:44 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm trying to boot Linux on the IBM (now AMCC) 440GX eval board. Using
the latest MontaVista 3.1 toolset + 440GX eval board package (Linux
kernel =3D 2.4.20) I can create a ramdisk-only Linux glob and boot it
successfully using the IBM supplied PIBS bios.
PIBS isn't what we want to use long term, we'd rather use uBoot. I've
downloaded and built the latest version of uBoot (1.1.2). I then
created a multi-file image with mkimage. I can download it via TFTP but
when I start to run it strange/bad things happen:
Kernel command line: ip=3Don console=3DttyS0,115200 root=3D/dev/ram rw
Warning: real time clock seems stuck!
Calibrating delay loop... 37.27 BogoMIPS
...now the RTC is know to work and the mips calculation is seriously
off. Then...
IBM ZMII: EMAC 0: SMII mode
OCP Reset timeout #2!
eth0: Got bad Phy Read (repeats)
.....
eth0: No PHY device found.
removing net dev
.....
cramfs: wrong magic
Kernel panic: VFS: Unable to mount root fs on 01:00
<0>Rebooting in 180 seconds..
It actually reboots in about 10 seconds.
I realize that ocotea.c will have to be modified to grab command line
options from NVRAM (uBoot) instead of FLASH (PIBS) but that doesn't seem
to explain why the internal timer is way off and the ethernet PHYs can't
be found.
If anyone on the list has done this I'd appreciate hearing what else
needs to be modified to make this configuration work.
Thanks,
Marc W. Howard
^ permalink raw reply
* Re: [RESEND] [PATCH 0/7] ppc: remove cli()/sti() from arch/ppc/*
From: Tom Rini @ 2005-01-11 22:46 UTC (permalink / raw)
To: James Nelson; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20050108170406.32690.36989.11853@localhost.localdomain>
On Sat, Jan 08, 2005 at 11:03:49AM -0600, James Nelson wrote:
> This series of patches is to remove the last cli()/sti() function calls in
> arch/ppc, and add spinlocks where necessary.
I'll push this to Andrew and hope they move from there, thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Linux hangs after early_init()
From: John W. Linville @ 2005-01-11 21:07 UTC (permalink / raw)
To: Jostein Pettersen; +Cc: u-boot-users, Tormod Tjaberg, linuxppc-embedded
In-Reply-To: <5.1.0.14.2.20050111210842.024ca490@wgmail3.oslo.eur.slb.com>
On Tue, Jan 11, 2005 at 09:29:38PM +0100, Jostein Pettersen wrote:
> I'm trying to get Linux (2.4.19) up and running on a BMW board (from
> Broadcom) with a 8245 processor. I'm using ppcboot 1.2.0.
IMHO, the BMW support from Broadcom is wretchedly bad. At my former
employer, I implemented my own BMW support and ignored the Broadcom
code completely. This helped my disposition immensely.
PPCboot 1.2.0 (or any version called "PPCboot") is pretty old.
Did you get reasonably fresh code from Broadcom (if they have any)?
Or is this the same BMW support that has been in the base for years?
Broadcom released a number of variations on the BMW platform,
including multiple CPCI cards and multiple pizza-box variations.
It is extremely likely that your board doesn't match what is in
the ppcboot/u-boot source in some crucial detail, e.g. clock speed.
Some experimentation may be worthwhile.
I spent a couple of years as "the" Linux (and U-Boot) guy for a
company which used nearly every Broadcom board based on BMW (and
Mousse, fwiw). I may be able to help you. Contact me off list if
you'd like to arrange something.
Thanks,
John
P.S. linuxppc-embedded is not the right list to ask about
PPCboot/U-boot...try u-boot-users@lists.sourceforge.net instead...
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Linux hangs after early_init()
From: Jostein Pettersen @ 2005-01-11 20:29 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Tormod Tjaberg
Hi,
I'm trying to get Linux (2.4.19) up and running on a BMW board (from
Broadcom) with a 8245 processor. I'm using ppcboot 1.2.0.
I've found that early_init() in setup.c does not return. Everything is ok
up until the very end of early_init().
Something very basic must be wrong. I would be happy for some some pointers
as to what this could be!
Cheers,
Jostein Pettersen
^ permalink raw reply
* Re: email message sizes
From: Conn Clark @ 2005-01-11 16:19 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, linuxppc-embedded, linuxppc64-dev
In-Reply-To: <200501102015.57394.hollis@penguinppc.org>
Hollis Blanchard wrote:
> On Monday 10 January 2005 15:22, Hollis Blanchard wrote:
>
>>Hi all, I am one of two people who moderates these mailing lists. On
>>occasion, people send large emails to these lists. I am of the opinion
>>that 1MB emails should not be mass-mailed, but if you all have no
>>problem with that then I will approve them.
>>
>>So are any of you on modems, or operate near the limits of your mail
>>quotas? I'd like to hear comments either way: how large is ok to post
>>to these mailing lists?
>
>
> So far I have received 5 private mails indicating that 100KB is a reasonable
> maximum. If you disagree please speak up...
>
> -Hollis
I say 101K because I think it should be 100k and I know I will want to
send something just over the limit.
-- Conn Clark
*****************************************************************
Give a man a match and you heat him for a moment. Set him on fire
and you'll heat him for life.
*****************************************************************
Conn Clark
Engineering Stooge clark@esteem.com
Electronic Systems Technology Inc. www.esteem.com
Stock Ticker Symbol ELST
^ permalink raw reply
* Re: 8xx_imap patch for the mpc8xx ATM driver
From: Wolfgang Denk @ 2005-01-10 18:49 UTC (permalink / raw)
To: Pedro Aguilar; +Cc: linuxppc-embedded
In-Reply-To: <61163.81.72.55.167.1105376661.squirrel@81.72.55.167>
Dear Pedro,
in message <61163.81.72.55.167.1105376661.squirrel@81.72.55.167> you wrote:
>
> It is a very simple change in the include/asm-ppc/8xx_imap.h file .
Checked in. Thanks a lot.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I am an atheist, thank God!
^ permalink raw reply
* Re: email message sizes
From: Hollis Blanchard @ 2005-01-10 20:15 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev, linuxppc-embedded
In-Reply-To: <78DE72FE-631B-11D9-AD26-000A95A0560C@penguinppc.org>
On Monday 10 January 2005 15:22, Hollis Blanchard wrote:
> Hi all, I am one of two people who moderates these mailing lists. On
> occasion, people send large emails to these lists. I am of the opinion
> that 1MB emails should not be mass-mailed, but if you all have no
> problem with that then I will approve them.
>
> So are any of you on modems, or operate near the limits of your mail
> quotas? I'd like to hear comments either way: how large is ok to post
> to these mailing lists?
So far I have received 5 private mails indicating that 100KB is a reasonable
maximum. If you disagree please speak up...
-Hollis
^ permalink raw reply
* Re: Classic PPC specific ASM (CONFIG_6XX)
From: Jerome Glisse @ 2005-01-10 19:31 UTC (permalink / raw)
To: Tom Rini; +Cc: Andrew Morton, linuxppc-dev, Paul Mackerras, linuxppc64-dev
In-Reply-To: <20050110191248.GB3391@smtp.west.cox.net>
On Mon, 10 Jan 2005 12:12:48 -0700, Tom Rini <trini@kernel.crashing.org> wr=
ote:
> On Mon, Jan 10, 2005 at 07:59:50PM +0100, Jerome Glisse wrote:
> > > I have a feeling CONFIG_6xx isn't selected for a good reason. Can yo=
u
> > > try, as a kludge, removing define_bool PPC_PREP from arch/ppc/Kconfig
> > > and seeing if you can build / boot ? Thanks.
> > >
> > > --
> > > Tom Rini
> > > http://gate.crashing.org/~trini/
> > >
> >
> > Seems that this flags is linked to many things :) I tried removing PPC_=
PREP
> > bool but the kernel fail to compile with again new errors :
> >
>=20
> One last thing before we just do what you suggested originally, can you
> hack it so that PPC_PREP is still set, but on 970 we still set
> CONFIG_6xx? Thanks again.
>=20
> --
> Tom Rini
> http://gate.crashing.org/~trini/
>=20
This issue must be strongly linked with the Murphy Law.
Got another compile error when y a add CONFIG_6xx=3Dy
to my kernel config.
LD .tmp_vmlinux1
ld: arch/ppc/kernel/idle_6xx.o: No such file: Aucun fichier ou
r=E9pertoire de ce type
Unfortunetly i've got to move (some trip for my study) and i won't be
able to have access any g5 or PPC970 with linux on it until i came back
friday or saturday. Anyway i may access my mail until then.
Does this disable_6xx_mmu function do something that we should really
have on PPC970 ? I hadn't get enought time to look at this function and
understand it.
By the way, even if i pretty sure this is not related, my kernel is patched
with one of my patch (i posted it on this mailling list) that add support o=
f U3
agp bridge on G5.
This patch only affect few file and if i remember well, i have tested witho=
ut
it too with no success.
Files affected by my patch pciids.h, uninorth.c(char/driver/agp),=20
uninorth.h(asm-ppc&64). and some change in Kconfig of (char/driver/agp)
One strange things is that no one except me report error on compilation ?
No one use linux with g5, am i alone :) ?
best,
Jerome Glisse
^ permalink raw reply
* Re: Classic PPC specific ASM (CONFIG_6XX)
From: Tom Rini @ 2005-01-10 19:12 UTC (permalink / raw)
To: Jerome Glisse; +Cc: Andrew Morton, linuxppc-dev, Paul Mackerras, linuxppc64-dev
In-Reply-To: <4240b91605011010593d2f3b3d@mail.gmail.com>
On Mon, Jan 10, 2005 at 07:59:50PM +0100, Jerome Glisse wrote:
> > I have a feeling CONFIG_6xx isn't selected for a good reason. Can you
> > try, as a kludge, removing define_bool PPC_PREP from arch/ppc/Kconfig
> > and seeing if you can build / boot ? Thanks.
> >
> > --
> > Tom Rini
> > http://gate.crashing.org/~trini/
> >
>
> Seems that this flags is linked to many things :) I tried removing PPC_PREP
> bool but the kernel fail to compile with again new errors :
>
One last thing before we just do what you suggested originally, can you
hack it so that PPC_PREP is still set, but on 970 we still set
CONFIG_6xx? Thanks again.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: ML300 and Linux
From: Peter Ryser @ 2005-01-10 19:10 UTC (permalink / raw)
To: Harnois Anne-Sophie; +Cc: linuxppc-embedded
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D5D23A6@rennsmail02.eu.thmulti.com>
Anne-Sophie,
Linux is fully ported for the ML300 board and the work has been
integrated into the 2.4 linuxppc kernel tree by MontaVista. A few links
that might you get started:
Free MontaVista Linux Preview Kit for ML300:
http://www.mvista.com/previewkit
ML300 home page: http://www.xilinx.com/ml300
Linux site for PowerPC: http://www.penguinppc.org
- Peter
Harnois Anne-Sophie wrote:
>I am working on a new board which is based on a Virtex II Pro. I would like to study the code for the ML300 which is the evaluation board from xilinx but I can't find any port for this board. Could you help me? What version of Linux should I use?
>Thanks a lot.
>Anne-Sophie.
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
^ 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