Re: boot/wrap assumes a biarch toolchain?
Andreas Schwab wrote: Jan Dittmer [EMAIL PROTECTED] writes: Same error, you write above that a newer compiler version should not need -m32 or --with-cpu=default32 any more? ??? Where did I say that? Your mail from 2007-10-29 4:39 pm (CET) Your compiler still needs -m32 to generate 32-bit code (or use --with-cpu=default32 to make that the default). See the 'still' ? I just assumed that it must have been changed in newer versions. But to sum up. I've to compile with '--with-cpu=default32' and all should be fine? Because I have no idea how to pass the -m32 flag just to the 32-bit code generation. Passing it via CFLAGS obviously does not work as it also passes it to the 64 bit code generation. Jan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
On 10/29/07, Dale Farnsworth [EMAIL PROTECTED] wrote: On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote: This commit made an incorrect assumption: -- Author: Lennert Buytenhek [EMAIL PROTECTED] Date: Fri Oct 19 04:10:10 2007 +0200 mv643xx_eth: Move ethernet register definitions into private header Move the mv643xx's ethernet-related register definitions from include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since they aren't of any use outside the ethernet driver. Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED] Acked-by: Tzachi Perelstein [EMAIL PROTECTED] Signed-off-by: Dale Farnsworth [EMAIL PROTECTED] -- arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there. [EMAIL PROTECTED]:~/devel/wireless-2.6$ git-describe v2.6.24-rc1-138-g0119130 This patch fixes this by internalizing 3 defines onto pegasos which are simply no longer available elsewhere. Without this your compile will fail That compile failure was fixed in commit 30e69bf4cce16d4c2dcfd629a60fcd8e1aba9fee by Al Viro. However, as I examine that commit, I see that it defines offsets from the eth block in the chip, rather than the full chip registeri block as the Pegasos 2 code expects. So, I think it fixes the compile failure, but leaves the Pegasos 2 broken. Luis, do you have Pegasos 2 hardware? Can you (or anyone) verify that the following patch is needed for the Pegasos 2? Nope, sorry. Luis ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: compile warning
thanks for your reply.
WARNING: vmlinux.o(.text+0x10f5c): Section mismatch: reference
to .init.text:cpm_muram_init (between 'cpm2_reset' and
'cpm2_smc_clk_setup')
It should be fixed, but its highly unlikely you'll see a problem
unless you start trying to build core parts of the CPM code as modules.
- k
we have no modules for CPM.
Fix it i could with :
diff --git a/arch/powerpc/sysdev/cpm2_common.c
b/arch/powerpc/sysdev/cpm2_common.c
index f8a621e..f507ada 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -61,7 +61,7 @@ cpm2_map_t __iomem *cpm2_immr;
of space for CPM as it is larger
than on PQ2 */
-void
+void __init
cpm2_reset(void)
{
#ifdef CONFIG_PPC_85xx
--
I am not sure it is ok.
But i have other 2 warnings (no modules).
WARNING: vmlinux.o(.exit.text+0x5da): Section mismatch: reference to
.init.data:of_platform_serial_driver (between 'of_platform_serial_exit' and
'phy_exit')
WARNING: vmlinux.o(.exit.text+0x5e2): Section mismatch: reference to
.init.data:of_platform_serial_driver (between 'of_platform_serial_exit' and
'phy_exit')
Regards.
--
Sergej Stepanov
IDS GmbH
Nobelstr. 18, Zim. 2.1.05
D-76275 Ettlingen
T +49 (0) 72 43/2 18-615
F +49 (0) 72 43/2 18-400
http://www.ids.de
Email: [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: add kexec support
Michael Ellerman [EMAIL PROTECTED] wrote on 28.10.2007 23:32:17: How do you plan to support kdump? When kexec is fully supported kdump should work out of the box as for any other ethernet card (if you load the right eth driver). There's nothing specific to kdump you have to handle in ethernet device drivers. Hope I didn't miss anything here... Gruss / Regards Christoph R ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH] Fix build failure in platforms/celleb/setup.c which CONFIG_VIRT_CPU_ACCOUNTING is not defined.
On Tuesday 30 October 2007, Tony Breeds wrote: Without this patch I get the following build failure CC arch/powerpc/platforms/celleb/setup.o arch/powerpc/platforms/celleb/setup.c:151: error: 'generic_calibrate_decr' undeclared here (not in a function) Signed-off-by: Tony Breeds [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Execute user program in kernel mode?
hi,
Is it possible to run user program (statically linked) in kernel mode? for
example the user program entry is 0x1000, can we call it directly from
kernel? I've tried many times, but I got the following Error(Oops):
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: 1094 LR: 1094 CTR: C001CBF4
REGS: d1072e90 TRAP: 0700 Not tainted (2.6.19.2-eldk-xm.1.0)
MSR: 00021000 ME CR: XER:
TASK = cf31dc70[809385534] '�1� �˸' THREAD: c001ca38
GPR00: D1072F40 C0555B70 1094 C02C41C0 D1066000 1094 D106C000
GPR08: C02CCAE4 D106A000 2822 00021000
GPR16:
GPR24:
NIP [1094] 0x1094
LR [1094] 0x1094
Call Trace:
Instruction dump:
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C00598C8 LR: C000A108 CTR: C001C2A4
REGS: d1072060 TRAP: 0300 Not tainted (2.6.19.2-eldk-xm.1.0)
MSR: 00021000 ME CR: 8444 XER:
DAR: 3E20736D, DSISR:
TASK = cf31dc70[809385534] '�1� �˸' THREAD: c001ca38
GPR00: C000A0FC D1072110 CF31DC70 3E207365 3E20736D C024
GPR08: CF31DD14 D1072000 00021002 C0002038 C001CBE8
GPR16:
GPR24: CF31DD48 D10721E0 3E20736D CF31DD14 CF31DD48
NIP [C00598C8] find_vma+0x24/0x90
LR [C000A108] do_page_fault+0x50/0x3e0
Call Trace:
Instruction dump:
4c9d0020 91230020 4e800020 7c681b79 3860 4d820020 480c 7d2a4b78
4870 80680008 2f83 419e001c 80030008 7f802040 409d0010 80030004
Kernel panic - not syncing: Aiee, killing interrupt handler!
0Rebooting in 180 seconds..
Does that mean we can not call user space entry code directly, can we?
Regards,
Wang
--
Wang, Baojun Lanzhou University
Distributed Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering [EMAIL PROTECTED]
Tianshui South Road 222. Lanzhou 73 .P.R.China
Tel:+86-931-8912025 Fax:+86-931-8912022
signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt as its own repo and submodule of dtc?
So, like, the other day Kumar Gala mumbled: Jon, It seems like have libfdt as a unique git repo that is a submodule of the things that need it (dtc, u-boot, etc.) might make some sense and it easier for the projects that need to pull it in. Is this something you can take a look at? (or have other ideas on). I would be fine with making libfdt a git repository separate from the DTC repository if that makes it easier to integrate it with other projects. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] using mii-bitbang on different processor ports
The patch makes possible to have mdio and mdc pins on different physical ports
also for CONFIG_PPC_CPM_NEW_BINDING.
To setup it in the device tree:
reg = 10d40 14 10d60 14; // mdc-offset: 0x10d40, mdio-offset: 0x10d60
or
reg = 10d40 14; // mdc and mdio have the same offset 0x10d40
The approach was taken from older version.
Signed-off-by: Sergej Stepanov [EMAIL PROTECTED]
--
diff --git a/drivers/net/fs_enet/mii-bitbang.c
b/drivers/net/fs_enet/mii-bitbang.c
index b8e4a73..86b73ea 100644
--- a/drivers/net/fs_enet/mii-bitbang.c
+++ b/drivers/net/fs_enet/mii-bitbang.c
@@ -29,12 +29,16 @@
#include fs_enet.h
-struct bb_info {
- struct mdiobb_ctrl ctrl;
+struct bb_port {
__be32 __iomem *dir;
__be32 __iomem *dat;
- u32 mdio_msk;
- u32 mdc_msk;
+ u32 msk;
+};
+
+struct bb_info {
+ struct mdiobb_ctrl ctrl;
+ struct bb_port mdc;
+ struct bb_port mdio;
};
/* FIXME: If any other users of GPIO crop up, then these will have to
@@ -62,18 +66,18 @@ static inline void mdio_dir(struct mdiobb_ctrl *ctrl, int
dir)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (dir)
- bb_set(bitbang-dir, bitbang-mdio_msk);
+ bb_set(bitbang-mdio.dir, bitbang-mdio.msk);
else
- bb_clr(bitbang-dir, bitbang-mdio_msk);
+ bb_clr(bitbang-mdio.dir, bitbang-mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang-dir);
+ in_be32(bitbang-mdio.dir);
}
static inline int mdio_read(struct mdiobb_ctrl *ctrl)
{
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
- return bb_read(bitbang-dat, bitbang-mdio_msk);
+ return bb_read(bitbang-mdio.dat, bitbang-mdio.msk);
}
static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
@@ -81,12 +85,12 @@ static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang-dat, bitbang-mdio_msk);
+ bb_set(bitbang-mdio.dat, bitbang-mdio.msk);
else
- bb_clr(bitbang-dat, bitbang-mdio_msk);
+ bb_clr(bitbang-mdio.dat, bitbang-mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang-dat);
+ in_be32(bitbang-mdio.dat);
}
static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
@@ -94,12 +98,12 @@ static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang-dat, bitbang-mdc_msk);
+ bb_set(bitbang-mdc.dat, bitbang-mdc.msk);
else
- bb_clr(bitbang-dat, bitbang-mdc_msk);
+ bb_clr(bitbang-mdc.dat, bitbang-mdc.msk);
/* Read back to flush the write. */
- in_be32(bitbang-dat);
+ in_be32(bitbang-mdc.dat);
}
static struct mdiobb_ops bb_ops = {
@@ -114,23 +118,23 @@ static struct mdiobb_ops bb_ops = {
static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
struct device_node *np)
{
- struct resource res;
+ struct resource res[2];
const u32 *data;
int mdio_pin, mdc_pin, len;
struct bb_info *bitbang = bus-priv;
- int ret = of_address_to_resource(np, 0, res);
+ int ret = of_address_to_resource(np, 0, res[0]);
if (ret)
return ret;
- if (res.end - res.start 13)
+ if (res[0].end - res[0].start 13)
return -ENODEV;
/* This should really encode the pin number as well, but all
* we get is an int, and the odds of multiple bitbang mdio buses
* is low enough that it's not worth going too crazy.
*/
- bus-id = res.start;
+ bus-id = res[0].start;
data = of_get_property(np, fsl,mdio-pin, len);
if (!data || len != 4)
@@ -142,13 +146,27 @@ static int __devinit fs_mii_bitbang_init(struct mii_bus
*bus,
return -ENODEV;
mdc_pin = *data;
- bitbang-dir = ioremap(res.start, res.end - res.start + 1);
- if (!bitbang-dir)
+ bitbang-mdc.dir = ioremap(res[0].start, res[0].end - res[0].start + 1);
+ if (!bitbang-mdc.dir)
return -ENOMEM;
- bitbang-dat = bitbang-dir + 4;
- bitbang-mdio_msk = 1 (31 - mdio_pin);
- bitbang-mdc_msk = 1 (31 - mdc_pin);
+ bitbang-mdc.dat = bitbang-mdc.dir + 4;
+ if( !of_address_to_resource(np, 1, res[1]))
+ {
+ bitbang-mdio.dir = ioremap(res[1].start, res[1].end -
res[1].start + 1);
+ if (!bitbang-mdio.dir)
+ {
+ iounmap(bitbang-mdc.dir);
+ return -ENOMEM;
+ }
+ bitbang-mdio.dat = bitbang-mdio.dir + 4;
+ }
+ else{
+ bitbang-mdio.dir =
Re: boot/wrap assumes a biarch toolchain?
Andreas Schwab wrote: Jan Dittmer [EMAIL PROTECTED] writes: Your mail from 2007-10-29 4:39 pm (CET) Your compiler still needs -m32 to generate 32-bit code (or use --with-cpu=default32 to make that the default). See the 'still' ? How would the compiler know whether to generate 64bit or 32bit code?? Andreas, I think we both got a bit lost. Lets take a step back. The original problem was that after 2.6.23 cross compiling powerpc/g5_defconfig broke (Regression). Using gcc 4.0.4, powerpc64 target as cross compiler and powerpc target as 32-bit cross compiler. Since 2.6.23-git1 it is now broken. Using gcc 4.1.2 didn't fix this. Neither with --with-cpu=default32 present nor without. So could you please explain to me how I'm supposed to cross compile powerpc/g5_defconfig now? Passing CFLAGS=-m32 didn't help too. Or is it just a new bug in the kernel make system? Just for reference up till 2.6.23 I used the following command: make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- \ CROSS32_COMPILE=powerpc-linux- Thanks, Jan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot/wrap assumes a biarch toolchain?
Andreas Schwab wrote: Jan Dittmer [EMAIL PROTECTED] writes: Your mail from 2007-10-29 4:39 pm (CET) Your compiler still needs -m32 to generate 32-bit code (or use --with-cpu=default32 to make that the default). See the 'still' ? How would the compiler know whether to generate 64bit or 32bit code?? ... and it works again with .24-rc1-git6. So whatever the problem was. Consider it resolved. Jan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new class property?
Explicitly specifying what device class bindings / conventions the
node complies with is cute, but not actually all that useful in
practice. If it looks like a duck class device node, and it
quacks^Whas the properties of a duck class device node, it's duck
class compliant.
Don't know how cute it is, but I think it is practically
helpful. Take another example:
Say you-- a human reader-- see this in a device
tree:
...
interrupts = b 8;
interrupt-parent = mpic ;
...
What does the 'b' and '8' mean? You look
at the interrupt controller node--
mpic: [EMAIL PROTECTED] {
clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 4 4;
compatible = fsl,xyz;
big-endian;
}
Note-- I removed the device_type property and changed
compatible somewhat. How are you going to find where
the meaning interrupt controller's interrupt cells are
defined? What spec will you look at?
device_type = open-pic; makes it perfectly clear.
It's an open-pic type controller and follows that
binding.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
mpic: [EMAIL PROTECTED] {
clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 4 4;
compatible = fsl,xyz;
big-endian;
}
Note-- I removed the device_type property and changed
compatible somewhat. How are you going to find where
the meaning interrupt controller's interrupt cells are
defined? What spec will you look at?
The binding for fsl,xyz.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] PowerPC: 440GRx Rainier bootwrapper.
Bootwrapper code for PowerPC 440GRx Rainier board.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/boot/Makefile |3 +
arch/powerpc/boot/cuboot-rainier.c | 56 +
2 files changed, 58 insertions(+), 1 deletion(-)
diff -pruN linux-2.6.orig/arch/powerpc/boot/cuboot-rainier.c
linux-2.6/arch/powerpc/boot/cuboot-rainier.c
--- linux-2.6.orig/arch/powerpc/boot/cuboot-rainier.c 1970-01-01
03:00:00.0 +0300
+++ linux-2.6/arch/powerpc/boot/cuboot-rainier.c2007-10-30
18:00:15.0 +0300
@@ -0,0 +1,56 @@
+/*
+ * Old U-boot compatibility for Rainier
+ *
+ * Valentine Barshak [EMAIL PROTECTED]
+ * Copyright 2007 MontaVista Software, Inc
+ *
+ * Based on Ebony code by David Gibson [EMAIL PROTECTED]
+ * Copyright IBM Corporation, 2007
+ *
+ * Based on Bamboo code by Josh Boyer [EMAIL PROTECTED]
+ * Copyright IBM Corporation, 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; version 2 of the License
+ */
+
+#include stdarg.h
+#include stddef.h
+#include types.h
+#include elf.h
+#include string.h
+#include stdio.h
+#include page.h
+#include ops.h
+#include dcr.h
+#include 4xx.h
+#include 44x.h
+#include cuboot.h
+
+#define TARGET_4xx
+#define TARGET_44x
+#include ppcboot.h
+
+static bd_t bd;
+
+
+static void rainier_fixups(void)
+{
+ unsigned long sysclk = ;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200);
+ ibm4xx_fixup_ebc_ranges(/plb/opb/ebc);
+ ibm4xx_denali_fixup_memsize();
+ dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ platform_ops.fixups = rainier_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ ft_init(_dtb_start, 0, 32);
+ serial_console_init();
+}
diff -pruN linux-2.6.orig/arch/powerpc/boot/Makefile
linux-2.6/arch/powerpc/boot/Makefile
--- linux-2.6.orig/arch/powerpc/boot/Makefile 2007-10-30 17:44:27.0
+0300
+++ linux-2.6/arch/powerpc/boot/Makefile2007-10-30 18:00:15.0
+0300
@@ -56,7 +56,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
\
- fixed-head.S ep88xc.c cuboot-hpc2.c
+ fixed-head.S ep88xc.c cuboot-hpc2.c cuboot-rainier.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -158,6 +158,7 @@ image-$(CONFIG_MPC7448HPC2) += cuImage.
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
image-$(CONFIG_SEQUOIA)+= cuImage.sequoia
+image-$(CONFIG_RAINIER)+= cuImage.rainier
image-$(CONFIG_WALNUT) += treeImage.walnut
endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] PowerPC: 440GRx Rainier DTS.
PowerPC 440GRx Rainier DTS.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/rainier.dts | 312 ++
1 files changed, 312 insertions(+)
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/rainier.dts
linux-2.6/arch/powerpc/boot/dts/rainier.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/rainier.dts1970-01-01
03:00:00.0 +0300
+++ linux-2.6/arch/powerpc/boot/dts/rainier.dts 2007-10-30 18:00:15.0
+0300
@@ -0,0 +1,312 @@
+/*
+ * Device Tree Source for AMCC Rainier
+ *
+ * Based on Sequoia code
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ *
+ * FIXME: Draft only!
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ *
+ */
+
+/ {
+ #address-cells = 2;
+ #size-cells = 1;
+ model = amcc,rainier;
+ compatible = amcc,rainier;
+ dcr-parent = /cpus/PowerPC,[EMAIL PROTECTED];
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ clock-frequency = 0; /* Filled in by zImage */
+ timebase-frequency = 0; /* Filled in by zImage */
+ i-cache-line-size = 20;
+ d-cache-line-size = 20;
+ i-cache-size = 8000;
+ d-cache-size = 8000;
+ dcr-controller;
+ dcr-access-method = native;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 0 0; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-440grx,ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0c0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = ibm,uic-440grx,ibm,uic;
+ interrupt-controller;
+ cell-index = 1;
+ dcr-reg = 0d0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 1e 4 1f 4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = ibm,uic-440grx,ibm,uic;
+ interrupt-controller;
+ cell-index = 2;
+ dcr-reg = 0e0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 1c 4 1d 4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ SDR0: sdr {
+ compatible = ibm,sdr-440grx, ibm,sdr-440ep;
+ dcr-reg = 00e 002;
+ };
+
+ CPR0: cpr {
+ compatible = ibm,cpr-440grx, ibm,cpr-440ep;
+ dcr-reg = 00c 002;
+ };
+
+ plb {
+ compatible = ibm,plb-440grx, ibm,plb4;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges;
+ clock-frequency = 0; /* Filled in by zImage */
+
+ SDRAM0: sdram {
+ device_type = memory-controller;
+ compatible = ibm,sdram-440grx,
ibm,sdram-44x-ddr2denali;
+ dcr-reg = 010 2;
+ };
+
+ DMA0: dma {
+ compatible = ibm,dma-440grx, ibm,dma-4xx;
+ dcr-reg = 100 027;
+ };
+
+ MAL0: mcmal {
+ compatible = ibm,mcmal-440grx, ibm,mcmal2;
+ dcr-reg = 180 62;
+ num-tx-chans = 2;
+ num-rx-chans = 2;
+ interrupt-parent = MAL0;
+ interrupts = 0 1 2 3 4;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = /*TXEOB*/ 0 UIC0 a 4
+ /*RXEOB*/ 1 UIC0 b 4
+ /*SERR*/ 2 UIC1 0 4
+ /*TXDE*/ 3 UIC1 1 4
+ /*RXDE*/ 4 UIC1 2 4;
+ interrupt-map-mask = ;
+ };
+
+ POB0: opb {
+ compatible = ibm,opb-440grx, ibm,opb;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 1 8000
+ 8000 1 8000 8000;
+
Re: [PATCH] using mii-bitbang on different processor ports
Hello Scott. Thank you for reply. Am Dienstag, den 30.10.2007, 11:32 -0500 schrieb Scott Wood: On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote: You could just use of_iomap() for the second one, since we don't need the physical address for bus-id. Nice tip. Than it would be needless--- | \/ + iounmap(bitbang-mdc.dir); + return -ENOMEM; Please use the goto-style error handling that's used elsewhere in the function. Regards Sergej. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] PowerPC: 440GRx Rainier board support.
PowerPC 440GRx Rainier board support.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/platforms/44x/Kconfig | 16 -
arch/powerpc/platforms/44x/Makefile |3 +
arch/powerpc/platforms/44x/rainier.c | 61 +++
3 files changed, 78 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig
linux-2.6/arch/powerpc/platforms/44x/Kconfig
--- linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig 2007-10-30
17:44:42.0 +0300
+++ linux-2.6/arch/powerpc/platforms/44x/Kconfig2007-10-30
18:04:28.0 +0300
@@ -22,6 +22,14 @@ config SEQUOIA
help
This option enables support for the AMCC PPC440EPX evaluation board.
+config RAINIER
+ bool Rainier
+ depends on 44x
+ default n
+ select 440GRX
+ help
+ This option enables support for the AMCC PPC440GRX evaluation board.
+
#config LUAN
# bool Luan
# depends on 44x
@@ -52,6 +60,12 @@ config 440EPX
select IBM_NEW_EMAC_RGMII
select IBM_NEW_EMAC_ZMII
+config 440GRX
+ bool
+ select IBM_NEW_EMAC_EMAC4
+ select IBM_NEW_EMAC_RGMII
+ select IBM_NEW_EMAC_ZMII
+
config 440GP
bool
select IBM_NEW_EMAC_ZMII
@@ -64,7 +78,7 @@ config 440SP
config 440A
bool
- depends on 440GX || 440EPX
+ depends on 440GX || 440EPX || 440GRX
default y
# 44x errata/workaround config symbols, selected by the CPU models above
diff -pruN linux-2.6.orig/arch/powerpc/platforms/44x/Makefile
linux-2.6/arch/powerpc/platforms/44x/Makefile
--- linux-2.6.orig/arch/powerpc/platforms/44x/Makefile 2007-10-30
17:44:42.0 +0300
+++ linux-2.6/arch/powerpc/platforms/44x/Makefile 2007-10-30
18:00:15.0 +0300
@@ -1,4 +1,5 @@
obj-$(CONFIG_44x) := misc_44x.o
obj-$(CONFIG_EBONY)+= ebony.o
-obj-$(CONFIG_BAMBOO) += bamboo.o
+obj-$(CONFIG_BAMBOO) += bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
+obj-$(CONFIG_RAINIER) += rainier.o
diff -pruN linux-2.6.orig/arch/powerpc/platforms/44x/rainier.c
linux-2.6/arch/powerpc/platforms/44x/rainier.c
--- linux-2.6.orig/arch/powerpc/platforms/44x/rainier.c 1970-01-01
03:00:00.0 +0300
+++ linux-2.6/arch/powerpc/platforms/44x/rainier.c 2007-10-30
18:00:15.0 +0300
@@ -0,0 +1,61 @@
+/*
+ * Rainier board specific routines
+ *
+ * Valentine Barshak [EMAIL PROTECTED]
+ * Copyright 2007 MontaVista Software Inc.
+ *
+ * Based on the Bamboo code by
+ * Josh Boyer [EMAIL PROTECTED]
+ * Copyright 2007 IBM Corporation
+ *
+ * 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 asm/machdep.h
+#include asm/prom.h
+#include asm/udbg.h
+#include asm/time.h
+#include asm/uic.h
+#include asm/of_platform.h
+#include 44x.h
+
+static struct of_device_id rainier_of_bus[] = {
+ { .compatible = ibm,plb4, },
+ { .compatible = ibm,opb, },
+ { .compatible = ibm,ebc, },
+ {},
+};
+
+static int __init rainier_device_probe(void)
+{
+ if (!machine_is(rainier))
+ return 0;
+
+ of_platform_bus_probe(NULL, rainier_of_bus, NULL);
+
+ return 0;
+}
+device_initcall(rainier_device_probe);
+
+static int __init rainier_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, amcc,rainier))
+ return 0;
+
+ return 1;
+}
+
+define_machine(rainier) {
+ .name = Rainier,
+ .probe = rainier_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq= uic_get_irq,
+ .restart= ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] PowerPC: 440GRx Rainier default config
PowerPC 440GRx Rainier default config. Signed-off-by: Valentine Barshak [EMAIL PROTECTED] --- arch/powerpc/configs/rainier_defconfig | 868 + 1 files changed, 868 insertions(+) diff -pruN linux-2.6.orig/arch/powerpc/configs/rainier_defconfig linux-2.6/arch/powerpc/configs/rainier_defconfig --- linux-2.6.orig/arch/powerpc/configs/rainier_defconfig 1970-01-01 03:00:00.0 +0300 +++ linux-2.6/arch/powerpc/configs/rainier_defconfig2007-10-30 18:19:59.0 +0300 @@ -0,0 +1,868 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.24-rc1 +# Tue Oct 30 18:19:49 2007 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +# CONFIG_6xx is not set +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +CONFIG_44x=y +# CONFIG_E200 is not set +CONFIG_4xx=y +CONFIG_BOOKE=y +CONFIG_PTE_64BIT=y +CONFIG_PHYS_64BIT=y +# CONFIG_PPC_MM_SLICES is not set +CONFIG_NOT_COHERENT_CACHE=y +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +CONFIG_PPC_UDBG_16550=y +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +CONFIG_PPC_DCR_NATIVE=y +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_PPC_DCR=y +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +# CONFIG_FAIR_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLUB_DEBUG=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y +# CONFIG_SLOB is not set +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y +CONFIG_BLOCK=y +CONFIG_LBD=y +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory + +# +# Platform support +# +# CONFIG_PPC_MPC52xx is not set +# CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +# CONFIG_BAMBOO is not set +# CONFIG_EBONY is not set +# CONFIG_SEQUOIA is not set +CONFIG_RAINIER=y +CONFIG_440GRX=y +CONFIG_440A=y +# CONFIG_MPIC is not set +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is not set +# CONFIG_CPU_FREQ is not set +# CONFIG_CPM2 is not set +# CONFIG_FSL_ULI1575 is not set + +# +# Kernel options +# +# CONFIG_HIGHMEM is not set +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set +CONFIG_HZ=250 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +CONFIG_MATH_EMULATION=y +CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_ARCH_POPULATES_NODE_MAP=y +CONFIG_SELECT_MEMORY_MODEL=y
Re: [PATCH] using mii-bitbang on different processor ports
Sergej Stepanov wrote: Hello Scott. Thank you for reply. Am Dienstag, den 30.10.2007, 11:32 -0500 schrieb Scott Wood: On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote: You could just use of_iomap() for the second one, since we don't need the physical address for bus-id. Nice tip. Than it would be needless--- | \/ + iounmap(bitbang-mdc.dir); + return -ENOMEM; Please use the goto-style error handling that's used elsewhere in the function. Hmm... in this case, it'd be impossible to tell using of_iomap() whether a failure was due to reg only having one resource (and thus meaning the same one should be used for both), or due to ioremap() failure. Maybe we should keep it separate. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/4] PowerPC: 440GRx Rainier board support.
The following patches add PowerPC 440GRx Rainier board support. The board is almost identical to Sequoia, but doesn't have USB and FPU is not supported. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] Add device-tree aware NDFC driver
On Tue, 30 October 2007 17:13:08 +0300, Valentine Barshak wrote: I'm not saying my approach is the best, but I was hoping for a discussion. That is good. So please take a moment to listen. I've reworked the patches according to the comments to the previous version and used my arguments to explain why I don't see much reason to mess with the code we currently have and added a separate _of version. Ok. This is the last time I disturb you with my e-mail, so please, forget it. Thomas words were harsh. Nothing unusual so far. Some people deserve harsh words, some don't and some simply are doing a good job to invite them. You mails so far were inviting harsh words. So how did you invite harsh words and what can you change to prevent this in the future? 1. Develop a thicker skin. No matter how well you do, there will always be the occasional harsh words, deserved or not. It is ok to get angry and call the person names - but do that at home and leave it out of your responses. Ignore the flamebait, at least in public. 2. Follow local customs. In particular you should follow the style of discussion commonly used in mailing lists: I'm doing this. Crap! Never do that! Why not? Can you explain? Because... Then I do that. Wouldn't ABCD be better? ABCD wouldn't work for me because of XYZ. Fair enough. Respond to individual comments _directly_following_the_comment_ do not collect comments from 10 mails, then respond to them all in a long paragraph. Noone will read that. I didn't read it either. 3. Be concise. When quoting someone, remove everything but the relevant bits. Respond only with relevant information. People regularly read 10+ mailing lists. Their attention span is short. If you manage to annoy them with irrelevant information in the first 10 lines, they will skip any amount of wisdom below. 4. Be polite. Even if the responses you get are not. Flamewars get you nowhere. 5. Have sound technical arguments. mtd concat adds a slight overhead is not for two reasons. First, it is lacking numbers. People's guesses about perceived overhead or usually wrong, so knowledgeable readers will immediately question such arguments. Secondly, you didn't explain _why_ mtdconcat adds overhead. In particular, why didn't you reduce the mtdconcat overhead instead of essentially copying its functionality? 6. Be structured. Empty lines are cheap. Use them. Add structure to your mails. Above you can see several paragraphs. You can quickly go back to a previous one. You can skip one after reading just the first sentence. After several attempts I still haven't read your 46-line monologue. I don't even know how far I made it because it is so damn hard to find the spot again. If you are willing to change the style of your mails, maybe people will actually read them and respond to you in ways you expected. Otherwise it may indeed be a wise choice not to come back. Some people simply just don't get along. Sometimes a proxy is needed to translate between people. But my hope is that you are willing and able to work with us directly. Jörn -- There is no worse hell than that provided by the regrets for wasted opportunities. -- Andre-Louis Moreau in Scarabouche ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Gianfar skb panic when bonding a VLAN interface
Hi, I tried to ping over a bonded VLAN tagged interface. (e.g - ifenslave bond0 eth3.24) This fails with following output: [EMAIL PROTECTED]:/root ping 192.168.24.101 PING 192.168.24.skb_under_panic: text:c01bbdf8 len:50 put:8 head:dd27a3a0 data:dd27a39a tail:dd27a3cc end:dd27a3e0 dev:eth3 Oops: Exception in kernel mode, sig: 5 [#1] NIP: C01E9110 LR: C01E9110 SP: C03479F0 REGS: c0347940 TRAP: 0700 Tainted: PF MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 TASK = c03031a0[0] 'swapper' THREAD: c0346000 Last syscall: 120 GPR00: C01E9110 C03479F0 C03031A0 0072 2D03 0030 3FFF GPR08: C037D0AC C034 65F51C00 6000 0FFE3900 C0347A7C GPR16: DFC1FD60 C0347DD0 C0B94800 0FFF3D0C C0347A80 007FD890 GPR24: C0A81865 C0A81805 C0B94800 DFC1FD60 C0B94A40 DF10C128 NIP [c01e9110] skb_under_panic+0x50/0x64 LR [c01e9110] skb_under_panic+0x50/0x64 Call trace: [c01bbe0c] gfar_add_fcb+0x7c/0xb4 [c01bbfc0] gfar_start_xmit+0x160/0x268 [c01c] qdisc_restart+0x100/0x1fc [c01f04c4] dev_queue_xmit+0xc88/0xde0 [c02a9684] vlan_dev_hwaccel_hard_start_xmit+0x9c/0xb0 [c01f054c] dev_queue_xmit+0xd10/0xde0 [c01afaa8] bond_dev_queue_xmit+0x2a8/0x2c4 [c01b4464] bond_xmit_roundrobin+0x94/0x108 [c01f054c] dev_queue_xmit+0xd10/0xde0 [c022f6cc] arp_xmit+0x5c/0x6c [c022f704] arp_send+0x28/0x38 [c022ef48] arp_solicit+0x1a0/0x1c0 [c01f81b0] neigh_timer_handler+0x294/0x31c [c0043310] run_timer_softirq+0xa7c/0xaec [c0039b68] __do_softirq+0xabc/0x15a0 101 (192.168.24.Kernel panic - not syncing: Aiee, killing interrupt handler! 101) 56(84) byte s of data. Call trace: [c0008258] dump_stack+0x18/0x28 [c002fa50] panic+0xa8/0x190 [c0033690] do_exit+0x3c/0xdec [c0002fb4] _exception+0x0/0x1558 [c0002ff0] _exception+0x3c/0x1558 [c0004d70] ProgramCheckException+0x11c/0x1c4 [c00029ac] ret_from_except_full+0x0/0x4c [c01e9110] skb_under_panic+0x50/0x64 [c01bbe0c] gfar_add_fcb+0x7c/0xb4 [c01bbfc0] gfar_start_xmit+0x160/0x268 [c01c] qdisc_restart+0x100/0x1fc [c01f04c4] dev_queue_xmit+0xc88/0xde0 [c02a9684] vlan_dev_hwaccel_hard_start_xmit+0x9c/0xb0 [c01f054c] dev_queue_xmit+0xd10/0xde0 [c01afaa8] bond_dev_queue_xmit+0x2a8/0x2c4 Rebooting in 180 seconds.. It seems that the skb headroom is to small. How can I solve this? I could insert skb_realloc_headroom() call, but where it's the best place then? What about alignement? Regards, Torsten ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Continued serial headaches
Well, now that I've got IRQs requestable, I'm back to battling SCC1 / SCC4
initialization,
I've verified the iop structures, and things look set-up correctly.
/* SCC1 */
{2, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{3, 29, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 30, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
{3, 31, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
/* SCC4 */
{3, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
I've also verified that upon first use (echo test /dev/ttyCPM[12] the
brgs are configured)
SCC1
cpm_uart_startup:417
CPM uart[1]:startup on IRQ: 40 - request returned 0
cpm_uart_startup:432 CPM uart[1] is scc
CPM uart[1]:set_termios
cpm_setbrg [cpm2_common.c:106] e00119f0:00010140
CPM uart[1]:shutdown
SCC4
cpm_uart_startup:417
CPM uart[2]:startup on IRQ: 43 - request returned 0
cpm_uart_startup:432 CPM uart[2] is scc
CPM uart[2]:set_termios
cpm_setbrg [cpm2_common.c:106] e00119fc:00010140
CPM uart[2]:shutdown
CPM uart[2]:initbd
However, SCC1 continues to get locked.
Am I missing something in the PRAM areas?
SMC1 (ttyCPM0...)
e0008000 : 00c000e0 30300020 eefe3e7a
e0008010 : 00c07331 11b6b05f 3044 07f4d082
e0008020 : 00e3 746562ec d98ceffd 0dec67e3
e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001
e0008040 : fc9d d08a
e0008050 : 80008000 80008000 80008000 80008000
SCC1
e0008000 : 00c000e0 30300020 eefe3e7a
e0008010 : 00c07331 11b6b05f 3044 07f4d082
e0008020 : 00e3 746562ec d98ceffd 0dec67e3
e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001
e0008040 : fc9d d08a
e0008050 : 80008000 80008000 80008000 80008000
SCC4
e0008300 : 01000120 30300020 30401000 07f4e001
e0008310 : 011f 993fb24d 30004000 07f4e0a2
e0008320 : 0130 0d0a8379 fedddfdc 94a967eb
e0008330 : 5d2b06bd 4708b3ce 0020001f 0001
e0008340 : 2804 e8a6
e0008350 : 80008000 80008000 80008000 80008000
-Alan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Continued serial headaches
Alan Bennett wrote: Am I missing something in the PRAM areas? SMC1 (ttyCPM0...) e0008000 : 00c000e0 30300020 eefe3e7a e0008010 : 00c07331 11b6b05f 3044 07f4d082 e0008020 : 00e3 746562ec d98ceffd 0dec67e3 e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001 e0008040 : fc9d d08a e0008050 : 80008000 80008000 80008000 80008000 SCC1 e0008000 : 00c000e0 30300020 eefe3e7a e0008010 : 00c07331 11b6b05f 3044 07f4d082 e0008020 : 00e3 746562ec d98ceffd 0dec67e3 e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001 e0008040 : fc9d d08a e0008050 : 80008000 80008000 80008000 80008000 I'm fairly sure you don't want SMC1 and SCC1 to have the same PRAM areas... Assuming that was just a typo, I don't know what could be wrong. You'll just have to debug it. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] using mii-bitbang on different processor ports
The patch makes possible to have mdio and mdc pins on different physical ports
also for CONFIG_PPC_CPM_NEW_BINDING.
To setup it in the device tree:
reg = 10d40 14 10d60 14; // mdc: 0x10d40, mdio: 0x10d60
or
reg = 10d40 14; // mdc and mdio have the same offset 10d40
The approach was taken from older version.
Signed-off-by: Sergej Stepanov [EMAIL PROTECTED]
--
diff --git a/drivers/net/fs_enet/mii-bitbang.c
b/drivers/net/fs_enet/mii-bitbang.c
index b8e4a73..eea5feb 100644
--- a/drivers/net/fs_enet/mii-bitbang.c
+++ b/drivers/net/fs_enet/mii-bitbang.c
@@ -29,12 +29,16 @@
#include fs_enet.h
-struct bb_info {
- struct mdiobb_ctrl ctrl;
+struct bb_port {
__be32 __iomem *dir;
__be32 __iomem *dat;
- u32 mdio_msk;
- u32 mdc_msk;
+ u32 msk;
+};
+
+struct bb_info {
+ struct mdiobb_ctrl ctrl;
+ struct bb_port mdc;
+ struct bb_port mdio;
};
/* FIXME: If any other users of GPIO crop up, then these will have to
@@ -62,18 +66,18 @@ static inline void mdio_dir(struct mdiobb_ctrl *ctrl, int
dir)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (dir)
- bb_set(bitbang-dir, bitbang-mdio_msk);
+ bb_set(bitbang-mdio.dir, bitbang-mdio.msk);
else
- bb_clr(bitbang-dir, bitbang-mdio_msk);
+ bb_clr(bitbang-mdio.dir, bitbang-mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang-dir);
+ in_be32(bitbang-mdio.dir);
}
static inline int mdio_read(struct mdiobb_ctrl *ctrl)
{
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
- return bb_read(bitbang-dat, bitbang-mdio_msk);
+ return bb_read(bitbang-mdio.dat, bitbang-mdio.msk);
}
static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
@@ -81,12 +85,12 @@ static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang-dat, bitbang-mdio_msk);
+ bb_set(bitbang-mdio.dat, bitbang-mdio.msk);
else
- bb_clr(bitbang-dat, bitbang-mdio_msk);
+ bb_clr(bitbang-mdio.dat, bitbang-mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang-dat);
+ in_be32(bitbang-mdio.dat);
}
static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
@@ -94,12 +98,12 @@ static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang-dat, bitbang-mdc_msk);
+ bb_set(bitbang-mdc.dat, bitbang-mdc.msk);
else
- bb_clr(bitbang-dat, bitbang-mdc_msk);
+ bb_clr(bitbang-mdc.dat, bitbang-mdc.msk);
/* Read back to flush the write. */
- in_be32(bitbang-dat);
+ in_be32(bitbang-mdc.dat);
}
static struct mdiobb_ops bb_ops = {
@@ -114,23 +118,23 @@ static struct mdiobb_ops bb_ops = {
static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
struct device_node *np)
{
- struct resource res;
+ struct resource res[2];
const u32 *data;
int mdio_pin, mdc_pin, len;
struct bb_info *bitbang = bus-priv;
- int ret = of_address_to_resource(np, 0, res);
+ int ret = of_address_to_resource(np, 0, res[0]);
if (ret)
return ret;
- if (res.end - res.start 13)
+ if (res[0].end - res[0].start 13)
return -ENODEV;
/* This should really encode the pin number as well, but all
* we get is an int, and the odds of multiple bitbang mdio buses
* is low enough that it's not worth going too crazy.
*/
- bus-id = res.start;
+ bus-id = res[0].start;
data = of_get_property(np, fsl,mdio-pin, len);
if (!data || len != 4)
@@ -142,15 +146,32 @@ static int __devinit fs_mii_bitbang_init(struct mii_bus
*bus,
return -ENODEV;
mdc_pin = *data;
- bitbang-dir = ioremap(res.start, res.end - res.start + 1);
- if (!bitbang-dir)
+ bitbang-mdc.dir = ioremap(res[0].start, res[0].end - res[0].start + 1);
+ if (!bitbang-mdc.dir)
return -ENOMEM;
- bitbang-dat = bitbang-dir + 4;
- bitbang-mdio_msk = 1 (31 - mdio_pin);
- bitbang-mdc_msk = 1 (31 - mdc_pin);
+ bitbang-mdc.dat = bitbang-mdc.dir + 4;
+ if( !of_address_to_resource(np, 1, res[1])) {
+ if (res[1].end - res[1].start 13)
+ goto bad_resource;
+ bitbang-mdio.dir = ioremap(res[1].start, res[1].end -
res[1].start + 1);
+ if (!bitbang-mdio.dir)
+ goto unmap_and_exit;
+ bitbang-mdio.dat = bitbang-mdio.dir + 4;
+ } else {
+ bitbang-mdio.dir = bitbang-mdc.dir;
+
[RFC] hotplug memory remove - walk_memory_resource for ppc64
Hi KAME,
As I mentioned while ago, ppc64 does not export information about
system RAM in /proc/iomem. Looking at the code and usage
scenerios I am not sure what its really serving. Could you
explain what its purpose how the range can be invalid ?
At least on ppc64, all the memory ranges we get passed comes from
/sysfs memblock information and they are guaranteed to match
device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry
and it will be part of the /proc/device-tree entry. Since we do
online or offline to /sysfs entries to add/remove pages -
these ranges are guaranteed to be valid.
Since this check is redundant for ppc64, I propose following patch.
Is this acceptable ? If some one really really wants, I can code
up this to walk lmb or /proc/device-tree and verify the range
adjust the entries for overlap (I don't see how that can happen).
Paul Kame, please comment.
Thanks,
Badari
---
arch/powerpc/Kconfig |3 +++
arch/powerpc/mm/mem.c | 13 +
kernel/resource.c |2 +-
3 files changed, 17 insertions(+), 1 deletion(-)
Index: linux-2.6.24-rc1/arch/powerpc/mm/mem.c
===
--- linux-2.6.24-rc1.orig/arch/powerpc/mm/mem.c 2007-10-30 07:39:16.0
-0800
+++ linux-2.6.24-rc1/arch/powerpc/mm/mem.c 2007-10-30 10:05:09.0
-0800
@@ -129,6 +129,19 @@ int __devinit arch_add_memory(int nid, u
return __add_pages(zone, start_pfn, nr_pages);
}
+/*
+ * I don't think we really need to do anything here to validate the memory
+ * range or walk the memory resource in lmb or device-tree. Only way we get
+ * the memory range here is through /sysfs in 16MB chunks and we are guaranteed
+ * to have a corresponding device-tree entry.
+ */
+int
+walk_memory_resource(unsigned long start_pfn, unsigned long nr_pages, void
*arg,
+ int (*func)(unsigned long, unsigned long, void *))
+{
+ return (*func)(start_pfn, nr_pages, arg);
+}
+
#endif /* CONFIG_MEMORY_HOTPLUG */
#ifdef CONFIG_MEMORY_HOTREMOVE
Index: linux-2.6.24-rc1/kernel/resource.c
===
--- linux-2.6.24-rc1.orig/kernel/resource.c 2007-10-23 20:50:57.0
-0700
+++ linux-2.6.24-rc1/kernel/resource.c 2007-10-30 08:58:41.0 -0800
@@ -228,7 +228,7 @@ int release_resource(struct resource *ol
EXPORT_SYMBOL(release_resource);
-#ifdef CONFIG_MEMORY_HOTPLUG
+#if defined(CONFIG_MEMORY_HOTPLUG) !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
/*
* Finds the lowest memory reosurce exists within [res-start.res-end)
* the caller must specify res-start, res-end, res-flags.
Index: linux-2.6.24-rc1/arch/powerpc/Kconfig
===
--- linux-2.6.24-rc1.orig/arch/powerpc/Kconfig 2007-10-30 07:39:17.0
-0800
+++ linux-2.6.24-rc1/arch/powerpc/Kconfig 2007-10-30 08:54:57.0
-0800
@@ -234,6 +234,9 @@ config HOTPLUG_CPU
config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
+config ARCH_HAS_WALK_MEMORY
+ def_bool y
+
config ARCH_ENABLE_MEMORY_HOTREMOVE
def_bool y
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new class property?
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, October 30, 2007 11:34 AM
To: Yoder Stuart-B08248
Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
Subject: Re: RFC: replace device_type with new class property?
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
mpic: [EMAIL PROTECTED] {
clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 4 4;
compatible = fsl,xyz;
big-endian;
}
Note-- I removed the device_type property and changed
compatible somewhat. How are you going to find where
the meaning interrupt controller's interrupt cells are
defined? What spec will you look at?
The binding for fsl,xyz.
Not every string listed in compatible has a spec
backing it (or should be required to). You would
have to go look at the source code and cross your
fingers that the comments were sufficient.
Another good reason for device_type-- it helps
distinguish between two similar classes of devices.
Both open-pic and isa-pic look very similar but
have different encodings of their interrupt cells.
Without a device_type it may be difficult or impossible
to distinguish them unless the name and
compatible are luckily clear enough.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Gianfar skb panic when bonding a VLAN interface
Demke Torsten-atd012 [EMAIL PROTECTED] wrote: I tried to ping over a bonded VLAN tagged interface. (e.g - ifenslave bond0 eth3.24) [...] It seems that the skb headroom is to small. How can I solve this? I could insert skb_realloc_headroom() call, but where it's the best place then? What about alignement? What kernel are you using? There was a fix applied to the bonding driver about a year ago to resolve this problem with gianfar: commit 54ef313714070b397d3857289f0fd099b7643631 Author: Jay Vosburgh [EMAIL PROTECTED] Date: Fri Sep 22 21:53:39 2006 -0700 [PATCH] bonding: Handle large hard_header_len The bonding driver fails to adjust its hard_header_len when enslaving interfaces. Whenever an interface with a hard_header_len greater than the ETH_HLEN default is enslaved, the potential for an oops exists, and if the oops happens while responding to an arp request, for example, the system panics. GIANFAR devices may use an extended hard_header for VLAN or hardware checksumming. Enslaving such a device and then transmitting over it causes a kernel panic. Patch modified from submitter's original, but submitter agreed with this patch in private email. Signed-off-by: Mark Huth [EMAIL PROTECTED] Signed-off-by: Jay Vosburgh [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
On 10/30/07, Yoder Stuart-B08248 [EMAIL PROTECTED] wrote: Another good reason for device_type-- it helps distinguish between two similar classes of devices. Both open-pic and isa-pic look very similar but have different encodings of their interrupt cells. Without a device_type it may be difficult or impossible to distinguish them unless the name and compatible are luckily clear enough. I don't think you want to go down that path. If your compatible list does not uniquely describe what the device is (followed by a list of devices it is compatible with); then it is not specific enough. It's fine for a device driver to go looking at other properties to get more details; but drivers should primarily bind on the compatible list. In other words; device_type and/or class are a coarser grained description of the device than the compatible list. If you match on compatible; why would there be any need at all to look at 'name', 'device_type' or the proposed 'class' properties? Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 05/28] Add cmpxchg64 and cmpxchg64_local to powerpc
Make sure that at least cmpxchg64_local is available on all architectures to use for unsigned long long values. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] Acked-by: Paul Mackerras [EMAIL PROTECTED] CC: linuxppc-dev@ozlabs.org --- include/asm-powerpc/system.h |6 ++ 1 file changed, 6 insertions(+) Index: linux-2.6-lttng/include/asm-powerpc/system.h === --- linux-2.6-lttng.orig/include/asm-powerpc/system.h 2007-09-24 10:50:11.0 -0400 +++ linux-2.6-lttng/include/asm-powerpc/system.h2007-09-24 11:01:04.0 -0400 @@ -488,6 +488,12 @@ __cmpxchg_local(volatile void *ptr, unsi */ #define NET_IP_ALIGN 0 #define NET_SKB_PADL1_CACHE_BYTES + +#define cmpxchg64 cmpxchg +#define cmpxchg64_localcmpxchg_local +#else +#include asm-generic/cmpxchg-local.h +#define cmpxchg64_local(ptr,o,n) __cmpxchg64_local_generic((ptr), (o), (n)) #endif #define arch_align_stack(x) (x) -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] PowerPC: 440GRx Rainier board support.
On Tuesday 30 October 2007, Valentine Barshak wrote:
+static struct of_device_id rainier_of_bus[] = {
+ { .compatible = ibm,plb4, },
+ { .compatible = ibm,opb, },
+ { .compatible = ibm,ebc, },
+ {},
+};
+
+static int __init rainier_device_probe(void)
+{
+ if (!machine_is(rainier))
+ return 0;
+
+ of_platform_bus_probe(NULL, rainier_of_bus, NULL);
+
+ return 0;
+}
+device_initcall(rainier_device_probe);
+
+static int __init rainier_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, amcc,rainier))
+ return 0;
+
+ return 1;
+}
+
+define_machine(rainier) {
+ .name = Rainier,
+ .probe = rainier_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart= ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
Wow, this is getting really small these days. I wonder if we should add two
more generic helpers to turn this into just
define_machine(rainier) {
.name = Rainier,
.compatible = amcc,rainier, /* new */
.probe_buses= 4xx_generic_bus_probe, /* new */
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq= uic_get_irq,
.restart= ppc44x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
On Tue, 30 Oct 2007 19:45:11 +0300 Valentine Barshak [EMAIL PROTECTED] wrote: The following patches add PowerPC 440GRx Rainier board support. The board is almost identical to Sequoia, but doesn't have USB and FPU is not supported. So why do we need anything other than the DTS and the defconfig? I would think the sequoia wrapper and platform files would suffice completely for this. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache
Fortunately, we don't support SMP on these or this solution wouldn't work. We should mark 44x BROKEN on SMP in Kconfig. Can we enable SMP on 44x at all currently ? No arch/ppc fix? I know we all want it to die as soon as possible, but still... :) Yeah, I didn't do it yet, which is one reason this patch is marked RFC :-) /* interrupts are hard-disabled at this point */ restore: +#ifdef CONFIG_44x + lis r4,[EMAIL PROTECTED] + lwz r5,[EMAIL PROTECTED](r4) + cmplwi cr0,r5,0 + beq+1f + iccci r0,r0 + li r6,0 + iccci r0,r0 + stw r6,[EMAIL PROTECTED](r4) +1: Why two iccci's here? No idea... thinko/typo. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache
On Wed, 31 Oct 2007 07:16:31 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Fortunately, we don't support SMP on these or this solution wouldn't work. We should mark 44x BROKEN on SMP in Kconfig. Can we enable SMP on 44x at all currently ? Not without editing the Kconfig.cputypes file. I was thinking of being a bit proactive so people didn't just add || 44x to it and think it would work. But it's minor. No arch/ppc fix? I know we all want it to die as soon as possible, but still... :) Yeah, I didn't do it yet, which is one reason this patch is marked RFC :-) Fair enough. /* interrupts are hard-disabled at this point */ restore: +#ifdef CONFIG_44x + lis r4,[EMAIL PROTECTED] + lwz r5,[EMAIL PROTECTED](r4) + cmplwi cr0,r5,0 + beq+1f + iccci r0,r0 + li r6,0 + iccci r0,r0 + stw r6,[EMAIL PROTECTED](r4) +1: Why two iccci's here? No idea... thinko/typo. And here I thought you were being extra careful ;) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)
Hello Stefan, In message [EMAIL PROTECTED] you wrote: I already have it running on my system using a quick hack (see patch below) in include/asm-ppc/nmi.h (yes, still arch/ppc for now :-( ). But for a clean implementation, that has chances for upstream merge (in arch/powerpc later), I would really like to hear if I should move on further this way. My impression is, that changing the name from touch_nmi_watchdog() to something like touch_watchdog(), and therefore touching lots of files, makes it more unlikely that this resulting patch will get accepted. But implementing this bootup watchdog support in asm-ppc(asm-powerpc)/nmi.h header seems also not totally correct, since it's not really an NMI in this case. Indeed. Using the header file asm/nmi.h is seriously misleading for the PowerPC version, as is the function name touch_nmi_watchdog() - thius has nothing to do with NMIs on PowerPC, and most probably not on any other non-x86 architecture as well. To make this mechanism generally usable (which is a good idea IMO) the names should be changed to get rid of the nmi reference. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] It may be that your whole purpose in life is simply to serve as a warning to others. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PPC405GP Walnut irq patch
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
the ethernet interrupts in the walnut.dts file doesn't match the
documentation. I discovered this when porting the BSP to a custom board
- the ethernet would not work. The attached patch corrects that.
This is the first patch I am submitting, so please advise me if there is
anything I should do differently.
Signed-off-by: Steve Falco sfalco at harris.com
--- walnut.dts.orig 2007-10-30 15:27:49.0 -0400
+++ walnut.dts 2007-10-30 15:29:40.0 -0400
@@ -67,7 +67,7 @@
num-tx-chans = 2;
num-rx-chans = 1;
interrupt-parent = UIC0;
- interrupts = a 4 b 4 c 4 d 4 e 4;
+ interrupts = b 4 c 4 a 4 d 4 e 4;
};
POB0: opb {
@@ -117,7 +117,7 @@
device_type = network;
compatible = ibm,emac-405gp, ibm,emac;
interrupt-parent = UIC0;
-interrupts = 9 4 f 4;
+interrupts = f 4 9 4;
reg = ef600800 70;
mal-device = MAL;
mal-tx-channel = 0 1;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC405GP Walnut irq patch
I realized that I should have done this from the root level. So here is
the corrected patch.
Signed-off-by: Steve Falco sfalco at harris.com
Steven A. Falco wrote:
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
the ethernet interrupts in the walnut.dts file doesn't match the
documentation. I discovered this when porting the BSP to a custom
board - the ethernet would not work. The attached patch corrects that.
This is the first patch I am submitting, so please advise me if there
is anything I should do differently.
Signed-off-by: Steve Falco sfalco at harris.com
diff --git a/arch/powerpc/boot/dts/walnut.dts b/arch/powerpc/boot/dts/walnut.dts
index 27bef06..dd65115 100644
--- a/arch/powerpc/boot/dts/walnut.dts
+++ b/arch/powerpc/boot/dts/walnut.dts
@@ -67,7 +67,7 @@
num-tx-chans = 2;
num-rx-chans = 1;
interrupt-parent = UIC0;
- interrupts = a 4 b 4 c 4 d 4 e 4;
+ interrupts = b 4 c 4 a 4 d 4 e 4;
};
POB0: opb {
@@ -117,7 +117,7 @@
device_type = network;
compatible = ibm,emac-405gp, ibm,emac;
interrupt-parent = UIC0;
-interrupts = 9 4 f 4;
+interrupts = f 4 9 4;
reg = ef600800 70;
mal-device = MAL;
mal-tx-channel = 0 1;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [powerpc v2] update xmon slb code
[powerpc] update xmon slb code
This adds a bit more detail to the xmon SLB output. When the valid bit is
set, This displays the ESID and VSID values, as well as decoding the
segment size. (1T or 256M). This supresses the output for any slb entries
that contain only zeros.
sample output from power6 (1T segment support):
00 c800 40004f7ca3000500 1T ESID= c0 VSID=40004f7ca3 LLP
bits:100
01 d800 4000eb71b400 1T ESID= d0 VSID=4000eb71b0 LLP
bits: 0
03 0800 628021c6ac80 256M ESID=0 VSID= 628021c6a LLP
bits: 0
04 0f000800 400095c1e8000c80 1T ESID=f VSID=400095c1e8 LLP
bits: 0
22 cf000800 400011b26500 1T ESID= cf VSID=400011b260 LLP
bits:100
62 04000800 40005d488d000c80 1T ESID=4 VSID=40005d488d LLP
bits: 0
63 1800 633f90285c80 256M ESID=1 VSID= 633f90285 LLP
bits: 0
sample output from power5 (notice the non-valid but non-zero entries)
00 c800 408f92c94500 256M ESID=c VSID= 408f92c94 LLP
bits:100
01 d800 f09b89af5400 256M ESID=d VSID= f09b89af5 LLP
bits: 0
03 1000 136eafb0bc80
11 0800 5928811f2c80 256M ESID=0 VSID= 5928811f2 LLP
bits: 0
12 f800 645ff8d87c80 256M ESID=f VSID= 645ff8d87 LLP
bits: 0
13 4800 5c263aa5ec80 256M ESID=4 VSID= 5c263aa5e LLP
bits: 0
14 1800 59e7ef80dc80 256M ESID=1 VSID= 59e7ef80d LLP
bits: 0
15 1000 59e7ef80dc80
Tested on power5 and power6.
Signed-Off-By: Will Schmidt [EMAIL PROTECTED]
---
This version adds padding around the ESID and VSID fields, and the LLP bits
are displayed too. (Per request from Olof and Ben).
I'll try to follow up sometime later with code that will handle decoding page
sizes. I dont have a testcase handy to properly exercise that yet. :-)
---
arch/powerpc/xmon/xmon.c | 27 +--
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 121b04d..93c26c3 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2527,16 +2527,31 @@ static void xmon_print_symbol(unsigned long address,
const char *mid,
static void dump_slb(void)
{
int i;
- unsigned long tmp;
+ unsigned long esid,vsid,valid;
+ unsigned long llp_bits;
printf(SLB contents of cpu %x\n, smp_processor_id());
for (i = 0; i SLB_NUM_ENTRIES; i++) {
- asm volatile(slbmfee %0,%1 : =r (tmp) : r (i));
- printf(%02d %016lx , i, tmp);
-
- asm volatile(slbmfev %0,%1 : =r (tmp) : r (i));
- printf(%016lx\n, tmp);
+ asm volatile(slbmfee %0,%1 : =r (esid) : r (i));
+ asm volatile(slbmfev %0,%1 : =r (vsid) : r (i));
+ valid = (esid SLB_ESID_V);
+ if (valid | esid | vsid) {
+ printf(%02d %016lx %016lx, i, esid, vsid);
+ if (valid) {
+ llp_bits = vsid SLB_VSID_LLP;
+ if (vsid SLB_VSID_B_1T) {
+ printf( 1T ESID=%9lx VSID=%10lx LLP
bits:%3lx \n,
+ GET_ESID_1T(esid),vsid
SLB_VSID_SHIFT_1T,
+ llp_bits);
+ } else {
+ printf( 256M ESID=%9lx VSID=%10lx LLP
bits:%3lx \n,
+ GET_ESID(esid),vsid
SLB_VSID_SHIFT,
+ llp_bits);
+ }
+ } else
+ printf(\n);
+ }
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: add kexec support
On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote: Michael Ellerman [EMAIL PROTECTED] wrote on 28.10.2007 23:32:17: How do you plan to support kdump? When kexec is fully supported kdump should work out of the box as for any other ethernet card (if you load the right eth driver). There's nothing specific to kdump you have to handle in ethernet device drivers. Hope I didn't miss anything here... Perhaps. When we kdump the kernel does not call the reboot notifiers, so the code Jan-Bernd just added won't get called. So the eHEA resources won't be freed. When the kdump kernel tries to load the eHEA driver what will happen? cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
Explicitly specifying what device class bindings / conventions the
node complies with is cute, but not actually all that useful in
practice. If it looks like a duck class device node, and it
quacks^Whas the properties of a duck class device node, it's duck
class compliant.
Don't know how cute it is, but I think it is practically
helpful. Take another example:
Say you-- a human reader-- see this in a device
tree:
...
interrupts = b 8;
interrupt-parent = mpic ;
...
What does the 'b' and '8' mean? You look
at the interrupt controller node--
mpic: [EMAIL PROTECTED] {
clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 4 4;
compatible = fsl,xyz;
big-endian;
}
Note-- I removed the device_type property and changed
compatible somewhat. How are you going to find where
the meaning interrupt controller's interrupt cells are
defined? What spec will you look at?
device_type = open-pic; makes it perfectly clear.
It's an open-pic type controller and follows that
binding.
That's an extremely contrived example - it only works because for
historical reasons the open-pic device_type describes a programming
model as well as an OF method interface. In general, you always need
to look at a node's compatible and the binding for that to work out
what it's properties mean, or if it's an interrupt controller what the
format of its interrupt specifiers is.
open-pic is the *only* example I can think of where device_type will
tell you this. In fact, open-pic really belongs in compatible.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
On Tue, Oct 30, 2007 at 12:06:33PM -0700, Yoder Stuart-B08248 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, October 30, 2007 11:34 AM
To: Yoder Stuart-B08248
Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
Subject: Re: RFC: replace device_type with new class property?
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
mpic: [EMAIL PROTECTED] {
clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 4 4;
compatible = fsl,xyz;
big-endian;
}
Note-- I removed the device_type property and changed
compatible somewhat. How are you going to find where
the meaning interrupt controller's interrupt cells are
defined? What spec will you look at?
The binding for fsl,xyz.
Not every string listed in compatible has a spec
backing it (or should be required to). You would
have to go look at the source code and cross your
fingers that the comments were sufficient.
But that's true in general. open-pic is practically the only time
device_type will let you avoid that.
Another good reason for device_type-- it helps
distinguish between two similar classes of devices.
Both open-pic and isa-pic look very similar but
have different encodings of their interrupt cells.
Without a device_type it may be difficult or impossible
to distinguish them unless the name and
compatible are luckily clear enough.
This is a totally misleading argument. There may be one or two cases
where the device_type is useful, but in most cases device_type will be
either not specific enough to give you the information you need, or it
we add lots of new device_type values, it will be so specific that it
suffers the same problem as looking at name or compatible - you have
to find the finding that goes with a particular device_type.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
PowerPC 440GRx Rainier DTS.
[snip]
+ SDRAM0: sdram {
+ device_type = memory-controller;
How many times do we need to say it...
Don't make up random device_type values. This does not belong here.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
On Tue, Oct 30, 2007 at 07:56:33AM -0700, Yoder Stuart-B08248 wrote: [snip] Yeah.. what he said. The *only* substantive change with the class proposal is the fact that multiple classes can be specified. That's nice, but I don't think it's worth the trouble of attempting to define a whole new chunk of standard for. I tend to agree, but I think device_type serves a useful purpose. I don't think we should deprecate it. Stuart, I think you overestimate the value of this class property to a human reader. The generic names convention (not followed as much as it should be) means the name should give the reader some idea of what the device is, in most cases. For trickier cases, if we really want something for humans reading the tree, we could add an optional comment or description property with purely human readable information. I think we should leave existing IEEE1275 defined uses of device_type, in order not to make flat trees gratuitously different from real-OF trees, but we should avoid any new use of device_type. I'm fine with keeping device_type, but there are a few of things I don't like about the 'no new use'. 1. There are types of nodes that don't have a programming inteface per se and thus no compatible. cpu, memory, cache are 3 that come to mind. Well, yes, this is why I suggested treating these fundamental nodes as a special case in an earlier mail. What if there is a _new_ class of nodes of this type? What is wrong with a new use of device_type for something say like i2c? Memory and cpu are pretty clearly special cases - if they're not there, you don't have a computer at all. The programming model for memory is always the same, and the programming model for the cpu has to be known before reading the device tree anyway. I don't think we need to worry about new classes of such things - i2c is *certainly* not an example of such. cache is a bit weird, because although there can be different types, the programming model is essentially determined by the cpu to which it is attached, and the nodes for cache are really just to give details of sizes and levels. Conceptually and ideally, what _is_ the right way to represent these types of devices. 2. 'Existing IEEE1275 defined uses' of device_type is actually very vague. There are a conglomeration of old bindings, recommended practices, proposals and it is not clear at all which are useful or not. What are the existing IEEE1275 uses??? I actually went through all the OF documents and there are dozens of device types that have no practical use. Also, many 'real-OF' trees seem to follow no published binding at all. Conceptually, I'd like to a crisp list of 'official' bindings and hope that the current ePAPR work in power.org will establish this list. Yeah, sorry, I am being a bit vauge here and we do need to be more specific. My point is that if you take a tree from a real OF, with lots of device_type values representing programming interfaces, then flatten it, it shouldn't be considered bad as a flattened tree. It's fine if most or all of the device_type values are optional in the flattened tree, so that it's ok whether or not they're present. 3. You're advocating deprecating device_class, but still requiring it for certain node types. So a network node is _required_ to have the deprecated device_type=network. But a i2c node is required _not_ to have device_type. Long term, I'd like to see any inconsitency be removed. If device_type is deprecated, it's use should be optional in flat device trees. That goes for cpu, memory, etc. I think what we should do is keep device_type, including permitting new uses of it in a limited way-- only permitting the use of device_type when there is an official binding (like in the power.org ePAPR) defined. That's what I was thinking when we first started defining flat tree bindings. But the more time I've spent thinking about it, and the more time I've spent reviewing people's proposed bindings, the less useful I think it is. The *only* reason I'm suggesting leaving device_type values for IEEE1275 defined classes is so that flat trees written as flat trees look more similar to OF derived trees. Explicitly specifying what device class bindings / conventions the node complies with is cute, but not actually all that useful in practice. If it looks like a duck class device node, and it quacks^Whas the properties of a duck class device node, it's duck class compliant. Or to look at it another way, class bindings aren't really bindings, but rather a set of conventions that device bindings for specific devices in that class ought to follow. I tend to think of a 'binding' as a 'set of conventions'. Well, whatever. My point is that conventions are most flexible if you don't have to
Re: libfdt as its own repo and submodule of dtc?
On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote: Jon Loeliger wrote: So, like, the other day Kumar Gala mumbled: Jon, It seems like have libfdt as a unique git repo that is a submodule of the things that need it (dtc, u-boot, etc.) might make some sense and it easier for the projects that need to pull it in. Is this something you can take a look at? (or have other ideas on). I would be fine with making libfdt a git repository separate from the DTC repository if that makes it easier to integrate it with other projects. I don't think it's a good idea to make dtc and libfdt entirely seperate repositories (again). Being able to use both together in their combined testsuite is very useful (libfdt is used to check trees generated by dtc, dtc is used to generate example trees for libfdt testing). I'm not sure how submodules/subrepositories work so I don't know if that makes sense. That sounds like a good idea to me. I would really prefer pulling patches out of a libfdt repo into the u-boot repo rather than trying to kerchunk upgrade lumps. While we can do this with a dtc repo, it potentially makes it a lot more difficult. I don't think upgrading embedded copies by diff is a good way to go. The upgrade method I had in mind was to pull out a whole new copy of libfdt, drop that into the embedding project verbatim and generate a new diff there in whatever their source tracking system is. I set out the repository to make this easy. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [powerpc v2] update xmon slb code
On Tue, Oct 30, 2007 at 04:50:39PM -0500, Will Schmidt wrote: [powerpc] update xmon slb code This adds a bit more detail to the xmon SLB output. When the valid bit is set, This displays the ESID and VSID values, as well as decoding the segment size. (1T or 256M). This supresses the output for any slb entries that contain only zeros. sample output from power6 (1T segment support): 00 c800 40004f7ca3000500 1T ESID= c0 VSID=40004f7ca3 LLP bits:100 01 d800 4000eb71b400 1T ESID= d0 VSID=4000eb71b0 LLP bits: 0 03 0800 628021c6ac80 256M ESID=0 VSID= 628021c6a LLP bits: 0 04 0f000800 400095c1e8000c80 1T ESID=f VSID=400095c1e8 LLP bits: 0 22 cf000800 400011b26500 1T ESID= cf VSID=400011b260 LLP bits:100 62 04000800 40005d488d000c80 1T ESID=4 VSID=40005d488d LLP bits: 0 63 1800 633f90285c80 256M ESID=1 VSID= 633f90285 LLP bits: 0 sample output from power5 (notice the non-valid but non-zero entries) 00 c800 408f92c94500 256M ESID=c VSID= 408f92c94 LLP bits:100 01 d800 f09b89af5400 256M ESID=d VSID= f09b89af5 LLP bits: 0 03 1000 136eafb0bc80 11 0800 5928811f2c80 256M ESID=0 VSID= 5928811f2 LLP bits: 0 12 f800 645ff8d87c80 256M ESID=f VSID= 645ff8d87 LLP bits: 0 13 4800 5c263aa5ec80 256M ESID=4 VSID= 5c263aa5e LLP bits: 0 14 1800 59e7ef80dc80 256M ESID=1 VSID= 59e7ef80d LLP bits: 0 15 1000 59e7ef80dc80 Tested on power5 and power6. Signed-Off-By: Will Schmidt [EMAIL PROTECTED] Acked-by: Olof Johansson [EMAIL PROTECTED] This makes the output wider than 80 characters, but that's fine with me. Thanks! -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [Powerpc V2.1] fix switch_slb handling of 1T ESID values
On Tue, 2007-10-30 at 13:59 -0500, Will Schmidt wrote:
[Powerpc] fix switch_slb handling of 1T ESID values
Now that we have 1TB segment size support, we need to be using the
GET_ESID_1T macro when comparing ESID values for pc,stack, and
unmapped_base within switch_slb().A new helper function called
esids_match() contains the logic for deciding when to call GET_ESID
and GET_ESID_1T.
This also happens to fix a duplicate-slb-entry inspired machine-check
exception I was seeing when trying to run java on a power6 partition.
Tested on power6 and power5.
Signed-Off-By: Will Schmidt [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
---
Just a bit of whitespace cosmetic touchup in this version, as suggested
by Stephen Rothwell.
---
arch/powerpc/mm/slb.c | 34 +++---
1 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index bbd2c51..8cbbfab 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -148,6 +148,35 @@ void slb_vmalloc_update(void)
slb_flush_and_rebolt();
}
+/* Helper function to compare esids. There are four cases to handle.
+ * 1. The system is not 1T segment size capable. Use the GET_ESID compare.
+ * 2. The system is 1T capable, both addresses are 1T, use the GET_ESID
compare.
+ * 3. The system is 1T capable, only one of the two addresses is 1T. This
is not a match.
+ * 4. The system is 1T capable, both addresses are 1T, use the GET_ESID_1T
macro to compare.
+ */
+static inline int esids_match(unsigned long addr1, unsigned long addr2)
+{
+ int esid_1t_count;
+
+ /* System is not 1T segment size capable. */
+ if (!cpu_has_feature(CPU_FTR_1T_SEGMENT))
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ esid_1t_count = (((addr1 SID_SHIFT_1T) != 0) +
+ ((addr2 SID_SHIFT_1T) != 0));
+
+ /* both addresses are 1T */
+ if (esid_1t_count == 0)
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ /* One address 1T, the other 1T. Not a match */
+ if (esid_1t_count == 1)
+ return 0;
+
+ /* Both addresses are 1T. */
+ return (GET_ESID_1T(addr1) == GET_ESID_1T(addr2));
+}
+
/* Flush all user entries from the segment table of the current processor. */
void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
{
@@ -193,15 +222,14 @@ void switch_slb(struct task_struct *tsk, struct
mm_struct *mm)
return;
slb_allocate(pc);
- if (GET_ESID(pc) == GET_ESID(stack))
+ if (esids_match(pc,stack))
return;
if (is_kernel_addr(stack))
return;
slb_allocate(stack);
- if ((GET_ESID(pc) == GET_ESID(unmapped_base))
- || (GET_ESID(stack) == GET_ESID(unmapped_base)))
+ if (esids_match(pc,unmapped_base) || esids_match(stack,unmapped_base))
return;
if (is_kernel_addr(unmapped_base))
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [powerpc v2] update xmon slb code
On Tue, 2007-10-30 at 16:50 -0500, Will Schmidt wrote:
[powerpc] update xmon slb code
This adds a bit more detail to the xmon SLB output. When the valid bit is
set, This displays the ESID and VSID values, as well as decoding the
segment size. (1T or 256M). This supresses the output for any slb entries
that contain only zeros.
sample output from power6 (1T segment support):
.../
Tested on power5 and power6.
Signed-Off-By: Will Schmidt [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
This version adds padding around the ESID and VSID fields, and the LLP bits
are displayed too. (Per request from Olof and Ben).
I'll try to follow up sometime later with code that will handle decoding page
sizes. I dont have a testcase handy to properly exercise that yet. :-)
---
arch/powerpc/xmon/xmon.c | 27 +--
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 121b04d..93c26c3 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2527,16 +2527,31 @@ static void xmon_print_symbol(unsigned long address,
const char *mid,
static void dump_slb(void)
{
int i;
- unsigned long tmp;
+ unsigned long esid,vsid,valid;
+ unsigned long llp_bits;
printf(SLB contents of cpu %x\n, smp_processor_id());
for (i = 0; i SLB_NUM_ENTRIES; i++) {
- asm volatile(slbmfee %0,%1 : =r (tmp) : r (i));
- printf(%02d %016lx , i, tmp);
-
- asm volatile(slbmfev %0,%1 : =r (tmp) : r (i));
- printf(%016lx\n, tmp);
+ asm volatile(slbmfee %0,%1 : =r (esid) : r (i));
+ asm volatile(slbmfev %0,%1 : =r (vsid) : r (i));
+ valid = (esid SLB_ESID_V);
+ if (valid | esid | vsid) {
+ printf(%02d %016lx %016lx, i, esid, vsid);
+ if (valid) {
+ llp_bits = vsid SLB_VSID_LLP;
+ if (vsid SLB_VSID_B_1T) {
+ printf( 1T ESID=%9lx VSID=%10lx LLP
bits:%3lx \n,
+ GET_ESID_1T(esid),vsid
SLB_VSID_SHIFT_1T,
+ llp_bits);
+ } else {
+ printf( 256M ESID=%9lx VSID=%10lx LLP
bits:%3lx \n,
+ GET_ESID(esid),vsid
SLB_VSID_SHIFT,
+ llp_bits);
+ }
+ } else
+ printf(\n);
+ }
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [powerpc v2] update xmon slb code
Will Schmidt writes: This adds a bit more detail to the xmon SLB output. When the valid bit is set, This displays the ESID and VSID values, as well as decoding the segment size. (1T or 256M). This supresses the output for any slb entries that contain only zeros. sample output from power6 (1T segment support): 00 c800 40004f7ca3000500 1T ESID= c0 VSID=40004f7ca3 LLP bits:100 The 4 at the top of the VSID is actually the B (segment size) field, isn't it? Shouldn't that get masked off, since you have already printed the segment size separately? Also, if you removed the bits text, it would just about fit into 80 columns. I think LLP is sufficient, the bits is redundant. Apart from that it looks good. Regards, Paul, ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC405GP Walnut irq patch
On Tue, 30 Oct 2007 17:41:27 -0400
Steven A. Falco [EMAIL PROTECTED] wrote:
From: Steven A. Falco [EMAIL PROTECTED]
To: linuxppc-dev@ozlabs.org
Subject: Re: PPC405GP Walnut irq patch
Date: Tue, 30 Oct 2007 17:41:27 -0400
Sender: [EMAIL PROTECTED]
User-Agent: Thunderbird 2.0.0.5 (X11/20070719)
I realized that I should have done this from the root level. So here is
the corrected patch.
Signed-off-by: Steve Falco sfalco at harris.com
Steven A. Falco wrote:
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
the ethernet interrupts in the walnut.dts file doesn't match the
documentation. I discovered this when porting the BSP to a custom
board - the ethernet would not work. The attached patch corrects that.
This is the first patch I am submitting, so please advise me if there
is anything I should do differently.
Signed-off-by: Steve Falco sfalco at harris.com
diff --git a/arch/powerpc/boot/dts/walnut.dts
b/arch/powerpc/boot/dts/walnut.dts
index 27bef06..dd65115 100644
--- a/arch/powerpc/boot/dts/walnut.dts
+++ b/arch/powerpc/boot/dts/walnut.dts
@@ -67,7 +67,7 @@
num-tx-chans = 2;
num-rx-chans = 1;
interrupt-parent = UIC0;
- interrupts = a 4 b 4 c 4 d 4 e 4;
+ interrupts = b 4 c 4 a 4 d 4 e 4;
};
I fixed this part already. Seems your tree is slightly old.
POB0: opb {
@@ -117,7 +117,7 @@
device_type = network;
compatible = ibm,emac-405gp, ibm,emac;
interrupt-parent = UIC0;
- interrupts = 9 4 f 4;
+ interrupts = f 4 9 4;
Could you redo the patch with just this bit and send it again?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
On Tue, 30 Oct 2007 20:56:51 -0500
Olof Johansson [EMAIL PROTECTED] wrote:
On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
PowerPC 440GRx Rainier DTS.
[snip]
+ SDRAM0: sdram {
+ device_type = memory-controller;
How many times do we need to say it...
Don't make up random device_type values. This does not belong here.
Maybe there should be something like checkpatch.pl that warns about
these kinds of things so people can check for it without getting flamed
first. :-)
That's actually a decent idea. We could even have this thing that
takes DTS files and processes them... oh wait.
So why can't we make a whitelist of allowed device_types in DTC and
make it whine about anything outside of that?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt as its own repo and submodule of dtc?
Jon Loeliger wrote: So, like, the other day Kumar Gala mumbled: Jon, It seems like have libfdt as a unique git repo that is a submodule of the things that need it (dtc, u-boot, etc.) might make some sense and it easier for the projects that need to pull it in. Is this something you can take a look at? (or have other ideas on). I would be fine with making libfdt a git repository separate from the DTC repository if that makes it easier to integrate it with other projects. jdl That sounds like a good idea to me. I would really prefer pulling patches out of a libfdt repo into the u-boot repo rather than trying to kerchunk upgrade lumps. While we can do this with a dtc repo, it potentially makes it a lot more difficult. gvb ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
On Tue, Oct 30, 2007 at 09:09:17PM -0500, Josh Boyer wrote:
On Tue, 30 Oct 2007 20:56:51 -0500
Olof Johansson [EMAIL PROTECTED] wrote:
On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
PowerPC 440GRx Rainier DTS.
[snip]
+ SDRAM0: sdram {
+ device_type = memory-controller;
How many times do we need to say it...
Don't make up random device_type values. This does not belong here.
Maybe there should be something like checkpatch.pl that warns about
these kinds of things so people can check for it without getting flamed
first. :-)
I'd be gentler; except that I know Valentine has been active on this
list recently, so has almost certainly seen similar comments before.
That's actually a decent idea. We could even have this thing that
takes DTS files and processes them... oh wait.
So why can't we make a whitelist of allowed device_types in DTC and
make it whine about anything outside of that?
Well, that sort of thing is the idea for dtc to check, when it has
checks enabled anyway. Getting it so that it doesn't have too many
false positives is the tricky bit, as we've seen with some of the
existing checks (where too many is almost any).
Patches welcome...
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[0/2] Embed a copy of dtc in the kernel source
These two patches are a respin of my previous patch to merge a copy of dtc into the kernel tree, so that kernel builds no longer depend on an externally installed copy of dtc. This respin embeds a newer revision of dtc, and incorporates Sam Ravnborg's preferred approach to Makefile integration. Also, since so many people whinged about it last time, I've split the patch into two parts, the first is the too-large-for-the-list patch just verbatim adding files and the second has the changes to existing kernel files to build and use the embedded code. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] PowerPC: 440GRx Rainier board support.
On Tue, 30 Oct 2007 19:57:39 +0300 Valentine Barshak [EMAIL PROTECTED] wrote: +++ linux-2.6/arch/powerpc/platforms/44x/rainier.c2007-10-30 18:00:15.0 +0300 +#include linux/init.h +#include asm/machdep.h +#include asm/prom.h +#include asm/udbg.h +#include asm/time.h +#include asm/uic.h +#include asm/of_platform.h You want linux/of_platform.h -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpLSdUhmE65u.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [0/2] Embed a copy of dtc in the kernel source
On Oct 30, 2007, at 10:24 PM, David Gibson wrote: These two patches are a respin of my previous patch to merge a copy of dtc into the kernel tree, so that kernel builds no longer depend on an externally installed copy of dtc. This respin embeds a newer revision of dtc, and incorporates Sam Ravnborg's preferred approach to Makefile integration. Also, since so many people whinged about it last time, I've split the patch into two parts, the first is the too-large-for-the-list patch just verbatim adding files and the second has the changes to existing kernel files to build and use the embedded code. What about doing part of this via git-submodule? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [0/2] Embed a copy of dtc in the kernel source
On Tue, Oct 30, 2007 at 11:37:15PM -0500, Kumar Gala wrote: On Oct 30, 2007, at 10:24 PM, David Gibson wrote: These two patches are a respin of my previous patch to merge a copy of dtc into the kernel tree, so that kernel builds no longer depend on an externally installed copy of dtc. This respin embeds a newer revision of dtc, and incorporates Sam Ravnborg's preferred approach to Makefile integration. Also, since so many people whinged about it last time, I've split the patch into two parts, the first is the too-large-for-the-list patch just verbatim adding files and the second has the changes to existing kernel files to build and use the embedded code. What about doing part of this via git-submodule? Uh.. where do I find out what that does? My version of git (Ubuntu gutsy) doesn't seem to know anything about it... -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ring on PowerPC
On 10/30/07, Bai Shuwei [EMAIL PROTECTED] wrote: Hi, everyone As we know, the program on the X86 can run on the differnt ring(0, 1, 2, 3) and the linux kernel run in the ring 0 and user program in the ring 3. And now I want to know wether there is a simple mechanism on the PowerPC architecture? thx all! Powerpc has 2 privilege levels; user and supervisor. The kernel runs in supervisor mode, and user-space runs in user mode. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ring on PowerPC
Hi, everyone As we know, the program on the X86 can run on the differnt ring(0, 1, 2, 3) and the linux kernel run in the ring 0 and user program in the ring 3. And now I want to know wether there is a simple mechanism on the PowerPC architecture? thx all! best regards! Buroc -- Add: Tianshui South Road 222, Lanzhou, P.R.China Tel: +86-931-8912025 Zip Code: 73 URL: oss.lzu.edu.cn Email: [EMAIL PROTECTED], [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ring on PowerPC
On Tue, 2007-10-30 at 23:18 -0600, Grant Likely wrote: On 10/30/07, Bai Shuwei [EMAIL PROTECTED] wrote: Hi, everyone As we know, the program on the X86 can run on the differnt ring(0, 1, 2, 3) and the linux kernel run in the ring 0 and user program in the ring 3. And now I want to know wether there is a simple mechanism on the PowerPC architecture? thx all! Powerpc has 2 privilege levels; user and supervisor. The kernel runs in supervisor mode, and user-space runs in user mode. To be complete here, some implementations have 3 :-) Don't forget hypervisor mode ! Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
On Wed, 31 Oct 2007 14:28:46 +0900 KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote: ioresource was good structure for remembering which memory is conventional memory and i386/x86_64/ia64 registered conventional memory as System RAM, when I posted patch. (just say System Ram is not for memory hotplug.) If I remember correctly, System RAM is for kdump (to know which memory should be dumped.) Then, memory-hotadd/remove has to modify it anyway. Thanks, -Kame ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] [POWERPC] Fix region size check in mpc5200 FEC driver
From: Grant Likely [EMAIL PROTECTED]
Driver shouldn't complain if the register range is larger than what
it expects. This works around failures with some device trees.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
drivers/net/fec_mpc52xx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index fc1cf0b..a8a0ee2 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -879,9 +879,9 @@ mpc52xx_fec_probe(struct of_device *op, const struct
of_device_id *match)
Error while parsing device node resource\n );
return rv;
}
- if ((mem.end - mem.start + 1) != sizeof(struct mpc52xx_fec)) {
+ if ((mem.end - mem.start + 1) sizeof(struct mpc52xx_fec)) {
printk(KERN_ERR DRIVER_NAME
-- invalid resource size (%lx != %x), check
mpc52xx_devices.c\n,
+- invalid resource size (%lx %x), check
mpc52xx_devices.c\n,
(unsigned long)(mem.end - mem.start + 1), sizeof(struct
mpc52xx_fec));
return -EINVAL;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] [POWERPC] mpc5200: Fix Kconfig dependancies on MPC5200 FEC device driver
From: Grant Likely [EMAIL PROTECTED] When not building an arch/powerpc kernel, the mpc5200 FEC driver depends on some symbols which are not defined (BESTCOMM BESTCOMM_FEC). This patch flips around the dependancy logic so that it cannot be selected unless BESTCOMM_FEC is selected first. Kconfig stops complaining this way. Also, the driver only works for arch/powerpc (not arch/ppc) anyway so it should depend on PPC_MERGE also. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- drivers/net/Kconfig |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 867cb73..5f800a6 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1883,9 +1883,7 @@ config FEC2 config FEC_MPC52xx tristate MPC52xx FEC driver - depends on PPC_MPC52xx - select PPC_BESTCOMM - select PPC_BESTCOMM_FEC + depends on PPC_MERGE PPC_MPC52xx PPC_BESTCOMM_FEC select CRC32 select PHYLIB ---help--- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] ppc405 Fix arithmatic rollover bug when memory size under 16M
From: Grant Likely [EMAIL PROTECTED]
mmu_mapin_ram() loops over total_lowmem to setup page tables. However, if
total_lowmem is less that 16M, the subtraction rolls over and results in
a number just under 4G (because total_lowmem is an unsigned value).
This patch rejigs the loop from countup to countdown to eliminate the
bug.
Special thanks to Magnus Hjorth who wrote the original patch to fix this
bug. This patch improves on his by making the loop code simpler (which
also eliminates the possibility of another rollover at the high end)
and also applies the change to arch/powerpc.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
Josh, I've tested this change on arch/ppc, but not arch/powerpc. The
ppc and powerpc code are darn near identical so it should be correct,
but you might want to boot a kernel before you push it to Paulus
anyway.
Cheers,
g.
arch/powerpc/mm/40x_mmu.c | 17 -
arch/ppc/mm/4xx_mmu.c | 17 -
2 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/mm/40x_mmu.c b/arch/powerpc/mm/40x_mmu.c
index e067df8..3899ea9 100644
--- a/arch/powerpc/mm/40x_mmu.c
+++ b/arch/powerpc/mm/40x_mmu.c
@@ -98,13 +98,12 @@ unsigned long __init mmu_mapin_ram(void)
v = KERNELBASE;
p = PPC_MEMSTART;
- s = 0;
+ s = total_lowmem;
- if (__map_without_ltlbs) {
- return s;
- }
+ if (__map_without_ltlbs)
+ return 0;
- while (s = (total_lowmem - LARGE_PAGE_SIZE_16M)) {
+ while (s = LARGE_PAGE_SIZE_16M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC |
_PAGE_HWWRITE;
@@ -116,10 +115,10 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_16M;
p += LARGE_PAGE_SIZE_16M;
- s += LARGE_PAGE_SIZE_16M;
+ s -= LARGE_PAGE_SIZE_16M;
}
- while (s = (total_lowmem - LARGE_PAGE_SIZE_4M)) {
+ while (s = LARGE_PAGE_SIZE_4M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC |
_PAGE_HWWRITE;
@@ -128,8 +127,8 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_4M;
p += LARGE_PAGE_SIZE_4M;
- s += LARGE_PAGE_SIZE_4M;
+ s -= LARGE_PAGE_SIZE_4M;
}
- return s;
+ return total_lowmem - s;
}
diff --git a/arch/ppc/mm/4xx_mmu.c b/arch/ppc/mm/4xx_mmu.c
index 838e09d..ea785db 100644
--- a/arch/ppc/mm/4xx_mmu.c
+++ b/arch/ppc/mm/4xx_mmu.c
@@ -99,13 +99,12 @@ unsigned long __init mmu_mapin_ram(void)
v = KERNELBASE;
p = PPC_MEMSTART;
- s = 0;
+ s = total_lowmem;
- if (__map_without_ltlbs) {
- return s;
- }
+ if (__map_without_ltlbs)
+ return 0;
- while (s = (total_lowmem - LARGE_PAGE_SIZE_16M)) {
+ while (s = LARGE_PAGE_SIZE_16M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC |
_PAGE_HWWRITE;
@@ -117,10 +116,10 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_16M;
p += LARGE_PAGE_SIZE_16M;
- s += LARGE_PAGE_SIZE_16M;
+ s -= LARGE_PAGE_SIZE_16M;
}
- while (s = (total_lowmem - LARGE_PAGE_SIZE_4M)) {
+ while (s = LARGE_PAGE_SIZE_4M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC |
_PAGE_HWWRITE;
@@ -129,8 +128,8 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_4M;
p += LARGE_PAGE_SIZE_4M;
- s += LARGE_PAGE_SIZE_4M;
+ s -= LARGE_PAGE_SIZE_4M;
}
- return s;
+ return total_lowmem - s;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
