* [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
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-19 4:55 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Pekka Enberg, linux-kernel, Linux MM
In-Reply-To: <20080118065621.GA27495@aepfle.de>
On Fri, 18 Jan 2008, Olaf Hering wrote:
> calls cache_grow with nodeid 0
> > [c00000000075bbd0] [c0000000000f82d0] .cache_alloc_refill+0x234/0x2c0
> calls cache_grow with nodeid 0
> > [c00000000075bbe0] [c0000000000f7f38] .____cache_alloc_node+0x17c/0x1e8
>
> calls cache_grow with nodeid 1
> > [c00000000075bbe0] [c0000000000f7d68] .fallback_alloc+0x1a0/0x1f4
Okay that makes sense. You have no node 0 with normal memory but the node
assigned to the executing processor is zero (correct?). Thus it needs to
fallback to node 1 and that is not possible during bootstrap. You need to
run kmem_cache_init() on a cpu on a processor with memory.
Or we need to revert the patch which would allocate control
structures again for all online nodes regardless if they have memory or
not.
Does reverting 04231b3002ac53f8a64a7bd142fde3fa4b6808c6 change the
situation? (However, we tried this on the other thread without success).
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-19 4:56 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Pekka Enberg, linux-kernel, Linux MM
In-Reply-To: <20080117202024.GA25090@aepfle.de>
On Thu, 17 Jan 2008, Olaf Hering wrote:
> On Thu, Jan 17, Olaf Hering wrote:
>
> > Since -mm boots further, what patch should I try?
>
> rc8-mm1 crashes as well, l3 passed to reap_alien() is NULL.
Sigh. It looks like we need alien cache structures in some cases for nodes
that have no memory. We must allocate structures for all nodes regardless
if they have allocatable memory or not.
^ permalink raw reply
* Re: [Add mpc5121 support PATCH v3 7/8] Factor out 52xx dependencies from 52xx psc driver
From: Grant Likely @ 2008-01-19 6:58 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <1200614738-25654-8-git-send-email-jrigby@freescale.com>
On 1/17/08, John Rigby <jrigby@freescale.com> wrote:
> PSCs change from 5200 to 5121
> this patch localizes the differences in
> preparation for adding 5121 support
>
> Signed-off-by: John Rigby <jrigby@freescale.com>
This patch breaks the serial console on my Efika.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [Add mpc5121 support PATCH v3 7/8] Factor out 52xx dependencies from 52xx psc driver
From: Grant Likely @ 2008-01-19 6:59 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801182258r5a3b6465kf0e7918e0e56e0c4@mail.gmail.com>
On 1/18/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/17/08, John Rigby <jrigby@freescale.com> wrote:
> > PSCs change from 5200 to 5121
> > this patch localizes the differences in
> > preparation for adding 5121 support
> >
> > Signed-off-by: John Rigby <jrigby@freescale.com>
>
> This patch breaks the serial console on my Efika.
Er, more specifically, I get console output, but I get no output from
the init process (like when I add "init=/bin/sh" to the kernel
parameters).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] Get rid of conditional includes of board specific setup
From: Arnd Bergmann @ 2008-01-19 12:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
In-Reply-To: <4790B891.3050106@scram.de>
On Friday 18 January 2008, Jochen Friedrich wrote:
> Directly include mpc885ads.h from mpc885ads_setup.c. Now we can get rid
> of the arch dependent includes in mpc8xx.h.
Ah, very nice. How close are we to enabling an 8xx multiplatform
build after this?
> =A0#ifdef CONFIG_8xx
> =A0
> =A0extern void mpc8xx_restart(char *cmd);
> @@ -18,22 +20,9 @@ extern void mpc8xx_get_rtc_time(struct rtc_time *tm);
> =A0extern void mpc8xx_pics_init(void);
> =A0extern unsigned int mpc8xx_get_irq(void);
>=20
> #ifdef CONFIG_PCMCIA_M8XX
> extern struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops;
> #endif
=20
> =A0#endif /* CONFIG_8xx */
> =A0#endif /* __CONFIG_8xx_DEFS */
You can also kill the #ifdef CONFIG_8xx and the #ifdef CONFIG_PCMCIA_M8XX,
there is no point hiding extern declarations behind an #ifdef, but it
has the disadvantage of causing unnecessary rebuilds if the configuration
symbols change.
Arnd <><
^ permalink raw reply
* Re: [RFC/PATCH 1/2] [POWERPC] mpc5200: normalize compatible property bindings
From: Stephen Rothwell @ 2008-01-19 12:34 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, jrigby
In-Reply-To: <20080118170443.10592.97538.stgit@trillian.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
Hi Grant,
On Fri, 18 Jan 2008 10:04:49 -0700 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> +++ b/arch/powerpc/platforms/52xx/lite5200.c
> @@ -44,9 +44,14 @@ lite5200_fix_clock_config(void)
> {
> struct device_node *np;
> struct mpc52xx_cdm __iomem *cdm;
> + struct of_device_id cdm_ids[] = {
Surely this should be static and __initdata?
> @@ -79,9 +84,14 @@ lite5200_fix_port_config(void)
> {
> struct device_node *np;
> struct mpc52xx_gpio __iomem *gpio;
> + struct of_device_id gpio_ids[] = {
And this?
> +++ b/arch/powerpc/platforms/52xx/lite5200_pm.c
> @@ -43,6 +43,12 @@ static int lite5200_pm_set_target(suspend_state_t state)
> static int lite5200_pm_prepare(void)
> {
> struct device_node *np;
> + struct of_device_id immr_ids[] = {
This should be static and const.
Similarly for the rest ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
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