* [PATH] ppc32: Add usb support to IBM stb04xxx platforms
From: Dale Farnsworth @ 2005-08-09 18:53 UTC (permalink / raw)
To: linuxppc-embedded
[ I previously submitted this on March 31st. Though I received a copy
back from the linuxppc-embedded mailing list, I don't find a copy in
the archive. (The same thing happend to my submission of asm-ppc/usb.h.)
So I'm resending. ]
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -72,12 +72,43 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr = USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end = USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end = USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xffffffffULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = "ppc-soc-ohci",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xffffffffULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ &ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x40000000
#define GPIO0_BASE 0x40060000
+#define USB0_BASE 0x40010000
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x40010000)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -52,8 +52,18 @@
void __init
redwood5_setup_arch(void)
{
+ u32 mask;
+
ppc4xx_setup_arch();
+ /*
+ * Set up USB interrupt as positive polarity and level-sensitive.
+ * Firmware should do this, but apparently does not.
+ */
+ mask = 1 << (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) & ~mask);
+
#ifdef CONFIG_DEBUG_BRINGUP
printk("\n");
printk("machine\t: %s\n", PPC4xx_MACHINE_NAME);
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Wall clock accuracy
From: Eugene Surovegin @ 2005-08-09 18:56 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B85941C@ismail.innsys.innovsys.com>
On Tue, Aug 09, 2005 at 01:52:33PM -0500, Rune Torgersen wrote:
>
>
> > -----Original Message-----
> > From: Eugene Surovegin [mailto:ebs@ebshome.net]
> > Sent: Tuesday, August 09, 2005 13:35
> > To: Rune Torgersen
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: Wall clock accuracy
> >
> > On Tue, Aug 09, 2005 at 01:21:09PM -0500, Rune Torgersen wrote:
> > >
> > > A proper fix would be for platfrom code to have a way to
> > set time_nsec
> > > instead of having it set by a constant.
> >
> > Or configure CLOCK_TICK_RATE in board/CPU specific fashion, e.g. like
> > ARM does.
>
> Then it would have to be a constant,
Why?
> and it would be much better to just
> use the clockrate given to the kernel than have to hardcode it into the
> kernel.
Nothing prevents you from defining this macro as a function call for
example. If this is needed for your CPU/board port. Probably common
case will be a constant, though.
--
Eugene
^ permalink raw reply
* MPC8260 - memcpy() vs IDMA
From: Jeff Angielski @ 2005-08-09 18:51 UTC (permalink / raw)
To: linuxppc-embedded
Does anybody have any real life numbers of the latency and/or throughput
associated with moving large amounts of data using the IDMA channels
rather than direct memcpy()? Some information online suggests that the
IDMA is noticeably slower than the CPU memcpy() and that it does
significantly impact the other CPM functionality. I guess the MPC860
was really bad in this regard but the MPC82xx was supposed to be much
better. Is anybody using IDMA on their systems (besides the PCI9
workaround?)
FWIW, I am moving around 1 to 4MB/s of data from an FPGA to local memory
on a custom MPC8260 board.
Thanks,
Jeff Angielski
The PTR Group
^ permalink raw reply
* Re: [PATH] ppc32: Add usb support to IBM stb04xxx platforms
From: Eugene Surovegin @ 2005-08-09 19:03 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <20050809185327.GA19340@xyzzy.farnsworth.org>
On Tue, Aug 09, 2005 at 11:53:27AM -0700, Dale Farnsworth wrote:
[snip]
> Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
> ===================================================================
> --- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
> +++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
> @@ -52,8 +52,18 @@
> void __init
> redwood5_setup_arch(void)
> {
> + u32 mask;
> +
> ppc4xx_setup_arch();
>
> + /*
> + * Set up USB interrupt as positive polarity and level-sensitive.
> + * Firmware should do this, but apparently does not.
> + */
> + mask = 1 << (31 - USB0_IRQ);
> + mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
> + mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) & ~mask);
> +
Please, DO NOT DO THIS.
There is a way to configure UIC settings without messing with UIC
registers directly. Refer to asm-ppc/ppc4xx_pic.h and other 4xx board
ports for more information.
--
Eugene
^ permalink raw reply
* RE: Wall clock accuracy
From: Rune Torgersen @ 2005-08-09 19:11 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
> -----Original Message-----
> From: Eugene Surovegin [mailto:ebs@ebshome.net]=20
> Sent: Tuesday, August 09, 2005 13:57
> > and it would be much better to just
> > use the clockrate given to the kernel than have to hardcode=20
> it into the
> > kernel.
>=20
> Nothing prevents you from defining this macro as a function call for=20
> example. If this is needed for your CPU/board port. Probably common
> case will be a constant, though.
Problem is that time_nsec is not directly set to CLOCK_TICK_RATE but
goes through some calculations I'd rather not have to lots of times in
runtime (maybe I'm not seeing how it could be done)
Anyways, the #define chain leading to time_nsec is:
unsigned long tick_nsec =3D TICK_NSEC; /* ACTHZ period (nsec)
*/ kernel/time.c:562
#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
asm-ppc/timex.h:14
Include/linux/jiffies.h:45 and out
/* LATCH is used in the interval timer and ftape setup. */
#define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ) /* For divider */
/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, the we
can
* improve accuracy by shifting LSH bits, hence calculating:
* (NOM << LSH) / DEN
* This however means trouble for large NOM, because (NOM << LSH) may no
* longer fit in 32 bits. The following way of calculating this gives us
* some slack, under the following conditions:
* - (NOM / DEN) fits in (32 - LSH) bits.
* - (NOM % DEN) fits in (32 - LSH) bits.
*/
#define SH_DIV(NOM,DEN,LSH) ( ((NOM / DEN) << LSH)
\
+ (((NOM % DEN) << LSH) + DEN / 2) / DEN)
/* HZ is the requested value. ACTHZ is actual HZ ("<< 8" is for
accuracy) */
#define ACTHZ (SH_DIV (CLOCK_TICK_RATE, LATCH, 8))
/* TICK_NSEC is the time between ticks in nsec assuming real ACTHZ */
#define TICK_NSEC (SH_DIV (1000000UL * 1000, ACTHZ, 8))
I cannot se a clean easy way of changing time_nsec or TIME_NSEC runtime
without messing with code that probably should not be messed with.
Of course I am probably wrong.
^ permalink raw reply
* make install target implementation
From: Joerg Dorchain @ 2005-08-09 19:11 UTC (permalink / raw)
To: Linux/PPC Development
[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]
Hi,
I noticed that the install target is mentioned in the help, but not
implemented. I tried an implementation that can be used by distributions
and does not break yaboot for me ;-) Patch enclosed, comments welcome.
Bye,
Joerg
Signed-off-by: Joerg Dorchain <joerg@dorchain.net>
--- arch/ppc/boot/install.sh.orig 2005-08-09 20:54:21.000000000 +0200
+++ arch/ppc/boot/install.sh 2005-08-09 21:07:26.000000000 +0200
@@ -0,0 +1,41 @@
+#!/bin/sh
+#
+# arch/ppc/boot/install.sh
+#
+# This file is subject to the terms and conditions of the GNU General Public
+# License. See the file "COPYING" in the main directory of this archive
+# for more details.
+#
+# Copyright (C) 1995 by Linus Torvalds
+#
+# Adapted from code in arch/i386/boot/install.sh by Joerg Dorchain
+#
+# "make install" script for ppc architecture
+#
+# Arguments:
+# $1 - kernel version
+# $2 - kernel image file
+# $3 - kernel map file
+# $4 - default install path (blank if root directory)
+#
+
+# User may have a custom install script
+
+if [ -x ~/bin/installkernel ]; then exec ~/bin/installkernel "$@"; fi
+if [ -x /sbin/installkernel ]; then exec /sbin/installkernel "$@"; fi
+
+# Default install - same as make zlilo
+
+if [ -f $4/vmlinux ]; then
+ mv $4/vmlinux $4/vmlinux.old
+fi
+
+if [ -f $4/System.map ]; then
+ mv $4/System.map $4/System.old
+fi
+
+cat $2 > $4/vmlinux
+cp $3 $4/System.map
+
+# No lilo here
+#if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi
--- arch/ppc/Makefile.orig 2005-08-09 20:44:33.000000000 +0200
+++ arch/ppc/Makefile 2005-08-09 21:08:20.000000000 +0200
@@ -94,7 +94,7 @@
@echo ' install - Install kernel using'
@echo ' (your) ~/bin/installkernel or'
@echo ' (distribution) /sbin/installkernel or'
- @echo ' install to $$(INSTALL_PATH) and run lilo'
+ @echo ' install to $$(INSTALL_PATH)'
@echo ' *_defconfig - Select default config from arch/$(ARCH)/ppc/configs'
endef
@@ -137,3 +137,5 @@
arch/$(ARCH)/kernel/asm-offsets.s \
$(TOUT)
+install: vmlinux
+ sh $(srctree)/$(boot)/install.sh $(KERNELRELEASE) $< System.map "$(INSTALL_PATH)"
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: Add usb support to IBM stb04xxx platforms
From: Dale Farnsworth @ 2005-08-09 19:23 UTC (permalink / raw)
To: Dale Farnsworth, linuxppc-embedded
In-Reply-To: <20050809190319.GC30956@gate.ebshome.net>
On Tue, Aug 09, 2005 at 12:03:19PM -0700, Eugene Surovegin wrote:
> On Tue, Aug 09, 2005 at 11:53:27AM -0700, Dale Farnsworth wrote:
> [snip]
>
> > Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
> > ===================================================================
> > --- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
> > +++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
> > @@ -52,8 +52,18 @@
> > void __init
> > redwood5_setup_arch(void)
> > {
> > + u32 mask;
> > +
> > ppc4xx_setup_arch();
> >
> > + /*
> > + * Set up USB interrupt as positive polarity and level-sensitive.
> > + * Firmware should do this, but apparently does not.
> > + */
> > + mask = 1 << (31 - USB0_IRQ);
> > + mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
> > + mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) & ~mask);
> > +
>
> Please, DO NOT DO THIS.
>
> There is a way to configure UIC settings without messing with UIC
> registers directly. Refer to asm-ppc/ppc4xx_pic.h and other 4xx board
> ports for more information.
>
> Eugene
Deja vu all over again, eh Eugene? I re-submitted the wrong old patch.
Correct (I hope) patch follows.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -11,6 +11,7 @@
#include <linux/init.h>
#include <asm/ocp.h>
+#include <asm/ppc4xx_pic.h>
#include <platforms/4xx/ibmstb4.h>
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,51 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr = USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+/* Polarity and triggering settings for internal interrupt sources */
+struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
+ { .polarity = 0x7fffff01,
+ .triggering = 0x00000000,
+ .ext_irq_mask = 0x0000007e, /* IRQ0 - IRQ5 */
+ }
+};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end = USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end = USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xffffffffULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = "ppc-soc-ohci",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xffffffffULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ &ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x40000000
#define GPIO0_BASE 0x40060000
+#define USB0_BASE 0x40010000
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x40010000)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -18,6 +18,19 @@
#include <linux/ioport.h>
#include <asm/io.h>
#include <asm/machdep.h>
+#include <asm/ppc4xx_pic.h>
+
+/*
+ * Define external IRQ senses and polarities.
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 3 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 4 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 5 */
+};
static struct resource smc91x_resources[] = {
[0] = {
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* ppc pci routines howto needed
From: dosilasolfamiredo @ 2005-08-09 17:56 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
Is there somewhere available howto/other_information describing powerpc pci routines in linux kernel? I am especially interested in pci routines for PQII processors (for instance mpc8260), pci bridge initialization, probing issues and pci9 errata.
Thanks in advance,
Peter
^ permalink raw reply
* [PATCH] ppc32: Added support for the Book-E style Watchdog Timer
From: Kumar Gala @ 2005-08-09 20:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
PowerPC 40x and Book-E processors support a watchdog timer at the processor
core level. The timer has implementation dependent timeout frequencies
that can be configured by software.
One the first Watchdog timeout we get a critical exception. It is left
to board specific code to determine what should happen at this point. If
nothing is done and another timeout period expires the processor may
attempt to reset the machine.
Command line parameters:
wdt=0 : disable watchdog (default)
wdt=1 : enable watchdog
wdt_period=N : N sets the value of the Watchdog Timer Period.
The Watchdog Timer Period meaning is implementation specific. Check
User Manual for the processor for more details.
This patch is based off of work done by Takeharu Kato.
Signed-off-by: Matt McClintock <msm@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 1780d9e65903f3132133f754cf290a5db7916965
tree 88daf35ce065f24a86ad0ad4f7a57c91aa15527d
parent a60c894ec93e545340a495fc15d34ca69e7accbe
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 09 Aug 2005 15:27:28 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 09 Aug 2005 15:27:28 -0500
Documentation/watchdog/watchdog-api.txt | 20 +++
arch/ppc/kernel/head_44x.S | 4 +
arch/ppc/kernel/head_4xx.S | 4 -
arch/ppc/kernel/head_fsl_booke.S | 5 +
arch/ppc/kernel/setup.c | 24 ++++
arch/ppc/kernel/traps.c | 19 +++
arch/ppc/syslib/ppc4xx_setup.c | 25 ----
drivers/char/watchdog/Kconfig | 4 +
drivers/char/watchdog/Makefile | 1
drivers/char/watchdog/booke_wdt.c | 191 +++++++++++++++++++++++++++++++
10 files changed, 270 insertions(+), 27 deletions(-)
diff --git a/Documentation/watchdog/watchdog-api.txt b/Documentation/watchdog/watchdog-api.txt
--- a/Documentation/watchdog/watchdog-api.txt
+++ b/Documentation/watchdog/watchdog-api.txt
@@ -228,6 +228,26 @@ advantechwdt.c -- Advantech Single Board
The GETSTATUS call returns if the device is open or not.
[FIXME -- silliness again?]
+booke_wdt.c -- PowerPC BookE Watchdog Timer
+
+ Timeout default varies according to frequency, supports
+ SETTIMEOUT
+
+ Watchdog can not be turned off, CONFIG_WATCHDOG_NOWAYOUT
+ does not make sense
+
+ GETSUPPORT returns the watchdog_info struct, and
+ GETSTATUS returns the supported options. GETBOOTSTATUS
+ returns a 1 if the last reset was caused by the
+ watchdog and a 0 otherwise. This watchdog can not be
+ disabled once it has been started. The wdt_period kernel
+ parameter selects which bit of the time base changing
+ from 0->1 will trigger the watchdog exception. Changing
+ the timeout from the ioctl calls will change the
+ wdt_period as defined above. Finally if you would like to
+ replace the default Watchdog Handler you can implement the
+ WatchdogHandler() function in your own code.
+
eurotechwdt.c -- Eurotech CPU-1220/1410
The timeout can be set using the SETTIMEOUT ioctl and defaults
diff --git a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S
--- a/arch/ppc/kernel/head_44x.S
+++ b/arch/ppc/kernel/head_44x.S
@@ -462,7 +462,11 @@ interrupt_base:
/* Watchdog Timer Interrupt */
/* TODO: Add watchdog support */
+#ifdef CONFIG_BOOKE_WDT
+ CRITICAL_EXCEPTION(0x1020, WatchdogTimer, WatchdogException)
+#else
CRITICAL_EXCEPTION(0x1020, WatchdogTimer, UnknownException)
+#endif
/* Data TLB Error Interrupt */
START_EXCEPTION(DataTLBError)
diff --git a/arch/ppc/kernel/head_4xx.S b/arch/ppc/kernel/head_4xx.S
--- a/arch/ppc/kernel/head_4xx.S
+++ b/arch/ppc/kernel/head_4xx.S
@@ -448,7 +448,9 @@ label:
/* 0x1020 - Watchdog Timer (WDT) Exception
*/
-
+#ifdef CONFIG_BOOKE_WDT
+ CRITICAL_EXCEPTION(0x1020, WDTException, WatchdogException)
+#else
CRITICAL_EXCEPTION(0x1020, WDTException, UnknownException)
#endif
diff --git a/arch/ppc/kernel/head_fsl_booke.S b/arch/ppc/kernel/head_fsl_booke.S
--- a/arch/ppc/kernel/head_fsl_booke.S
+++ b/arch/ppc/kernel/head_fsl_booke.S
@@ -564,8 +564,11 @@ interrupt_base:
EXCEPTION(0x3100, FixedIntervalTimer, UnknownException, EXC_XFER_EE)
/* Watchdog Timer Interrupt */
- /* TODO: Add watchdog support */
+#ifdef CONFIG_BOOKE_WDT
+ CRITICAL_EXCEPTION(0x3200, WatchdogTimer, WatchdogException)
+#else
CRITICAL_EXCEPTION(0x3200, WatchdogTimer, UnknownException)
+#endif
/* Data TLB Error Interrupt */
START_EXCEPTION(DataTLBError)
diff --git a/arch/ppc/kernel/setup.c b/arch/ppc/kernel/setup.c
--- a/arch/ppc/kernel/setup.c
+++ b/arch/ppc/kernel/setup.c
@@ -615,6 +615,30 @@ machine_init(unsigned long r3, unsigned
if (ppc_md.progress)
ppc_md.progress("id mach(): done", 0x200);
}
+#ifdef CONFIG_BOOKE_WDT
+/* Checks wdt=x and wdt_period=xx command-line option */
+int __init early_parse_wdt(char *p)
+{
+ extern u32 wdt_enable;
+
+ if (p && strncmp(p, "0", 1) != 0)
+ wdt_enable = 1;
+
+ return 0;
+}
+early_param("wdt", early_parse_wdt);
+
+int __init early_parse_wdt_period (char *p)
+{
+ extern u32 wdt_period;
+
+ if (p)
+ wdt_period = simple_strtoul(p, NULL, 0);
+
+ return 0;
+}
+early_param("wdt_period", early_parse_wdt_period);
+#endif /* CONFIG_BOOKE_WDT */
/* Checks "l2cr=xxxx" command-line option */
int __init ppc_setup_l2cr(char *str)
diff --git a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
--- a/arch/ppc/kernel/traps.c
+++ b/arch/ppc/kernel/traps.c
@@ -904,6 +904,25 @@ void SPEFloatingPointException(struct pt
}
#endif
+#ifdef CONFIG_BOOKE_WDT
+/*
+ * Default handler for a Watchdog exception,
+ * spins until a reboot occurs
+ */
+void __attribute__ ((weak)) WatchdogHandler(struct pt_regs *regs)
+{
+ /* Generic WatchdogHandler, implement your own */
+ mtspr(SPRN_TCR, mfspr(SPRN_TCR)&(~TCR_WIE));
+ return;
+}
+
+void WatchdogException(struct pt_regs *regs)
+{
+ printk (KERN_EMERG "PowerPC Book-E Watchdog Exception\n");
+ WatchdogHandler(regs);
+}
+#endif
+
void __init trap_init(void)
{
}
diff --git a/arch/ppc/syslib/ppc4xx_setup.c b/arch/ppc/syslib/ppc4xx_setup.c
--- a/arch/ppc/syslib/ppc4xx_setup.c
+++ b/arch/ppc/syslib/ppc4xx_setup.c
@@ -48,10 +48,6 @@
extern void abort(void);
extern void ppc4xx_find_bridges(void);
-extern void ppc4xx_wdt_heartbeat(void);
-extern int wdt_enable;
-extern unsigned long wdt_period;
-
/* Global Variables */
bd_t __res;
@@ -257,22 +253,6 @@ ppc4xx_init(unsigned long r3, unsigned l
*(char *) (r7 + KERNELBASE) = 0;
strcpy(cmd_line, (char *) (r6 + KERNELBASE));
}
-#if defined(CONFIG_PPC405_WDT)
-/* Look for wdt= option on command line */
- if (strstr(cmd_line, "wdt=")) {
- int valid_wdt = 0;
- char *p, *q;
- for (q = cmd_line; (p = strstr(q, "wdt=")) != 0;) {
- q = p + 4;
- if (p > cmd_line && p[-1] != ' ')
- continue;
- wdt_period = simple_strtoul(q, &q, 0);
- valid_wdt = 1;
- ++q;
- }
- wdt_enable = valid_wdt;
- }
-#endif
/* Initialize machine-dependent vectors */
@@ -286,11 +266,6 @@ ppc4xx_init(unsigned long r3, unsigned l
ppc_md.halt = ppc4xx_halt;
ppc_md.calibrate_decr = ppc4xx_calibrate_decr;
-
-#ifdef CONFIG_PPC405_WDT
- ppc_md.heartbeat = ppc4xx_wdt_heartbeat;
-#endif
- ppc_md.heartbeat_count = 0;
ppc_md.find_end_of_memory = ppc4xx_find_end_of_memory;
ppc_md.setup_io_mappings = ppc4xx_map_io;
diff --git a/drivers/char/watchdog/Kconfig b/drivers/char/watchdog/Kconfig
--- a/drivers/char/watchdog/Kconfig
+++ b/drivers/char/watchdog/Kconfig
@@ -346,6 +346,10 @@ config 8xx_WDT
tristate "MPC8xx Watchdog Timer"
depends on WATCHDOG && 8xx
+config BOOKE_WDT
+ tristate "PowerPC Book-E Watchdog Timer"
+ depends on WATCHDOG && (BOOKE || 4xx)
+
# MIPS Architecture
config INDYDOG
diff --git a/drivers/char/watchdog/Makefile b/drivers/char/watchdog/Makefile
--- a/drivers/char/watchdog/Makefile
+++ b/drivers/char/watchdog/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_
obj-$(CONFIG_IXP2000_WATCHDOG) += ixp2000_wdt.o
obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o
obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
+obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
# Only one watchdog can succeed. We probe the hardware watchdog
# drivers first, then the softdog driver. This means if your hardware
diff --git a/drivers/char/watchdog/booke_wdt.c b/drivers/char/watchdog/booke_wdt.c
new file mode 100644
--- /dev/null
+++ b/drivers/char/watchdog/booke_wdt.c
@@ -0,0 +1,191 @@
+/*
+ * drivers/char/watchdog/booke_wdt.c
+ *
+ * Watchdog timer for PowerPC Book-E systems
+ *
+ * Author: Matthew McClintock
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/notifier.h>
+#include <linux/watchdog.h>
+
+#include <asm/reg_booke.h>
+#include <asm/uaccess.h>
+
+/* If the kernel parameter wdt_enable=1, the watchdog will be enabled at boot.
+ * Also, the wdt_period sets the watchdog timer period timeout.
+ * For E500 cpus the wdt_period sets which bit changing from 0->1 will
+ * trigger a watchog timeout. This watchdog timeout will occur 3 times, the
+ * first time nothing will happen, the second time a watchdog exception will
+ * occur, and the final time the board will reset.
+ */
+
+#ifdef CONFIG_FSL_BOOKE
+#define WDT_PERIOD_DEFAULT 63 /* Ex. wdt_period=28 bus=333Mhz , reset=~40sec */
+#else
+#define WDT_PERIOD_DEFAULT 4 /* Refer to the PPC40x and PPC4xx manuals */
+#endif /* for timing information */
+
+u32 wdt_enable = 0;
+u32 wdt_period = WDT_PERIOD_DEFAULT;
+
+#ifdef CONFIG_FSL_BOOKE
+#define WDTP(x) ((((63-x)&0x3)<<30)|(((63-x)&0x3c)<<15))
+#else
+#define WDTP(x) (TCR_WP(x))
+#endif
+
+/*
+ * booke_wdt_enable:
+ */
+static __inline__ void booke_wdt_enable(void)
+{
+ u32 val;
+
+ val = mfspr(SPRN_TCR);
+ val |= (TCR_WIE|TCR_WRC(WRC_CHIP)|WDTP(wdt_period));
+
+ mtspr(SPRN_TCR, val);
+}
+
+/*
+ * booke_wdt_ping:
+ */
+static __inline__ void booke_wdt_ping(void)
+{
+ mtspr(SPRN_TSR, TSR_ENW|TSR_WIS);
+}
+
+/*
+ * booke_wdt_write:
+ */
+static ssize_t booke_wdt_write (struct file *file, const char *buf,
+ size_t count, loff_t *ppos)
+{
+ booke_wdt_ping();
+ return count;
+}
+
+static struct watchdog_info ident = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
+ .firmware_version = 0,
+ .identity = "PowerPC Book-E Watchdog",
+};
+
+/*
+ * booke_wdt_ioctl:
+ */
+static int booke_wdt_ioctl (struct inode *inode, struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ u32 tmp = 0;
+
+ switch (cmd) {
+ case WDIOC_GETSUPPORT:
+ if (copy_to_user ((struct watchdog_info *) arg, &ident,
+ sizeof(struct watchdog_info)))
+ return -EFAULT;
+ case WDIOC_GETSTATUS:
+ return put_user(ident.options, (u32 *) arg);
+ case WDIOC_GETBOOTSTATUS:
+ /* XXX: something is clearing TSR */
+ tmp = mfspr(SPRN_TSR) & TSR_WRS(3);
+ /* returns 1 if last reset was caused by the WDT */
+ return (tmp ? 1 : 0);
+ case WDIOC_KEEPALIVE:
+ booke_wdt_ping();
+ return 0;
+ case WDIOC_SETTIMEOUT:
+ if (get_user(wdt_period, (u32 *) arg))
+ return -EFAULT;
+ mtspr(SPRN_TCR, (mfspr(SPRN_TCR)&~WDTP(0))|WDTP(wdt_period));
+ return 0;
+ case WDIOC_GETTIMEOUT:
+ return put_user(wdt_period, (u32 *) arg);
+ case WDIOC_SETOPTIONS:
+ if (get_user(tmp, (u32 *) arg))
+ return -EINVAL;
+ if (tmp == WDIOS_ENABLECARD) {
+ booke_wdt_ping();
+ break;
+ } else
+ return -EINVAL;
+ return 0;
+ default:
+ return -ENOIOCTLCMD;
+ }
+
+ return 0;
+}
+/*
+ * booke_wdt_open:
+ */
+static int booke_wdt_open (struct inode *inode, struct file *file)
+{
+ if (wdt_enable == 0) {
+ wdt_enable = 1;
+ booke_wdt_enable();
+ printk (KERN_INFO "PowerPC Book-E Watchdog Timer Enabled (wdt_period=%d)\n",
+ wdt_period);
+ }
+
+ return 0;
+}
+
+static struct file_operations booke_wdt_fops = {
+ .owner = THIS_MODULE,
+ .llseek = no_llseek,
+ .write = booke_wdt_write,
+ .ioctl = booke_wdt_ioctl,
+ .open = booke_wdt_open,
+};
+
+static struct miscdevice booke_wdt_miscdev = {
+ .minor = WATCHDOG_MINOR,
+ .name = "watchdog",
+ .fops = &booke_wdt_fops,
+};
+
+static void __exit booke_wdt_exit(void)
+{
+ misc_deregister(&booke_wdt_miscdev);
+}
+
+/*
+ * booke_wdt_init:
+ */
+static int __init booke_wdt_init(void)
+{
+ int ret = 0;
+
+ printk (KERN_INFO "PowerPC Book-E Watchdog Timer Loaded\n");
+ ident.firmware_version = cpu_specs[0].pvr_value;
+
+ ret = misc_register(&booke_wdt_miscdev);
+ if (ret) {
+ printk (KERN_CRIT "Cannot register miscdev on minor=%d (err=%d)\n",
+ WATCHDOG_MINOR, ret);
+ return ret;
+ }
+
+ if (wdt_enable == 1) {
+ printk (KERN_INFO "PowerPC Book-E Watchdog Timer Enabled (wdt_period=%d)\n",
+ wdt_period);
+ booke_wdt_enable();
+ }
+
+ return ret;
+}
+device_initcall(booke_wdt_init);
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler 'is' invoked
From: Vikas Aggarwal @ 2005-08-09 20:52 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-embedded
In-Reply-To: <20050803153540.3530e114.kim.phillips@freescale.com>
The address returned by kmalloc=0x009ffc5c is 4 byte aligned.
Are u advicing that dma_map_single() should return 8 byte aligned ,
becuase thats what gets written into the Data-Paclet_descriptor later.
regards
-vikas
> On Wed, 3 Aug 2005 14:33:26 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> I will try the new BSP but meanwhile like to debug my ported driver.
>>
>> Is there a way , like kernel level single-stepping to know why the
>> "interrupt status register" gets a value of "0x0000000000000040" which
>> means TEA , transfer error acknowledge.
>
> afaik, TEA usually means memory was unable to be accessed by the sec
> (somewhat along the same lines as a SIGBUS or SIGSEGV).
>
> It's a long shot, but you may want to increase the 4-byte alignment of the
> rng buffer (0x009ffc5c in your trace?) to at least 8-byte.
>
> as for debugging, you can printk sec status registers every time you write
> one, e.g. in a sec register write wrapper fn. Be sure to check the RNG
> interrupt status register, and the RNG status register, and the RNG
> interrupt control register.
>
> and if all else fails, you can bypass the channel infrastructure
> altogether, and use the RNG EU in slave mode. Reset the SEC, write the
> RNG Reset Control Register SR bit, write <anyvalue> to the RNG Data size
> register, and pull data off the RNG FIFO at will.
>
> Kim
>
^ permalink raw reply
* Re: Volunteers to test i2c-algo-8xx on v2.6?
From: Wolfgang Denk @ 2005-08-09 21:18 UTC (permalink / raw)
To: Debora Liu; +Cc: Linuxppc-embedded
In-Reply-To: <20050809052142.2C53242C5E@denx.de>
In message <20050809052142.2C53242C5E@denx.de> you wrote:
>
> I'm working with Wolfgang's ELDK-3.1.1,
> diff against Wolfgang's ELDK-3.1.1 patch is attached.
Ummm... A quick scan showed only reformatting and style changes. I
think someone who really understands the controller should perform a
review of the code. There are most likely problems hidden - like the
timeout of 1 second which is much too short; we measured nearly 4
seconds (under heavy load) between starting a transfer and getting
the interrupt.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Work 8 hours, sleep 8 hours; but not the same 8 hours.
^ permalink raw reply
* Re: about building RTAI 24.1.12 at Linux 2.4.25
From: Wolfgang Denk @ 2005-08-09 21:21 UTC (permalink / raw)
To: 徐勝威的EMAIL; +Cc: linuxppc-embedded
In-Reply-To: <1123568715.4219.7.camel@banana>
In message <1123568715.4219.7.camel@banana> you wrote:
>
> I got some error while make RTAI, anybody know how to fix it please
> tell me,thanks.
Use current code and current documentation.
See ftp://ftp.denx.de/pub/RTAI/README
> [root@banana rtai-24.1.12]# make
Don't use rtai-24.1.12 any more, it's too old. We support RTAI
version 3.0r5 (kilauea) and 24.1.13 (stromboli); see the README.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If all the Chinese simultaneously jumped into the Pacific off a 10
foot platform erected 10 feet off their coast, it would cause a tidal
wave that would destroy everything in this country west of Nebraska.
^ permalink raw reply
* [PATCH] ppc32: Add usb support to IBM stb04xxx platforms
From: Matt Porter @ 2005-08-09 21:38 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Support ochi-ppc-soc.c on IBM stb04xxx platforms
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -11,6 +11,7 @@
#include <linux/init.h>
#include <asm/ocp.h>
+#include <asm/ppc4xx_pic.h>
#include <platforms/4xx/ibmstb4.h>
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,51 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr = USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+/* Polarity and triggering settings for internal interrupt sources */
+struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
+ { .polarity = 0x7fffff01,
+ .triggering = 0x00000000,
+ .ext_irq_mask = 0x0000007e, /* IRQ0 - IRQ5 */
+ }
+};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end = USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end = USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xffffffffULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = "ppc-soc-ohci",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xffffffffULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ &ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x40000000
#define GPIO0_BASE 0x40060000
+#define USB0_BASE 0x40010000
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x40010000)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -18,6 +18,19 @@
#include <linux/ioport.h>
#include <asm/io.h>
#include <asm/machdep.h>
+#include <asm/ppc4xx_pic.h>
+
+/*
+ * Define external IRQ senses and polarities.
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 3 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 4 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 5 */
+};
static struct resource smc91x_resources[] = {
[0] = {
^ permalink raw reply
* Re: How to disable dcache on MPC82xx platform
From: Prashant Alange @ 2005-08-09 21:50 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <e0e99d07a5f20187cf45caac1ee9fa10@embeddededge.com>
Thanks Dan for your explaination. I am linking multiple BDs only but
no of BDs are very large in my case so I am allocating the memory and
updating the BD pointer for all BDs. I am thinking of using mem start
parameter option. I even tried using __get_free_page instead of using
cpm_hostalloc() but that also did not help.
If i use mem=3D option as kernel command line argument then I will have
to just ioremap() this reserved address in my driver and start
accessing the memory. I do not have to worry about cache related
things. right?
Thanks again,
Prashant
On 8/9/05, Dan Malek <dan@embeddededge.com> wrote:
>=20
> On Aug 9, 2005, at 10:57 AM, Prashant Alange wrote:
>=20
> > Since the existing UART/ethernet drivers are using cpm_hostalloc() so
> > I am also using the same function.
>=20
> As I have said too many times before, cpm_hostalloc() is only used
> to allocate small memory regions that would otherwise be wasteful
> with the normal Linux memory allocators. This function does not
> do anything special with the memory, aside from allowing us have
> multiple drivers share a page for efficiency.
>=20
> > Then can I use kmalloc() to alloc
> > such huge memory.
>=20
> Yes, and you should.
>=20
> > If at all I have to configure BATx to just test how
> > it behaves.
>=20
> No, that's not all you have to do. It's not a trivial process
> easily described here.
>=20
> > ..... One more thing is that
> > totally I am allocating about 1MB memory in a chunk of 200K.
>=20
> I can't comprehend a reason why you need to allocate so much
> space in a driver, especially for CPM devices. The driver is just
> a temporary FIFO for data flowing to/from other consumer/producers
> of the data in the system. If the software above a driver needs
> that kind of buffering, it should manage that itself.
>=20
> If you do need so much space, use the beauty of the CPM and
> link multiple BDs with reasonable sized buffers more easily
> managed by the existing Linux allocators.
>=20
> The other alternative is just reserve memory using the 'mem=3D'
> start parameter so it isn't know to Linux, and manage entirely
> yourself.
>=20
>=20
> -- Dan
>=20
>
^ permalink raw reply
* Re: [PATCH] ppc32: Added support for the Book-E style Watchdog Timer
From: Andrew Morton @ 2005-08-09 22:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0508091530060.10161@nylon.am.freescale.net>
Kumar Gala <galak@freescale.com> wrote:
>
> PowerPC 40x and Book-E processors support a watchdog timer at the processor
> core level. The timer has implementation dependent timeout frequencies
> that can be configured by software.
>
> One the first Watchdog timeout we get a critical exception. It is left
> to board specific code to determine what should happen at this point. If
> nothing is done and another timeout period expires the processor may
> attempt to reset the machine.
>
> Command line parameters:
> wdt=0 : disable watchdog (default)
> wdt=1 : enable watchdog
>
> wdt_period=N : N sets the value of the Watchdog Timer Period.
>
> The Watchdog Timer Period meaning is implementation specific. Check
> User Manual for the processor for more details.
>
> This patch is based off of work done by Takeharu Kato.
>
> ...
>
> +#ifdef CONFIG_BOOKE_WDT
> +/* Checks wdt=x and wdt_period=xx command-line option */
> +int __init early_parse_wdt(char *p)
> +{
> + extern u32 wdt_enable;
> +
> + if (p && strncmp(p, "0", 1) != 0)
> + wdt_enable = 1;
> +
> + return 0;
> +}
> +early_param("wdt", early_parse_wdt);
> +
> +int __init early_parse_wdt_period (char *p)
> +{
> + extern u32 wdt_period;
> +
> + if (p)
> + wdt_period = simple_strtoul(p, NULL, 0);
> +
> + return 0;
> +}
Would prefer to see the declaration of wdt_period in a header file, please.
But beware that wdt_enable() is already a static symbol in a couple of
watchdog drivers. It might be best to rename the ppc global to something
less generic-sounding while you're there.
^ permalink raw reply
* Re: How to disable dcache on MPC82xx platform
From: Dan Malek @ 2005-08-09 22:28 UTC (permalink / raw)
To: Prashant Alange; +Cc: linuxppc-embedded
In-Reply-To: <6d145b4205080914506cbc5e80@mail.gmail.com>
On Aug 9, 2005, at 5:50 PM, Prashant Alange wrote:
> ....... I am linking multiple BDs only but
> no of BDs are very large in my case so I am allocating the memory and
> updating the BD pointer for all BDs.
I don't understand what you mean here.
> If i use mem= option as kernel command line argument then I will have
> to just ioremap() this reserved address in my driver and start
> accessing the memory. I do not have to worry about cache related
> things. right?
Yes.
-- Dan
^ permalink raw reply
* gen550_dbg.c cannot handle 16 or 32 bit access to UART registers
From: Shawn Jin @ 2005-08-09 22:23 UTC (permalink / raw)
To: ppcembed
Hi,
The arch/ppc/syslib/gen550_dbg.c assumes UART registers are all
accessed in bytes. However in some designs the bus connected to UART
can only be addressed in 32 or 16 bits. So some flexibility is
desirable. And the change is kinda trivial.
Before making this trivial change, I'm confused about two sets of
defintions on io_type. In <linux/serial.h>, the following are defined.
#define SERIAL_IO_PORT=090
#define SERIAL_IO_HUB6=091
#define SERIAL_IO_MEM=092
However in <linux/serial_core.h>, these are defined.
#define UPIO_PORT=09=09(0)
#define UPIO_HUB6=09=09(1)
#define UPIO_MEM=09=09(2)
#define UPIO_MEM32=09=09(3)
Which set of defintion is better to be used in defining
SERIAL_PORT_DFNS? Currently gen550_gdb.c use SERAIL_IO_XXXX macros.
Either adding a new macro SERIAL_IO_MEM32 in <linux/serial.h> or just
use what are already there.
Are these two sets duplicated? If they are, maybe one of them will be
deprecated soon.
Regards,
-Shawn.
^ permalink raw reply
* Re: [PATCH] ppc32: Added support for the Book-E style Watchdog Timer
From: Kumar Gala @ 2005-08-09 22:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <20050809150131.7eac43ad.akpm@osdl.org>
On Aug 9, 2005, at 5:01 PM, Andrew Morton wrote:
> Kumar Gala <galak@freescale.com> wrote:
>
>>
>> PowerPC 40x and Book-E processors support a watchdog timer at the
>>
> processor
>
>> core level. The timer has implementation dependent timeout
>>
> frequencies
>
>> that can be configured by software.
>>
>> One the first Watchdog timeout we get a critical exception. It is
>>
> left
>
>> to board specific code to determine what should happen at this point.
>>
> If
>
>> nothing is done and another timeout period expires the processor may
>> attempt to reset the machine.
>>
>> Command line parameters:
>> wdt=0 : disable watchdog (default)
>> wdt=1 : enable watchdog
>>
>> wdt_period=N : N sets the value of the Watchdog Timer Period.
>>
>> The Watchdog Timer Period meaning is implementation specific. Check
>> User Manual for the processor for more details.
>>
>> This patch is based off of work done by Takeharu Kato.
>>
>> ...
>>
>> +#ifdef CONFIG_BOOKE_WDT
>> +/* Checks wdt=x and wdt_period=xx command-line option */
>> +int __init early_parse_wdt(char *p)
>> +{
>> + extern u32 wdt_enable;
>> +
>> + if (p && strncmp(p, "0", 1) != 0)
>> + wdt_enable = 1;
>> +
>> + return 0;
>> +}
>> +early_param("wdt", early_parse_wdt);
>> +
>> +int __init early_parse_wdt_period (char *p)
>> +{
>> + extern u32 wdt_period;
>> +
>> + if (p)
>> + wdt_period = simple_strtoul(p, NULL, 0);
>> +
>> + return 0;
>> +}
>>
>
>
> Would prefer to see the declaration of wdt_period in a header file,
> please.
>
> But beware that wdt_enable() is already a static symbol in a couple of
> watchdog drivers. It might be best to rename the ppc global to
> something
> less generic-sounding while you're there.
Ok, will make these changes and send an updated patch.
- kumar
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Paul Mackerras @ 2005-08-09 22:48 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Joel Schopp, linuxppc-dev, linuxppc64-dev
In-Reply-To: <bb9b1e9e1ebdc3ac5b23b3cab327bfd5@kernel.crashing.org>
Segher Boessenkool writes:
> _Please_ don't throw the real device tree away; I'm happy with
> the flattened device tree if and only if it is a _minimum_
> requirement, and having a _real_ device tree (or even real
> Open Firmware support) is still an option.
Aarrgh! <sound of paulus tearing hair out>
There seems to be a lot of misunderstanding about the flattened device
tree concept. The flattened device tree is simply a representation of
a device tree (i.e., the full, or "real" (whatever that means) device
tree) that does not contain any pointers and is in a single contiguous
block of memory.
On systems with open firmware, the boot is separated into two phases.
In the first phase, OF is still active. The kernel is not based at
physical address 0, and can do OF client calls. In the second phase,
the kernel is based at physical address 0 and OF's memory has been
reclaimed by the kernel. The flattened device tree is the main data
structure that is passed from the first phase to the second. One of
the first things that the second phase does is to expand the flattened
device tree into the normal in-kernel device tree representation (a
tree of struct device_node).
Having the flattened device tree doesn't mean that we will be using
the device tree less, it means we will be using it _more_.
Paul.
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Paul Mackerras @ 2005-08-09 22:55 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc64-dev, Geert Uytterhoeven, Linux/PPC Development
In-Reply-To: <dc3d7701e701266ffe852acf4da127ed@kernel.crashing.org>
Segher Boessenkool writes:
> Yes, and that is exactly what I do not want. We are not going
> to require OF implementations that do not need yaboot or similar
> to pass a flattened device tree to the kernel, eh? Also, there
> is no reason why something like yaboot (with an OF still running
> underneath) should have to care about anything device-tree related
> at all; the OS can just as easily ask the OF itself.
For now the kernel will cope with either having an OF client interface
entry point or a flattened device tree passed to it. In the future we
intend to move all the OF client calls into the zImage wrapper and
have the zImage wrapper pass the flattened device tree to the kernel
proper. That will be much cleaner because we will be able to get rid
of all of the dodgy RELOC stuff in prom_init.c.
It is already the case (and has always been the case) that you can't
boot a vmlinux image directly from OF - there is always either or both
of yaboot or a zImage wrapper in between anyway.
Paul.
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Kumar Gala @ 2005-08-09 23:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, Geert Uytterhoeven, Linux/PPC Development
In-Reply-To: <17145.13414.996858.522127@cargo.ozlabs.ibm.com>
On Aug 9, 2005, at 5:55 PM, Paul Mackerras wrote:
> Segher Boessenkool writes:
>
>
>> Yes, and that is exactly what I do not want. We are not going
>> to require OF implementations that do not need yaboot or similar
>> to pass a flattened device tree to the kernel, eh? Also, there
>> is no reason why something like yaboot (with an OF still running
>> underneath) should have to care about anything device-tree related
>> at all; the OS can just as easily ask the OF itself.
>>
>
> For now the kernel will cope with either having an OF client interface
> entry point or a flattened device tree passed to it. In the future we
> intend to move all the OF client calls into the zImage wrapper and
> have the zImage wrapper pass the flattened device tree to the kernel
> proper. That will be much cleaner because we will be able to get rid
> of all of the dodgy RELOC stuff in prom_init.c.
Can you clarify when the "future" is. I'd like to see this change
happen as part of the arch/powerpc work.
- kumar
^ permalink raw reply
* Re: pci_enable_device fails on MPC8541
From: Kumar Gala @ 2005-08-09 23:11 UTC (permalink / raw)
To: Bizhan Gholikhamseh \(((bgholikh\))); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA91127964158494FC@xmb-sjc-212.amer.cisco.com>
Do you need support for the VIA IDE controller? I'm not sure if that
is causing you issues.
Also, can you try enabling DEBUG in arch/ppc/kernel/pci.c and send a
boot log. I'm trying to figure out what is causing the resource
conflict. It appears that the memory resource is reasonable, but
there could be possible conflict on the IO resource side.
Also, if you can send logs of the same thing from the working 8540
ADS that would be helpful.
- kumar
On Aug 9, 2005, at 12:18 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote:
> Hi Kumar,
> I am using Linux 2.6.11, u-boot 1.1.2.
> I see failure in pci_enable_device with message:
> "PCI: Device 0000:02:01.0 not available because of resource
> collisions"
>
> I have attached three files:
> lspci_output.txt: out put of the "lspci -v"
> proc_pci.txt: output of the "cat /proc/pci"
> u-boot.txt: output of the "pci command at u-boot"
>
> Any help greatly appreciated,
> Bizhan
> -----Original Message-----
> From: Kumar Gala [mailto:kumar.gala@freescale.com]
> Sent: Monday, August 08, 2005 1:34 PM
> To: Bizhan Gholikhamseh (bgholikh)
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: pci_enable_device fails on MPC8541
>
> Bizhan,
>
> A few questions:
>
> 1. what kernel version are you using on these boards:
> 2. can you do an lspci -v on the boards
>
> - kumar
>
> On Aug 8, 2005, at 1:12 PM, Bizhan Gholikhamseh \(((bgholikh\)))
> wrote:
>
>
>> Hi All,
>> I am using two evaluation board from freescale, 8540ADS and MPC8541.
>> The same PCI driver is being compiled and loaded on both platforms.
>> The same PCI driver (developed by me) for DSP board compiled and
>> loaded on both platforms.
>>
>> When I type: "insmod C6415.ko" on 8541 board, I get the following
>> error:
>> "PCI: Device 0000:02:01.0 not available because of resource
>> collisions"
>> This messages is because of the execution of the generic PCI Linux
>> command:
>> "pci_enable_device(pdev)"
>> The same API has no problem on 8540ADS.
>>
>>
>>
>>> From UBOOT I can see my device is on bus 3:
>>>
>>>
>> => pci 3
>> Scanning PCI devices on bus 3
>> BusDev FUN VendorID DeviceID Device Class Sub-Class
>> ---------------------------------------------------------------------
>> -
>> --
>> --------------------
>> 03.01.00 0x104c 0xa106 .........
>>
>> Any idea why the insmod fails on one board and not on the other one?
>>
>> Many thanks in advance,
>> Bizhan
>>
>> <ATT2118305.txt>
>>
>>
>> <lspci_output.txt>
>> <proc_pci.txt>
>> <u-boot.txt>
>
^ permalink raw reply
* Re: [Fwd: Wall clock accuracy]
From: George Anzinger @ 2005-08-10 0:07 UTC (permalink / raw)
To: Geoff Levand, Rune Torgersen, linuxppc-embedded
In-Reply-To: <42F94091.90309@am.sony.com>
Geoff Levand wrote:
> FYI...
>
> -------- Original Message --------
> Subject: Wall clock accuracy
> Date: Tue, 9 Aug 2005 10:23:19 -0500
> From: Rune Torgersen <runet@innovsys.com>
> To: <linuxppc-embedded@ozlabs.org>
>
> Hi
>
> I have discovered that the accuracy of the wallclock (xtime) on ppc is
> not very good.
> I am running a custom telco board based on a 8266, and the main busclock
> is derived off of a T1 reference clock.
> I was noticing a huge number of logentries fron OpenNTPD about
> adjustiing the clock, so I started to check.
> The drift of the walltime was a little over 7 seconds in 15 hours (7
> seconds slow) (equals about 130us per s)
>
> When I checked around, I found that xtime is updated in kernel/time.c
> and is updated by time_nsec nanoseconds per timer interrupt.
> This value is hardcoded (through some obscure macros) to be 999848
> ns/timertick. Tis is 152ns slow per timertick. This works out to be
> 152us per second, almost the value I found.
The problem here is that the CLOCK_TICK_RATE is not correctly defined.
This should be the rate at which the decrementer is clocked in hertz.
If this is properly defined the tick_nsec value will be what works to to
be an integral number of these that gives an nsec value less than or
equal to what LATCH says you should be using for the number of
decrementer counts in a jiffie. It is important that this be correctly
defined so that a) LATCH is right and b) the jiffies to/from conversions
are done right. These conversions rely on TICK_NSEC to get the right
answer. (Also, so you don't step into a computing mess, it is important
that these be defined at compile time so the compiler can do the heavy
lifting. If defined as variables the conversions will take a LOT longer
(and use more code to boot).)
If you are getting 999848, it would appear that you are using the x86
value which, I assume, is NOT right for a PPC, but then the PPC is NOT
my strong suit...
George
>
> I have tried a few workarounds, and made one that modifies time_nsec
> before update_wall_time_one_tick() is called.
> With this fix (which is 8260 specific at the time) I have less than 1 ms
> drift after 5 days.
>
> The fix works by calculating how many ns and fractions of ns there is in
> one timer-tick (one jiffie).
> Then, at each timer interrupt, I accumulate the ns fractions, and add
> whole ns to the timer when needed.
>
> This is tested on 8266 under 80.00MHz and 82.575360MHz main busclock. It
> also works correct if HZ=1024 instead of 1000
>
> It is not meant as a patch to be added to the kernel right now, but more
> of a possible solution to a problem that it doesn't seem anybody has
> noticed before.
>
> Index: arch/ppc/kernel/time.c
> ===================================================================
> --- arch/ppc/kernel/time.c (revision 20)
> +++ arch/ppc/kernel/time.c (working copy)
> @@ -119,6 +119,11 @@
> EXPORT_SYMBOL(profile_pc);
> #endif
>
> +
> +#ifdef CONFIG_8260
> +extern unsigned long get_ns_delta(void); /*
> arch/ppc/syslib/m8260_setup.c */
> +extern unsigned long tick_nsec; /* kernel/time.c */
> +#endif
> /*
> * timer_interrupt - gets called when the decrementer overflows,
> * with interrupts disabled.
> @@ -148,6 +153,10 @@
> /* We are in an interrupt, no need to save/restore flags
> */
> write_seqlock(&xtime_lock);
> tb_last_stamp = jiffy_stamp;
> +
> +#ifdef CONFIG_8260
> + tick_nsec = get_ns_delta();
> +#endif
> do_timer(regs);
>
> /*
> @@ -179,7 +188,7 @@
> write_sequnlock(&xtime_lock);
> }
> if ( !disarm_decr[smp_processor_id()] )
> - set_dec(next_dec);
> + set_dec(next_dec-1);
> last_jiffy_stamp(cpu) = jiffy_stamp;
>
> if (ppc_md.heartbeat && !ppc_md.heartbeat_count--)
> Index: arch/ppc/syslib/m8260_setup.c
> ===================================================================
> --- arch/ppc/syslib/m8260_setup.c (revision 20)
> +++ arch/ppc/syslib/m8260_setup.c (working copy)
> @@ -31,6 +31,8 @@
>
> #include "cpm2_pic.h"
>
> +#include <linux/module.h>
> +
> unsigned char __res[sizeof(bd_t)];
>
> extern void cpm2_reset(void);
> @@ -82,16 +84,63 @@
> /* The decrementer counts at the system (internal) clock frequency
> * divided by four.
> */
> +unsigned long tb_time_nsec;
> +unsigned long tb_frac_nsec;
> +unsigned long tb_frac_limit;
> +
> +extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
> +
> static void __init
> m8260_calibrate_decr(void)
> +{
> + bd_t *binfo = (bd_t *)__res;
> + int freq, divisor, tick_freq;
> + uint64_t tmp;
> + printk("Calibrating Decrementer\n");
> +
> + freq = binfo->bi_busfreq;
> + divisor = 4;
> +
> + /* get rounded off decrementer frequency */
> + tick_freq = (freq + 3) / 4;
> +
> + /* get number of timebase ticks per jiffy (timerint) */
> + tb_ticks_per_jiffy = (tick_freq + (HZ/2)) / HZ;
> + tb_to_us = mulhwu_scale_factor(tick_freq, 1000000);
> +
> + /* calculate timer interrupt interval in nano seconds */
> + tmp = 1000000000ULL * (u64)tb_ticks_per_jiffy;
> + __div64_32(&tmp, tick_freq);
> + tb_time_nsec = tmp;
> +
> + /* calculate fractions of nanosecons per timer interrupt */
> + tb_frac_limit = 100000UL;
> + tmp = 1000000000ULL * (u64)tb_ticks_per_jiffy * tb_frac_limit;
> + __div64_32(&tmp, tick_freq);
> + tb_frac_nsec = (u32)(tmp - (u64)tb_time_nsec * (u64)tb_frac_limit);
> +
> + printk("busfreq = %u\n", freq);
> + printk("tb_ticks_per_jiffy = %u\ntb_to_us = %u\n",
> tb_ticks_per_jiffy, tb_to_us);
> + printk("tick_freq = %u\ntime_nsec = %u\ntb_frac_nsec = %u\n",
> tick_freq, tb_time_nsec, tb_frac_nsec);
> +}
> +
> +unsigned long get_ns_delta(void)
> {
> - bd_t *binfo = (bd_t *)__res;
> - int freq, divisor;
> + static uint32_t frac = 0;
>
> - freq = binfo->bi_busfreq;
> - divisor = 4;
> - tb_ticks_per_jiffy = freq / HZ / divisor;
> - tb_to_us = mulhwu_scale_factor(freq / divisor, 1000000);
> + unsigned long delta_ns;
> +
> + delta_ns = tb_time_nsec;
> +
> + /* adjust for inaccuracy in calculation */
> + frac += tb_frac_nsec;
> + if (frac >= tb_frac_limit)
> + {
> + delta_ns += frac / tb_frac_limit;
> + frac %= tb_frac_limit;
> + }
> +
> + return delta_ns;
> }
>
> /* The 8260 has an internal 1-second timer update register that
>
> Rune Torgersen
> System Developer
> Innovative Systems LLC
> 1000 Innovative Drive
> Mitchell, SD 57301
> Ph: 605-995-6120
> www.innovsys.com
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
^ permalink raw reply
* passing ram= argument to kernel
From: Prashant Alange @ 2005-08-10 0:23 UTC (permalink / raw)
To: Linuxppc-embedded
Hi,
I am trying to pass ram=3D argument to kernel and my bootcmd is as shown be=
low
tftpboot 03000000 prashant/root.img; tftpboot 00100000 prashant/uImage; set=
env b
ootargs root=3D/dev/ram ram=3D60M
ip=3D10.67.65.68:10.67.65.39:255.255.255.0:MPC8270:eth1:off; bootm
00100000 03000000
I have 64 MB RAM on my system. With above command if I boot the board and s=
ee
cat /proc/meminfo I still see 64MB RAM.
Can anyone tell me, how to pass ram argument.=20
Thanks,
Prashant
^ permalink raw reply
* Re: passing ram= argument to kernel
From: Kumar Gala @ 2005-08-10 0:30 UTC (permalink / raw)
To: Prashant Alange; +Cc: Linuxppc-embedded
In-Reply-To: <6d145b42050809172365209b9e@mail.gmail.com>
I think you want mem=60M
- kumar
On Tue, 9 Aug 2005, Prashant Alange wrote:
> Hi,
> I am trying to pass ram= argument to kernel and my bootcmd is as shown below
>
> tftpboot 03000000 prashant/root.img; tftpboot 00100000 prashant/uImage; setenv b
> ootargs root=/dev/ram ram=60M
> ip=10.67.65.68:10.67.65.39:255.255.255.0:MPC8270:eth1:off; bootm
> 00100000 03000000
>
> I have 64 MB RAM on my system. With above command if I boot the board and see
> cat /proc/meminfo I still see 64MB RAM.
> Can anyone tell me, how to pass ram argument.
>
> Thanks,
> Prashant
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ 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