[PATCH 1/4] powerpc: Rename exception.h to exception-64s.h
The file include/asm/exception.h contains definitions
that are specific to exception handling on 64-bit server
type processors.
This renames the file to exception-64s.h to reflect that
fact and avoid confusion.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/exception-64s.h | 279 +
arch/powerpc/include/asm/exception.h | 279 -
arch/powerpc/kernel/exceptions-64s.S |2
arch/powerpc/kernel/head_64.S |1
arch/powerpc/platforms/iseries/exception.h |2
5 files changed, 282 insertions(+), 281 deletions(-)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-work/arch/powerpc/include/asm/exception-64s.h 2009-07-10
11:22:59.0 +1000
@@ -0,0 +1,279 @@
+#ifndef _ASM_POWERPC_EXCEPTION_H
+#define _ASM_POWERPC_EXCEPTION_H
+/*
+ * Extracted from head_64.S
+ *
+ * PowerPC version
+ *Copyright (C) 1995-1996 Gary Thomas (g...@linuxppc.org)
+ *
+ * Rewritten by Cort Dougan (c...@cs.nmt.edu) for PReP
+ *Copyright (C) 1996 Cort Dougan c...@cs.nmt.edu
+ * Adapted for Power Macintosh by Paul Mackerras.
+ * Low-level exception handlers and MMU support
+ * rewritten by Paul Mackerras.
+ *Copyright (C) 1996 Paul Mackerras.
+ *
+ * Adapted for 64bit PowerPC by Dave Engebretsen, Peter Bergner, and
+ *Mike Corrigan {engebret|bergner|mike...@us.ibm.com
+ *
+ * This file contains the low-level support and setup for the
+ * PowerPC-64 platform, including trap and interrupt dispatch.
+ *
+ * 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.
+ */
+/*
+ * The following macros define the code that appears as
+ * the prologue to each of the exception handlers. They
+ * are split into two parts to allow a single kernel binary
+ * to be used for pSeries and iSeries.
+ *
+ * We make as much of the exception code common between native
+ * exception handlers (including pSeries LPAR) and iSeries LPAR
+ * implementations as possible.
+ */
+
+#define EX_R9 0
+#define EX_R10 8
+#define EX_R11 16
+#define EX_R12 24
+#define EX_R13 32
+#define EX_SRR040
+#define EX_DAR 48
+#define EX_DSISR 56
+#define EX_CCR 60
+#define EX_R3 64
+#define EX_LR 72
+
+/*
+ * We're short on space and time in the exception prolog, so we can't
+ * use the normal SET_REG_IMMEDIATE macro. Normally we just need the
+ * low halfword of the address, but for Kdump we need the whole low
+ * word.
+ */
+#define LOAD_HANDLER(reg, label) \
+ addireg,reg,(label)-_stext; /* virt addr of handler ... */
+
+#define EXCEPTION_PROLOG_1(area) \
+ mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \
+ std r9,area+EX_R9(r13); /* save r9 - r12 */ \
+ std r10,area+EX_R10(r13); \
+ std r11,area+EX_R11(r13); \
+ std r12,area+EX_R12(r13); \
+ mfspr r9,SPRN_SPRG1; \
+ std r9,area+EX_R13(r13);\
+ mfcrr9
+
+#define EXCEPTION_PROLOG_PSERIES(area, label) \
+ EXCEPTION_PROLOG_1(area); \
+ ld r12,PACAKBASE(r13); /* get high part of label */ \
+ ld r10,PACAKMSR(r13); /* get MSR value for kernel */ \
+ mfspr r11,SPRN_SRR0; /* save SRR0 */ \
+ LOAD_HANDLER(r12,label) \
+ mtspr SPRN_SRR0,r12; \
+ mfspr r12,SPRN_SRR1; /* and SRR1 */ \
+ mtspr SPRN_SRR1,r10; \
+ rfid; \
+ b . /* prevent speculative execution */
+
+/*
+ * The common exception prolog is used for all except a few exceptions
+ * such as a segment miss on a kernel address. We have to be prepared
+ * to take another exception from the point where we first touch the
+ * kernel stack onwards.
+ *
+ * On entry r13 points to the paca, r9-r13 are saved in the paca,
+ * r9 contains the saved CR, r11 and r12 contain the saved SRR0 and
+ * SRR1, and relocation is on.
+ */
+#define EXCEPTION_PROLOG_COMMON(n, area) \
+ andi. r10,r12,MSR_PR; /* See if coming from user */ \
+ mr r10,r1; /* Save r1 */ \
+ subi
[PATCH 2/4] powerpc: Use names rather than numbers for SPRGs (v2)
The kernel uses SPRG registers for various purposes, typically in low level assembly code as scratch registers or to hold per-cpu global infos such as the PACA or the current thread_info pointer. We want to be able to easily shuffle the usage of those registers as some implementations have specific constraints realted to some of them, for example, some have userspace readable aliases, etc.. and the current choice isn't always the best. This patch should not change any code generation, and replaces the usage of SPRN_SPRGn everywhere in the kernel with a named replacement and adds documentation next to the definition of the names as to what those are used for on each processor family. The only parts that still use the original numbers are bits of KVM or suspend/resume code that just blindly needs to save/restore all the SPRGs. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org -- v2. Missed some iseries bits arch/powerpc/include/asm/exception-64s.h | 18 ++-- arch/powerpc/include/asm/reg.h | 113 ++ arch/powerpc/kernel/cpu_setup_6xx.S|2 arch/powerpc/kernel/entry_32.S | 20 ++-- arch/powerpc/kernel/entry_64.S |4 arch/powerpc/kernel/exceptions-64s.S | 44 +++--- arch/powerpc/kernel/fpu.S |2 arch/powerpc/kernel/head_32.S | 40 - arch/powerpc/kernel/head_40x.S | 124 ++--- arch/powerpc/kernel/head_44x.S | 56 ++--- arch/powerpc/kernel/head_64.S | 14 +-- arch/powerpc/kernel/head_8xx.S | 13 +-- arch/powerpc/kernel/head_booke.h | 50 --- arch/powerpc/kernel/head_fsl_booke.S | 60 +++--- arch/powerpc/kernel/setup_64.c |4 arch/powerpc/kernel/vector.S |2 arch/powerpc/kvm/booke_interrupts.S| 18 ++-- arch/powerpc/mm/hash_low_32.S |4 arch/powerpc/platforms/iseries/exception.S | 28 +++--- arch/powerpc/platforms/iseries/exception.h |4 20 files changed, 356 insertions(+), 264 deletions(-) --- linux-work.orig/arch/powerpc/include/asm/reg.h 2009-07-13 10:54:38.0 +1000 +++ linux-work/arch/powerpc/include/asm/reg.h 2009-07-15 15:08:10.0 +1000 @@ -646,6 +646,119 @@ #endif /* + * SPRG usage: + * + * All 64-bit: + * - SPRG3 stores PACA pointer + * + * 64-bit server: + * - SPRG0 unused (reserved for HV on Power4) + * - SPRG1 scratch for exception vectors + * - SPRG2 scratch for exception vectors + * + * All 32-bit: + * - SPRG3 current thread_info pointer + *(virtual on BookE, physical on others) + * + * 32-bit classic: + * - SPRG0 scratch for exception vectors + * - SPRG1 scratch for exception vectors + * - SPRG2 indicator that we are in RTAS + * - SPRG4 (603 only) pseudo TLB LRU data + * + * 32-bit 40x: + * - SPRG0 scratch for exception vectors + * - SPRG1 scratch for exception vectors + * - SPRG2 scratch for exception vectors + * - SPRG4 scratch for exception vectors (not 403) + * - SPRG5 scratch for exception vectors (not 403) + * - SPRG6 scratch for exception vectors (not 403) + * - SPRG7 scratch for exception vectors (not 403) + * + * 32-bit 440 and FSL BookE: + * - SPRG0 scratch for exception vectors + * - SPRG1 scratch for exception vectors (*) + * - SPRG2 scratch for crit interrupts handler + * - SPRG4 scratch for exception vectors + * - SPRG5 scratch for exception vectors + * - SPRG6 scratch for machine check handler + * - SPRG7 scratch for exception vectors + * - SPRG9 scratch for debug vectors (e500 only) + * + * Additionally, BookE separates read and write + * of those registers. That allows to use the userspace + * readable variant for reads, which can avoid a fault + * with KVM type virtualization. + * + * (*) Under KVM, the host SPRG1 is used to point to + * the current VCPU data structure + * + * 32-bit 8xx: + * - SPRG0 scratch for exception vectors + * - SPRG1 scratch for exception vectors + * - SPRG2 apparently unused but initialized + * + */ +#ifdef CONFIG_PPC64 +#define SPRN_SPRG_PACA SPRN_SPRG3 +#else +#define SPRN_SPRG_THREAD SPRN_SPRG3 +#endif + +#ifdef CONFIG_PPC_BOOK3S_64 +#define SPRN_SPRG_SCRATCH0 SPRN_SPRG1 +#define SPRN_SPRG_SCRATCH1 SPRN_SPRG2 +#endif + +#ifdef CONFIG_PPC_BOOK3S_32 +#define SPRN_SPRG_SCRATCH0 SPRN_SPRG0 +#define SPRN_SPRG_SCRATCH1 SPRN_SPRG1 +#define SPRN_SPRG_RTAS SPRN_SPRG2 +#define SPRN_SPRG_603_LRU SPRN_SPRG4 +#endif + +#ifdef CONFIG_40x +#define SPRN_SPRG_SCRATCH0 SPRN_SPRG0 +#define SPRN_SPRG_SCRATCH1 SPRN_SPRG1 +#define SPRN_SPRG_SCRATCH2 SPRN_SPRG2 +#define SPRN_SPRG_SCRATCH3 SPRN_SPRG4 +#define SPRN_SPRG_SCRATCH4 SPRN_SPRG5 +#define SPRN_SPRG_SCRATCH5 SPRN_SPRG6
[PATCH 3/4] powerpc: Remove use of a second scratch SPRG in STAB code
The STAB code used on Power3 and RS/64 uses a second scratch SPRG to save a GPR in order to decide whether to go to do_stab_bolted_* or to handle a normal data access exception. This prevents our scheme of freeing SPRG3 which is user visible for user uses since we cannot use SPRG0 which, on RS/64, seems to be read-only for supervisor mode (like POWER4). This reworks the STAB exception entry to use the PACA as temporary storage instead. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- arch/powerpc/include/asm/exception-64s.h |7 - arch/powerpc/include/asm/reg.h |3 -- arch/powerpc/kernel/exceptions-64s.S | 36 ++--- arch/powerpc/platforms/iseries/exception.S | 34 --- 4 files changed, 50 insertions(+), 30 deletions(-) --- linux-work.orig/arch/powerpc/include/asm/exception-64s.h2009-07-15 15:07:50.0 +1000 +++ linux-work/arch/powerpc/include/asm/exception-64s.h 2009-07-15 15:15:36.0 +1000 @@ -66,8 +66,7 @@ std r9,area+EX_R13(r13);\ mfcrr9 -#define EXCEPTION_PROLOG_PSERIES(area, label) \ - EXCEPTION_PROLOG_1(area); \ +#define EXCEPTION_PROLOG_PSERIES_1(label) \ ld r12,PACAKBASE(r13); /* get high part of label */ \ ld r10,PACAKMSR(r13); /* get MSR value for kernel */ \ mfspr r11,SPRN_SRR0; /* save SRR0 */ \ @@ -78,6 +77,10 @@ rfid; \ b . /* prevent speculative execution */ +#define EXCEPTION_PROLOG_PSERIES(area, label) \ + EXCEPTION_PROLOG_1(area); \ + EXCEPTION_PROLOG_PSERIES_1(label); + /* * The common exception prolog is used for all except a few exceptions * such as a segment miss on a kernel address. We have to be prepared Index: linux-work/arch/powerpc/kernel/exceptions-64s.S === --- linux-work.orig/arch/powerpc/kernel/exceptions-64s.S2009-07-15 15:07:50.0 +1000 +++ linux-work/arch/powerpc/kernel/exceptions-64s.S 2009-07-15 15:39:12.0 +1000 @@ -50,18 +50,26 @@ data_access_pSeries: HMT_MEDIUM mtspr SPRN_SPRG_SCRATCH0,r13 BEGIN_FTR_SECTION - mtspr SPRN_SPRG_SCRATCH1,r12 - mfspr r13,SPRN_DAR - mfspr r12,SPRN_DSISR - srdir13,r13,60 - rlwimi r13,r12,16,0x20 - mfcrr12 - cmpwi r13,0x2c + mfspr r13,SPRN_SPRG_PACA + std r9,PACA_EXSLB+EX_R9(r13) + std r10,PACA_EXSLB+EX_R10(r13) + mfspr r10,SPRN_DAR + mfspr r9,SPRN_DSISR + srdir10,r10,60 + rlwimi r10,r9,16,0x20 + mfcrr9 + cmpwi r10,0x2c beq do_stab_bolted_pSeries - mtcrf 0x80,r12 - mfspr r12,SPRN_SPRG_SCRATCH1 + ld r10,PACA_EXSLB+EX_R10(r13) + std r11,PACA_EXGEN+EX_R11(r13) + ld r11,PACA_EXSLB+EX_R9(r13) + std r12,PACA_EXGEN+EX_R12(r13) + mfspr r12,SPRN_SPRG_SCRATCH0 + std r10,PACA_EXGEN+EX_R10(r13) + std r11,PACA_EXGEN+EX_R9(r13) + std r12,PACA_EXGEN+EX_R13(r13) END_FTR_SECTION_IFCLR(CPU_FTR_SLB) - EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, data_access_common) + EXCEPTION_PROLOG_PSERIES_1(data_access_common) . = 0x380 .globl data_access_slb_pSeries @@ -224,9 +232,11 @@ masked_interrupt: .align 7 do_stab_bolted_pSeries: - mtcrf 0x80,r12 - mfspr r12,SPRN_SPRG_SCRATCH1 - EXCEPTION_PROLOG_PSERIES(PACA_EXSLB, .do_stab_bolted) + std r11,PACA_EXSLB+EX_R11(r13) + std r12,PACA_EXSLB+EX_R12(r13) + mfspr r10,SPRN_SPRG_SCRATCH0 + std r10,PACA_EXSLB+EX_R13(r13) + EXCEPTION_PROLOG_PSERIES_1(.do_stab_bolted) #ifdef CONFIG_PPC_PSERIES /* Index: linux-work/arch/powerpc/platforms/iseries/exception.S === --- linux-work.orig/arch/powerpc/platforms/iseries/exception.S 2009-07-15 15:07:50.0 +1000 +++ linux-work/arch/powerpc/platforms/iseries/exception.S 2009-07-15 15:39:14.0 +1000 @@ -128,25 +128,33 @@ iSeries_secondary_smp_loop: data_access_iSeries: mtspr SPRN_SPRG_SCRATCH0,r13 BEGIN_FTR_SECTION - mtspr SPRN_SPRG_SCRATCH1,r12 - mfspr r13,SPRN_DAR - mfspr r12,SPRN_DSISR - srdir13,r13,60 - rlwimi r13,r12,16,0x20 - mfcrr12 - cmpwi r13,0x2c + mfspr r13,SPRN_SPRG_PACA + std r9,PACA_EXSLB+EX_R9(r13) + std r10,PACA_EXSLB+EX_R10(r13) + mfspr r10,SPRN_DAR + mfspr r9,SPRN_DSISR + srdir10,r10,60 +
[PATCH 4/4] powerpc: Change PACA from SPRG3 to SPRG1
This change the SPRG used to store the PACA on ppc64 from SPRG3 to SPRG1. SPRG3 is user readable on most processors and we want to use it for other things. We change the scratch SPRG used by exception vectors from SRPG1 to SPRG2. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- arch/powerpc/include/asm/reg.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --- linux-work.orig/arch/powerpc/include/asm/reg.h 2009-07-15 15:24:07.0 +1000 +++ linux-work/arch/powerpc/include/asm/reg.h 2009-07-15 15:56:42.0 +1000 @@ -649,12 +649,12 @@ * SPRG usage: * * All 64-bit: - * - SPRG3 stores PACA pointer + * - SPRG1 stores PACA pointer * * 64-bit server: * - SPRG0 unused (reserved for HV on Power4) - * - SPRG1 scratch for exception vectors - * - SPRG2 unused + * - SPRG2 scratch for exception vectors + * - SPRG3 unused (user visible) * * All 32-bit: * - SPRG3 current thread_info pointer @@ -700,13 +700,13 @@ * */ #ifdef CONFIG_PPC64 -#define SPRN_SPRG_PACA SPRN_SPRG3 +#define SPRN_SPRG_PACA SPRN_SPRG1 #else #define SPRN_SPRG_THREAD SPRN_SPRG3 #endif #ifdef CONFIG_PPC_BOOK3S_64 -#define SPRN_SPRG_SCRATCH0 SPRN_SPRG1 +#define SPRN_SPRG_SCRATCH0 SPRN_SPRG2 #endif #ifdef CONFIG_PPC_BOOK3S_32 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pmac: Fix PowerSurge SMP IPI allocation
The code for setting up the IPIs for SMP PowerSurge marchines bitrot, it needs to properly map the HW interrupt number Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org -- arch/powerpc/platforms/powermac/smp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-work.orig/arch/powerpc/platforms/powermac/smp.c 2009-07-15 16:55:28.0 +1000 +++ linux-work/arch/powerpc/platforms/powermac/smp.c2009-07-15 16:55:36.0 +1000 @@ -408,7 +408,7 @@ static void __init smp_psurge_setup_cpu( /* reset the entry point so if we get another intr we won't * try to startup again */ out_be32(psurge_start, 0x100); - if (setup_irq(30, psurge_irqaction)) + if (setup_irq(irq_create_mapping(NULL, 30), psurge_irqaction)) printk(KERN_ERR Couldn't get primary IPI interrupt); } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
ethernet driver - problem capturing own packet in promiscous mode
Hi all In ethernet driver i need to enable promiscous mode and have to capture the packet that is sent by the same ethernet. The board is connected to a packet generator and could send/receive packets whenever i need . In the board ethernet driver , I made sure that am sending only broadcast packets and promisc mode is enabled but the packets are not captured. If i am sending a packet to the board from packetgenerator it is receiving. Could any one please suggest me any clues. Having the promisc enabled: Packet sent by packetgenerator is received by board. Packet sent by board is received by packetgenerator, The same packet should be captured by board as promiscuous is enabled. but not happening. Thanks Sudheer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: ethernet driver - problem capturing own packet in promiscous mode
Hi all In ethernet driver i need to enable promiscous mode and have to capture the packet that is sent by the same ethernet. The board is connected to a packet generator and could send/receive packets whenever i need . In the board ethernet driver , I made sure that am sending only broadcast packets and promisc mode is enabled but the packets are not captured. If i am sending a packet to the board from packetgenerator it is receiving. Could any one please suggest me any clues. Having the promisc enabled: Packet sent by packetgenerator is received by board. Packet sent by board is received by packetgenerator, The same packet should be captured by board as promiscuous is enabled. but not happening. The Ethernet interface that sent the packet will never receive the packet it sent even if you are in promiscuous mode. To be able to do that you should put your interface in loopback mode. In promiscuous mode, you will be able to receive any packets sent by other interfaces (broadcast, multicast and also unicast that is not directed to you interface MAC address). But not from your interface. Regards Sylvain This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
On Wed, Jul 15, 2009 at 05:49:47PM +1000, Benjamin Herrenschmidt wrote: Upcoming paches to support the new 64-bit BookE powerpc architecture will need to have the virtual address corresponding to PTE page when freeing it, due to the way the HW table walker works. Basically, the TLB can be loaded with large pages that cover the whole virtual space (well, sort-of, half of it actually) represented by a PTE page, and which contain an indirect bit indicating that this TLB entry RPN points to an array of PTEs from which the TLB can then create direct entries. RPN is PFN in ppc speak, right? Thus, in order to invalidate those when PTE pages are deleted, we need the virtual address to pass to tlbilx or tlbivax instructions. Interesting arrangement. So are these last level ptes modifieable from userspace or something? If not, I wonder if you could manage them as another level of pointers with the existing pagetable functions? The old trick of sticking it somewhere in the PTE page struct page sucks too much, the address is almost readily available in all call sites and almost everybody implemets these as macros, so we may as well add the argument everywhere. I added it to the pmd and pud variants for consistency. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- I would like to merge the new support that depends on this in 2.6.32, so unless there's major objections, I'd like this to go in early during the merge window. We can sort out separately how to carry the patch around in -next until then since the powerpc tree will have a dependency on it. Can't see any problem with that. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
having access to interrupt specifier in map() function
Ben, Do you have any ideas on keeping access to the interrupt specifier around so when we call map() we have access to it. Our HV guys are looking at using additional bits in the interrupt specifier to encode information beyond just level/sense of the IRQ and want to make decisions based on it during map(). Maybe we can keep it around in irq_map[]. thoughts? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
booting MPC8313 based board with yaffs2 RFS
Hi I am using MPC8313 board which is currently booting with JFFS2 root file system. I am using linux kernel version 2.6.23 from FreeScale's LTIB for MPC8313. As, I want it to boot with YAFFS2 root file system, I did compile kernel with yaffs2 support, craeted yaffs2 rootfile system and passed yaffs2 partiton of nand in bootargs. However it didnot work. If any one has done it successfully, can please share the steps to be followed ? Thanks Rupesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2 v3] fs_enet/mii-fec.c: fix MII speed calculation
The MII speed calculation was based on the CPU clock (ppc_proc_freq),
but for MPC512x we must use the bus clock instead.
This patch makes it use the correct clock and makes sure we don't
clobber reserved bits in the MII_SPEED register.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: net...@vger.kernel.org
---
Please ignore patch v2, it's crap.
Hope this is a bit better.
arch/powerpc/include/asm/mpc5xxx.h | 10 +
arch/powerpc/sysdev/mpc5xxx_clocks.c | 37 ++
drivers/net/fs_enet/mii-fec.c| 13 +--
3 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc5xxx.h
b/arch/powerpc/include/asm/mpc5xxx.h
index 5ce9c5f..86ab29f 100644
--- a/arch/powerpc/include/asm/mpc5xxx.h
+++ b/arch/powerpc/include/asm/mpc5xxx.h
@@ -15,8 +15,18 @@
#ifndef __ASM_POWERPC_MPC5xxx_H__
#define __ASM_POWERPC_MPC5xxx_H__
+#include linux/of_platform.h
extern unsigned long mpc5xxx_get_bus_frequency(struct device_node *node);
+#if defined(CONFIG_PPC_MPC512x) || defined(CONFIG_PPC_MPC52xx)
+extern int mpc5xxx_get_mii_speed(struct of_device *ofdev);
+#else
+static inline int mpc5xxx_get_mii_speed(struct of_device *ofdev)
+{
+ return -1;
+}
+#endif
+
#endif /* __ASM_POWERPC_MPC5xxx_H__ */
diff --git a/arch/powerpc/sysdev/mpc5xxx_clocks.c
b/arch/powerpc/sysdev/mpc5xxx_clocks.c
index 34e12f9..e26d12b 100644
--- a/arch/powerpc/sysdev/mpc5xxx_clocks.c
+++ b/arch/powerpc/sysdev/mpc5xxx_clocks.c
@@ -31,3 +31,40 @@ mpc5xxx_get_bus_frequency(struct device_node *node)
return p_bus_freq ? *p_bus_freq : 0;
}
EXPORT_SYMBOL(mpc5xxx_get_bus_frequency);
+
+/**
+ * mpc5xxx_get_mii_speed - Get the MII_SPEED value
+ * @node: device node
+ *
+ * Returns the MII_SPEED value for MPC512x and MPC52xx systems.
+ * The value gets computed such that the resulting MDC frequency
+ * is 2.5 MHz or lower.
+ */
+
+int
+mpc5xxx_get_mii_speed(struct of_device *ofdev)
+{
+ unsigned int clock, speed;
+
+ clock = mpc5xxx_get_bus_frequency(ofdev-node);
+
+ if (!clock) {
+ dev_err(ofdev-dev, could not determine IPS/IPB clock\n);
+ return -ENODEV;
+ }
+
+ /* scale for a MII clock = 2.5 MHz */
+ speed = (clock + 249) / 250;
+
+ /* only 6 bits available for MII speed */
+ if (speed 0x3F) {
+ speed = 0x3F;
+ dev_err(ofdev-dev,
+ MII clock (%d MHz) exceeds max (2.5 MHz)\n,
+ clock / speed);
+ }
+
+ /* Field is in bits 25:30 of MII_SPEED register */
+ return speed 1;
+}
+EXPORT_SYMBOL(mpc5xxx_get_mii_speed);
diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
index 75a0999..a28d39f 100644
--- a/drivers/net/fs_enet/mii-fec.c
+++ b/drivers/net/fs_enet/mii-fec.c
@@ -36,6 +36,7 @@
#include asm/pgtable.h
#include asm/irq.h
#include asm/uaccess.h
+#include asm/mpc5xxx.h
#include fs_enet.h
#include fec.h
@@ -103,7 +104,6 @@ static int fs_enet_fec_mii_reset(struct mii_bus *bus)
static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct resource res;
struct mii_bus *new_bus;
struct fec_info *fec;
@@ -133,13 +133,20 @@ static int __devinit fs_enet_mdio_probe(struct of_device
*ofdev,
if (!fec-fecp)
goto out_fec;
- fec-mii_speed = ((ppc_proc_freq + 499) / 500) 1;
+ if (of_device_is_compatible(ofdev-node, fsl,mpc5121-fec-mdio)) {
+ i = mpc5xxx_get_mii_speed(ofdev);
+ if (i 0)
+ goto out_unmap_regs;
+ fec-mii_speed = i;
+ } else {
+ fec-mii_speed = ((ppc_proc_freq + 499) / 500) 1;
+ }
setbits32(fec-fecp-fec_r_cntrl, FEC_RCNTRL_MII_MODE);
setbits32(fec-fecp-fec_ecntrl, FEC_ECNTRL_PINMUX |
FEC_ECNTRL_ETHER_EN);
out_be32(fec-fecp-fec_ievent, FEC_ENET_MII);
- out_be32(fec-fecp-fec_mii_speed, fec-mii_speed);
+ clrsetbits_be32(fec-fecp-fec_mii_speed, 0x7E, fec-mii_speed);
new_bus-phy_mask = ~0;
new_bus-irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] MPC52xx FEC: be more conservative when setting MII_SPEED register
This patch adds error checking and prevents clobbering unrelated bits (reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED register on MPC52xx systems. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Grant Likely grant.lik...@secretlab.ca Cc: Kumar Gala ga...@kernel.crashing.org Cc: net...@vger.kernel.org --- drivers/net/fec_mpc52xx.c |2 +- drivers/net/fec_mpc52xx_phy.c |6 -- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c index cc78633..b69d440 100644 --- a/drivers/net/fec_mpc52xx.c +++ b/drivers/net/fec_mpc52xx.c @@ -639,7 +639,7 @@ static void mpc52xx_fec_hw_init(struct net_device *dev) /* set phy speed. * this can't be done in phy driver, since it needs to be called * before fec stuff (even on resume) */ - out_be32(fec-mii_speed, priv-mdio_speed); + clrsetbits_be32(fec-mii_speed, 0x7E, priv-mdio_speed); } /** diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.c index 31e6d62..f733d43 100644 --- a/drivers/net/fec_mpc52xx_phy.c +++ b/drivers/net/fec_mpc52xx_phy.c @@ -105,8 +105,10 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of, dev_set_drvdata(dev, bus); /* set MII speed */ - out_be32(priv-regs-mii_speed, - ((mpc5xxx_get_bus_frequency(of-node) 20) / 5) 1); + i = mpc5xxx_get_mii_speed(of); + if (i0) + goto out_unmap; + clrsetbits_be32(priv-regs-mii_speed, 0x7E, i); err = of_mdiobus_register(bus, np); if (err) -- 1.6.0.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v3] fs_enet/mii-fec.c: fix MII speed calculation
On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denkw...@denx.de wrote:
The MII speed calculation was based on the CPU clock (ppc_proc_freq),
but for MPC512x we must use the bus clock instead.
This patch makes it use the correct clock and makes sure we don't
clobber reserved bits in the MII_SPEED register.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: net...@vger.kernel.org
---
Please ignore patch v2, it's crap.
Hope this is a bit better.
arch/powerpc/include/asm/mpc5xxx.h | 10 +
arch/powerpc/sysdev/mpc5xxx_clocks.c | 37
++
Drop the common code bit. The 5200 and 5121 are different devices and
it is a tiny bit of code. I don't think there is any benefit to
having it as a common function. Just roll the get_mii_speed function
in the mii-fec driver itself.
Also, this patch can be quite a bit simpler if you use the .data
pointer in the drivers match table to specify the function used to
return the bus clock speed. Something like this:
static struct of_device_id fs_enet_mdio_fec_match[] = {
{
.compatible = fsl,pq1-fec-mdio,
},
#if defined(CONFIG_PPC_MPC512x)
{
.compatible = fsl,mpc5121-fec-mdio,
.data = mpc5xxx_get_bus_frequency,
},
#endif
{},
};
and
int *get_bus_freq(of_node *) = data;
if (get_bus_freq)
bus_freq = get_bus_freq(np);
else
bus_freq = ppc_proc_freq / 2;
... then do the regular calculation here and add in the additional
robustification you did in this patch.
Heck, you could even eliminate the if/else above if the normal case
you have a get_bus_speed function for the original ppc_proc_freq case,
but I'm not sure if it is worth it.
drivers/net/fs_enet/mii-fec.c | 13 +--
3 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc5xxx.h
b/arch/powerpc/include/asm/mpc5xxx.h
index 5ce9c5f..86ab29f 100644
--- a/arch/powerpc/include/asm/mpc5xxx.h
+++ b/arch/powerpc/include/asm/mpc5xxx.h
@@ -15,8 +15,18 @@
#ifndef __ASM_POWERPC_MPC5xxx_H__
#define __ASM_POWERPC_MPC5xxx_H__
+#include linux/of_platform.h
extern unsigned long mpc5xxx_get_bus_frequency(struct device_node *node);
+#if defined(CONFIG_PPC_MPC512x) || defined(CONFIG_PPC_MPC52xx)
+extern int mpc5xxx_get_mii_speed(struct of_device *ofdev);
+#else
+static inline int mpc5xxx_get_mii_speed(struct of_device *ofdev)
+{
+ return -1;
+}
+#endif
+
#endif /* __ASM_POWERPC_MPC5xxx_H__ */
diff --git a/arch/powerpc/sysdev/mpc5xxx_clocks.c
b/arch/powerpc/sysdev/mpc5xxx_clocks.c
index 34e12f9..e26d12b 100644
--- a/arch/powerpc/sysdev/mpc5xxx_clocks.c
+++ b/arch/powerpc/sysdev/mpc5xxx_clocks.c
@@ -31,3 +31,40 @@ mpc5xxx_get_bus_frequency(struct device_node *node)
return p_bus_freq ? *p_bus_freq : 0;
}
EXPORT_SYMBOL(mpc5xxx_get_bus_frequency);
+
+/**
+ * mpc5xxx_get_mii_speed - Get the MII_SPEED value
+ * @node: device node
+ *
+ * Returns the MII_SPEED value for MPC512x and MPC52xx systems.
+ * The value gets computed such that the resulting MDC frequency
+ * is 2.5 MHz or lower.
+ */
+
+int
+mpc5xxx_get_mii_speed(struct of_device *ofdev)
+{
+ unsigned int clock, speed;
+
+ clock = mpc5xxx_get_bus_frequency(ofdev-node);
+
+ if (!clock) {
+ dev_err(ofdev-dev, could not determine IPS/IPB clock\n);
+ return -ENODEV;
+ }
+
+ /* scale for a MII clock = 2.5 MHz */
+ speed = (clock + 249) / 250;
+
+ /* only 6 bits available for MII speed */
+ if (speed 0x3F) {
+ speed = 0x3F;
+ dev_err(ofdev-dev,
+ MII clock (%d MHz) exceeds max (2.5 MHz)\n,
+ clock / speed);
+ }
+
+ /* Field is in bits 25:30 of MII_SPEED register */
+ return speed 1;
+}
+EXPORT_SYMBOL(mpc5xxx_get_mii_speed);
diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
index 75a0999..a28d39f 100644
--- a/drivers/net/fs_enet/mii-fec.c
+++ b/drivers/net/fs_enet/mii-fec.c
@@ -36,6 +36,7 @@
#include asm/pgtable.h
#include asm/irq.h
#include asm/uaccess.h
+#include asm/mpc5xxx.h
#include fs_enet.h
#include fec.h
@@ -103,7 +104,6 @@ static int fs_enet_fec_mii_reset(struct mii_bus *bus)
static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct resource res;
struct mii_bus *new_bus;
struct fec_info *fec;
@@ -133,13 +133,20 @@ static int __devinit fs_enet_mdio_probe(struct
of_device *ofdev,
if (!fec-fecp)
goto out_fec;
- fec-mii_speed = ((ppc_proc_freq + 499) / 500) 1;
+ if
Re: [PATCH 2/2] MPC52xx FEC: be more conservative when setting MII_SPEED register
On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denkw...@denx.de wrote: This patch adds error checking and prevents clobbering unrelated bits (reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED register on MPC52xx systems. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Grant Likely grant.lik...@secretlab.ca Cc: Kumar Gala ga...@kernel.crashing.org Cc: net...@vger.kernel.org As I mentioned in the other patch, I don't want the 5121 and 5200 FEC devices using common code for this. It is a tiny block of code and they are different devices. Just open code the needed calculation into this driver. g. --- drivers/net/fec_mpc52xx.c | 2 +- drivers/net/fec_mpc52xx_phy.c | 6 -- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c index cc78633..b69d440 100644 --- a/drivers/net/fec_mpc52xx.c +++ b/drivers/net/fec_mpc52xx.c @@ -639,7 +639,7 @@ static void mpc52xx_fec_hw_init(struct net_device *dev) /* set phy speed. * this can't be done in phy driver, since it needs to be called * before fec stuff (even on resume) */ - out_be32(fec-mii_speed, priv-mdio_speed); + clrsetbits_be32(fec-mii_speed, 0x7E, priv-mdio_speed); } /** diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.c index 31e6d62..f733d43 100644 --- a/drivers/net/fec_mpc52xx_phy.c +++ b/drivers/net/fec_mpc52xx_phy.c @@ -105,8 +105,10 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of, dev_set_drvdata(dev, bus); /* set MII speed */ - out_be32(priv-regs-mii_speed, - ((mpc5xxx_get_bus_frequency(of-node) 20) / 5) 1); + i = mpc5xxx_get_mii_speed(of); + if (i0) + goto out_unmap; + clrsetbits_be32(priv-regs-mii_speed, 0x7E, i); err = of_mdiobus_register(bus, np); if (err) -- 1.6.0.6 -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Support for PCI Express reset type in EEH
This patch was simultaneously submitted to Red Hat for review. As a result of
that review, I'm withdrawing this patch and will submit a new version shortly.
Mike
Mike Mason wrote:
By default, EEH does what's known as a hot reset during error recovery
of a PCI Express device. We've found a case where the device needs a
fundamental reset to recover properly. The current PCI error recovery
and EEH frameworks do not support this distinction.
The attached patch (courtesy of Richard Lary) implements a reset type
callback that can be used to determine what type of reset a device
requires. It is backwards compatible with all other drivers that
implement PCI error recovery callbacks. Only drivers that require a
fundamental reset need to be changed. So far we're only aware of one
driver that has the requirement (qla2xxx). The patch touches mostly EEH
and pseries code, but does require a couple of minor additions to the
overall PCI error recovery framework.
Signed-off-by: Mike Mason mm...@us.ibm.com
--- a/arch/powerpc/include/asm/ppc-pci.h2009-06-09
20:05:27.0 -0700
+++ b/arch/powerpc/include/asm/ppc-pci.h2009-07-13
16:12:31.0 -0700
@@ -90,7 +90,9 @@ int rtas_pci_enable(struct pci_dn *pdn,
*
* Returns a non-zero value if the reset failed.
*/
-int rtas_set_slot_reset (struct pci_dn *);
+#define HOT_RESET1
+#define FUNDAMENTAL_RESET3
+int rtas_set_slot_reset (struct pci_dn *, int reset_type);
int eeh_wait_for_slot_status(struct pci_dn *pdn, int max_wait_msecs);
/** --- a/arch/powerpc/platforms/pseries/eeh.c2009-06-09
20:05:27.0 -0700
+++ b/arch/powerpc/platforms/pseries/eeh.c2009-07-13
16:27:27.0 -0700
@@ -666,7 +666,7 @@ rtas_pci_enable(struct pci_dn *pdn, int
/**
* rtas_pci_slot_reset - raises/lowers the pci #RST line
* @pdn pci device node
- * @state: 1/0 to raise/lower the #RST
+ * @state: 1/3/0 to raise hot-reset/fundamental-reset/lower the #RST
*
* Clear the EEH-frozen condition on a slot. This routine
* asserts the PCI #RST line if the 'state' argument is '1',
@@ -742,9 +742,9 @@ int pcibios_set_pcie_reset_state(struct
* Return 0 if success, else a non-zero value.
*/
-static void __rtas_set_slot_reset(struct pci_dn *pdn)
+static void __rtas_set_slot_reset(struct pci_dn *pdn, int reset_type)
{
-rtas_pci_slot_reset (pdn, 1);
+rtas_pci_slot_reset (pdn, reset_type);
/* The PCI bus requires that the reset be held high for at least
* a 100 milliseconds. We wait a bit longer 'just in case'. */
@@ -766,13 +766,13 @@ static void __rtas_set_slot_reset(struct
msleep (PCI_BUS_SETTLE_TIME_MSEC);
}
-int rtas_set_slot_reset(struct pci_dn *pdn)
+int rtas_set_slot_reset(struct pci_dn *pdn, int reset_type)
{
int i, rc;
/* Take three shots at resetting the bus */
for (i=0; i3; i++) {
-__rtas_set_slot_reset(pdn);
+__rtas_set_slot_reset(pdn, reset_type);
rc = eeh_wait_for_slot_status(pdn, PCI_BUS_RESET_WAIT_MSEC);
if (rc == 0)
--- a/arch/powerpc/platforms/pseries/eeh_driver.c2009-07-13
14:25:24.0 -0700
+++ b/arch/powerpc/platforms/pseries/eeh_driver.c2009-07-13
16:39:16.0 -0700
@@ -115,6 +115,34 @@ static void eeh_enable_irq(struct pci_de
/* --- */
/**
+ * eeh_query_reset_type - query each device driver for reset type
+ *
+ * Query each device driver for special reset type if required
+ * merge the device driver responses. Cumulative response
+ * passed back in userdata.
+ */
+
+static int eeh_query_reset_type(struct pci_dev *dev, void *userdata)
+{
+enum pci_ers_result rc, *res = userdata;
+struct pci_driver *driver = dev-driver;
+
+if (!driver)
+return 0;
+
+if (!driver-err_handler ||
+!driver-err_handler-reset_type)
+return 0;
+
+rc = driver-err_handler-reset_type (dev);
+
+/* A driver that needs a special reset trumps all others */
+if (rc == PCI_ERS_RESULT_FUNDAMENTAL_RESET ) *res = rc;
+
+return 0;
+}
+
+/**
* eeh_report_error - report pci error to each device driver
* * Report an EEH error to each device driver, collect up and @@ -282,9
+310,12 @@ static int eeh_report_failure(struct pci
* @pe_dn: pointer to a Partionable Endpoint device node.
*This is the top-level structure on which pci
*bus resets can be performed.
+ *
+ * reset_type: some devices may require type other than default hot reset.
*/
-static int eeh_reset_device (struct pci_dn *pe_dn, struct pci_bus *bus)
+static int eeh_reset_device (struct pci_dn *pe_dn, struct pci_bus *bus,
+ int reset_type)
{
struct device_node *dn;
int cnt, rc;
@@ -298,7 +329,7 @@ static int eeh_reset_device (struct pci_
/* Reset the pci controller. (Asserts RST#; resets config space).
* Reconfigure bridges and devices. Don't try to bring the system
* up if the reset failed for some reason. */
-rc =
[PATCH] Support for PCI Express reset type in EEH
By default, EEH does what's known as a hot reset during error recovery of a PCI Express
device. We've found a case where the device needs a fundamental reset to recover
properly. The current PCI error recovery and EEH frameworks do not support this distinction.
The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev that
indicates whether the device requires a fundamental reset during error
recovery. This bit can be checked by EEH to determine which reset type is
required.
This patch supersedes the previously submitted patch that implemented a reset
type callback.
Please review and let me know of any concerns.
Signed-off-by: Mike Mason mm...@us.ibm.com
diff -uNrp a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
--- a/arch/powerpc/kernel/pci_64.c 2009-07-13 14:25:24.0 -0700
+++ b/arch/powerpc/kernel/pci_64.c 2009-07-15 10:26:26.0 -0700
@@ -143,6 +143,7 @@ struct pci_dev *of_create_pci_dev(struct
dev-dev.bus = pci_bus_type;
dev-devfn = devfn;
dev-multifunction = 0; /* maybe a lie? */
+ dev-fndmntl_rst_rqd = 0; /* pcie fundamental reset required */
dev-vendor = get_int_prop(node, vendor-id, 0x);
dev-device = get_int_prop(node, device-id, 0x);
diff -uNrp a/arch/powerpc/platforms/pseries/eeh.c
b/arch/powerpc/platforms/pseries/eeh.c
--- a/arch/powerpc/platforms/pseries/eeh.c 2009-06-09 20:05:27.0
-0700
+++ b/arch/powerpc/platforms/pseries/eeh.c 2009-07-15 10:29:04.0
-0700
@@ -744,7 +744,15 @@ int pcibios_set_pcie_reset_state(struct
static void __rtas_set_slot_reset(struct pci_dn *pdn)
{
- rtas_pci_slot_reset (pdn, 1);
+ struct pci_dev *dev = pdn-pcidev;
+
+ /* Determine type of EEH reset required by device,
+* default hot reset or fundamental reset
+*/
+ if (dev-fndmntl_rst_rqd)
+ rtas_pci_slot_reset(pdn, 3);
+ else
+ rtas_pci_slot_reset(pdn, 1);
/* The PCI bus requires that the reset be held high for at least
* a 100 milliseconds. We wait a bit longer 'just in case'. */
diff -uNrp a/include/linux/pci.h b/include/linux/pci.h
--- a/include/linux/pci.h 2009-07-13 14:25:37.0 -0700
+++ b/include/linux/pci.h 2009-07-15 10:25:37.0 -0700
@@ -273,6 +273,7 @@ struct pci_dev {
unsigned intari_enabled:1; /* ARI forwarding */
unsigned intis_managed:1;
unsigned intis_pcie:1;
+ unsigned intfndmntl_rst_rqd:1; /* Dev requires fundamental reset */
unsigned intstate_saved:1;
unsigned intis_physfn:1;
unsigned intis_virtfn:1;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [00/15] swiotlb cleanup
On Jul 13, 2009, at 10:13 PM, Becky Bruce wrote: On Jul 10, 2009, at 12:12 AM, Ingo Molnar wrote: * FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote: - removes unused (and unnecessary) hooks in swiotlb. - adds dma_capable() and converts swiotlb to use it. It can be used to know if a memory area is dma capable or not. I added is_buffer_dma_capable() for the same purpose long ago but it turned out that the function doesn't work on POWERPC. This can be applied cleanly to linux-next, -mm, and mainline. This patchset touches multiple architectures (ia64, powerpc, x86) so I guess that -mm is appropriate for this patchset (I don't care much what tree would merge this though). This is tested on x86 but only compile tested on POWERPC and IA64. Thanks, = arch/ia64/include/asm/dma-mapping.h| 18 ++ arch/powerpc/include/asm/dma-mapping.h | 23 +++ arch/powerpc/kernel/dma-swiotlb.c | 48 +--- arch/x86/include/asm/dma-mapping.h | 18 ++ arch/x86/kernel/pci-dma.c |2 +- arch/x86/kernel/pci-gart_64.c |5 +- arch/x86/kernel/pci-nommu.c|2 +- arch/x86/kernel/pci-swiotlb.c | 25 include/linux/dma-mapping.h|5 -- include/linux/swiotlb.h| 11 lib/swiotlb.c | 102 +--- 11 files changed, 92 insertions(+), 167 deletions(-) Hm, the functions and facilities you remove here were added as part of preparatory patches for Xen guest support. You were aware of them, you were involved in discussions about those aspects with Ian and Jeremy but still you chose not to Cc: either of them and you failed to address that aspect in the changelogs. I'd like the Xen code to become cleaner more than anyone else here i guess, but patch submission methods like this are not really helpful. A far better method is to be open about such disagreements, to declare them, to Cc: everyone who disagrees, and to line out the arguments in the changelogs as well - instead of just curtly declaring those APIs 'unused' and failing to Cc: involved parties. Alas, on the technical level the cleanups themselves look mostly fine to me. Ian, Jeremy, the changes will alter Xen's use of swiotlb, but can the Xen side still live with these new methods - in particular is dma_capable() sufficient as a mechanism and can the Xen side filter out DMA allocations to make them physically continuous? Ben, Tony, Becky, any objections wrt. the PowerPC / IA64 impact? If everyone agrees i can apply them to the IOMMU tree, test it and push it out to -next, etc. Ingo, With the exception of the patch I commented on, I think these look OK from the powerpc point of view. I've successfully booted one of my test platforms with the entire series applied and will run some more extensive (i.e. not Whee! A prompt!) tests tomorrow. Well, I am still testing. I've observed one unexpected LTP testcase failure with these patches applied, but so far have been unable to reproduce it. So these patches are probably OK, but I will look into this some more next week. -Becky -Becky ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Hold reference to device_node during EEH event handling
This patch increments the device_node reference counter when an EEH error
occurs and decrements the counter when the event has been handled. This is to
prevent the device_node from being released until eeh_event_handler() has had a
chance to deal with the event. We've seen cases where the device_node is
released too soon when an EEH event occurs during a dlpar remove, causing the
event handler to attempt to access bad memory locations.
Please review and let me know of any concerns.
Signed-off-by: Mike Mason mm...@us.ibm.com
--- a/arch/powerpc/platforms/pseries/eeh_event.c2008-10-09
15:13:53.0 -0700
+++ b/arch/powerpc/platforms/pseries/eeh_event.c2009-07-14
14:14:00.0 -0700
@@ -75,6 +75,14 @@ static int eeh_event_handler(void * dumm
if (event == NULL)
return 0;
+ /* EEH holds a reference to the device_node, so if it
+* equals 1 it's no longer valid and the event should
+* be ignored */
+ if (atomic_read(event-dn-kref.refcount) == 1) {
+ of_node_put(event-dn);
+ return 0;
+ }
+
/* Serialize processing of EEH events */
mutex_lock(eeh_event_mutex);
eeh_mark_slot(event-dn, EEH_MODE_RECOVERING);
@@ -86,6 +94,7 @@ static int eeh_event_handler(void * dumm
eeh_clear_slot(event-dn, EEH_MODE_RECOVERING);
pci_dev_put(event-dev);
+ of_node_put(event-dn);
kfree(event);
mutex_unlock(eeh_event_mutex);
@@ -140,7 +149,7 @@ int eeh_send_failure_event (struct devic
if (dev)
pci_dev_get(dev);
- event-dn = dn;
+ event-dn = of_node_get(dn);
event-dev = dev;
/* We may or may not be called in an interrupt context */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: having access to interrupt specifier in map() function
On Wed, 2009-07-15 at 09:11 -0500, Kumar Gala wrote: Ben, Do you have any ideas on keeping access to the interrupt specifier around so when we call map() we have access to it. Our HV guys are looking at using additional bits in the interrupt specifier to encode information beyond just level/sense of the IRQ and want to make decisions based on it during map(). Maybe we can keep it around in irq_map[]. Or we could translate those additional info into flags in the IRQ desc ? Might be possible to request some arch specific flags in there. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: removing addr_needs_map in struct dma_mapping_ops
On Jul 13, 2009, at 7:49 PM, FUJITA Tomonori wrote:
On Mon, 13 Jul 2009 16:50:43 -0500
Becky Bruce bec...@kernel.crashing.org wrote:
talked about defining something like struct dma_data. Then we could
struct dev_archdata {
...
struct dma_data *ddata;
};
or
struct dev_archdata {
...
struct dma_data ddata;
};
struct dma_data needs dma_direct_offset, iommu_table, dma_base, and
dma_window_size, anything else?
IIRC, what we had talked about was simpler - we talked about changing
the current dev_archdata from this:
struct dev_archdata {
struct device_node *of_node;
struct dma_mapping_ops *dma_ops;
void*dma_data;
};
to this:
struct dev_archdata {
struct device_node *of_node;
struct dma_mapping_ops *dma_ops;
unsigned long long dma_data;
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
#endif
};
Where max_direct_dma_addr is the address beyond which a specific
device must use swiotlb, and dma_data is the offset like it is now
(but wider on 32-bit systems than void *). I believe Ben had
mentioned
wanting to make the max_direct_dma_addr part conditional so we don't
bloat archdata on platforms that don't ever bounce.
Only maximum address is enough? The minimum (dma_window_base_cur in
swiotlb_pci_addr_needs_map) is not necessary?
The change to the type of dma_data is actually in preparation for an
optimization I have planned for 64-bit PCI devices (and which
probably
requires more discussion), so that doesn't need to happen now - just
leave it as a void *, and I can post a followup patch.
Let me know if I can help or do any testing - I've been meaning to
look into switching to dma_map_ops for a while now but it hasn't
managed to pop off my todo stack.
Ok, how about this? I'm not familiar with POWERPC so I might
misunderstand something.
This is close, but it misses the setup for non-pci devices. We have a
bus notifier that we use to set up archdata for those devices -
ppc_swiotlb_bus_notify() in arch/powerpc/kernel/dma-swiotlb.c. It
won't cause breakage to not have this set up, because those will fall
through to the dma_capable(), but I think we should initialize it
anyway (who knows what it will end up used for later).
diff --git a/arch/powerpc/include/asm/device.h b/arch/powerpc/
include/asm/device.h
index 7d2277c..0086f8d 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -16,6 +16,9 @@ struct dev_archdata {
/* DMA operations on that device */
struct dma_mapping_ops *dma_ops;
void*dma_data;
+#ifdef CONFIG_SWIOTLB
+ dma_addr_t max_direct_dma_addr;
+#endif
};
static inline void dev_archdata_set_node(struct dev_archdata *ad,
diff --git a/arch/powerpc/include/asm/swiotlb.h b/arch/powerpc/
include/asm/swiotlb.h
index 30891d6..b23a4f1 100644
--- a/arch/powerpc/include/asm/swiotlb.h
+++ b/arch/powerpc/include/asm/swiotlb.h
@@ -24,4 +24,6 @@ static inline void dma_mark_clean(void *addr,
size_t size) {}
extern unsigned int ppc_swiotlb_enable;
int __init swiotlb_setup_bus_notifier(void);
+extern void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev);
+
#endif /* __ASM_SWIOTLB_H */
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/
dma-swiotlb.c
index 68ccf11..e21359e 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -56,39 +56,16 @@ swiotlb_arch_address_needs_mapping(struct device
*hwdev, dma_addr_t addr,
size_t size)
{
struct dma_mapping_ops *dma_ops = get_dma_ops(hwdev);
+ struct dev_archdata *sd = hwdev-archdata;
BUG_ON(!dma_ops);
- return dma_ops-addr_needs_map(hwdev, addr, size);
-}
You can get rid of the dma_ops stuff here it's no longer needed.
-/*
- * Determine if an address is reachable by a pci device, or if we
must bounce.
- */
-static int
-swiotlb_pci_addr_needs_map(struct device *hwdev, dma_addr_t addr,
size_t size)
-{
- u64 mask = dma_get_mask(hwdev);
- dma_addr_t max;
- struct pci_controller *hose;
- struct pci_dev *pdev = to_pci_dev(hwdev);
-
- hose = pci_bus_to_host(pdev-bus);
- max = hose-dma_window_base_cur + hose-dma_window_size;
-
- /* check that we're within mapped pci window space */
- if ((addr + size max) | (addr hose-dma_window_base_cur))
+ if (sd-max_direct_dma_addr addr + size sd-
max_direct_dma_addr)
return 1;
- return !is_buffer_dma_capable(mask, addr, size);
-}
-
-static int
-swiotlb_addr_needs_map(struct device *hwdev, dma_addr_t addr,
size_t size)
-{
return !is_buffer_dma_capable(dma_get_mask(hwdev), addr, size);
}
-
/*
* At the moment, all platforms that use this code only require
* swiotlb to be used if we're operating on HIGHMEM. Since
@@ -104,7 +81,6 @@ struct dma_mapping_ops swiotlb_dma_ops = {
Re: [PATCH 2/4] edac: mpc85xx add mpc83xx support
Ira or Kumar,
can you address Andrew's concerns below and what was posted in prior posts on
this?
thanks
doug t
--- On Wed, 7/15/09, Andrew Morton a...@linux-foundation.org wrote:
From: Andrew Morton a...@linux-foundation.org
Subject: Re: [PATCH 2/4] edac: mpc85xx add mpc83xx support
To: dougthomp...@xmission.com
Cc: bluesmoke-de...@lists.sourceforge.net, linux-ker...@vger.kernel.org
Date: Wednesday, July 15, 2009, 1:52 PM
On Wed, 15 Jul 2009 11:38:49 -0600
dougthomp...@xmission.com
wrote:
Add support for the Freescale MPC83xx memory
controller to the existing
driver for the Freescale MPC85xx memory controller.
The only difference
between the two processors are in the CS_BNDS register
parsing code, which
has been changed so it will work on both processors.
The L2 cache controller does not exist on the MPC83xx,
but the OF subsystem
will not use the driver if the device is not present
in the OF device tree.
Kumar, I had to change the nr_pages calculation to
make the math work
out. I checked it on my board and did the math by hand
for a 64GB 85xx
using 64K pages. In both cases, nr_pages * PAGE_SIZE
comes out to the
correct value. Thanks for the help.
v1 - v2:
* Use PAGE_SHIFT to parse cs_bnds
regardless of board type
* Remove special-casing for the 83xx
processor
...
@@ -789,19 +791,20 @@ static void __devinit
mpc85xx_init_csrow
csrow =
mci-csrows[index];
cs_bnds =
in_be32(pdata-mc_vbase + MPC85XX_MC_CS_BNDS_0 +
(index *
MPC85XX_MC_CS_BNDS_OFS));
- start =
(cs_bnds 0xfff) 4;
- end = ((cs_bnds
0xfff) 20);
- if (start)
-
start |= 0xf;
- if (end)
-
end |= 0xf;
+
+ start =
(cs_bnds 0x) 16;
+
end = (cs_bnds 0x);
if (start
== end)
continue; /* not
populated */
+ start =
(24 - PAGE_SHIFT);
+
end = (24 - PAGE_SHIFT);
+ end
|= (1 (24 - PAGE_SHIFT)) - 1;
stares for a while
That looks like the original code was really really wrong.
The setting of all the lower bits in `end' is
funny-looking. What's
happening here? Should it be commented?
csrow-first_page = start PAGE_SHIFT;
csrow-last_page = end PAGE_SHIFT;
-
csrow-nr_pages = csrow-last_page + 1 -
csrow-first_page;
+
csrow-nr_pages = end + 1 - start;
csrow-grain = 8;
csrow-mtype = mtype;
csrow-dtype = DEV_UNKNOWN;
@@ -985,6 +988,7 @@ static struct of_device_id
mpc85xx_mc_er
{ .compatible =
fsl,mpc8560-memory-controller, },
{ .compatible =
fsl,mpc8568-memory-controller, },
{ .compatible =
fsl,mpc8572-memory-controller, },
+ { .compatible =
fsl,mpc8349-memory-controller, },
{ .compatible =
fsl,p2020-memory-controller, },
{},
};
@@ -1001,13 +1005,13 @@ static struct
of_platform_driver mpc85xx
},
};
-
+#ifdef CONFIG_MPC85xx
static void __init mpc85xx_mc_clear_rfxe(void
*data)
{
orig_hid1[smp_processor_id()]
= mfspr(SPRN_HID1);
mtspr(SPRN_HID1,
(orig_hid1[smp_processor_id()] ~0x2));
}
-
+#endif
static int __init mpc85xx_mc_init(void)
{
@@ -1040,26 +1044,32 @@ static int __init
mpc85xx_mc_init(void)
printk(KERN_WARNING EDAC_MOD_STR PCI fails to
register\n);
#endif
+#ifdef CONFIG_MPC85xx
/*
* need to clear
HID1[RFXE] to disable machine check int
* so we can catch
it
*/
if (edac_op_state ==
EDAC_OPSTATE_INT)
on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
+#endif
return 0;
}
The patch adds lots of ifdefs :(
module_init(mpc85xx_mc_init);
+#ifdef CONFIG_MPC85xx
static void __exit mpc85xx_mc_restore_hid1(void
*data)
{
mtspr(SPRN_HID1,
orig_hid1[smp_processor_id()]);
}
+#endif
afacit this will run smp_processor_id() from within
preemptible code,
which is often buggy on preemptible kernels and will cause
runtime
warnings on at least some architectures.
static void __exit mpc85xx_mc_exit(void)
{
+#ifdef CONFIG_MPC85xx
on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
+#endif
#ifdef CONFIG_PCI
of_unregister_platform_driver(mpc85xx_pci_err_driver);
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] kmemleak: Allow kmemleak to be built on powerpc
Very lightly tested, doesn't crash the kernel. Signed-off-by: Michael Ellerman mich...@ellerman.id.au --- It doesn't look like we actually need to add any support in the arch code - or is there something I'm missing? lib/Kconfig.debug |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 12327b2..d5ca9a5 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -338,7 +338,7 @@ config SLUB_STATS config DEBUG_KMEMLEAK bool Kernel memory leak detector - depends on DEBUG_KERNEL EXPERIMENTAL (X86 || ARM) \ + depends on DEBUG_KERNEL EXPERIMENTAL (X86 || ARM || PPC) \ !MEMORY_HOTPLUG select DEBUG_FS if SYSFS select STACKTRACE if STACKTRACE_SUPPORT -- 1.6.2.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
On Wed, 2009-07-15 at 17:49 +1000, Benjamin Herrenschmidt wrote: Upcoming paches to support the new 64-bit BookE powerpc architecture will need to have the virtual address corresponding to PTE page when freeing it, due to the way the HW table walker works. I haven't had a chance to test or even build on most architectures, the patch is reasonably trivial but I may have screwed up regardless, I appologize in advance, let me know if something is wrong. Builds for the important architectures, powerpc, ia64, arm, sparc, sparc64, oh and x86: http://kisskb.ellerman.id.au/kisskb/head/1976/ (based on your test branch 34f25476) cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Hold reference to device_node during EEH event handling
On Wed, 2009-07-15 at 14:43 -0700, Mike Mason wrote:
This patch increments the device_node reference counter when an EEH
error occurs and decrements the counter when the event has been
handled. This is to prevent the device_node from being released until
eeh_event_handler() has had a chance to deal with the event. We've
seen cases where the device_node is released too soon when an EEH
event occurs during a dlpar remove, causing the event handler to
attempt to access bad memory locations.
Please review and let me know of any concerns.
Taking a reference sounds sane, but ...
Signed-off-by: Mike Mason mm...@us.ibm.com
--- a/arch/powerpc/platforms/pseries/eeh_event.c 2008-10-09
15:13:53.0 -0700
+++ b/arch/powerpc/platforms/pseries/eeh_event.c 2009-07-14
14:14:00.0 -0700
@@ -75,6 +75,14 @@ static int eeh_event_handler(void * dumm
if (event == NULL)
return 0;
+ /* EEH holds a reference to the device_node, so if it
+ * equals 1 it's no longer valid and the event should
+ * be ignored */
+ if (atomic_read(event-dn-kref.refcount) == 1) {
+ of_node_put(event-dn);
+ return 0;
+ }
That's really gross :)
And what happens if the refcount goes to 1 just after the check? ie.
here.
/* Serialize processing of EEH events */
mutex_lock(eeh_event_mutex);
eeh_mark_slot(event-dn, EEH_MODE_RECOVERING);
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote: On Wed, Jul 15, 2009 at 05:49:47PM +1000, Benjamin Herrenschmidt wrote: Upcoming paches to support the new 64-bit BookE powerpc architecture will need to have the virtual address corresponding to PTE page when freeing it, due to the way the HW table walker works. Basically, the TLB can be loaded with large pages that cover the whole virtual space (well, sort-of, half of it actually) represented by a PTE page, and which contain an indirect bit indicating that this TLB entry RPN points to an array of PTEs from which the TLB can then create direct entries. RPN is PFN in ppc speak, right? Ah right, real page number in ppc slang :-) Thus, in order to invalidate those when PTE pages are deleted, we need the virtual address to pass to tlbilx or tlbivax instructions. Interesting arrangement. So are these last level ptes modifieable from userspace or something? If not, I wonder if you could manage them as another level of pointers with the existing pagetable functions? I don't understand what you mean. Basically, the TLB contains PMD's. There's nothing to change to the existing page table layout :-) But because they appear as large page TLB entries that cover the virtual space covered by a PMD, they need to be invalidated using virtual addresses when PMDs are removed. The old trick of sticking it somewhere in the PTE page struct page sucks too much, the address is almost readily available in all call sites and almost everybody implemets these as macros, so we may as well add the argument everywhere. I added it to the pmd and pud variants for consistency. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- I would like to merge the new support that depends on this in 2.6.32, so unless there's major objections, I'd like this to go in early during the merge window. We can sort out separately how to carry the patch around in -next until then since the powerpc tree will have a dependency on it. Can't see any problem with that. Thanks, can I get an Ack then ? :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
On Thu, 2009-07-16 at 11:36 +1000, Michael Ellerman wrote: Builds for the important architectures, powerpc, ia64, arm, sparc, sparc64, oh and x86: http://kisskb.ellerman.id.au/kisskb/head/1976/ (based on your test branch 34f25476) Note for all lurkers: the fails in there are unrelated to the patch (mostly warnings triggering our new Werror and probably mostly fixed upstream already). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/15] swiotlb: remove unnecessary swiotlb_bus_to_virt
On Mon, 2009-07-13 at 21:17 -0500, Becky Bruce wrote: phys_to_virt (also, virt_to_phys) is invalid for highmem addresses on ppc. I would be surprised if x86 was any different here. Most of our highmem implementation comes straight from x86 :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ethernet driver - problem capturing own packet in promiscous mode
On Wed, Jul 15, 2009 at 5:52 PM, Cote, Sylvain sylvain.c...@verint.comwrote: Hi all In ethernet driver i need to enable promiscous mode and have to capture the packet that is sent by the same ethernet. The board is connected to a packet generator and could send/receive packets whenever i need . In the board ethernet driver , I made sure that am sending only broadcast packets and promisc mode is enabled but the packets are not captured. If i am sending a packet to the board from packetgenerator it is receiving. Could any one please suggest me any clues. Having the promisc enabled: Packet sent by packetgenerator is received by board. Packet sent by board is received by packetgenerator, The same packet should be captured by board as promiscuous is enabled. but not happening. The Ethernet interface that sent the packet will never receive the packet it sent even if you are in promiscuous mode. To be able to do that you should put your interface in loopback mode. In promiscuous mode, you will be able to receive any packets sent by other interfaces (broadcast, multicast and also unicast that is not directed to you interface MAC address). But not from your interface. Thanks for your inputs Sylvain. I tried with loopback, it is working. But during the time the hardware is in lopback mode, it may miss some rx packets coming from outside or packet generator unfortunately and i dont want it to happen. Please let me know your views and suggestions. Thanks Sudheer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: booting MPC8313 based board with yaffs2 RFS
Hi Thanks for reply. After erasing one of the flash partition, i mounted it as yaffs2 and manually created rootfs there. Though it (careting RFS in NAND partiton) marked blocks bad, I am able to boot with this yaffs2 filesystem. When image is created with mkyffs2image binary, board does not boot with that and says kernel panic. 1. What nand flash is on-board? what's the size of the nand flash page size, 512/2048? Nand Flash used on board is K9F2G08U0M-P from Samsung and page size is 2048. 2. what's the version of mkyaffs2image you are using? mkyaffs2image: image building tool for YAFFS2 built Jan 31 2009 3. Can you mount an empty nand flash partition using yaffs2 type, mount /dev/mtdblock##x xxx Yes, i wrote RFS contents to the nand flash partition and booted with that. 4. It's better to attatch bootup message. Bootup message is attached for both conditions 1) booting with manually created RFS on flash drive mounted as yaffs2(boot-up_manual_RFS.txt). 2) booting with yaffs2 image created by mkyaffs2image tool. Note :- below are steps used for writing RFS iamge ~ # flash_eraseall /dev/mtd11 ~ # nandwrite -a -o /dev/mtd11 rootrfs_1.yaffs2 Thanks Rupesh tonyliu bo@windriver.com 07/17/2009 07:37 AM To Rupesh Kumar rupesh.ku...@lntemsys.com cc linuxppc-dev@lists.ozlabs.org Subject Re: booting MPC8313 based board with yaffs2 RFS Rupesh Kumar wrote: Hi I am using MPC8313 board which is currently booting with JFFS2 root file system. I am using linux kernel version 2.6.23 from FreeScale's LTIB for MPC8313. As, I want it to boot with YAFFS2 root file system, I did compile kernel with yaffs2 support, craeted yaffs2 rootfile system and passed yaffs2 partiton of nand in bootargs. However it didnot work. If any one has done it successfully, can please share the steps to be followed ? More detailed info maybe helpful for debugging this issue. 1. What nand flash is on-board? what's the size of the nand flash page size, 512/2048? 2. what's the version of mkyaffs2image you are using? 3. Can you mount an empty nand flash partition using yaffs2 type, mount /dev/mtdblock##x xxx 4. It's better to attatch bootup message. Tony Thanks Rupesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev U-Boot 1.3.0-S600-Ver1.0 (Jul 16 2009 - 00:03:56) MPC83XX Reset Status: Software Hard, External/Internal Soft, External/Internal Hard CPU: e300c3, Rev: Unknown revision number:80b10021 Warning: Unsupported cpu revision! Board: S600 CPU BOARD I2C: ready DRAM: 128 MB FLASH: 16 MB NAND: 256 MiB In:serial Out: serial Err: serial Net: TSEC0, TSEC1 [PRIME] Hit any key to stop autoboot: 6 5 4 3 2 1 0 Speed: 100, full duplex Using TSEC1 device TFTP from server 192.168.6.251; our IP address is 192.168.34.10; sending through gateway 192.168.32.47 Filename 'uImage_yaffs2'. Load address: 0x20 Loading: *# # done Bytes transferred = 1669252 (197884 hex) ## Booting image at 0020 ... Image Name: Linux-2.6.23-S600-Ver1.0 Created: 2009-07-16 2:03:41 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1669188 Bytes = 1.6 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0xfe90 Loading Device Tree to 007fd000, end 007fef4f ... OK Using MPC8313 RDB machine description Linux version 2.6.23-S600-Ver1.0 (r...@leapfrogserver) (gcc version 4.1.2) #71 Thu Jul 16 07:33:39 IST 2009 console [udbg0] enabled setup_arch: bootmem mpc8313_rdb_setup_arch() Found MPC83xx PCI host bridge at 0xe0008500. Firmware bus number: 0-0 arch: exit Zone PFN ranges: DMA 0 -32768 Normal 32768 -32768 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -32768 Built 1 zonelists in Zone order. Total pages: 32512 Kernel command line: root=/dev/mtdblock12 rootfstype=yaffs2 rw console=ttyS0,115200 IPIC (128 IRQ sources) at fdef9700 PID hash table entries: 512 (order: 9, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 126220k/131072k available (3288k kernel code, 4712k reserved, 148k data, 96k bss, 152k init) Mount-cache hash table entries: 512 NET: Registered protocol family 16 PCI: Probing PCI hardware Generic PHY: Registered new driver SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 IP route cache hash table entries: 1024
