[RFC][PATCH] powerpc: Use the #address-cells information to parse memory/reg
Use the #address-cells, #size-cells information to parse the memory/reg info
from device tree.
The format of memory/reg is based on the #address-cells,#size-cells. Currently,
the kexec-tools doesn't use the above values in parsing the memory/reg values.
Hence the kexec cannot handle cases where #address-cells, #size-cells are
different, (for e.g, PPC440X ).
This patch introduces a read_memory_region_limits(), which parses the
memory/reg contents based on the values of #address-cells and #size-cells.
Changed the add_usable_mem_property() to accept FILE* fp instead of int fd,
as most of the other users of read_memory_region_limits() deals with FILE*.
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
---
kexec/arch/ppc/crashdump-powerpc.c | 23 --
kexec/arch/ppc/fs2dt.c | 31 ++--
kexec/arch/ppc/kexec-ppc.c | 136 ++---
kexec/arch/ppc/kexec-ppc.h |6 +
4 files changed, 118 insertions(+), 78 deletions(-)
Index: kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
===
--- kexec-tools-2.0.4.orig/kexec/arch/ppc/kexec-ppc.c
+++ kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
@@ -26,6 +26,7 @@
#include config.h
+unsigned long dt_address_cells = 0, dt_size_cells = 0;
uint64_t rmo_top;
unsigned long long crash_base = 0, crash_size = 0;
unsigned long long initrd_base = 0, initrd_size = 0;
@@ -34,6 +35,92 @@ unsigned int rtas_base, rtas_size;
int max_memory_ranges;
const char *ramdisk;
+/*
+ * Reads the #address-cells and #size-cells on this platform.
+ * This is used to parse the memory/reg info from the device-tree
+ */
+int init_memory_region_info()
+{
+ size_t res = 0;
+ FILE *fp;
+ char *file;
+
+ file = /proc/device-tree/#address-cells;
+ fp = fopen(file, r);
+ if (!fp) {
+ fprintf(stderr,Unable to open %s\n, file);
+ return -1;
+ }
+
+ res = fread(dt_address_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,Error reading %s\n, file);
+ return -1;
+ }
+ fclose(fp);
+ dt_address_cells *= sizeof(unsigned long);
+
+ file = /proc/device-tree/#size-cells;
+ fp = fopen(file, r);
+ if (!fp) {
+ fprintf(stderr,Unable to open %s\n, file);
+ return -1;
+ }
+
+ res = fread(dt_size_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,Error reading %s\n, file);
+ return -1;
+ }
+ fclose(fp);
+ dt_size_cells *= sizeof(unsigned long);
+
+ return 0;
+}
+
+#define MAXBYTES 128
+/*
+ * Reads the memory region info from the device-tree node pointed
+ * by @fp and fills the *start, *end with the boundaries of the region
+ */
+int read_memory_region_limits(FILE* fp, unsigned long long *start,
+ unsigned long long *end)
+{
+ char buf[MAXBYTES];
+ unsigned long *p;
+ unsigned long nbytes = dt_address_cells + dt_size_cells;
+
+ if (fread(buf, 1, MAXBYTES, fp) != nbytes) {
+ fprintf(stderr, Error reading the memory region info\n);
+ return -1;
+ }
+
+ p = (unsigned long*)buf;
+ if (dt_address_cells == sizeof(unsigned long)) {
+ *start = p[0];
+ p++;
+ } else if (dt_address_cells == sizeof(unsigned long long)) {
+ *start = ((unsigned long long *)p)[0];
+ p = (unsigned long long *)p + 1;
+ } else {
+ fprintf(stderr,Unsupported value for #address-cells : %ld\n,
+ dt_address_cells);
+ return -1;
+ }
+
+ if (dt_size_cells == sizeof(unsigned long))
+ *end = *start + p[0];
+ else if (dt_size_cells == sizeof(unsigned long long))
+ *end = *start + ((unsigned long long *)p)[0];
+ else {
+ fprintf(stderr,Unsupported value for #size-cells : %ld\n,
+ dt_size_cells);
+ return -1;
+ }
+
+ return 0;
+}
+
void arch_reuse_initrd(void)
{
reuse_initrd = 1;
@@ -182,9 +269,6 @@ static int sort_base_ranges(void)
return 0;
}
-
-#define MAXBYTES 128
-
static int realloc_memory_ranges(void)
{
size_t memory_range_len;
@@ -248,6 +332,8 @@ static int get_base_ranges(void)
return -1;
}
while ((mentry = readdir(dmem)) != NULL) {
+ unsigned long long start, end;
+
if (strcmp(mentry-d_name, reg))
continue;
strcat(fname, /reg);
@@ -257,8 +343,7 @@ static int get_base_ranges(void)
closedir(dir);
return -1;
}
-
[RFC][PATCH] Kexec support for PPC440x
KEXEC Support for ppc440X The patch adds kexec support for PPC440x based boards. This work is based on the KEXEC patches for FSL BookE. The FSL BookE patch and the code flow could be found at the link below: http://patchwork.ozlabs.org/patch/49359/ We invalidate all the TLB entries except the one this code is run from, and create a 1:1 mapping for 0-2GiB in blocks of 256M. Later we jump to the 1:1 mapping. I have tested this patches on Ebony and Sequoia boards. It would be great if somebody could test this on the other boards. Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com --- arch/powerpc/Kconfig|2 arch/powerpc/include/asm/kexec.h|2 arch/powerpc/kernel/44x_kexec_mapping.S | 66 arch/powerpc/kernel/misc_32.S | 22 ++ 4 files changed, 90 insertions(+), 2 deletions(-) Index: powerpc/arch/powerpc/Kconfig === --- powerpc.orig/arch/powerpc/Kconfig +++ powerpc/arch/powerpc/Kconfig @@ -349,7 +349,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE config KEXEC bool kexec system call (EXPERIMENTAL) - depends on (PPC_BOOK3S || FSL_BOOKE) EXPERIMENTAL + depends on (PPC_BOOK3S || FSL_BOOKE || (44x !SMP !47x)) EXPERIMENTAL help kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot Index: powerpc/arch/powerpc/include/asm/kexec.h === --- powerpc.orig/arch/powerpc/include/asm/kexec.h +++ powerpc/arch/powerpc/include/asm/kexec.h @@ -2,7 +2,7 @@ #define _ASM_POWERPC_KEXEC_H #ifdef __KERNEL__ -#ifdef CONFIG_FSL_BOOKE +#if defined(CONFIG_FSL_BOOKE) || defined(CONFIG_44x) /* * On FSL-BookE we setup a 1:1 mapping which covers the first 2GiB of memory Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S === --- /dev/null +++ powerpc/arch/powerpc/kernel/44x_kexec_mapping.S @@ -0,0 +1,66 @@ +/* + * Copyright (C) 2011 IBM + * + * Author : Suzuki K. Poulose suz...@in.ibm.com + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + * + * Code for setting up 1:1 mapping for PPC440x for KEXEC + * + * We cannot switch off the MMU on PPC44x. + * So we: + * 1) Invalidate all the mappings except the one we are + * running from. + * 2) Create a 1:1 mapping for 0-2GiB + * + * - Based on the kexec support code for FSL BookE + * - Based on the boot up code for ppc44x from head_44x.S + * - Doesn't support 47x yet. + * - Doesn't support SMP. + * + */ + bl nxtins /* Find our address */ +nxtins:mflrr5 /* Make it accessible */ + tlbsx r23,0,r5/* Find entry we are in */ + li r4,0/* Start at TLB entry 0 */ + li r3,0/* Set PAGEID inval value */ +1: cmpwr23,r4 /* Is this our entry? */ + beq skip/* If so, skip the inval */ + tlbwe r3,r4,PPC44x_TLB_PAGEID /* If not, inval the entry */ +skip: addir4,r4,1 /* Increment */ + cmpwi r4,64 /* Are we done? */ + bne 1b /* If not, repeat */ + isync + +/* + * Setup 1:1 mapping for 0-2GiB in blocks of 256M. + * r23 is the index to the mapping of this code. + * Skip it. + */ + /* attribute fields. rwx for SUPERVISOR mode */ + li r5, 0 + ori r5, r5, (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G) + + li r11, 0 /* PageNumber */ + li r6, 0 /* TLB Index */ + +next_tlb: + rotlwi r3, r11, 28 /* Create EPN (bits 0-3) */ + mr r4, r3 /* RPN = EPN */ + ori r3, r3, PPC44x_TLB_VALID | PPC44x_TLB_256M /* SIZE = 256M, Valid */ + cmpwr6, r23 /* Is this our TLB entry ? */ + bne write_tlb + addir6, r6, 1 /* Skip our entry */ + +write_tlb: + tlbwe r3, r6, PPC44x_TLB_PAGEID /* PageID field : EPN, V, SIZE */ + tlbwe r4, r6, PPC44x_TLB_XLAT /* Address translation : RPN */ + tlbwe r5, r6, PPC44x_TLB_ATTRIB /* Attributes */ + + addir11, r11, 1 /* Increment PN */ + addir6, r6, 1 /* Increment TLB Index */ + cmpwi r11, 8 /* Are we done ? */ + bne next_tlb + isync + Index: powerpc/arch/powerpc/kernel/misc_32.S
Re: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307 driver
Hi, Priyanka, Yes, It is possible to directly use platform device 'ds1307' in device tree. Great, thanks for testing. But I have one query of how to capture the information that pericom, pt7c4338 device is compatible with dallas, ds1307. Can it be done in somewhere in some document or some code. Actually for pt7c4338 device Yes, it should definately be documented in the source. driver, I actually started by asking if there is any already existing rtc device driver which is compatible with pericom pt7c4338 device on mailing list and as there was no answer or help then, I actually ended up writing device driver for that The first place where this should be mentioned is the datasheet of the pt-chip, so you might ask the producer to add this information (don't expect much to happen, though). For such generic devices, it is then useful to look for similar register sets in existing drivers to find a duplicate. Please don't forget that such lists are voluntary, there is no guarantee that mails get replied to. and then on the suggestion using ds1307 device driver for this. IIRC I asked you explicitly for the differences between the chips. If there are none, you can use the driver directly, right? :) Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mpic: support compiling with DEBUG enabled
Support compilation of mpic.c with DEBUG defined, as now we have irq_desc and not irq number. Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com --- arch/powerpc/sysdev/mpic.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c index 3a8de5b..3f995dc 100644 --- a/arch/powerpc/sysdev/mpic.c +++ b/arch/powerpc/sysdev/mpic.c @@ -848,7 +848,7 @@ static void mpic_unmask_tm(struct irq_data *d) struct mpic *mpic = mpic_from_irq_data(d); unsigned int src = virq_to_hw(d-irq) - mpic-timer_vecs[0]; - DBG(%s: enable_tm: %d (tm %d)\n, mpic-name, irq, src); + DBG(%s: enable_tm: %d (tm %d)\n, mpic-name, d-irq, src); mpic_tm_write(src, mpic_tm_read(src) ~MPIC_VECPRI_MASK); mpic_tm_read(src); } -- 1.7.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add cpufreq driver for Momentum Maple boards
Hello, On 5/21/11, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: Add simple cpufreq driver for Maple-based boards (ppc970fx evaluation kit and others). Driver is based on a cpufreq driver for 64-bit powermac boxes with all pmac-dependant features removed and simple cleanup applied. Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com --- arch/powerpc/kernel/misc_64.S |4 +- arch/powerpc/platforms/Kconfig |8 + arch/powerpc/platforms/maple/Makefile |1 + arch/powerpc/platforms/maple/cpufreq.c | 317 4 files changed, 328 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/platforms/maple/cpufreq.c What about this patch? -- With best wishes Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] 2.6.39 powerpc: Fix 32-bit SMP build
Backport upstream commit 6de06f313a65d0ec Commit fa3f82c8bb7acb (powerpc/smp: soft-replugged CPUs must go back to start_secondary) introduced start_secondary_resume to head_32.S, however it uses a 64-bit instruction which is not valid on 32-bit platforms. Use 'stw' instead. CC: sta...@kernel.org Signed-off-by: Josh Boyer jwbo...@linux.vnet.ibm.com --- diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S index c5c24be..727f40a 100644 --- a/arch/powerpc/kernel/head_32.S +++ b/arch/powerpc/kernel/head_32.S @@ -896,7 +896,7 @@ _GLOBAL(start_secondary_resume) rlwinm r1,r1,0,0,(31-THREAD_SHIFT) /* current_thread_info() */ addir1,r1,THREAD_SIZE-STACK_FRAME_OVERHEAD li r3,0 - std r3,0(r1)/* Zero the stack frame pointer */ + stw r3,0(r1)/* Zero the stack frame pointer */ bl start_secondary b . #endif /* CONFIG_SMP */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307 driver
On Mon, May 30, 2011 at 3:24 AM, Wolfram Sang w.s...@pengutronix.de wrote: The first place where this should be mentioned is the datasheet of the pt-chip, so you might ask the producer to add this information (don't expect much to happen, though). It's true that the data sheet does not mention that it's identical to the DS1307, but that's still no excuse for not noticing it and writing a whole driver for it. :-( IIRC I asked you explicitly for the differences between the chips. If there are none, you can use the driver directly, right? :) Yes. The device tree node for the PT7C4338 device should just say /* The board has a PT7C4338, which is compatible with the DS1307 */ compatible = dallas,ds1307; And that's it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307 driver
IIRC I asked you explicitly for the differences between the chips. If there are none, you can use the driver directly, right? :) Yes. The device tree node for the PT7C4338 device should just say /* The board has a PT7C4338, which is compatible with the DS1307 */ compatible = dallas,ds1307; And that's it. I'd also suggest to add a comment to the id_table in rtc-ds1307.c, so the chip name can be grepped for. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307 driver
On Mon, May 30, 2011 at 02:29:58PM +, Tabi Timur-B04825 wrote: On Mon, May 30, 2011 at 3:24 AM, Wolfram Sang w.s...@pengutronix.de wrote: The first place where this should be mentioned is the datasheet of the pt-chip, so you might ask the producer to add this information (don't expect much to happen, though). It's true that the data sheet does not mention that it's identical to the DS1307, but that's still no excuse for not noticing it and writing a whole driver for it. :-( IIRC I asked you explicitly for the differences between the chips. If there are none, you can use the driver directly, right? :) Yes. The device tree node for the PT7C4338 device should just say /* The board has a PT7C4338, which is compatible with the DS1307 */ compatible = dallas,ds1307; While it seems to be 100% compatible, there could be chip-specific bugs or some interesting features that are hidden behind reserved bits and registers. So I think device tree should not lie about the chip model. Doing 'compatible = pericom,pt7c4338, dallas,ds1307' is perfectly fine. Note that today the several compatible entries approach gives you almost nothing, as you will need to add pt7c4338 entry into the driver anyway. I tried to improve this, i.e. make linux do OF-matching on the most generic compatible entry (the last one): http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg21196.html It was received coldly though: http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg22041.html http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg21273.html -- Anton Vorontsov Email: cbouatmai...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PMAC_ZILOG serial driver locks up.
The powerpc systems I emulate under qemu use the mac99 board emulation, which routes the serial console through a PMAC_ZILOG serial chip. It got screwed up by Alan Cox's refactoring of the tty layer in 2.6.28: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078700.html And then partially fixed here: http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40477.html However, if significant input and output traffic overlaps, the serial port locks up. Here's a test for that. Grab this tarball: http://landley.net/aboriginal/downloads/binaries/system-image-powerpc.tar.bz2 And do this: echo -e \necho hello world | ./run-emulator.sh That's echo a line of 20 spaces, a newline, and a command to see if it makes it through to the comand prompt. Data makes it out the serial console right up until init launches (and interrupts are enabled), then it locks hard. if you just ./run-emulator.sh directly and don't type anything until you get a shell prompt, it works fine. It's the data crossing in both directions at once that screws the driver up. Trivially reproducible. I've tested back to 2.6.32 and it was doing it back then. (2.6.31 was a build break.) Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] 2.6.39 powerpc: Fix 32-bit SMP build
On Mon, 2011-05-30 at 08:26 -0400, Josh Boyer wrote: Backport upstream commit 6de06f313a65d0ec Commit fa3f82c8bb7acb (powerpc/smp: soft-replugged CPUs must go back to start_secondary) introduced start_secondary_resume to head_32.S, however it uses a 64-bit instruction which is not valid on 32-bit platforms. Use 'stw' instead. CC: sta...@kernel.org Signed-off-by: Josh Boyer jwbo...@linux.vnet.ibm.com Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S index c5c24be..727f40a 100644 --- a/arch/powerpc/kernel/head_32.S +++ b/arch/powerpc/kernel/head_32.S @@ -896,7 +896,7 @@ _GLOBAL(start_secondary_resume) rlwinm r1,r1,0,0,(31-THREAD_SHIFT) /* current_thread_info() */ addir1,r1,THREAD_SIZE-STACK_FRAME_OVERHEAD li r3,0 - std r3,0(r1)/* Zero the stack frame pointer */ + stw r3,0(r1)/* Zero the stack frame pointer */ bl start_secondary b . #endif /* CONFIG_SMP */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
Hi, This is an SMP machine ? If not, does it work with a UP kernel ? Cheers, Ben. ??? Even if it is SMP, you can run non-SMP kernel on it, right? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
On Mon, 2011-05-30 at 17:11 -0500, kevin diggs wrote: Hi, This is an SMP machine ? If not, does it work with a UP kernel ? Cheers, Ben. ??? Even if it is SMP, you can run non-SMP kernel on it, right? Yes, I was asking whether the bug also occured with an UP kernel. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
