* Re: [PATCH 4/5 v3] Add RapidIO support to powerpc architecture.
From: Kumar Gala @ 2007-07-27 8:22 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11854393763547-git-send-email-wei.zhang@freescale.com>
On Jul 26, 2007, at 3:42 AM, Zhang Wei wrote:
> This patch adds the RapidIO support to the powerpc architecture.
> Some files are moved from ppc. OF-tree and OF-device supports are
> added.
> New silicons such as MPC8548, MPC8641 with serial RapidIO
> controller are
> all supported.
> Memory driver hardware operations are added.
> Global mport variables are changed to master port private variables.
> Multi master ports are supported.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> ---
> arch/powerpc/Kconfig | 8 +
> arch/powerpc/kernel/Makefile | 1 +
> arch/powerpc/kernel/rio.c | 64 ++
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/fsl_rio.c | 1455 ++++++++++++++++++++++++++++++
> +++++++++++
how much of this moved from ppc85xx_rio.c?
> arch/powerpc/sysdev/fsl_rio.h | 20 +
> 6 files changed, 1549 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/kernel/rio.c
> create mode 100644 arch/powerpc/sysdev/fsl_rio.c
> create mode 100644 arch/powerpc/sysdev/fsl_rio.h
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 00099ef..45f32f1 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -492,6 +492,14 @@ source "drivers/pci/Kconfig"
>
> source "drivers/pcmcia/Kconfig"
>
> +config RAPIDIO
> + bool "RapidIO support" if MPC8540 || MPC8560 || MPC8641 || MPC8548
> + help
> + If you say Y here, the kernel will include drivers and
> + infrastructure code to support RapidIO interconnect devices.
why not make this depend on something like HAS_RAPIDIO and let the
boards select HAS_RAPIDIO if they have it
> +
> +source "drivers/rapidio/Kconfig"
> +
> source "drivers/pci/hotplug/Kconfig"
>
> endmenu
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/
> Makefile
> index 42c42ec..02d4100 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -70,6 +70,7 @@ pci64-$(CONFIG_PPC64) += pci_64.o pci_dn.o isa-
> bridge.o
> pci32-$(CONFIG_PPC32) := pci_32.o
> obj-$(CONFIG_PCI) += $(pci64-y) $(pci32-y) pci-common.o
> obj-$(CONFIG_PCI_MSI) += msi.o
> +obj-$(CONFIG_RAPIDIO) += rio.o
should probably live in sysdev/rio.c
> kexec-$(CONFIG_PPC64) := machine_kexec_64.o
> kexec-$(CONFIG_PPC32) := machine_kexec_32.o
> obj-$(CONFIG_KEXEC) += machine_kexec.o crash.o $(kexec-y)
> diff --git a/arch/powerpc/kernel/rio.c b/arch/powerpc/kernel/rio.c
> new file mode 100644
> index 0000000..8d41e93
> --- /dev/null
> +++ b/arch/powerpc/kernel/rio.c
> @@ -0,0 +1,64 @@
> +/*
> + * RapidIO PowerPC support
> + *
> + * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights
> reserved.
> + * Zhang Wei <wei.zhang@freescale.com>, Jun 2007
> + *
> + * 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.
> + *
> + * New RapidIO peer-to-peer network initialize with of-device
> supoort.
> + *
> + */
> +
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/rio.h>
> +
> +#include <asm/rio.h>
> +#include <asm/of_device.h>
> +#include <asm/of_platform.h>
> +
> +#include <../sysdev/fsl_rio.h>
> +
> +
> +/* The probe function for RapidIO peer-to-peer network.
> + */
> +static int __devinit of_rio_rpn_probe(struct of_device *dev,
> + const struct of_device_id *match)
> +{
> + int rc;
> + printk(KERN_INFO "Setting up RapidIO peer-to-peer network %s\n",
> + dev->node->full_name);
> +
> + rc = fsl_rio_setup(dev);
> + if (rc)
> + goto out;
> +
> + /* Enumerate all registered ports */
> + rc = rio_init_mports();
> +out:
> + return rc;
> +};
> +
> +static struct of_device_id of_rio_rpn_ids[] = {
> + {
> + .compatible = "fsl,rapidio-delta",
> + },
> + {},
> +};
> +
> +static struct of_platform_driver of_rio_rpn_driver = {
> + .name = "of-rio",
> + .match_table = of_rio_rpn_ids,
> + .probe = of_rio_rpn_probe,
> +};
> +
> +static __init int of_rio_rpn_init(void)
> +{
> + return of_register_platform_driver(&of_rio_rpn_driver);
> +}
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Kumar Gala @ 2007-07-27 8:14 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070726135738.GB5643@localhost.localdomain>
On Jul 26, 2007, at 8:57 AM, Anton Vorontsov wrote:
> mmc_spi already tested to work. When it will hit mainline
> the only change that would be needed is replacing "spidev"
> by "mmc_spi", and adding trivial platform data to mmc_spi
> driver.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 33 ++++++++++++++++++
> ++-
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 46 ++++++++++++++++++
> +++++++++++
> 2 files changed, 78 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/
> boot/dts/mpc832x_rdb.dts
> index 7c4beff..5dcbdd3 100644
> --- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> +++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> @@ -183,6 +183,21 @@
> 1 c 1 0 1 0 /* TX_EN */
> 1 d 2 0 1 0>; /* CRS */
> };
> + spi1pio:spi_pin@01 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 3 0 3 0 1 0 /* SPI1 MOSI, I/O */
> + 3 1 3 0 1 0 /* SPI1 MISO, I/O */
> + 3 2 3 0 1 0 /* SPI1 CLK, I/O */
> + 3 3 2 0 1 0>; /* SPI1 SEL, I */
> + };
> + mmc1pio:mmc_pin@01 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 3 d 1 0 0 0 /* !SD_CS */
> + 3 e 2 0 0 0 /* SD_INSERT */
> + 3 f 2 0 0 0>; /* SD_PROTECT */
> + };
> };
> };
>
> @@ -207,20 +222,36 @@
>
> spi@4c0 {
> device_type = "spi";
> + device-id = <1>;
Can we just use the reg value for bus_num in the kernel.
> compatible = "fsl_spi";
> reg = <4c0 40>;
> interrupts = <2>;
> interrupt-parent = <&qeic>;
> - mode = "cpu";
> + mode = "qe";
> + sysclk = <5f5e100>; /* 100000000 Hz */
we don't need this in the spi node, its just the system clock
frequency which we can get other ways.
> + max-chipselect = <1>;
I'm not sure how I feel about this in here, I'm thinking it should go.
> + pio-handle = <&spi1pio>;
> +
> + mmc@01 {
> + device_type = "mmc";
> + compatible = "mmc-spi";
> + device-id = <1>;
> + max-speed-hz = <bebc20>; /* 12500000 Hz */
> + chip-select = <0>;
> + pio-handle = <&mmc1pio>;
> + };
we should do this in board code and not the device tree.
> };
>
> spi@500 {
> device_type = "spi";
> + device-id = <2>;
> compatible = "fsl_spi";
> reg = <500 40>;
> interrupts = <1>;
> interrupt-parent = <&qeic>;
> mode = "cpu";
> + sysclk = <5f5e100>; /* 100000000 Hz */
> + max_chipselect = <1>;
> };
>
> ucc@3000 {
> diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/
> powerpc/platforms/83xx/mpc832x_rdb.c
> index b2b28a4..c5463c7 100644
> --- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> +++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> @@ -15,6 +15,7 @@
> */
>
> #include <linux/pci.h>
> +#include <linux/spi/spi.h>
>
> #include <asm/of_platform.h>
> #include <asm/time.h>
> @@ -24,6 +25,7 @@
> #include <asm/qe_ic.h>
>
> #include "mpc83xx.h"
> +#include "../../sysdev/fsl_soc.h"
>
> #undef DEBUG
> #ifdef DEBUG
> @@ -32,6 +34,43 @@
> #define DBG(fmt...)
> #endif
>
> +extern int par_io_data_set(u8 port, u8 pin, u8 val);
> +
> +static void mpc83xx_spi_activate_cs(u8 cs, u8 polarity)
> +{
> + pr_debug("%s %d %d\n", __func__, cs, polarity);
> + par_io_data_set(3, 13, polarity);
> +}
> +
> +static void mpc83xx_spi_deactivate_cs(u8 cs, u8 polarity)
> +{
> + pr_debug("%s %d %d\n", __func__, cs, polarity);
> + par_io_data_set(3, 13, !polarity);
> +}
> +
> +static int __init mpc83xx_spi_devices_init(void)
> +{
> + struct spi_board_info spi_bi = {
> + .bus_num = 1,
> + /*
> + * XXX: This is spidev (spi in userspace) stub, should
> + * be replaced by "mmc_spi" when mmc_spi will hit mainline.
> + */
> + .modalias = "spidev",
> + };
> + struct device_node *np = NULL;
> +
> + np = of_find_compatible_node(np, "mmc", "mmc-spi");
> + if (!np)
> + return 0;
> +
> + spi_bi.max_speed_hz = *((u32 *)of_get_property(np, "max-speed-
> hz", NULL));
> + spi_bi.chip_select = *((u32 *)of_get_property(np, "chip-select",
> NULL));
> +
> + return spi_register_board_info(&spi_bi, 1);
> +}
> +device_initcall(mpc83xx_spi_devices_init);
> +
> /*
> **********************************************************************
> **
> *
> * Setup the architecture
> @@ -62,8 +101,15 @@ static void __init mpc832x_rdb_setup_arch(void)
>
> for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
> par_io_of_config(np);
> + for (np = NULL; (np = of_find_node_by_name(np, "spi")) != NULL;)
> + par_io_of_config(np);
> + for (np = NULL; (np = of_find_node_by_name(np, "mmc")) != NULL;)
> + par_io_of_config(np);
> }
> #endif /* CONFIG_QUICC_ENGINE */
> +
> + fsl_spi_activate_cs = mpc83xx_spi_activate_cs;
> + fsl_spi_deactivate_cs = mpc83xx_spi_deactivate_cs;
> }
>
> static struct of_device_id mpc832x_ids[] = {
> --
> 1.5.0.6
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 4/5 v3] Add RapidIO support to powerpc architecture.
From: Stephen Rothwell @ 2007-07-27 8:12 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11854393763547-git-send-email-wei.zhang@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
On Thu, 26 Jul 2007 16:42:51 +0800 Zhang Wei <wei.zhang@freescale.com> wrote:
>
> +
> +#include <../sysdev/fsl_rio.h>
This can just be <sysdev/fsl_rio.h> if it is only built on 32bit.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5 v3] Add the platform device support with RapidIO to MPC8641HPCN platform.
From: Stephen Rothwell @ 2007-07-27 7:54 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11854393753986-git-send-email-wei.zhang@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 324 bytes --]
On Thu, 26 Jul 2007 16:42:50 +0800 Zhang Wei <wei.zhang@freescale.com> wrote:
>
> +#include <asm/of_device.h>
> +#include <asm/of_platform.h>
These should now be <linux/of_device.h> and <linux/of_platform.h>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, registermmc_spi stub
From: Kumar Gala @ 2007-07-27 7:55 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <02bd01c7cfbc$cf213610$02ac10ac@Jocke>
On Jul 26, 2007, at 2:40 PM, Joakim Tjernlund wrote:
>
>
>> -----Original Message-----
>> From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]
>> Sent: den 26 juli 2007 17:48
>> To: Joakim Tjernlund
>> Cc: linuxppc-dev@ozlabs.org
>> Subject: Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi,
>> registermmc_spi stub
>>
>> On Thu, Jul 26, 2007 at 05:36:06PM +0200, Joakim Tjernlund wrote:
>> [...]
>>>> spi@4c0 {
>>>> device_type = "spi";
>>>> + device-id = <1>;
>>>> compatible = "fsl_spi";
>>>> reg = <4c0 40>;
>>>> interrupts = <2>;
>>>> interrupt-parent = <&qeic>;
>>>> - mode = "cpu";
>>>> + mode = "qe";
>>>
>>> The driver is still using "cpu" mode. It just happens that
>> the cpu mode for QE
>>> enabled CPUs isn't 100% compatible with the defacto cpu
>> mode used by other CPU:s.
>>
>> Yup, indeed.
>>
>>> So mode should probably be "cpu_qe" or, even better, if the
>> drver could
>>
>> That's easy to change, thanks.
>>
>>> autodetect that it is running on a QE enabled CPU and
>> adjust accordinly.
>>> Maybe the Freescale guys have some ideas how to do that.
>>
>> Ok. Well, for now could we use machine_is() for kind of autodetect?
>> Or it's better leave it as is, and just rename mode to cpu_qe?
>
> Unless the DTS guys thinks otherwise, just rename to "cpu_qe".
> "qe" would then be reserved for true QE mode.
Agreed, we need to update booting-without-of.txt.
- k
^ permalink raw reply
* Re: [RFC][PATCH] fsl_soc: add support for fsl_spi
From: Kumar Gala @ 2007-07-27 7:52 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070726210507.18829b9a@vitb.ru.mvista.com>
On Jul 26, 2007, at 12:05 PM, Vitaly Bordug wrote:
> On Thu, 26 Jul 2007 11:45:08 -0500
> Scott Wood <scottwood@freescale.com> wrote:
>
>> On Thu, Jul 26, 2007 at 05:56:55PM +0400, Anton Vorontsov wrote:
>>> +void (*fsl_spi_activate_cs)(u8 cs, u8 polarity) = NULL;
>>> +EXPORT_SYMBOL(fsl_spi_activate_cs);
>>> +void (*fsl_spi_deactivate_cs)(u8 cs, u8 polarity) = NULL;
>>> +EXPORT_SYMBOL(fsl_spi_deactivate_cs);
>>
>> What are these for? It looks like you're using them to set pins,
>> but that should be done in the firmware (and if the firmware
>> sucks, then
>> do it in the platform code at bootup).
>>
> That is not exactly the point.
> I won't respond for Anton, but we already had such hooks justified
> in SPI case iirc.
No they are used for runtime chip select handling. The SPI
controller is able to handle multiple devices, however the chipselect
is not specified by SPI and thus it left to board code.
>>> +static int __init fsl_spi_of_init(void)
>>> +{
>>> + struct device_node *np;
>>> + unsigned int i;
>>> +
>>> + for (np = NULL, i = 1;
>>> + (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
>>> + i++) {
>>
>> s/fsl_spi/fsl,mpc8323-spi/, please.
>>
>> Why not make the fsl spi driver an of_platform device?
>>
> Because this particular thing is not ppc-only from what I recall.
The device node name already existed before this patch.
- k
^ permalink raw reply
* Re: creation of jffs2 rootfile system..
From: Florian A. Voegel @ 2007-07-27 8:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11823840.post@talk.nabble.com>
Hi Nethra,
what does your inittab and your startup files look like? It looks like
- your inittab does not start a getty but rather a shell, thus no login
- your /proc isn't mounted, and it's needed for ps to work properly
Greets,
Florian Voegel
Carangul.Tech
On Thu, 26 Jul 2007 23:41:32 -0700 (PDT)
Nethra <nethra_gmit@yahoo.co.in> wrote:
>
> when boot the board with jffs2 rootfile system i m getting output like this,
>
> TCP: Hash tables configured (established 4096 bind 8192)
> IPv4 over IPv4 tunneling driver
> NET: Registered protocol family 1
> NET: Registered protocol family 10
> IPv6 over IPv4 tunneling driver
> NET: Registered protocol family 17
> Disabled Privacy Extensions on device c02527a0(lo)
> IP-Config: Incomplete network configuration information.
> Empty flash at 0x0000ffa0 ends at 0x00010000
> Empty flash at 0x0002ffec ends at 0x00030000
> Empty flash at 0x0004ffe8 ends at 0x00050000
> Empty flash at 0x0006ffc8 ends at 0x00070000
> Empty flash at 0x0008fffc ends at 0x00090000
> Empty flash at 0x000afffc ends at 0x000b0000
> Empty flash at 0x000cfffc ends at 0x000d0000
> Empty flash at 0x000efffc ends at 0x000f0000
> Empty flash at 0x0010fffc ends at 0x00110000
> Empty flash at 0x0012fffc ends at 0x00130000
> Empty flash at 0x0014fffc ends at 0x00150000
> Empty flash at 0x0016fffc ends at 0x00170000
> Empty flash at 0x0018fffc ends at 0x00190000
> Empty flash at 0x001cfffc ends at 0x001d0000
> Empty flash at 0x001efffc ends at 0x001f0000
> Empty flash at 0x0020fffc ends at 0x00210000
> Empty flash at 0x0022fffc ends at 0x00230000
> Empty flash at 0x0024fffc ends at 0x00250000
> Empty flash at 0x0026fffc ends at 0x00270000
> Empty flash at 0x002afffc ends at 0x002b0000
> Empty flash at 0x002cfffc ends at 0x002d0000
> VFS: Mounted root (jffs2 filesystem).
> Freeing unused kernel memory: 108k init
>
> Please press Enter to activate this console.
> / #
> / #
> / #
>
> login prompt itself is not coming and
>
> ps command is not working....
> # ps
> PID Uid VmSize Stat Command
> #
>
> what is the problem..?
>
> waiting for early response,
> Nethra
>
> --
> View this message in context: http://www.nabble.com/creation-of-jffs2-rootfile-system..-tf4155759.html#a11823840
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Decermenter overflow interrupt atfer the init.d launch.
From: Benjamin Herrenschmidt @ 2007-07-27 7:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <D4037DB6-8832-4057-A9FF-BAD32592E6C9@kernel.crashing.org>
On Fri, 2007-07-27 at 01:46 -0500, Kumar Gala wrote:
> On Jul 27, 2007, at 1:36 AM, Nicolas Mederle wrote:
>
> > Hi,
> >
> > I want to know how the kernel switch the task. Because my
> > kernel
> > start very well, and it launch the init.d. With the log, i can see
> > that
> > the kernel launch the getty task. But after, there is a decrementer
> > overflow interrupt ( vector at adress 900 ). Is it the task
> > switch? Or
> > is it an error in the decrementer init.
>
> This should be a task switch. The decrementer is used to handle the
> periodic interrupt to switch processes.
I would have expected quite of few of these actually before you get
there :-)
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Benjamin Herrenschmidt @ 2007-07-27 7:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Alan Curry, linux-kernel
In-Reply-To: <20070726212241.032e9755.akpm@linux-foundation.org>
On Thu, 2007-07-26 at 21:22 -0700, Andrew Morton wrote:
>
> > Merged a fixed version:
> >
> > f5d834fc34e61f1a40435981062000e5d2b2baa8
> >
> > (In linus tree as of now)
>
> I hope so. Alan's patch looks rather different from what you have
> now:
> fall back to of_find_node_by_name() if of_find_node_by_type() failed.
Which is just waht that commit does :-)
Ben.
^ permalink raw reply
* Re: ping command
From: Nethra @ 2007-07-27 6:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1185458965.6839.8.camel@saruman.qstreams.net>
root@cashel:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.32.0 0.0.0.0 255.255.248.0 U 0 0 0 eth1
0.0.0.0 192.168.32.47 0.0.0.0 UG 0 0 0 eth1
0.0.0.0 192.168.178.47 0.0.0.0 UG 0 0 0 eth0
root@cashel:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:13:72:FE:A9:02
inet addr:192.168.178.89 Bcast:192.168.178.255
Mask:255.255.255.0
inet6 addr: fe80::213:72ff:fefe:a902/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15665 errors:0 dropped:0 overruns:0 frame:0
TX packets:9285 errors:0 dropped:0 overruns:0 carrier:9019
collisions:0 txqueuelen:1000
RX bytes:12957285 (12.3 MiB) TX bytes:2720267 (2.5 MiB)
Base address:0x8400
eth1 Link encap:Ethernet HWaddr 00:13:72:7E:A9:02
inet addr:192.168.33.135 Bcast:192.168.33.255 Mask:255.255.248.0
inet6 addr: fe80::213:72ff:fe7e:a902/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:634 errors:0 dropped:0 overruns:0 frame:0
TX packets:84 errors:0 dropped:0 overruns:0 carrier:82
collisions:0 txqueuelen:1000
RX bytes:103558 (101.1 KiB) TX bytes:12832 (12.5 KiB)
Base address:0x8500
lo Link encap:Local Loopback
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
root@cashel:~#
On Wed, 2007-07-25 at 02:29 -0700, Nethra wrote:
> hi,
>
> I m using custom board same as eval board MPC8272ADS board.
>
> IP assigned for both ethernets are...
>
> ifconfig eth1 192.168.33.135 up
> ifconfig eth1 netmask 255.255.248.0
> route add default gw 192.168.32.47 eth1
>
>
> ifconfig eth0 192.168.178.89 up
> ifconfig eth0netmask 255.255.255.0
> route add default gw 192.168.178.47 eth0
>
> but if i try for ping 192.168.33.135 command pails by the server of 178
> series
> similarly ping 192.168.178.89 command pails by the server of 33 series..
>
> what is the problem..and whre i m going wrong..?
What does your routing table show? (route -n). It wouldn't hurt to
also post the output of ifconfig for both interfaces.
regards,
Ben
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
View this message in context: http://www.nabble.com/ping-command-tf4141032.html#a11823845
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Decermenter overflow interrupt atfer the init.d launch.
From: Kumar Gala @ 2007-07-27 6:46 UTC (permalink / raw)
To: Nicolas Mederle; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <46A9925A.2060508@yahoo.fr>
On Jul 27, 2007, at 1:36 AM, Nicolas Mederle wrote:
> Hi,
>
> I want to know how the kernel switch the task. Because my
> kernel
> start very well, and it launch the init.d. With the log, i can see
> that
> the kernel launch the getty task. But after, there is a decrementer
> overflow interrupt ( vector at adress 900 ). Is it the task
> switch? Or
> is it an error in the decrementer init.
This should be a task switch. The decrementer is used to handle the
periodic interrupt to switch processes.
- k
^ permalink raw reply
* creation of jffs2 rootfile system..
From: Nethra @ 2007-07-27 6:41 UTC (permalink / raw)
To: linuxppc-embedded
when boot the board with jffs2 rootfile system i m getting output like this,
TCP: Hash tables configured (established 4096 bind 8192)
IPv4 over IPv4 tunneling driver
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
Disabled Privacy Extensions on device c02527a0(lo)
IP-Config: Incomplete network configuration information.
Empty flash at 0x0000ffa0 ends at 0x00010000
Empty flash at 0x0002ffec ends at 0x00030000
Empty flash at 0x0004ffe8 ends at 0x00050000
Empty flash at 0x0006ffc8 ends at 0x00070000
Empty flash at 0x0008fffc ends at 0x00090000
Empty flash at 0x000afffc ends at 0x000b0000
Empty flash at 0x000cfffc ends at 0x000d0000
Empty flash at 0x000efffc ends at 0x000f0000
Empty flash at 0x0010fffc ends at 0x00110000
Empty flash at 0x0012fffc ends at 0x00130000
Empty flash at 0x0014fffc ends at 0x00150000
Empty flash at 0x0016fffc ends at 0x00170000
Empty flash at 0x0018fffc ends at 0x00190000
Empty flash at 0x001cfffc ends at 0x001d0000
Empty flash at 0x001efffc ends at 0x001f0000
Empty flash at 0x0020fffc ends at 0x00210000
Empty flash at 0x0022fffc ends at 0x00230000
Empty flash at 0x0024fffc ends at 0x00250000
Empty flash at 0x0026fffc ends at 0x00270000
Empty flash at 0x002afffc ends at 0x002b0000
Empty flash at 0x002cfffc ends at 0x002d0000
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 108k init
Please press Enter to activate this console.
/ #
/ #
/ #
login prompt itself is not coming and
ps command is not working....
# ps
PID Uid VmSize Stat Command
#
what is the problem..?
waiting for early response,
Nethra
--
View this message in context: http://www.nabble.com/creation-of-jffs2-rootfile-system..-tf4155759.html#a11823840
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Decermenter overflow interrupt atfer the init.d launch.
From: Nicolas Mederle @ 2007-07-27 6:36 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
Hi,
I want to know how the kernel switch the task. Because my kernel
start very well, and it launch the init.d. With the log, i can see that
the kernel launch the getty task. But after, there is a decrementer
overflow interrupt ( vector at adress 900 ). Is it the task switch? Or
is it an error in the decrementer init.
--
Cordialement,
MEDERLE Nicolas.
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 0/4] Few spi_mpc83xx.c fixes and improvements
From: Kumar Gala @ 2007-07-27 6:32 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <200707261958.09127.david-b@pacbell.net>
On Jul 26, 2007, at 9:58 PM, David Brownell wrote:
> On Thursday 26 July 2007, Anton Vorontsov wrote:
>> Hi all,
>>
>> These patches based on Linus' tree, as of today.
>
> I don't know mpc83xx ... are there any PPC folk who can see
> any reason not to just merge these patches? They look OK
> to me, but in this case that doesn't mean much. :)
>
> If I don't hear otherwise, I'll forward all four of these
> patches upstream on Monday.
>
> (Anton, thanks for these updates!)
These all look good to me for upstream.
Acked-off-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 1/4] [POWERPC][SPI] spi_mpc83xx.c: should turn off SPI unit while switching any mode.
From: Kumar Gala @ 2007-07-27 6:32 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <20070726131346.GA3417@localhost.localdomain>
On Jul 26, 2007, at 8:13 AM, Anton Vorontsov wrote:
> Documentation clearly states, that mode should not be changed
> till SPMODE_ENABLE bit set. I've seen hangs w/o this patch.
Out of interest what board/part do you see the hang on?
- k
^ permalink raw reply
* Re: [PATCH] xmon consistency clean up
From: Ishizaki Kou @ 2007-07-27 6:11 UTC (permalink / raw)
To: benh, michael; +Cc: linuxppc-dev, paulus
In-Reply-To: <1185365630.21877.4.camel@concordia.ozlabs.ibm.com>
Michael Ellerman <michael@ellerman.id.au> wrote:
> On Wed, 2007-07-25 at 16:21 +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2007-07-25 at 11:57 +0900, Ishizaki Kou wrote:
> > > This patch cleans up xmon to keep consistency.
> > >
> > > In xmon, we should use console I/O functions that are named the
same
> > > as user space stdio functions. But commit
> > > 4d404edce30f911004850d472e05a31efd751662 broke this consistency.
> > >
> > > Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
> > > ---
> > >
> > > Index: linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
> > >
===================================================================
> > > --- linux-powerpc-git.orig/arch/powerpc/xmon/nonstdio.c
> > > +++ linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
> > > @@ -133,7 +133,7 @@ void xmon_printf(const char *format, ...
> > > xmon_write(xmon_outbuf, n);
> > > }
> > >
> > > -void xmon_puts(const char *str)
> > > +void xmon_fputs(const char *str)
> > > {
> > > xmon_write(str, strlen(str));
> >
> > Nah, keep it xmon_puts, since it doesn't take a stream argument and
> > define a "puts" for use by xmon core.
>
> But then it needs to add a newline .. and we've gone around in a
circle
> again. Funny how the trivialest of patches gets the most review.
In my opinion, our goal is providing stdio functions like fputs to
xmon.c. So, xmon_fputs need not be compatible with fputs because
xmon.c doesn't use it directly.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Alan Curry @ 2007-07-27 4:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-dev
In-Reply-To: <20070726212241.032e9755.akpm@linux-foundation.org>
Andrew Morton writes the following:
>> >
>> > Did this get merged, or otherwise fixed? Even though the code in there has
>> > changed quite a bit, it looks to my untrained eye like the fix is still
>> > applicable?
>>
>> Merged a fixed version:
>>
>> f5d834fc34e61f1a40435981062000e5d2b2baa8
>>
>> (In linus tree as of now)
>
>I hope so. Alan's patch looks rather different from what you have now:
>fall back to of_find_node_by_name() if of_find_node_by_type() failed.
>
Looking at it via gitweb, I think the commit mentioned above is actually the
same as what I submitted. The diff context lines are different because there
was a similar patch in between the 2.6.22 release and my patch, which
apparently fixed the same problem on a different type of machine. It looks
like these 2 workarounds will function independently of each other.
The first 8042-detection fix was:
db0dbae9d9680bce69fe1ce775709e60c8ee9c29
And mine is:
f5d834fc34e61f1a40435981062000e5d2b2baa8
--
Alan Curry
pacman@world.std.com
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Andrew Morton @ 2007-07-27 4:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Alan Curry, linux-kernel
In-Reply-To: <1185505222.5495.182.camel@localhost.localdomain>
On Fri, 27 Jul 2007 13:00:21 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2007-07-26 at 18:48 -0700, Andrew Morton wrote:
> > On Wed, 25 Jul 2007 17:12:45 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > On Tue, 2007-07-24 at 21:28 -0400, Alan Curry wrote:
> > > > As of 2.6.22 the kernel doesn't recognize the i8042 keyboard/mouse controller
> > > > on the PegasosPPC. This is because of a feature/bug in the OF device tree:
> > > > the "device_type" attribute is an empty string instead of "8042" as the
> > > > kernel expects. This patch (against 2.6.22.1) adds a secondary detection
> > > > which looks for a device whose *name* is "8042" if there is no device whose
> > > > *type* is "8042".
> > > >
> > > > Signed-off-by: Alan Curry <pacman@world.std.com>
> > >
> > > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > >
> > > Note, if there's a volunteer, we could probably turn that code into a
> > > nice table lookup.
> >
> > Did this get merged, or otherwise fixed? Even though the code in there has
> > changed quite a bit, it looks to my untrained eye like the fix is still
> > applicable?
>
> Merged a fixed version:
>
> f5d834fc34e61f1a40435981062000e5d2b2baa8
>
> (In linus tree as of now)
I hope so. Alan's patch looks rather different from what you have now:
fall back to of_find_node_by_name() if of_find_node_by_type() failed.
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add support of platforms without PHY to gianfar driver
From: Kumar Gala @ 2007-07-27 4:16 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, linuxppc-dev
In-Reply-To: <46A7BEE2.8020504@garzik.org>
On Jul 25, 2007, at 4:21 PM, Jeff Garzik wrote:
> I'll let paulus and linuxppc merge this one (or not)...
That would most likely be me, than paulus. Since this is for a
Freescale PPC SoC.
- k
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 2/3] [SPI] Add new mode: SPI_LOOP
From: Ned Forrester @ 2007-07-27 3:34 UTC (permalink / raw)
To: David Brownell; +Cc: spi-devel-general, Stephen Street, linuxppc-dev
In-Reply-To: <200707262007.07537.david-b@pacbell.net>
David Brownell wrote:
> On Thursday 26 July 2007, Anton Vorontsov wrote:
>> Loopback mode is supported by various controllers, this mode
>> is useful for testing, especially in conjunction with spidev
>> driver.
>
> ISTR that Stephen Street provided a loopback mode for debug
> in his pxa2xx_spi code. And I know you're fight that this
> mode shows up in a lot of hardware.
>
> Comments, anyone? This seems like a fair way to expose this
> mechanism. And I tend to agree that it'd mostly be useful in
> conjunction with "spidev".
Yes, it is in pxa2xx_spi. It is passed in a structure that is attached
to spi_board_info.controller_data. I have used it to great effect to
test data modes in the driver for which I have no external hardware
support: various bits/word, clock frequencies, fifo thresholds, dma
burst sizes, etc.
It works for me if this is moved to struct spi_device.
I don't think I have any code that could be readily turned into a
generic test program.
--
Ned Forrester nforrester@whoi.edu
Oceanographic Systems Lab 508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 2/3] [SPI] Add new mode: SPI_LOOP
From: David Brownell @ 2007-07-27 3:07 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev, Stephen Street
In-Reply-To: <20070726135051.GB5550@localhost.localdomain>
On Thursday 26 July 2007, Anton Vorontsov wrote:
> Loopback mode is supported by various controllers, this mode
> is useful for testing, especially in conjunction with spidev
> driver.
ISTR that Stephen Street provided a loopback mode for debug
in his pxa2xx_spi code. And I know you're fight that this
mode shows up in a lot of hardware.
Comments, anyone? This seems like a fair way to expose this
mechanism. And I tend to agree that it'd mostly be useful in
conjunction with "spidev".
Anton -- assuming this goes in, it'd be nice if you could
contribute a simple test program using this, which we could
keep in Documentation/spi somewhere. (Maybe with other testing
notes, if anyone comes up with such.)
- Dave
> ...
>
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -77,6 +77,7 @@ struct spi_device {
> #define SPI_CS_HIGH 0x04 /* chipselect active high? */
> #define SPI_LSB_FIRST 0x08 /* per-word bits-on-wire */
> #define SPI_3WIRE 0x10 /* SI/SO signals shared */
> +#define SPI_LOOP 0x20 /* loopback mode */
> u8 bits_per_word;
> int irq;
> void *controller_state;
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 1/3] [SPI] Sync spidev.{h, c} with spi.h
From: David Brownell @ 2007-07-27 3:02 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
In-Reply-To: <20070726135041.GA5550@localhost.localdomain>
On Thursday 26 July 2007, Anton Vorontsov wrote:
> --- a/drivers/spi/spidev.c
> +++ b/drivers/spi/spidev.c
> @@ -56,8 +56,8 @@ static unsigned long minors[N_SPI_MINORS / BITS_PER_LONG];
>
>
> /* Bit masks for spi_device.mode management */
> -#define SPI_MODE_MASK (SPI_CPHA | SPI_CPOL)
> -
> +#define SPI_MODE_MASK (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | \
> + SPI_LSB_FIRST | SPI_3WIRE)
Hmm, I seem to recall explicitly leaving out CS_HIGH on the grounds
that getting it wrong could corrupt the whole bus; Not Good (tm).
And the same argument can apply to 3WIRE mode ...
On the other hand, that's not necessarily a good reason, since there
are other ways to trash hardware too.
Comments anyone?
- Dave
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Benjamin Herrenschmidt @ 2007-07-27 3:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Alan Curry, linux-kernel
In-Reply-To: <20070726184800.0bb3b9fb.akpm@linux-foundation.org>
On Thu, 2007-07-26 at 18:48 -0700, Andrew Morton wrote:
> On Wed, 25 Jul 2007 17:12:45 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > On Tue, 2007-07-24 at 21:28 -0400, Alan Curry wrote:
> > > As of 2.6.22 the kernel doesn't recognize the i8042 keyboard/mouse controller
> > > on the PegasosPPC. This is because of a feature/bug in the OF device tree:
> > > the "device_type" attribute is an empty string instead of "8042" as the
> > > kernel expects. This patch (against 2.6.22.1) adds a secondary detection
> > > which looks for a device whose *name* is "8042" if there is no device whose
> > > *type* is "8042".
> > >
> > > Signed-off-by: Alan Curry <pacman@world.std.com>
> >
> > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >
> > Note, if there's a volunteer, we could probably turn that code into a
> > nice table lookup.
>
> Did this get merged, or otherwise fixed? Even though the code in there has
> changed quite a bit, it looks to my untrained eye like the fix is still
> applicable?
Merged a fixed version:
f5d834fc34e61f1a40435981062000e5d2b2baa8
(In linus tree as of now)
Cheers,
Ben.
>
> From: Alan Curry <pacman@TheWorld.com>
>
> As of 2.6.22 the kernel doesn't recognize the i8042 keyboard/mouse
> controller on the PegasosPPC. This is because of a feature/bug in the OF
> device tree: the "device_type" attribute is an empty string instead of
> "8042" as the kernel expects. This patch (against 2.6.22.1) adds a
> secondary detection which looks for a device whose *name* is "8042" if
> there is no device whose *type* is "8042".
>
> Signed-off-by: Alan Curry <pacman@world.std.com>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> arch/powerpc/kernel/setup-common.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff -puN /dev/null /dev/null
> diff -puN arch/powerpc/kernel/setup-common.c~powerpc-pegasos-keyboard-detection arch/powerpc/kernel/setup-common.c
> --- a/arch/powerpc/kernel/setup-common.c~powerpc-pegasos-keyboard-detection
> +++ a/arch/powerpc/kernel/setup-common.c
> @@ -496,6 +496,12 @@ int check_legacy_ioport(unsigned long ba
> break;
> }
> np = of_find_node_by_type(NULL, "8042");
> + /*
> + * Pegasos has no device_type on its 8042 node, look for the
> + * name instead
> + */
> + if (!np)
> + np = of_find_node_by_name(NULL, "8042");
> break;
> case FDC_BASE: /* FDC1 */
> np = of_find_node_by_type(NULL, "fdc");
> _
>
>
> And ALan says that 2.6.22 is bust, but this patch no won't apply there so
> if we want to fix 2.6.22.x then Alan's original patch would be needed.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 0/4] Few spi_mpc83xx.c fixes and improvements
From: David Brownell @ 2007-07-27 2:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: spi-devel-general
In-Reply-To: <20070726131134.GA3309@localhost.localdomain>
On Thursday 26 July 2007, Anton Vorontsov wrote:
> Hi all,
>
> These patches based on Linus' tree, as of today.
I don't know mpc83xx ... are there any PPC folk who can see
any reason not to just merge these patches? They look OK
to me, but in this case that doesn't mean much. :)
If I don't hear otherwise, I'll forward all four of these
patches upstream on Monday.
(Anton, thanks for these updates!)
- Dave
^ permalink raw reply
* Re: DTC 1.0.0 Release Coming?
From: David Gibson @ 2007-07-27 2:00 UTC (permalink / raw)
To: Jon Loeliger, linuxppc-dev
In-Reply-To: <20070727013331.GB1561@localhost.localdomain>
On Fri, Jul 27, 2007 at 11:33:31AM +1000, David Gibson wrote:
> On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote:
[snip]
> > I hve also verified that at least one other independent build
> > using this approach produces a correct version string for them
> > as well.
>
> Yes, well, this is the other trouble - the current system is so
> complex it's very hard to debug and figure out why it's claiming my
> build is dirty but not yours.
Ok, figured out why. When I push, then pop a quilt patch some of the
files end up with their original contents, but changed timestamps.
That altered stat information causes git-diff-index to give false
indications of changed files, so setlocalversion adds the -dirty.
Running git status, or gitool or various other things causes git to
notice that the files aren't really changed, updates the index and
then the version is generated correctly again.
Not very robust though.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ 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