* Re: [PATCH/RFCv2] [POWERPC] Add support for freescale watchdog to CPM serial driver.
From: Kumar Gala @ 2008-01-18 21:51 UTC (permalink / raw)
To: Alan Cox; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <20080118204030.48fbb683@lxorguk.ukuu.org.uk>
On Jan 18, 2008, at 2:40 PM, Alan Cox wrote:
> On Fri, 18 Jan 2008 19:47:43 +0100
> Jochen Friedrich <jochen@scram.de> wrote:
>
>> Hi Alan,
>>
>>>> If a freescale watchdog device node is present, reset the watchdog
>>>> while waiting for serial input.
>>>
>>> Why ? We normally rely on user space for watchdog management as
>>> only the
>>> fact user space is behaving really proves a box is happy ?
>>
>> This is in the boot wrapper code, not in the linux kernel.
>
> Ok now that makes sense, thanks
So I'll ask, what serial input are you waiting for from the boot
wrapper?
- k
^ permalink raw reply
* Re: [PATCH/RFCv2] [POWERPC] Add support for freescale watchdog to CPM serial driver.
From: Scott Wood @ 2008-01-18 21:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Alan Cox, linux-kernel
In-Reply-To: <EC416CBA-9200-4D71-8D95-39798937203D@kernel.crashing.org>
Kumar Gala wrote:
> So I'll ask, what serial input are you waiting for from the boot wrapper?
The bootwrapper has a command line editing prompt. It's fairly
gratuitous in the presence of semi-decent firmware, but it's there
nonetheless.
-Scott
^ permalink raw reply
* Re: [PATCH] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
From: Kumar Gala @ 2008-01-18 21:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080114162935.GA27862@ld0162-tx32.am.freescale.net>
On Mon, 14 Jan 2008, Scott Wood wrote:
> The reg property in fsl soc nodes should be removed.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_soc.c | 14 +++++++++++---
> 1 files changed, 11 insertions(+), 3 deletions(-)
applied. (dropped the size == 12 check).
- k
^ permalink raw reply
* Re: [PATCH/RFCv2] [POWERPC] Add support for freescale watchdog to CPM serial driver.
From: Jochen Friedrich @ 2008-01-18 21:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, linux-kernel, Alan Cox
In-Reply-To: <EC416CBA-9200-4D71-8D95-39798937203D@kernel.crashing.org>
Hi Kumar,
>> Ok now that makes sense, thanks
>
> So I'll ask, what serial input are you waiting for from the boot wrapper?
It's the editor for the kernel command line.
Thanks,
Jochen
^ permalink raw reply
* External audio clock with MPC5200B
From: Jon Smirl @ 2008-01-18 21:56 UTC (permalink / raw)
To: Linux/PPC Development
Has anyone tried using an external audio clock chip with the MPC5200B?
We've discovered that the on-chip clock dividers aren't flexible
enough and have too much error in the final frequencies. The level of
error is ok for iPod type use but not for playing broadcast music.
192K sample rate is totally messed up with a 2.7% error.
Note to chip designers - USB and 44.1Khz are not compatible
frequencies and can't share the same PLL without FractionalN dividers
on the audio clock. Freescale MX31/MX21 both have separate PLLs for
UBS and audio.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH/RFCv2] [POWERPC] Add support for freescale watchdog to CPM serial driver.
From: Kumar Gala @ 2008-01-18 22:08 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Scott Wood, linuxppc-dev, linux-kernel, Alan Cox
In-Reply-To: <47912088.4040507@scram.de>
On Jan 18, 2008, at 3:56 PM, Jochen Friedrich wrote:
> Hi Kumar,
>
>>> Ok now that makes sense, thanks
>> So I'll ask, what serial input are you waiting for from the boot
>> wrapper?
>
> It's the editor for the kernel command line.
thanks, learn something everyday.
- k
^ permalink raw reply
* [PATCH/RFCv3] [POWERPC] Add support for freescale watchdog to CPM serial driver.
From: Jochen Friedrich @ 2008-01-18 22:12 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Scott Wood, linux-kernel
If a freescale watchdog device node is present, reset the watchdog
while waiting for serial input.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/boot/Makefile | 2 +-
arch/powerpc/boot/cpm-serial.c | 6 +++
arch/powerpc/boot/cuboot-8xx.c | 1 +
arch/powerpc/boot/ops.h | 8 ++++
arch/powerpc/boot/watchdog.c | 81 ++++++++++++++++++++++++++++++++++++++++
5 files changed, 97 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/watchdog.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d1e625c..66edf77 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -56,7 +56,7 @@ src-wlib := string.S crt0.S stdio.c main.c \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
- fsl-soc.c mpc8xx.c pq2.c
+ fsl-soc.c mpc8xx.c pq2.c watchdog.c
src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
diff --git a/arch/powerpc/boot/cpm-serial.c b/arch/powerpc/boot/cpm-serial.c
index 28296fa..56b5fda 100644
--- a/arch/powerpc/boot/cpm-serial.c
+++ b/arch/powerpc/boot/cpm-serial.c
@@ -6,6 +6,9 @@
*
* It is assumed that the firmware (or the platform file) has already set
* up the port.
+ *
+ * If a watchdog node exists, periodically reset the watchdog while waiting
+ * for console input.
*/
#include "types.h"
@@ -154,6 +157,9 @@ static void cpm_serial_putc(unsigned char c)
static unsigned char cpm_serial_tstc(void)
{
+
+ watchdog_poke();
+
barrier();
return !(rbdf->sc & 0x8000);
}
diff --git a/arch/powerpc/boot/cuboot-8xx.c b/arch/powerpc/boot/cuboot-8xx.c
index c202c88..767670e 100644
--- a/arch/powerpc/boot/cuboot-8xx.c
+++ b/arch/powerpc/boot/cuboot-8xx.c
@@ -43,5 +43,6 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
CUBOOT_INIT();
fdt_init(_dtb_start);
serial_console_init();
+ watchdog_init();
platform_ops.fixups = platform_fixups;
}
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index 6036a98..cc97e2b 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -70,6 +70,12 @@ struct serial_console_data {
void (*close)(void);
};
+/* Watchdog operations */
+struct watchdog_ops {
+ void (*poke)(void);
+};
+extern struct watchdog_ops watchdog_ops;
+
struct loader_info {
void *promptr;
unsigned long initrd_addr, initrd_size;
@@ -86,6 +92,8 @@ int mpsc_console_init(void *devp, struct serial_console_data *scdp);
int cpm_console_init(void *devp, struct serial_console_data *scdp);
int mpc5200_psc_console_init(void *devp, struct serial_console_data *scdp);
int uartlite_console_init(void *devp, struct serial_console_data *scdp);
+void watchdog_poke(void);
+void watchdog_init(void);
void *simple_alloc_init(char *base, unsigned long heap_size,
unsigned long granularity, unsigned long max_allocs);
extern void flush_cache(void *, unsigned long);
diff --git a/arch/powerpc/boot/watchdog.c b/arch/powerpc/boot/watchdog.c
new file mode 100644
index 0000000..2bdee77
--- /dev/null
+++ b/arch/powerpc/boot/watchdog.c
@@ -0,0 +1,81 @@
+/*
+ * PQ Watchdog
+ *
+ * Copyright 2008 Jochen Friedrich <jochen@scram.de>
+ *
+ * Search for PowerQUICC type watchdog devices. Provide a callback to
+ * periodically reset the watchdog while waiting for console input.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include "types.h"
+#include "io.h"
+#include "ops.h"
+
+struct watchdog_ops watchdog_ops;
+
+/* pq Watchdog */
+
+struct pq_wdt {
+ u32 res0;
+ u32 swcrr; /* System watchdog control register */
+ u32 swcnr; /* System watchdog count register */
+ u8 res1[2];
+ u16 swsrr; /* System watchdog service register */
+};
+
+static struct pq_wdt *pq_wdt;
+
+static void pq_poke(void)
+{
+ out_be16(&pq_wdt->swsrr, 0x556c);
+ out_be16(&pq_wdt->swsrr, 0xaa39);
+}
+
+static void pq_init(void *wdt_node)
+{
+ int n;
+ void *reg_virt[2];
+ unsigned long reg_phys;
+
+ n = getprop(wdt_node, "virtual-reg", reg_virt, sizeof(reg_virt));
+ if (n < (int)sizeof(reg_virt)) {
+ if (!dt_xlate_reg(wdt_node, 0, ®_phys, NULL))
+ return;
+ reg_virt[0] = (void *)reg_phys;
+ }
+ pq_wdt = reg_virt[0];
+ if (pq_wdt)
+ watchdog_ops.poke = pq_poke;
+}
+
+/* generic watchdog */
+
+void watchdog_poke(void)
+{
+ if (watchdog_ops.poke)
+ watchdog_ops.poke();
+}
+
+void watchdog_init(void)
+{
+ void *watchdog;
+
+ watchdog = finddevice("/soc/wdt");
+ if (watchdog && (dt_is_compatible(watchdog, "fsl,pq1-wdt") ||
+ dt_is_compatible(watchdog, "fsl,pq2-wdt") ||
+ dt_is_compatible(watchdog, "fsl,pq2pro-wdt")))
+ pq_init(watchdog);
+}
--
1.5.3.8
^ permalink raw reply related
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-18 22:16 UTC (permalink / raw)
To: Olaf Hering
Cc: lee.schermerhorn, Linux MM, Mel Gorman, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
KAMEZAWA Hiroyuki
In-Reply-To: <20080118213011.GC10491@csn.ul.ie>
Could you try this patch?
Memoryless nodes: Set N_NORMAL_MEMORY for a node if we do not support HIGHMEM
It seems that we only scan through zones to set N_NORMAL_MEMORY only if
CONFIG_HIGHMEM and CONFIG_NUMA are set. We need to set N_NORMAL_MEMORY
in the !CONFIG_HIGHMEM case.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6/mm/page_alloc.c
===================================================================
--- linux-2.6.orig/mm/page_alloc.c 2008-01-18 14:08:41.000000000 -0800
+++ linux-2.6/mm/page_alloc.c 2008-01-18 14:13:34.000000000 -0800
@@ -3812,7 +3812,6 @@ restart:
/* Any regular memory on that node ? */
static void check_for_regular_memory(pg_data_t *pgdat)
{
-#ifdef CONFIG_HIGHMEM
enum zone_type zone_type;
for (zone_type = 0; zone_type <= ZONE_NORMAL; zone_type++) {
@@ -3820,7 +3819,6 @@ static void check_for_regular_memory(pg_
if (zone->present_pages)
node_set_state(zone_to_nid(zone), N_NORMAL_MEMORY);
}
-#endif
}
/**
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Nish Aravamudan @ 2008-01-18 22:19 UTC (permalink / raw)
To: Christoph Lameter
Cc: lee.schermerhorn, Olaf Hering, Linux MM, Mel Gorman, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0801181414200.8924@schroedinger.engr.sgi.com>
On 1/18/08, Christoph Lameter <clameter@sgi.com> wrote:
> Could you try this patch?
>
> Memoryless nodes: Set N_NORMAL_MEMORY for a node if we do not support
> HIGHMEM
>
> It seems that we only scan through zones to set N_NORMAL_MEMORY only if
> CONFIG_HIGHMEM and CONFIG_NUMA are set. We need to set
> N_NORMAL_MEMORY
> in the !CONFIG_HIGHMEM case.
I'm testing this exact patch right now on the machine Mel saw the issues with.
Thanks,
Nish
^ permalink raw reply
* RE: A file of 5 MB on tmpfs file system uses 5 MB of RAM or more?
From: DI BACCO ANTONIO - technolabs @ 2008-01-18 22:23 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20080118155853.GA15620@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
No I simply did several malloc(s) without writing to the allocated space.
This means that the pages are not allocated really?
-----Original Message-----
From: Scott Wood [mailto:scottwood@freescale.com]
Sent: Fri 18/01/2008 16.58
To: DI BACCO ANTONIO - technolabs
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: A file of 5 MB on tmpfs file system uses 5 MB of RAM or more?
On Fri, Jan 18, 2008 at 02:15:02PM +0100, DI BACCO ANTONIO - technolabs wrote:
> I have a linux-2.6.19.2 board with an MPC880 with 16MB ram and 16 MB
> flash.
> Normally I have 9-10 MB of free RAM.
>
> If I allocate 5 MB of ram memory, the system continues to work normally,
Are you sure the RAM was actually allocated (i.e. did you write to all of
the pages)?
-Scott
[-- Attachment #2: Type: text/html, Size: 1346 bytes --]
^ permalink raw reply
* Re: A file of 5 MB on tmpfs file system uses 5 MB of RAM or more?
From: Scott Wood @ 2008-01-18 22:25 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8E264A19@aquib01a>
DI BACCO ANTONIO - technolabs wrote:
> No I simply did several malloc(s) without writing to the allocated space.
>
> This means that the pages are not allocated really?
Correct.
-Scott
^ permalink raw reply
* Re: [PATCH 4/4] IB/ehca: Prevent RDMA-related connection failures
From: Roland Dreier @ 2008-01-18 22:27 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, OF-EWG, LinuxPPC-Dev, Christoph Raisch, OF-General,
Stefan Roscher
In-Reply-To: <200801171507.25145.fenkes@de.ibm.com>
thanks, applied 1-4.
^ permalink raw reply
* Re: [PATCH 05/10] powerpc: Add crash kernel support for 85xx
From: Kumar Gala @ 2008-01-18 22:29 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20071214172315.GA26448@xyzzy.farnsworth.org>
On Dec 14, 2007, at 11:23 AM, Dale Farnsworth wrote:
> On Fri, Dec 14, 2007 at 10:48:58AM -0600, Kumar Gala wrote:
>> On Nov 22, 2007, at 9:46 AM, Dale Farnsworth wrote:
>>
>>> Add the ability to build a ppc_85xx kernel to run at a physical
>>> address of 32MB.
>>>
>>> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
>>> ---
>>> arch/powerpc/Kconfig | 2 +-
>>> arch/powerpc/kernel/head_fsl_booke.S | 23 ++++++++++++++++++-----
>>> arch/powerpc/mm/fsl_booke_mmu.c | 6 +++---
>>> 3 files changed, 22 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>> index 805b4d1..d405298 100644
>>> --- a/arch/powerpc/Kconfig
>>> +++ b/arch/powerpc/Kconfig
>>> @@ -253,7 +253,7 @@ config KEXEC
>>>
>>> config CRASH_DUMP
>>> bool "Build a kdump crash kernel (EXPERIMENTAL)"
>>> - depends on PPC_MULTIPLATFORM && EXPERIMENTAL
>>> + depends on (PPC_MULTIPLATFORM || PPC_85xx) && EXPERIMENTAL
>>> help
>>> Build a kernel suitable for use as a kdump capture kernel.
>>> The kernel will be linked at a different address than normal, and
>>> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/
>>> kernel/head_fsl_booke.S
>>> index 4b98227..1c9685f 100644
>>> --- a/arch/powerpc/kernel/head_fsl_booke.S
>>> +++ b/arch/powerpc/kernel/head_fsl_booke.S
>>> @@ -41,6 +41,12 @@
>>> #include <asm/asm-offsets.h>
>>> #include "head_booke.h"
>>>
>>> +#ifdef CONFIG_CRASH_DUMP
>>> +#define INITIAL_BOOKE_PAGESZ (BOOKE_PAGESZ_64M)
>>> +#else
>>> +#define INITIAL_BOOKE_PAGESZ (BOOKE_PAGESZ_16M)
>>> +#endif
>>
>> I'm ok with bumping the first page to 64M in all cases.
>
> OK, I'll make that change in the next rev. Thanks.
I'm about to commit a version of this patch, why did you need to bump
to 64M?
>
>
> <snip>
>
>> The rest looks good. Does this mean we can boot a e500 kernel at a
>> non-zero physical address? (can we run or is the non-zero phy just
>> for a short period of init time).
>
> Yes, with this series of patches, we can boot and run with a classic
> ppc
> or e500 kernel at 32MB physical (0xc2000000 virtual). Note that on
> classic, we still need memory at phys 0 for the exception vectors.
> On e500 IIRC, we don't use the vectors at phys 0, but we still write
> the trampoline vectors there. I just didn't bother making that
> conditional.
trampoline vectors?
> I'll post an updated series soon, with hopes of getting it into 2.6.25
- k
^ permalink raw reply
* ping 127.0.0.1 takes too much
From: DI BACCO ANTONIO - technolabs @ 2008-01-18 22:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
I have two different boards: one with MPC875 running at 66 MHz cpu/66 MHz bus, one with MPC880 running at 132 MHz cpu /66MHz bus, I load the same kernel and root file system on both the boards that have only different u-boot(s).
If I do a ping 127.0.0.1 on the MPC875 I get a round trip of 0.300 ms, while on the other one I get 0.900 ms, I expected the opposite.
Could be an issue with memory configuration? In the formula to calculate the PTx on the MPC885RM manual I used 66 MHz as "system clock" for the first board and 132 MHz for the second board. Probably this is a mistake because "system clock" should be the bus clock but how this can so adversely affect the ping round trip?
Thank you,
Antonio.
[-- Attachment #2: Type: text/html, Size: 1134 bytes --]
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-18 22:38 UTC (permalink / raw)
To: Mel Gorman
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0801181414200.8924@schroedinger.engr.sgi.com>
On Fri, 18 Jan 2008, Christoph Lameter wrote:
> Memoryless nodes: Set N_NORMAL_MEMORY for a node if we do not support HIGHMEM
If !CONFIG_HIGHMEM then
enum node_states {
#ifdef CONFIG_HIGHMEM
N_HIGH_MEMORY, /* The node has regular or high memory */
#else
N_HIGH_MEMORY = N_NORMAL_MEMORY,
#endif
So
for_each_online_node(nid) {
pg_data_t *pgdat = NODE_DATA(nid);
free_area_init_node(nid, pgdat, NULL,
find_min_pfn_for_node(nid), NULL);
/* Any memory on that node */
if (pgdat->node_present_pages)
node_set_state(nid, N_HIGH_MEMORY);
^^^ sets N_NORMAL_MEMORY
check_for_regular_memory(pgdat);
}
^ permalink raw reply
* Re: ping 127.0.0.1 takes too much
From: Scott Wood @ 2008-01-18 22:48 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8E264A1A@aquib01a>
DI BACCO ANTONIO - technolabs wrote:
> I have two different boards: one with MPC875 running at 66 MHz cpu/66
> MHz bus, one with MPC880 running at 132 MHz cpu /66MHz bus, I load the
> same kernel and root file system on both the boards that have only
> different u-boot(s).
>
> If I do a ping 127.0.0.1 on the MPC875 I get a round trip of 0.300 ms,
> while on the other one I get 0.900 ms, I expected the opposite.
>
> Could be an issue with memory configuration? In the formula to calculate
> the PTx on the MPC885RM manual I used 66 MHz as "system clock" for the
> first board and 132 MHz for the second board. Probably this is a mistake
> because "system clock" should be the bus clock but how this can so
> adversely affect the ping round trip?
Are you sure the timebase clock is what the kernel thinks it is? Does
the time-of-day clock progress at the correct rate?
-Scott
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Olaf Hering @ 2008-01-18 22:57 UTC (permalink / raw)
To: Christoph Lameter
Cc: lee.schermerhorn, Linux MM, Mel Gorman, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0801181414200.8924@schroedinger.engr.sgi.com>
On Fri, Jan 18, Christoph Lameter wrote:
> Could you try this patch?
Does not help, same crash.
^ permalink raw reply
* Re: [PATCH 05/10] powerpc: Add crash kernel support for 85xx
From: Dale Farnsworth @ 2008-01-18 23:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <96E82635-F660-4D42-8834-2AF6AD264C28@kernel.crashing.org>
On Fri, Jan 18, 2008 at 04:29:23PM -0600, Kumar Gala wrote:
> On Dec 14, 2007, at 11:23 AM, Dale Farnsworth wrote:
>> On Fri, Dec 14, 2007 at 10:48:58AM -0600, Kumar Gala wrote:
>>> On Nov 22, 2007, at 9:46 AM, Dale Farnsworth wrote:
>>>
>>>> Add the ability to build a ppc_85xx kernel to run at a physical
>>>> address of 32MB.
>>>>
>>>> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
>>>> ---
>>>> arch/powerpc/Kconfig | 2 +-
>>>> arch/powerpc/kernel/head_fsl_booke.S | 23 ++++++++++++++++++-----
>>>> arch/powerpc/mm/fsl_booke_mmu.c | 6 +++---
>>>> 3 files changed, 22 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>>> index 805b4d1..d405298 100644
>>>> --- a/arch/powerpc/Kconfig
>>>> +++ b/arch/powerpc/Kconfig
>>>> @@ -253,7 +253,7 @@ config KEXEC
>>>>
>>>> config CRASH_DUMP
>>>> bool "Build a kdump crash kernel (EXPERIMENTAL)"
>>>> - depends on PPC_MULTIPLATFORM && EXPERIMENTAL
>>>> + depends on (PPC_MULTIPLATFORM || PPC_85xx) && EXPERIMENTAL
>>>> help
>>>> Build a kernel suitable for use as a kdump capture kernel.
>>>> The kernel will be linked at a different address than normal, and
>>>> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/
>>>> kernel/head_fsl_booke.S
>>>> index 4b98227..1c9685f 100644
>>>> --- a/arch/powerpc/kernel/head_fsl_booke.S
>>>> +++ b/arch/powerpc/kernel/head_fsl_booke.S
>>>> @@ -41,6 +41,12 @@
>>>> #include <asm/asm-offsets.h>
>>>> #include "head_booke.h"
>>>>
>>>> +#ifdef CONFIG_CRASH_DUMP
>>>> +#define INITIAL_BOOKE_PAGESZ (BOOKE_PAGESZ_64M)
>>>> +#else
>>>> +#define INITIAL_BOOKE_PAGESZ (BOOKE_PAGESZ_16M)
>>>> +#endif
>>>
>>> I'm ok with bumping the first page to 64M in all cases.
>>
>> OK, I'll make that change in the next rev. Thanks.
>
> I'm about to commit a version of this patch, why did you need to bump to
> 64M?
See below.
>> <snip>
>>
>>> The rest looks good. Does this mean we can boot a e500 kernel at a
>>> non-zero physical address? (can we run or is the non-zero phy just
>>> for a short period of init time).
>>
>> Yes, with this series of patches, we can boot and run with a classic ppc
>> or e500 kernel at 32MB physical (0xc2000000 virtual). Note that on
>> classic, we still need memory at phys 0 for the exception vectors.
>> On e500 IIRC, we don't use the vectors at phys 0, but we still write
>> the trampoline vectors there. I just didn't bother making that
>> conditional.
>
> trampoline vectors?
Even though the kernel is loaded at 32M, the vectors still reside at 0
(at least on non-booke). There is code that saves the low 64K away, then
create_trampoline() in crash_dump.c fills each vector with a "b . + 32M"
sequence.
As to why 64M, since the kernel is loaded at 32M, and we still set up
the trampoline vectors at 0, we need more than 16M. It's possible
that we could skip writing the trampoline vectors on booke and
then just just initially map 16M at 32M. I haven't tried it and
can't prove that it won't work, but I don't know that it's worth doing.
>> I'll post an updated series soon, with hopes of getting it into 2.6.25
I think my time for doing it "soon" has passed. Still plan to do it.
Kumar, thanks for pursuing this.
-Dale
^ permalink raw reply
* RE: ping 127.0.0.1 takes too much
From: DI BACCO ANTONIO - technolabs @ 2008-01-18 23:10 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <47912CDA.9020603@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 267 bytes --]
>Are you sure the timebase clock is what the kernel thinks it is? Does
>the time-of-day clock progress at the correct rate?
The kernel receives the CPU clock from the bdinfo structure and thus I think the kernel knows how fast the CPU is.
Bye,
Antonio.
[-- Attachment #2: Type: text/html, Size: 683 bytes --]
^ permalink raw reply
* Re: ping 127.0.0.1 takes too much
From: Scott Wood @ 2008-01-18 23:17 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8E264A1B@aquib01a>
DI BACCO ANTONIO - technolabs wrote:
>
> >Are you sure the timebase clock is what the kernel thinks it is? Does
> >the time-of-day clock progress at the correct rate?
>
> The kernel receives the CPU clock from the bdinfo structure and thus I
> think the kernel knows how fast the CPU is.
That wasn't what I asked. I asked whether you checked whether it was
actually correct or not. I've seen it be wrong quite often.
-Scott
^ permalink raw reply
* Re: ml310 kernel2.6 booting problems
From: Ron Sass @ 2008-01-19 0:11 UTC (permalink / raw)
To: Jean-Samuel Chenard; +Cc: linuxppc-embedded
In-Reply-To: <169c03cb0801171849i59d35893hda44a7f0c5417b58@mail.gmail.com>
Hello All,
I have a sidewise question related to this thread. We have
several ML-310 and ML-410 boards. At some point, we may need
PCI but right now it is not urgent so I am not ready to invest
a lot of time yet either. I imagine that 2.6 + PCI would be
relatively similiar for both ML-310 and ML-410...
My question is this: Would it make sense to have a Kernel
configuration something like "VIRTEX_PCI" and a platforms
"XILINX_ML4xx" / "XILINX_ML3xx" ... or create four platforms:
XILINX_ML300
XILINX_ML310
XILINX_ML40x
XILINX_ML410
I ask now because we are working on some device drivers for
the ML410 that may work on 40x and I wondering if I should
introduce a new ML410 platform option...
Ron
> > Date: Thu, 17 Jan 2008 21:19:04 +0100
> > From: Joachim Meyer
> > Hmmm... I'm not really ready to invest that much time into the PCI for ML=
> -310.
> > -------------------------------------------------------------------------=
> -------
> > http://ozlabs.org/pipermail/linuxppc-embedded/2007-December/029211.html
> >
> > How much work would it be (approximated), and do you think I can success =
> (I'm a novice, like you know)?
> > Would you help me (Tell me where to start & what to do)?
>
> Hi Joachim,
>
> I was also interested in getting the PCI to run on the ML-310. I did
> spend an evening trying to integrate a patch sent over by Stephen
> Neuendorffer from Xilinx. I managed to get everything to compile
> (basically I fixed a few missing macros and had to search a bit to
> ensure that the memory mapping was correctly ported). Unfortunately,
> when I tried the new kernel, I think that I must have messed something
> up with the interrupt mappings (I am a newbie to PCI) and I had to
> remove some interrupt mapping from Stephen's patch.
>
> In any case, my ML-310 was booting the Linux kernel, but something was
> not right and I did not get anymore printouts from the UART Lite.
> Since I don't have the JTAG cable, I was stuck at this point with
> little means to debug the system. One day I'll spoil myself with one
> of those platform JTAG USB cables...
>
> I used Z-modem to transfer files to/from my workstation to my CF card
> on the ML-310 and this was an acceptable compromise.
>
> I'd still be interested in having the PCI bus working on the ML-310,
> but now that I got my BEE2 booting Linux 2.6, its not such a big
> priority for me. Let me know if you have some success in that
> direction.
>
> Regards,
>
> Jean-Samuel
> -- =
>
> Integrated Microsystems Laboratory
> McGill University, Montr=E9al, QC, CANADA
> Web Page: http://chaos.ece.mcgill.ca
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: ml310 kernel2.6 booting problems
From: Stephen Neuendorffer @ 2008-01-19 0:35 UTC (permalink / raw)
To: Ron Sass, Jean-Samuel Chenard; +Cc: linuxppc-embedded
In-Reply-To: <200801190011.m0J0BCtr001286@rsass-homer.uncc.edu>
Ron,
It might be better to start with the kernel from git.xilinx.com, which
already has an ML41x option. The current version of EDK will also
generate support for ML410 with the PCI driver, if you are still using a
2.6.10-era kernel. =20
I've refrained putting the PCI stuff on git.xilinx.com, because any
non-trivial usage of it that I've tried has generated warnings. On top
of that, the code has some interrupt values hardcoded in the ALI
southbridge code. Since there is no way to have this code pushed into
mainline, I'm not terribly interested in encouraging any work on it,
either. Perhaps since there is so much interest in this code, someone
would like to get it working in ARCH=3Dpowerpc? I'm happy to provide =
some
handholding to get someone started.
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Ron Sass
> Sent: Friday, January 18, 2008 4:11 PM
> To: Jean-Samuel Chenard
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: ml310 kernel2.6 booting problems
>=20
>=20
> Hello All,
>=20
> I have a sidewise question related to this thread. We have
> several ML-310 and ML-410 boards. At some point, we may need
> PCI but right now it is not urgent so I am not ready to invest
> a lot of time yet either. I imagine that 2.6 + PCI would be
> relatively similiar for both ML-310 and ML-410...
>=20
> My question is this: Would it make sense to have a Kernel
> configuration something like "VIRTEX_PCI" and a platforms
> "XILINX_ML4xx" / "XILINX_ML3xx" ... or create four platforms:
>=20
> XILINX_ML300
> XILINX_ML310
> XILINX_ML40x
> XILINX_ML410
>=20
> I ask now because we are working on some device drivers for
> the ML410 that may work on 40x and I wondering if I should
> introduce a new ML410 platform option...
>=20
> Ron
>=20
> > > Date: Thu, 17 Jan 2008 21:19:04 +0100
> > > From: Joachim Meyer
> > > Hmmm... I'm not really ready to invest that much time into the PCI
for ML=3D
> > -310.
> > >
------------------------------------------------------------------------
-=3D
> > -------
> > >
http://ozlabs.org/pipermail/linuxppc-embedded/2007-December/029211.html
> > >
> > > How much work would it be (approximated), and do you think I can
success =3D
> > (I'm a novice, like you know)?
> > > Would you help me (Tell me where to start & what to do)?
> >
> > Hi Joachim,
> >
> > I was also interested in getting the PCI to run on the ML-310. I
did
> > spend an evening trying to integrate a patch sent over by Stephen
> > Neuendorffer from Xilinx. I managed to get everything to compile
> > (basically I fixed a few missing macros and had to search a bit to
> > ensure that the memory mapping was correctly ported).
Unfortunately,
> > when I tried the new kernel, I think that I must have messed
something
> > up with the interrupt mappings (I am a newbie to PCI) and I had to
> > remove some interrupt mapping from Stephen's patch.
> >
> > In any case, my ML-310 was booting the Linux kernel, but something
was
> > not right and I did not get anymore printouts from the UART Lite.
> > Since I don't have the JTAG cable, I was stuck at this point with
> > little means to debug the system. One day I'll spoil myself with
one
> > of those platform JTAG USB cables...
> >
> > I used Z-modem to transfer files to/from my workstation to my CF
card
> > on the ML-310 and this was an acceptable compromise.
> >
> > I'd still be interested in having the PCI bus working on the ML-310,
> > but now that I got my BEE2 booting Linux 2.6, its not such a big
> > priority for me. Let me know if you have some success in that
> > direction.
> >
> > Regards,
> >
> > Jean-Samuel
> > -- =3D
> >
> > Integrated Microsystems Laboratory
> > McGill University, Montr=3DE9al, QC, CANADA
> > Web Page: http://chaos.ece.mcgill.ca
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: ml310 kernel2.6 booting problems
From: Ron Sass @ 2008-01-19 1:21 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-embedded
In-Reply-To: <20080119003518.25AC41CF8068@mail125-dub.bigfish.com>
Oops. I should have looked at git.xilinx.com. I've been using
secretlab's for a while and I saw xilinx site come up but never
took the time to investigate. Even if it not mainline suitable
code and 2.6.10-era, I would be interested. I'll explore in my
free time over the next couple of weeks and see what I can figure
out.
Thanks for the speedy response!
Ron
>
> Ron,
>
> It might be better to start with the kernel from git.xilinx.com, which
> already has an ML41x option. The current version of EDK will also
> generate support for ML410 with the PCI driver, if you are still using a
> 2.6.10-era kernel. =20
>
> I've refrained putting the PCI stuff on git.xilinx.com, because any
> non-trivial usage of it that I've tried has generated warnings. On top
> of that, the code has some interrupt values hardcoded in the ALI
> southbridge code. Since there is no way to have this code pushed into
> mainline, I'm not terribly interested in encouraging any work on it,
> either. Perhaps since there is so much interest in this code, someone
> would like to get it working in ARCH=3Dpowerpc? I'm happy to provide =
> some
> handholding to get someone started.
>
> Steve
>
> > -----Original Message-----
> > From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
> > bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Ron Sass
> > Sent: Friday, January 18, 2008 4:11 PM
> > To: Jean-Samuel Chenard
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: ml310 kernel2.6 booting problems
> >=20
> >=20
> > Hello All,
> >=20
> > I have a sidewise question related to this thread. We have
> > several ML-310 and ML-410 boards. At some point, we may need
> > PCI but right now it is not urgent so I am not ready to invest
> > a lot of time yet either. I imagine that 2.6 + PCI would be
> > relatively similiar for both ML-310 and ML-410...
> >=20
> > My question is this: Would it make sense to have a Kernel
> > configuration something like "VIRTEX_PCI" and a platforms
> > "XILINX_ML4xx" / "XILINX_ML3xx" ... or create four platforms:
> >=20
> > XILINX_ML300
> > XILINX_ML310
> > XILINX_ML40x
> > XILINX_ML410
> >=20
> > I ask now because we are working on some device drivers for
> > the ML410 that may work on 40x and I wondering if I should
> > introduce a new ML410 platform option...
> >=20
> > Ron
> >=20
> > > > Date: Thu, 17 Jan 2008 21:19:04 +0100
> > > > From: Joachim Meyer
> > > > Hmmm... I'm not really ready to invest that much time into the PCI
> for ML=3D
> > > -310.
> > > >
> ------------------------------------------------------------------------
> -=3D
> > > -------
> > > >
> http://ozlabs.org/pipermail/linuxppc-embedded/2007-December/029211.html
> > > >
> > > > How much work would it be (approximated), and do you think I can
> success =3D
> > > (I'm a novice, like you know)?
> > > > Would you help me (Tell me where to start & what to do)?
> > >
> > > Hi Joachim,
> > >
> > > I was also interested in getting the PCI to run on the ML-310. I
> did
> > > spend an evening trying to integrate a patch sent over by Stephen
> > > Neuendorffer from Xilinx. I managed to get everything to compile
> > > (basically I fixed a few missing macros and had to search a bit to
> > > ensure that the memory mapping was correctly ported).
> Unfortunately,
> > > when I tried the new kernel, I think that I must have messed
> something
> > > up with the interrupt mappings (I am a newbie to PCI) and I had to
> > > remove some interrupt mapping from Stephen's patch.
> > >
> > > In any case, my ML-310 was booting the Linux kernel, but something
> was
> > > not right and I did not get anymore printouts from the UART Lite.
> > > Since I don't have the JTAG cable, I was stuck at this point with
> > > little means to debug the system. One day I'll spoil myself with
> one
> > > of those platform JTAG USB cables...
> > >
> > > I used Z-modem to transfer files to/from my workstation to my CF
> card
> > > on the ML-310 and this was an acceptable compromise.
> > >
> > > I'd still be interested in having the PCI bus working on the ML-310,
> > > but now that I got my BEE2 booting Linux 2.6, its not such a big
> > > priority for me. Let me know if you have some success in that
> > > direction.
> > >
> > > Regards,
> > >
> > > Jean-Samuel
> > > -- =3D
> > >
> > > Integrated Microsystems Laboratory
> > > McGill University, Montr=3DE9al, QC, CANADA
> > > Web Page: http://chaos.ece.mcgill.ca
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: ml310 kernel2.6 booting problems
From: Grant Likely @ 2008-01-19 1:23 UTC (permalink / raw)
To: Ron Sass; +Cc: Jean-Samuel Chenard, linuxppc-embedded
In-Reply-To: <200801190011.m0J0BCtr001286@rsass-homer.uncc.edu>
On 1/18/08, Ron Sass <rsass@uncc.edu> wrote:
> My question is this: Would it make sense to have a Kernel
> configuration something like "VIRTEX_PCI" and a platforms
> "XILINX_ML4xx" / "XILINX_ML3xx" ... or create four platforms:
>
> XILINX_ML300
> XILINX_ML310
> XILINX_ML40x
> XILINX_ML410
The whole CONFIG_XILINX_ML*** stuff will be disappearing as part of
the migration from arch/ppc to arch/powerpc. Instead, the board
configuration will be described using a device tree file (dts). Feel
free to add stuff in your local tree, but be prepared to migrate your
drivers in the next 6 months or so.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH/RFC] [POWERPC] Allow multiple images to be built when CONFIG_DEFAULT_UIMAGE set
From: Grant Likely @ 2008-01-19 3:55 UTC (permalink / raw)
To: linuxppc-dev, paulus, scottwood, david
From: Grant Likely <grant.likely@secretlab.ca>
Most of the embedded board ports select CONFIG_DEFAULT_UIMAGE so that
uImage files get built by default. However, the current code casues
the arch/powerpc/boot/Makefile to be called with the 'uImage' target
and adds 'uImage' to the 'image-y' make variable. If CONFIG_DEFAULT_UIMAGE
is not set, then the boot makefile is called with target 'zImage'.
However, the zImage target already automatically causes all targets
listed in 'image-y' to be built, which includes uImage.
This patch makes the default build target alwasy call the boot makefile
using the 'zImage' target, regardless of if CONFIG_DEFAULT_UIMAGE is set.
Making this change allows multiple boot images to be built from a single
kernel compile. An example of where this is useful is with the Efika
and lite5200 boards. Both boards can use the same kernel image (vmlinux),
but they use different boot image files (zImage.chrp vs. uImage). By
making this change, the boot makefile now builds both by default so a
single defconfig can be used for testing both platforms.
This patch also eliminates the BOOTIMAGE variable because it doesn't
appear to be used anywhere. (Someone please correct me if I'm wrong)
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/Makefile | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f70df9b..6451c2f 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -151,10 +151,7 @@ core-$(CONFIG_XMON) += arch/powerpc/xmon/
drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
-defaultimage-y := zImage
-defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
-KBUILD_IMAGE := $(defaultimage-y)
-all: $(KBUILD_IMAGE)
+all: zImage
CPPFLAGS_vmlinux.lds := -Upowerpc
@@ -180,7 +177,7 @@ define archhelp
endef
install: vdso_install
- $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install
+ $(Q)$(MAKE) $(build)=$(boot) install
vdso_install:
ifeq ($(CONFIG_PPC64),y)
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox