* Re: [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
From: Dan Malek @ 2005-05-07 3:09 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050506200338.GC14486@logos.cnet>
On May 6, 2005, at 4:03 PM, Marcelo Tosatti wrote:
> The data I have tells me otherwise. I have seen the I-TLB entries
> getting created for kernel space.
Of course. That's because the pinned entries aren't working :-)
> Can't the BDI work on the 8Mbyte page? Same for other software
> or debuggers...
The BDI can, but other software functions will walk the page
tables looking for PTE information.
> /* get the PTE for the bootpage */
> if (!get_pteptr(&init_mm, bootpage, &pte))
> panic("get_pteptr failed\n");
>
> /* and make it uncachable */
> pte_val(*pte) |= _PAGE_NO_CACHE;
> _tlbie(bootpage);
This is a bad hack (that I wrote) that needs to get fixed.
> Because DMA pages need to have their PTE's marked as uncached, which
> in turn
> means their TLB's need to be marked as uncached.
Right, but these are allocated from the vmalloc() space, far away
from the pinned entries.
> I dont think you can have multiple overlapping TLB entries.
Sure you can, we do it all of the time. The kernel maps all of
memory, and then user applications do it again. The only time
it causes a problem is when you have different cache attributes
for the same physical page. In this case, you need to ensure
you only use one mapping. You can't have the same virtual
address twice in the TLB (iirc, the 8xx automatically invalidates
an existing one if you do this), but you can have the same
physical page mapped multiple times.
> How is the MMU supposed to decide between multiple mappings
> for the same address ?
You are thinking backward. The MMU maps the virtual address
accessed, there is only one valid at a time. You can have multiple
VM addresses accessing the same physical page.
> That is how it is now. See previous posts with detailed TLB debugging.
Something isn't correct if it isn't working.
> Maybe you thought you got it right because the initial 8Mbyte
> mapping works?
No, this is required to work for some execute in place from rom
systems I have done. It was adapted from that. The initial 8M
mapping must be evicted when the mapin_ram() is done. It's
supposed to happen that way.
> Unfortunately that mapping is trashed after overlapping
> pte's are created.
Right, that is supposed to happen unless TLB pinning
is configured.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
From: Marcelo Tosatti @ 2005-05-06 20:03 UTC (permalink / raw)
To: Dan Malek; +Cc: linux-ppc-embedded
In-Reply-To: <3ebef94782a6090ac3eb44bd7e78efbf@embeddededge.com>
Hi Dan,
On Fri, May 06, 2005 at 06:49:11PM -0400, Dan Malek wrote:
>
> On May 6, 2005, at 9:38 AM, Marcelo Tosatti wrote:
>
> >1) avoids the creation of pte tables in the 8Mbyte range, thus
> >preserving
> >the pinned TLB entry.
>
> This has nothing to do with "preserving" the pinned TLB entry.
> The pinned entries are placed into the reserved portion of the TLB,
> and are never evicted.
OK.
> We never get a fault on these pages, so wenever look up an
> entry in the page table.
The data I have tells me otherwise. I have seen the I-TLB entries
getting created for kernel space.
I did the following:
- insert a break at the beginning of start_kernel, another break at
the end of start_kernel.
- boot, BDI stops at start_kernel.
- dump I-TLB contents, no entries for "start_kernel" pages on I-TLB.
- "go".
- BDI stops at the end of start_kernel.
- dump I-TLB contents, see the 4kb entries for "start_kernel" I-cache
there (ie we _do_ get faults on these pages).
Check it out.
If your setup is not working yet I can get the data for you tomorrow.
> We need to create the
> page tables for informational purposes, so software or debugger
> lookups will do the right thing.
Can't the BDI work on the 8Mbyte page? Same for other software
or debuggers...
Any in-kernel algorithm which relies on direct pte manipulation
looks fragile...
i386 and some (?) other architectures do use big pages for the first
kernel addresses, right?
> >2) restricts bootmem to above 8Mbyte region
>
> Why is this necessary?
void __init
m8xx_setup_arch(void)
{
int cpm_page;
cpm_page = (int) alloc_bootmem_pages(PAGE_SIZE);
/* Reset the Communication Processor Module.
*/
m8xx_cpm_reset(cpm_page);
...
void
m8xx_cpm_reset(uint bootpage)
{
...
/* get the PTE for the bootpage */
if (!get_pteptr(&init_mm, bootpage, &pte))
panic("get_pteptr failed\n");
/* and make it uncachable */
pte_val(*pte) |= _PAGE_NO_CACHE;
_tlbie(bootpage);
host_buffer = bootpage;
host_end = host_buffer + PAGE_SIZE;
> >3) Memory for DMA pages must not be in the pinned region. ie. drivers
> >should not allocate memory directly for DMA purposes.
>
> Why not?
Because DMA pages need to have their PTE's marked as uncached, which in turn
means their TLB's need to be marked as uncached.
> It doesn't matter if we cover a VM space with a bunch of 4K
> entries or a single 8M entry. The physical pages are always going to
> be multiple mapped, either through the mapin_ram() space or a single 8M
> entry, and also through the vmalloc() space. You just have to ensure,
> in any case, that you don't access the pages through both VM spaces.
I dont think you can have multiple overlapping TLB entries.
How is the MMU supposed to decide between multiple mappings
for the same address ?
> >Dan, I would really enjoy having access to some of your precious 8xx
> >knowledge: share it, along with the correct way to fix this and the
> >other pending issues.
>
> The correct fix is rather simple, just make sure you configure the TLB
> to reserve entries, and get the pinned entries into those reserved
> entries.
That is how it is now. See previous posts with detailed TLB debugging.
> I know I had it right once, I don't know what happened :-)
Maybe you thought you got it right because the initial 8Mbyte
mapping works?
Unfortunately that mapping is trashed after overlapping
pte's are created.
> Just hang on and I'll get you some code to test ....
Sure...
^ permalink raw reply
* Re: Laptop sleep & current "git" tree
From: Benjamin Herrenschmidt @ 2005-05-07 0:06 UTC (permalink / raw)
To: Eddy Petrisor; +Cc: linuxppc-dev list, DebianPPC
In-Reply-To: <427BE8B0.5030802@gmail.com>
On Sat, 2005-05-07 at 00:59 +0300, Eddy Petrisor wrote:
> Benjamin Herrenschmidt wrote:
> >
> > I don't know this problem, what happens precisely and what model of
> > radeon chip do you have ?
> >
> I am just interfering as you talked about radeon models; is there any
> good news regarding the >9600 chipsets?
> I know there was a project (R300 iirc) that wanted to make a driver, but
> progress was slow or non-existant last time I heard about it.
There is a fully working 2D driver and there is an in-progress 3D driver
based on some sort of reverse engineering. It works weel enough for some
things like tuxracer, pinball or bzflag :) You probably need to get all
sort of up to date CVS things to get it to work though (X.org, DRI and
Mesa)
Ben.
^ permalink raw reply
* Re: [PATCH] ppc32: Fix POWER3/POWER4 compiler error
From: Paul Mackerras @ 2005-05-06 23:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel, Kumar Gala
In-Reply-To: <Pine.LNX.4.61.0505061336250.28348@nylon.am.freescale.net>
Kumar Gala writes:
> In separating out support for hardware floating point we missed the fact that
> both POWER3 and POWER4 have HW FP. Enable CONFIG_PPC_FPU for POWER3
> and POWER4 fixes the issue.
>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
From: Dan Malek @ 2005-05-06 23:10 UTC (permalink / raw)
To: Dan Malek; +Cc: linux-ppc-embedded
In-Reply-To: <3ebef94782a6090ac3eb44bd7e78efbf@embeddededge.com>
On May 6, 2005, at 6:49 PM, Dan Malek wrote:
>> 3) Memory for DMA pages must not be in the pinned region. ie. drivers
>> should not allocate memory directly for DMA purposes.
>
> Why not?
Having now read this again, the "Why not?" was for the first
sentence :-)
Drivers should always use the proper dma allocation functions.
Unpredictable and sometimes exciting results can happen if
they don't.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
From: Dan Malek @ 2005-05-06 22:49 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050506133858.GA6032@logos.cnet>
On May 6, 2005, at 9:38 AM, Marcelo Tosatti wrote:
> 1) avoids the creation of pte tables in the 8Mbyte range, thus
> preserving
> the pinned TLB entry.
This has nothing to do with "preserving" the pinned TLB entry.
The pinned entries are placed into the reserved portion of the TLB,
and are never evicted. We never get a fault on these pages, so we
never look up an entry in the page table. We need to create the
page tables for informational purposes, so software or debugger
lookups will do the right thing.
> 2) restricts bootmem to above 8Mbyte region
Why is this necessary?
> 3) Memory for DMA pages must not be in the pinned region. ie. drivers
> should not allocate memory directly for DMA purposes.
Why not? It doesn't matter if we cover a VM space with a bunch of 4K
entries or a single 8M entry. The physical pages are always going to
be multiple mapped, either through the mapin_ram() space or a single 8M
entry, and also through the vmalloc() space. You just have to ensure,
in any case, that you don't access the pages through both VM spaces.
> Dan, I would really enjoy having access to some of your precious 8xx
> knowledge: share it, along with the correct way to fix this and the
> other pending issues.
The correct fix is rather simple, just make sure you configure the TLB
to reserve entries, and get the pinned entries into those reserved
entries. I know I had it right once, I don't know what happened :-)
Just hang on and I'll get you some code to test ....
Thanks.
-- Dan
^ permalink raw reply
* Re: PPC uImage build not reporting correctly
From: Sam Ravnborg @ 2005-05-06 21:45 UTC (permalink / raw)
To: Kumar Gala
Cc: Tom Rini, Sam Ravnborg, Linux Kernel list, linuxppc-embedded list
In-Reply-To: <cbf07e669ed84066a0bc366ca254123b@freescale.com>
> Sam,
>
> Tom pointed me at you to look at a makefile issue with
> arch/ppc/boot/images/Makefile. When I do the following:
>
> $ make uImage
> CHK include/linux/version.h
> make[1]: `arch/ppc/kernel/asm-offsets.s' is up to date.
> CHK include/linux/compile.h
> CHK usr/initramfs_list
> UIMAGE arch/ppc/boot/images/uImage
> Image Name: Linux-2.6.12-rc3
> Created: Fri May 6 10:19:28 2005
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 993322 Bytes = 970.04 kB = 0.95 MB
> Load Address: 0x00000000
> Entry Point: 0x00000000
> Image: arch/ppc/boot/images/uImage not made
>
> The issue is that the file arch/ppc/boot/images/uImage does exit (the
> 'not made' is not correct).
>
> $(obj)/uImage: $(obj)/vmlinux.gz
> $(Q)rm -f $@
> $(call if_changed,uimage)
> @echo ' Image: $@' $(if $(wildcard $@),'is ready','not made')
>
> It seems the $(wildcard $@) expands at the start of the rule. Any
> ideas?
It probarly uses the build-in cache in make - and I see no easy way to
tell make not to use the cache in this case.
Could you try to replace "$(wildcard $@)" with something like:
$(shell if -f $@ echo Y; fi)
Untested - I'm not on a Linux box right now.
Sam
^ permalink raw reply
* Re: Laptop sleep & current "git" tree
From: Eddy Petrisor @ 2005-05-06 21:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, DebianPPC
In-Reply-To: <1115163690.7568.45.camel@gaston>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=x-user-defined; format=flowed, Size: 495 bytes --]
Benjamin Herrenschmidt wrote:
>
> I don't know this problem, what happens precisely and what model of
> radeon chip do you have ?
>
I am just interfering as you talked about radeon models; is there any
good news regarding the >9600 chipsets?
I know there was a project (R300 iirc) that wanted to make a driver, but
progress was slow or non-existant last time I heard about it.
--
Regards,
EddyP
===========================
I had a favourite quote, but I forgot it. And it was insightful.
^ permalink raw reply
* Re: PPC uImage build not reporting correctly
From: Kumar Gala @ 2005-05-06 21:57 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Tom Rini, Linux Kernel list, linuxppc-embedded list
In-Reply-To: <33091.80.160.117.125.1115415913.squirrel@80.160.117.125>
On May 6, 2005, at 4:45 PM, Sam Ravnborg wrote:
> > Sam,
> >
> > Tom pointed me at you to look at a makefile issue with
> > arch/ppc/boot/images/Makefile.=A0 When I do the following:
> >
> > $ make uImage
> >=A0=A0=A0 CHK=A0=A0=A0=A0 include/linux/version.h
> > make[1]: `arch/ppc/kernel/asm-offsets.s' is up to date.
> >=A0=A0=A0 CHK=A0=A0=A0=A0 include/linux/compile.h
> >=A0=A0=A0 CHK=A0=A0=A0=A0 usr/initramfs_list
> >=A0=A0=A0 UIMAGE=A0 arch/ppc/boot/images/uImage
> > Image Name:=A0=A0 Linux-2.6.12-rc3
> > Created:=A0=A0=A0=A0=A0 Fri May=A0 6 10:19:28 2005
> > Image Type:=A0=A0 PowerPC Linux Kernel Image (gzip compressed)
> > Data Size:=A0=A0=A0 993322 Bytes =3D 970.04 kB =3D 0.95 MB
> > Load Address: 0x00000000
> > Entry Point:=A0 0x00000000
> >=A0=A0=A0 Image: arch/ppc/boot/images/uImage not made
> >
> > The issue is that the file arch/ppc/boot/images/uImage does exit=20
> (the
> > 'not made' is not correct).
> >
> > $(obj)/uImage: $(obj)/vmlinux.gz
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0 $(Q)rm -f $@
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0 $(call if_changed,uimage)
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0 @echo '=A0 Image: $@' $(if $(wildcard =
$@),'is ready','not=20
> made')
> >
> > It seems the $(wildcard $@) expands at the start of the rule.=A0 =
Any
> > ideas?
>
> It probarly uses the build-in cache in make - and I see no easy way to
> tell make not to use the cache in this case.
> Could you try to replace "$(wildcard $@)" with something like:
> $(shell if -f $@ echo Y; fi)
>
> Untested - I'm not on a Linux box right now.
I tried the following w/o success:
$(obj)/uImage: $(obj)/vmlinux.gz
$(Q)rm -f $@
$(call if_changed,uimage)
@echo ' Image: $@' $(shell if [ -f $@ ]; then echo 'is ready';=20=
else echo 'not made'; fi)
- kumar=
^ permalink raw reply
* [PATCH] BOOKE_WDT Part 2/2 (Re: PPC 44x Watchdog timer)
From: Takeharu KATO @ 2005-05-06 21:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: Glenn Burkhardt, Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <905bacf60cf1e3167d4f42dba31c9d4f@freescale.com>
Hi Kumar:
>
> Sorry, I think Matt and I have been busy with normal "work". I'll take
> a look at this in the next week. If you can update the patches to
> something current that would help (but is not critical).
>
This is device driver part.
Signed-off-by: kato.takeharu@jp.fujitsu.com
diff -Nupr linux-2.6.orig/drivers/char/watchdog/Kconfig
linux-2.6/drivers/char/watchdog/Kconfig
--- linux-2.6.orig/drivers/char/watchdog/Kconfig 2005-05-06
05:04:23.000000000 +0900
+++ linux-2.6/drivers/char/watchdog/Kconfig 2005-05-07
05:17:03.000000000 +0900
@@ -346,6 +346,13 @@ config 8xx_WDT
tristate "MPC8xx Watchdog Timer"
depends on WATCHDOG && 8xx
+config BOOKE_WDT
+ bool "Book E(PowerPC 4xx/e500) Watchdog Timer"
+ depends on WATCHDOG && ( 4xx || E500 )
+ ---help---
+ This is the driver for the watchdog timers on
+ PowerPC 4xx and PowerPC e500.
+
# MIPS Architecture
config INDYDOG
diff -Nupr linux-2.6.orig/drivers/char/watchdog/Makefile
linux-2.6/drivers/char/watchdog/Makefile
--- linux-2.6.orig/drivers/char/watchdog/Makefile 2005-05-06
05:04:23.000000000 +0900
+++ linux-2.6/drivers/char/watchdog/Makefile 2005-05-07
05:17:34.000000000 +0900
@@ -33,6 +33,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.
obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o
obj-$(CONFIG_IXP2000_WATCHDOG) += ixp2000_wdt.o
obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.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 -Nupr linux-2.6.orig/drivers/char/watchdog/booke_wdt.c
linux-2.6/drivers/char/watchdog/booke_wdt.c
--- linux-2.6.orig/drivers/char/watchdog/booke_wdt.c 1970-01-01
09:00:00.000000000 +0900
+++ linux-2.6/drivers/char/watchdog/booke_wdt.c 2005-05-07
05:19:17.000000000 +0900
@@ -0,0 +1,629 @@
+/*
+ * Copyright (c) 2005 Fujitsu Limited
+ *
+ * Module name: booke_wdt.c
+ * Author: Takeharu KATO<kato.takeharu@jp.fujitsu.com>
+ *
+ * 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.
+ *
+ * Neither Takeharu KATO nor Fujitsu Ltd. admit liability nor provide
+ * warranty for any of this software.
+ *
+ * Description:
+ * Watchdog driver for PowerPC Book E (PowerPC 4xx series
processors and
+ * PowerPC e500 series processors).
+ * Derived from drivers/char/watchdog/wdt.c by Alan cox
+ * and drivers/char/watchdog/ppc405_wdt.c by Armin Kuster.
+ * PPC4xx WDT operation is driverd from Appendix of
+ * PowerPC Embedded Processors Application Note
+ * ``PowerPC 40x Watch Dog Timer'' published from IBM.
+ * This driver is written according to ``PowerPC e500 Core Complex
+ * Reference Manual'' for e500 part.
+ */
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/miscdevice.h>
+#include <linux/watchdog.h>
+#include <linux/fs.h>
+#include <linux/reboot.h>
+#include <linux/init.h>
+#include <linux/capability.h>
+#include <linux/string.h>
+#include <linux/ptrace.h>
+#include <asm/reg.h>
+#include <asm/uaccess.h>
+#include <asm/system.h>
+#include <asm/cputable.h>
+#include "booke_wdt.h"
+
+/* micro seconds per one milli-second(used to calculatewatchdog
+ * counter to be set). */
+#define US_PER_MS 1000
+/* Calculate watchdog count */
+#define calculate_wdt_count(t) ((((unsigned long)(t))*HZ)/1000)
+
+int wdt_enable=0; /* WDT start on boot */
+int wdt_period=WDT_TIMO; /* Time out in ms */
+
+#ifdef CONFIG_WATCHDOG_NOWAYOUT
+static int nowayout = 1;
+#else
+static int nowayout = 0;
+#endif
+
+/*
+ * Global variables
+ */
+static int wdt_count = 0; /* WDT intrrupt counter to be
reloaded */
+static volatile int wdt_heartbeat_count = 0; /* WDT intrrupt
counter(compatible mode)*/
+static unsigned long driver_state; /* Driver status (see: booke_wdt.h) */
+/*
+ * Identifier for this watchdog
+ */
+static struct watchdog_info ident = {
+ .options=WDIOF_SETTIMEOUT|WDIOF_KEEPALIVEPING|WDIOF_MAGICCLOSE,
+ .firmware_version = 0, /* This is filled with PVR in
initialization. */
+ .identity = "Book E(PPC 4xx/e500) WDT",
+};
+
+/*
+ * PowerPC Linux common exception handler
+ */
+extern void _exception(int signr, struct pt_regs *regs, int code,
unsigned long addr);
+/* Panic notifier */
+extern struct notifier_block *panic_notifier_list;
+/*
+ * Watchdog operations on PPC4xx/e500 MPU
+ */
+/**
+ * __booke_wdt_setup_val
+ * Enable Watchdog, sets up passed in values for TCR[WP],
+ * TCR[WRC]
+ *
+ * @period: Input Watchdog Period - TCR[WP]
+ * 0...2^17(PPC405) or 2^21(PPC440/e500) clocks
+ * 1...2^21(PPC405) or 2^25(PPC440/e500) clocks
+ * 2...2^25(PPC405) or 2^29(PPC440/e500) clocks
+ * 3...2^25(PPC405) or 2^29(PPC440/e500) clocks
+ * @reset: Watchdog reset control - TCR[WRC]
+ * 0 = No reset
+ * 1 = PPC Core reset only
+ * 2 = PPC Chip reset
+ * 3 = System reset
+ * Note: The meaning of period number is differ PPC405 from PPC440.
+ * Current version assume that this function called with
+ * WRC_NONE as reset, if someone who want to remove this
+ * constraint, please note that when we disable WDT, we should
+ * set WRC with WRC_NONE and s/he should also modify
+ * disable/enable_wdt function.
+ *
+ */
+static __inline__ void
+__booke_wdt_setup_val(int period,int reset)
+{
+ unsigned long val;
+
+ /* Set up TCR */
+ val=wdt_calculate_tcr(period,reset)| mfspr(SPRN_TCR);
+ /* Disable WDT */
+ val &= ~(TCR_WIE);
+
+ mtspr(SPRN_TCR,val);
+}
+/**
+ * __booke_wdt_enable
+ * Enable Watchdog
+ */
+static __inline__ void
+__booke_wdt_enable(void)
+{
+ mtspr(SPRN_TCR,(mfspr(SPRN_TCR)|TCR_WIE));
+}
+/**
+ * __booke_wdt_disable
+ * Disable Watchdog
+ */
+static __inline__ void
+__booke_wdt_disable(void)
+{
+ mtspr(SPRN_TCR,(mfspr(SPRN_TCR)&(~(TCR_WIE))));
+}
+/**
+ * __booke_wdt_is_enabled
+ * Check whether Watchdog is enabled.
+ */
+static __inline__ int
+__booke_wdt_is_enabled(void)
+{
+ return (mfspr(SPRN_TCR) & TCR_WIE);
+}
+/**
+ * __booke_wdt_clear_init_stat
+ * Clear interrupt status of watchdog to ping it.
+ */
+static __inline__ void
+__booke_wdt_clear_int_stat(void)
+{
+ mtspr(SPRN_TSR, (TSR_ENW|TSR_WIS));
+}
+/**
+ * __booke_wdt_set_timeout:
+ * @t: the new time out value that needs to be set.
+ *
+ * Set a new time out value for the watchdog device.
+ *
+ */
+static __inline__ void
+__booke_wdt_set_timeout(int t)
+{
+ wdt_count=calculate_wdt_count(t);
+ return;
+}
+
+/*
+ * Driver specific functions
+ */
+
+/**
+ * booke_wdt_setup_options
+ * @cmd_line : a pointer to kernel command line.
+ *
+ */
+void
+booke_wdt_setup_options(char *cmd_line)
+{
+/*
+ * 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;
+ }
+ return;
+}
+/**
+ * booke_wdt_heartbeat:
+ * Ping routine called from kernel.
+ */
+void
+booke_wdt_heartbeat(void)
+{
+ /* Disable watchdog */
+ __booke_wdt_disable();
+
+ /* Write a watchdog value */
+ __booke_wdt_clear_int_stat();
+
+ if (!wdt_enable)
+ goto out;
+
+ if (wdt_heartbeat_count > 0)
+ wdt_heartbeat_count--;
+ else
+ panic(booke_mkmsg("Initiating system reboot.\n"));
+
+ /* Enable watchdog */
+ __booke_wdt_enable();
+ out:
+ /* Reset count */
+ ppc_md.heartbeat_count = 0;
+}
+/**
+ * booke_wdt_exception:
+ * WatchDog Exception handler for PPC4xx/e500.
+ * @regs : A registers information.
+ */
+void
+booke_wdt_exception(struct pt_regs *regs)
+{
+
+ wdt_enable=0;
+ __booke_wdt_disable();
+ printk(KERN_EMERG "WDT Exception at PC: %lx, MSR: %lx, vector=%lx
%s\n",
+ regs->nip, regs->msr, regs->trap, print_tainted());
+ panic(booke_mkmsg("Initiating system reboot.\n"));
+}
+/*
+ * Driver Logic functions
+ */
+static __inline__ int
+booke_wdt_is_enabled(void)
+{
+ return __booke_wdt_is_enabled();
+}
+/**
+ * booke_wdt_start:
+ *
+ * Start the watchdog driver.
+ */
+static __inline__ int
+booke_wdt_start(void)
+{
+
+ __booke_wdt_enable();
+ return 0;
+}
+
+/**
+ * booke_wdt_stop:
+ *
+ * Stop the watchdog driver.
+ */
+static __inline__ int
+booke_wdt_stop (void)
+{
+
+ __booke_wdt_disable();
+ return 0;
+}
+/**
+ * booke_wdt_ping:
+ *
+ * Reload counter one with the watchdog heartbeat. We don't bother
reloading
+ * the cascade counter.
+ */
+static __inline__ int
+booke_wdt_ping(void)
+{
+
+ /* Disable watchdog */
+ __booke_wdt_disable();
+ /* Write a watchdog value */
+ __booke_wdt_clear_int_stat();
+ /* Reset count */
+ wdt_heartbeat_count=wdt_count;
+ /* Enable watchdog */
+ __booke_wdt_enable();
+
+ return 0;
+}
+/**
+ * booke_wdt_set_timeout:
+ * @t: the new timeout value that needs to be set.
+ *
+ * Set a new time out value for the watchdog device.
+ * If the heartbeat value is incorrect we keep the old value
+ * and return -EINVAL. If successfull we return 0.
+ */
+static __inline__ int
+booke_wdt_set_timeout(int t)
+{
+
+ if ((t < WDT_HEARTBEAT_MIN) || (t > WDT_HEARTBEAT_MAX))
+ return -EINVAL;
+
+ wdt_period = t;
+ __booke_wdt_set_timeout(t);
+ wdt_heartbeat_count=wdt_count;
+ booke_wdt_dbg("The WDT counter set %d.\n",wdt_count);
+
+ return 0;
+}
+
+/**
+ * booke_wdt_get_status:
+ * @status: the new status.
+ *
+ * Return the enable/disable card status.
+ */
+static __inline__ int
+booke_wdt_get_status(int *status)
+{
+
+ if (wdt_enable)
+ *status = WDIOS_ENABLECARD;
+ else
+ *status = WDIOS_DISABLECARD;
+
+ return 0;
+}
+/*
+ * Kernel Interfaces
+ */
+/**
+ * booke_wdt_init_device:
+ *
+ * Initilize PowerPC 4xx/e500 family Watch Dog facility.
+ */
+static void
+booke_wdt_init_device(void)
+{
+
+ /* Hardware WDT provided by the processor.
+ * So, we set firmware version as processor version number.
+ */
+ ident.firmware_version=cpu_specs[0].pvr_value;
+ __booke_wdt_setup_val(WDT_WP,WRC_NONE);
+}
+/**
+ * booke_wdt_write:
+ * @file: file handle to the watchdog
+ * @buf: buffer to write (unused as data does not matter here
+ * @count: count of bytes
+ * @ppos: pointer to the position to write. No seeks allowed
+ *
+ * A write to a watchdog device is defined as a keepalive signal. Any
+ * write of data will do, as we we don't define content meaning expept
+ * 'V' character. It is performed as a sign to set stop-on-close mode.
+ */
+
+static ssize_t
+booke_wdt_write(struct file *file, const char *buf, size_t count,
loff_t *ppos)
+{
+ size_t i;
+
+ if (!nowayout) {
+ /* In case it was set long ago */
+ clear_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state);
+
+ for (i = 0; i < count; i++) {
+ char c;
+
+ if (get_user(c, buf + i))
+ return -EFAULT;
+
+ if (c == 'V') {
+ set_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state);
+ }
+ }
+ }
+ booke_wdt_ping();
+
+ return count;
+}
+
+/**
+ * booke_wdt_ioctl:
+ * @inode: inode of the device
+ * @file: file handle to the device
+ * @cmd: watchdog command
+ * @arg: argument pointer
+ *
+ */
+static int
+booke_wdt_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ int new_timeout;
+ int status;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM; /* It may be too strict manner. */
+ switch(cmd)
+ {
+ default:
+ return -ENOIOCTLCMD;
+ case WDIOC_GETSUPPORT:
+ if (copy_to_user((struct watchdog_info *)arg, &ident,
sizeof(struct watchdog_info)))
+ return -EFAULT;
+ else
+ break;
+ case WDIOC_GETSTATUS:
+ booke_wdt_get_status(&status);
+ return put_user(status,(int *)arg);
+ case WDIOC_KEEPALIVE:
+ booke_wdt_ping();
+ break;
+ case WDIOC_SETTIMEOUT:
+ if (get_user(new_timeout, (int *)arg))
+ return -EFAULT;
+ if (booke_wdt_set_timeout(new_timeout))
+ return -EINVAL;
+ booke_wdt_ping();
+ break;
+ case WDIOC_GETTIMEOUT:
+ return put_user(wdt_period, (int *)arg);
+ case WDIOC_SETOPTIONS:
+ if (get_user(status, (int *)arg))
+ return -EFAULT;
+ /* Return -EINVAL when the driver can not figure out
+ * what it should do. Unknown cases are just ignored.
+ */
+ if ( (status & (WDIOS_DISABLECARD|WDIOS_ENABLECARD))
+ == (WDIOS_DISABLECARD|WDIOS_ENABLECARD) )
+ return -EINVAL;
+ if (status & WDIOS_DISABLECARD) {
+ wdt_enable = 0;
+ booke_wdt_stop();
+ booke_wdt_info("Watchdog timer is disabled\n");
+ }
+ if (status & WDIOS_ENABLECARD) {
+ wdt_enable = 1;
+ booke_wdt_start();
+ booke_wdt_info("Watchdog timer is enabled\n");
+ }
+ break;
+ }
+ return 0;
+}
+/**
+ * booke_wdt_open:
+ * @inode: inode of device
+ * @file: file handle to device
+ *
+ * The watchdog device has been opened. The watchdog device is single
+ * open and start the WDT timer.
+ */
+static int
+booke_wdt_open(struct inode *inode, struct file *file)
+{
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ if (test_and_set_bit(WDT_STATE_OPEN, &driver_state))
+ return -EBUSY;
+ /*
+ * Activate
+ */
+ booke_wdt_start();
+ wdt_enable=1;
+
+ if (nowayout)
+ set_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state);
+
+ return 0;
+}
+
+/**
+ * booke_wdt_release:
+ * @inode: inode to board
+ * @file: file handle to board
+ *
+ */
+static int
+booke_wdt_release(struct inode *inode, struct file *file)
+{
+ if (test_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state)) {
+ booke_wdt_info("WDT device is stopped.\n");
+ booke_wdt_stop();
+ wdt_enable=0;
+ } else {
+ if ( (booke_wdt_is_enabled()) && (!nowayout) ) {
+ booke_wdt_info("WDT device may be closed unexpectedly. WDT will
not stop!\n");
+ booke_wdt_ping();
+ }
+ }
+ clear_bit(WDT_STATE_OPEN, &driver_state);
+
+ return 0;
+}
+/**
+ * notify_sys:
+ * @this: our notifier block
+ * @code: the event being reported
+ * @unused: unused
+ * Note: This function assume that the panic notifier is called with
CODE=0
+ * (see panic function in kernel/panic.c).
+ */
+static int
+booke_wdt_notify_sys(struct notifier_block *this, unsigned long code,
+ void *unused)
+{
+
+ if (code != SYS_POWER_OFF) /* Turn the card off */
+ booke_wdt_stop();
+
+ return NOTIFY_DONE;
+}
+
+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,
+ .release = booke_wdt_release,
+};
+
+static struct miscdevice booke_wdt_miscdev = {
+ .minor = WATCHDOG_MINOR,
+ .name = "watchdog",
+ .fops = &booke_wdt_fops,
+};
+
+/*
+ * The WDT card needs to know about shutdowns in order to
+ * turn WDT off.
+ */
+
+static struct notifier_block booke_wdt_notifier = {
+ .notifier_call = booke_wdt_notify_sys,
+};
+
+/**
+ * cleanup_module:
+ *
+ * If your watchdog is set to continue ticking on close and you unload
+ * it, well it keeps ticking. You just have to load a new
+ * module in 60 seconds or reboot.
+ * This behavior(more over the comments as above) is borrowed from
+ * Alan cox's driver.
+ */
+
+static void __exit
+booke_wdt_exit(void)
+{
+ misc_deregister(&booke_wdt_miscdev);
+ unregister_reboot_notifier(&booke_wdt_notifier);
+ notifier_chain_unregister(&panic_notifier_list,&booke_wdt_notifier);
+}
+
+/**
+ * booke_wdt_init:
+ *
+ * Set up the WDT relevant timer facility.
+ */
+
+static int __init
+booke_wdt_init(void)
+{
+ int ret;
+ unsigned long flags;
+
+ ret = register_reboot_notifier(&booke_wdt_notifier);
+ if(ret) {
+ booke_wdt_err("Cannot register reboot notifier (err=%d)\n", ret);
+ return ret;
+ }
+
+ /* Register panic notifier */
+ ret =
notifier_chain_register(&panic_notifier_list,&booke_wdt_notifier);
+ if(ret) {
+ booke_wdt_err("Cannot register panic notifier (err=%d)\n", ret);
+ unregister_reboot_notifier(&booke_wdt_notifier);
+ return ret;
+ }
+
+ ret = 0;
+ booke_wdt_init_device();
+ /* Check that the heartbeat value is within it's range ; if not
reset to the default */
+ if (booke_wdt_set_timeout(wdt_period)) {
+ if (wdt_period)
+ booke_wdt_info("The heartbeat value must be %d < wdt_period <
%d, using %d\n",WDT_HEARTBEAT_MIN,WDT_HEARTBEAT_MAX,WDT_TIMO);
+ booke_wdt_set_timeout(WDT_TIMO);
+ }
+
+ local_irq_save(flags); /* Prevent timer interrupt */
+ ppc_md.heartbeat_count = 0;
+ ppc_md.heartbeat=booke_wdt_heartbeat;
+ local_irq_restore(flags);
+
+ booke_wdt_info("Book E(PPC 4xx/e500) Watchdog Driver. period=%d ms
(nowayout=%d)\n",wdt_period, nowayout);
+
+ ret = misc_register(&booke_wdt_miscdev);
+ if (ret) {
+ booke_wdt_err("Cannot register miscdev on minor=%d (err=%d)\n",
+ WATCHDOG_MINOR, ret);
+ goto outmisc;
+ }
+
+ if (wdt_enable) {
+ booke_wdt_info("WDT start on boot.\n");
+ booke_wdt_start();
+ }
+out:
+ return ret;
+outmisc:
+ unregister_reboot_notifier(&booke_wdt_notifier);
+ local_irq_save(flags);
+ ppc_md.heartbeat=NULL;
+ ppc_md.heartbeat_count = 0;
+ local_irq_restore(flags);
+ goto out;
+}
+
+device_initcall(booke_wdt_init);
diff -Nupr linux-2.6.orig/drivers/char/watchdog/booke_wdt.h
linux-2.6/drivers/char/watchdog/booke_wdt.h
--- linux-2.6.orig/drivers/char/watchdog/booke_wdt.h 1970-01-01
09:00:00.000000000 +0900
+++ linux-2.6/drivers/char/watchdog/booke_wdt.h 2005-05-07
05:17:03.000000000 +0900
@@ -0,0 +1,110 @@
+/*
+ *
+ * Copyright (c) 2004 Fujitsu Limited
+ *
+ * Module name: booke_wdt.h
+ * Author: Takeharu KATO<kato.takeharu@jp.fujitsu.com>
+ * Description:
+ * Header file for PowerPC Book E(PPC 4xx/e500) watchdog driver.
+ *
+ * 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.
+ *
+ * Neither Takeharu KATO nor Fujitsu Ltd. admit liability nor provide
+ * warranty for any of this software.
+ *
+ */
+#ifndef _DRIVERS_CHAR_WATCHDOG_BOOKE_WDT_H
+#define _DRIVERS_CHAR_WATCHDOG_BOOKE_WDT_H
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/ptrace.h>
+#include <linux/watchdog.h>
+#include <asm/reg_booke.h>
+
+/*
+ * Driver state flags(bit position)
+ */
+#define WDT_STATE_OPEN 0 /* driver is opend */
+#define WDT_STATE_STOP_ON_CLOSE 1 /* Stop with close is
expected */
+/*
+ * Configurations
+ */
+#define WDT_TIMO 60000 /* Default timeout = 60000 ms(1min) */
+#define WDT_HEARTBEAT_MIN 100 /* Minimum timeout = 100 ms */
+#define WDT_HEARTBEAT_MAX 600000 /* Maximum timeout = 600000ms(1hour) */
+#ifdef __KERNEL__
+//#define BOOKE_WDT_DEBUG /* Debug switch */
+
+/* Watchdog timer periods can be set on PPC 4xx cpus. */
+#if defined(CONFIG_4xx)
+/*
+ * For PowerPC 4xx
+ */
+#define WDT_WP0 0
+#define WDT_WP1 1
+#define WDT_WP2 2
+#define WDT_WP3 3
+#define wdt_calculate_tcr(period,reset) ( TCR_WP(period) | TCR_WRC(reset) )
+#else
+#if defined(CONFIG_E500)
+/*
+ * For e500 CPU
+ * Actually, e500 can arbitrary periods can be set,
+ * But this driver uses fix period value as same as PPC440
+ * on purpose for simplicity.
+ * Following values split into WP and WP_EXT parts in booke_wdt.c.
+ */
+#define WDT_WP0 21
+#define WDT_WP1 25
+#define WDT_WP2 29
+#define WDT_WP3 33
+#define WDT_TCR_WP_BITLEN 2 /* 2bit length */
+#define WDT_TCR_WP_BITMSK ((1<<(WDT_TCR_WP_BITLEN))-1) /* mask */
+#define WDT_TCR_WPEXT_BITMSK 0xf /* 4bit length */
+#define WDT_TCR_WPEXT_SHIFT 17
+#define WDT_WPEXT_VAL(period) (((period)>>WDT_TCR_WP_BITLEN)& \
+ (WDT_TCR_WPEXT_BITMSK))
+#define wdt_calculate_tcr(period,reset) \
+ ( TCR_WP((period)&(WDT_TCR_WP_BITMSK)) |\
+ TCR_WRC((reset)) |\
+ ( WDT_WPEXT_VAL(period) << WDT_TCR_WPEXT_SHIFT))
+#else
+#error "Book E WDT detects invalid configuration(Unknown CPU)"
+#endif /* CONFIG_E500 */
+#endif /* CONFIG_4xx */
+/*
+ * WP relevant values used in our driver.
+ * Note:WDT period must be more than HZ(Timer ticks)
+ */
+#define WDT_WP WDT_WP3
+
+/*
+ * IOCTL commands for comaptiblity for old driver
+ */
+#define WDIOC_GETPERIOD WDIOC_GETTIMEOUT
+#define WDIOC_SETPERIOD WDIOC_SETTIMEOUT
+
+/*
+ * output messages
+ */
+#define __BOOKE_WDT_MSG "BookE-WDT : "
+#define booke_mkmsg(str) __BOOKE_WDT_MSG str
+#define booke_wdt_info(fmt,arg...) \
+ printk(KERN_INFO __BOOKE_WDT_MSG fmt,##arg)
+#define booke_wdt_note(fmt,arg...) \
+ printk(KERN_NOTICE __BOOKE_WDT_MSG fmt,##arg)
+#define booke_wdt_err(fmt,arg...) \
+ printk(KERN_ALERT __BOOKE_WDT_MSG fmt,##arg)
+#if defined(BOOKE_WDT_DEBUG)
+#define booke_wdt_dbg(fmt,arg...) \
+ printk(KERN_ALERT __BOOKE_WDT_MSG fmt,##arg)
+#else
+#define booke_wdt_dbg(fmt,arg...) \
+ do{}while(0)
+#endif /* WDT_DEBUG */
+
+#endif /* __KERNEL__ */
+#endif /* _DRIVERS_CHAR_WATCHDOG_BOOKE_WDT_H */
^ permalink raw reply
* [PATCH] BOOKE_WDT Part 1/2 (Re: PPC 44x Watchdog timer)
From: Takeharu KATO @ 2005-05-06 21:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: Glenn Burkhardt, Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <905bacf60cf1e3167d4f42dba31c9d4f@freescale.com>
Hi Kumar:
>
> Sorry, I think Matt and I have been busy with normal "work". I'll take
> a look at this in the next week. If you can update the patches to
> something current that would help (but is not critical).
>
I updated the patch to current linus-git kernel(pulled in 2005/05/05
JST). Please use this for your testing.
This is architecture dependent part.
I'll re-test this patch in the next week.
Signed-off-by: kato.takeharu@jp.fujitsu.com
diff -Nupr linux-2.6.orig/arch/ppc/kernel/head_44x.S
linux-2.6/arch/ppc/kernel/head_44x.S
--- linux-2.6.orig/arch/ppc/kernel/head_44x.S 2005-05-06
05:03:55.000000000 +0900
+++ linux-2.6/arch/ppc/kernel/head_44x.S 2005-05-07 05:03:24.000000000 +0900
@@ -448,8 +448,11 @@ interrupt_base:
EXCEPTION(0x1010, FixedIntervalTimer, UnknownException, EXC_XFER_EE)
/* Watchdog Timer Interrupt */
- /* TODO: Add watchdog support */
+#if defined(CONFIG_BOOKE_WDT)
+ CRITICAL_EXCEPTION(0x1020, WatchdogTimer, booke_wdt_exception)
+#else
CRITICAL_EXCEPTION(0x1020, WatchdogTimer, UnknownException)
+#endif /* CONFIG_BOOKE_WDT */
/* Data TLB Error Interrupt */
START_EXCEPTION(DataTLBError)
diff -Nupr linux-2.6.orig/arch/ppc/kernel/head_4xx.S
linux-2.6/arch/ppc/kernel/head_4xx.S
--- linux-2.6.orig/arch/ppc/kernel/head_4xx.S 2005-05-06
05:03:55.000000000 +0900
+++ linux-2.6/arch/ppc/kernel/head_4xx.S 2005-05-07 05:03:24.000000000 +0900
@@ -430,27 +430,24 @@ label:
/* 0x1000 - Programmable Interval Timer (PIT) Exception */
START_EXCEPTION(0x1000, Decrementer)
- NORMAL_EXCEPTION_PROLOG
- lis r0,TSR_PIS@h
- mtspr SPRN_TSR,r0 /* Clear the PIT exception */
- addi r3,r1,STACK_FRAME_OVERHEAD
- EXC_XFER_LITE(0x1000, timer_interrupt)
+ b DecrementerHandler
#if 0
/* NOTE:
- * FIT and WDT handlers are not implemented yet.
+ * FIT handler is not implemented yet.
*/
/* 0x1010 - Fixed Interval Timer (FIT) Exception
*/
STND_EXCEPTION(0x1010, FITException, UnknownException)
-/* 0x1020 - Watchdog Timer (WDT) Exception
-*/
-
- CRITICAL_EXCEPTION(0x1020, WDTException, UnknownException)
#endif
+/* 0x1020 - Watchdog Timer (WDT) Exception
+ */
+ START_EXCEPTION(0x1020, WDTException)
+ b WatchDogHandler
+
/* 0x1100 - Data TLB Miss Exception
* As the name implies, translation is not in the MMU, so search the
* page tables and fix it. The only purpose of this function is to
@@ -732,6 +729,13 @@ label:
(MSR_KERNEL & ~(MSR_ME|MSR_DE|MSR_CE)), \
NOCOPY, crit_transfer_to_handler, ret_from_crit_exc)
+DecrementerHandler:
+ NORMAL_EXCEPTION_PROLOG
+ lis r0,TSR_PIS@h
+ mtspr SPRN_TSR,r0 /* Clear the PIT exception */
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ EXC_XFER_LITE(0x1000, timer_interrupt)
+
/*
* The other Data TLB exceptions bail out to this point
* if they can't resolve the lightweight TLB fault.
@@ -804,6 +808,19 @@ finish_tlb_load:
PPC405_ERR77_SYNC
rfi /* Should sync shadow TLBs */
b . /* prevent prefetch past rfi */
+/*
+ * WatchDog Exception
+ */
+WatchDogHandler:
+ CRITICAL_EXCEPTION_PROLOG;
+ addi r3,r1,STACK_FRAME_OVERHEAD;
+#if defined(CONFIG_BOOKE_WDT)
+ EXC_XFER_TEMPLATE(booke_wdt_exception, 0x1022, (MSR_KERNEL &
~(MSR_ME|MSR_DE|MSR_CE)),NOCOPY, crit_transfer_to_handler,
ret_from_crit_exc)
+
+#else
+ EXC_XFER_TEMPLATE(UnknownException, 0x1022, (MSR_KERNEL &
~(MSR_ME|MSR_DE|MSR_CE)),NOCOPY, crit_transfer_to_handler,
ret_from_crit_exc)
+#endif /* CONFIG_BOOKE_WDT */
+
/* extern void giveup_fpu(struct task_struct *prev)
*
diff -Nupr linux-2.6.orig/arch/ppc/kernel/head_fsl_booke.S
linux-2.6/arch/ppc/kernel/head_fsl_booke.S
--- linux-2.6.orig/arch/ppc/kernel/head_fsl_booke.S 2005-05-06
05:03:55.000000000 +0900
+++ linux-2.6/arch/ppc/kernel/head_fsl_booke.S 2005-05-07
05:05:06.000000000 +0900
@@ -526,8 +526,11 @@ interrupt_base:
EXCEPTION(0x3100, FixedIntervalTimer, UnknownException, EXC_XFER_EE)
/* Watchdog Timer Interrupt */
- /* TODO: Add watchdog support */
- CRITICAL_EXCEPTION(0x3200, WatchdogTimer, UnknownException)
+#if defined(CONFIG_BOOKE_WDT)
+ CRITICAL_EXCEPTION(0x3200, WatchdogTimer, booke_wdt_exception)
+#else
+ CRITICAL_EXCEPTION(0x3200, WatchdogTimer, UnknownException)
+#endif /* CONFIG_BOOKE_WDT */
/* Data TLB Error Interrupt */
START_EXCEPTION(DataTLBError)
diff -Nupr linux-2.6.orig/arch/ppc/platforms/85xx/mpc8540_ads.c
linux-2.6/arch/ppc/platforms/85xx/mpc8540_ads.c
--- linux-2.6.orig/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-05-06
05:03:57.000000000 +0900
+++ linux-2.6/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-05-07
05:08:39.000000000 +0900
@@ -187,6 +187,14 @@ platform_init(unsigned long r3, unsigned
strcpy(cmd_line, (char *) (r6 + KERNELBASE));
}
+#ifdef CONFIG_BOOKE_WDT
+ {
+ extern void booke_wdt_setup_options(char *cmd_line);
+
+ booke_wdt_setup_options(cmd_line);
+ }
+#endif /* CONFIG_BOOKE_WDT */
+
identify_ppc_sys_by_id(mfspr(SPRN_SVR));
/* setup the PowerPC module struct */
diff -Nupr linux-2.6.orig/arch/ppc/platforms/85xx/mpc8560_ads.c
linux-2.6/arch/ppc/platforms/85xx/mpc8560_ads.c
--- linux-2.6.orig/arch/ppc/platforms/85xx/mpc8560_ads.c 2005-05-06
05:03:57.000000000 +0900
+++ linux-2.6/arch/ppc/platforms/85xx/mpc8560_ads.c 2005-05-07
05:09:12.000000000 +0900
@@ -183,6 +183,14 @@ platform_init(unsigned long r3, unsigned
strcpy(cmd_line, (char *) (r6 + KERNELBASE));
}
+#ifdef CONFIG_BOOKE_WDT
+ {
+ extern void booke_wdt_setup_options(char *cmd_line);
+
+ booke_wdt_setup_options(cmd_line);
+ }
+#endif /* CONFIG_BOOKE_WDT */
+
identify_ppc_sys_by_id(mfspr(SPRN_SVR));
/* setup the PowerPC module struct */
diff -Nupr linux-2.6.orig/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
linux-2.6/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- linux-2.6.orig/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
2005-05-06 05:03:57.000000000 +0900
+++ linux-2.6/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-05-07
05:07:59.000000000 +0900
@@ -432,6 +432,14 @@ platform_init(unsigned long r3, unsigned
strcpy(cmd_line, (char *) (r6 + KERNELBASE));
}
+#ifdef CONFIG_BOOKE_WDT
+ {
+ extern void booke_wdt_setup_options(char *cmd_line);
+
+ booke_wdt_setup_options(cmd_line);
+ }
+#endif /* CONFIG_BOOKE_WDT */
+
identify_ppc_sys_by_id(mfspr(SPRN_SVR));
/* setup the PowerPC module struct */
diff -Nupr linux-2.6.orig/arch/ppc/platforms/85xx/sbc8560.c
linux-2.6/arch/ppc/platforms/85xx/sbc8560.c
--- linux-2.6.orig/arch/ppc/platforms/85xx/sbc8560.c 2005-05-06
05:03:57.000000000 +0900
+++ linux-2.6/arch/ppc/platforms/85xx/sbc8560.c 2005-05-07
05:06:59.000000000 +0900
@@ -198,6 +198,14 @@ platform_init(unsigned long r3, unsigned
strcpy(cmd_line, (char *) (r6 + KERNELBASE));
}
+#ifdef CONFIG_BOOKE_WDT
+ {
+ extern void booke_wdt_setup_options(char *cmd_line);
+
+ booke_wdt_setup_options(cmd_line);
+ }
+#endif /* CONFIG_BOOKE_WDT */
+
identify_ppc_sys_by_id(mfspr(SPRN_SVR));
/* setup the PowerPC module struct */
diff -Nupr linux-2.6.orig/arch/ppc/platforms/85xx/stx_gp3.c
linux-2.6/arch/ppc/platforms/85xx/stx_gp3.c
--- linux-2.6.orig/arch/ppc/platforms/85xx/stx_gp3.c 2005-05-06
05:03:57.000000000 +0900
+++ linux-2.6/arch/ppc/platforms/85xx/stx_gp3.c 2005-05-07
05:10:12.000000000 +0900
@@ -331,6 +331,14 @@ platform_init(unsigned long r3, unsigned
strcpy(cmd_line, (char *) (r6 + KERNELBASE));
}
+#ifdef CONFIG_BOOKE_WDT
+ {
+ extern void booke_wdt_setup_options(char *cmd_line);
+
+ booke_wdt_setup_options(cmd_line);
+ }
+#endif /* CONFIG_BOOKE_WDT */
+
identify_ppc_sys_by_id(mfspr(SPRN_SVR));
/* setup the PowerPC module struct */
diff -Nupr linux-2.6.orig/arch/ppc/syslib/ppc4xx_setup.c
linux-2.6/arch/ppc/syslib/ppc4xx_setup.c
--- linux-2.6.orig/arch/ppc/syslib/ppc4xx_setup.c 2005-05-06
05:03:58.000000000 +0900
+++ linux-2.6/arch/ppc/syslib/ppc4xx_setup.c 2005-05-07
05:03:25.000000000 +0900
@@ -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,14 @@ 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
+
+#ifdef CONFIG_BOOKE_WDT
+ {
+ extern void booke_wdt_setup_options(char *cmd_line);
+
+ booke_wdt_setup_options(cmd_line);
+ }
+#endif /* CONFIG_BOOKE_WDT */
/* Initialize machine-dependent vectors */
^ permalink raw reply
* How to fix 8xx dcbst bug?
From: Marcelo Tosatti @ 2005-05-06 15:45 UTC (permalink / raw)
To: Dan Malek, linux-ppc-embedded; +Cc: Joakim Tjernlund
Hi Dan,
So, restarting this conversation...
On Tue, Apr 05, 2005 at 11:58:17AM -0400, Dan Malek wrote:
>
> On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
>
> >Problem is that the "dcbst" instruction will, _sometimes_ (the
> >failure/success rate is about 1/4
> >with my test application) fault as a _write_ operation on the data.
>
> Oh, geeze .... It's all coming back to me now ....
>
> The 8xx cache operations don't always operate as defined in the PEM.
> There are likely to be some archive discussions within the Freescale
> knowledge data base that describe the different behaviors I've seen
> with the chip variants and revisions. I can't find any of those e-mail
> discussions, so I'll try to recall from memory.
>
> The PEM cache instructions are all implemented in a microcode that
> uses the 8xx unique cache control SPRs. Depending upon the state
> of the cache and MMU, it seems in some cases the EA translation is
> subject to a "normal" protection match instead of a load operation
> match.
>
> The behavior of these operations isn't consistent across all of the 8xx
> processor revisions, especially with early silicon if people are still
> using those. During conversations with Freescale engineers, it seems
> the only guaranteed operation was to use the 8xx unique SPRs, but
> I think I only did that in 8xx specific functions.
>
> We have way too much code in the TLB exception handlers already,
> so let's just try a tlbia of the EA in the update_mmu_cache, with an
> #ifdef
> for the 8xx.
> We may want to make the dcbxxx instructions
> some
> kind of macro, so on 8xx we can include such operations in otherwise
> "standard" software.
Now that I think of it, userspace dcbst users should not be an issue
because the intermediate invalid TLB entry is not visible to applications.
Userspace sees only: not present pte, or valid present pte.
Well, at least the entry which has been causing problems,
created by DataStoreTLBMiss.
Is it safe to assume that dcbst usage on userspace is restricted
to valid TLBs? Since MMU SPRs are restricted to supervisor
protection, I think so.
So, if that is true, can you please merge the update_mmu_cache() fix
for the dcbst misbehaviour previously discussed ?
Thanks!!
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2] Updated platform additions for 82xx
From: Eugene Surovegin @ 2005-05-06 18:43 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <427B3465.1070502@ru.mvista.com>
On Fri, May 06, 2005 at 01:09:57PM +0400, Vitaly Bordug wrote:
>
> PHY_INTERRUPT is defined in the board-specific platforms/pq2ads.h
> (likewise approach was used in 2.4). Others from this define crowd
> should reside as they are IMHO, until we have some common board-specific
> header for 82xx (or all these will be scattered along different 82xx
> platform defines such as tqm8260.h etc. which is even worse). What do
> you think?
The best way I think is to NOT use defines like PHY_INTERRUPT at all.
This is what I mean in my previous e-mail when I said I didn't quite
like approach your chosen but thought it was OK for now.
I think that platform files should initialize only stuff which is
common for all boards using this platform.
Board specific stuff should be _filled_ in board .c file. Basically we
have two different ways to do board specific stuff (I think feature
call stuff which Dan is proposing is orthogonal to these):
1) Add some defines with generic name like PHY_INTERRUPT_FCC1, allow
board specific _header_ file to define them and use some default if
it wasn't overridden by the board port. This is I believe approach you
have chosen.
2) _Fill_ corresponding platform_device fields in the board C file.
This is what I think is better.
Approach 1) is less intrusive because it's similar to what we were
doing so far.
Approach 2) is more flexible (e.g. I wasn't to use the same kernel
image for all boards from some family, and they may use different IRQ
routing). Also, 2) avoids "header file hell", when board info scattered
around different headers and sometime it's not that obvious where
particular define comes from.
--
Eugene
^ permalink raw reply
* 2.4.18: CPM1 stops when initializing ATM/UTOPIA.
From: Theo Gjaltema @ 2005-05-06 18:41 UTC (permalink / raw)
To: Linuxppc-embedded
Hi,
Last week I was trying to integrate the atm/utopia driver (sourceforce)
into a 2.4.18 kernel build for a 862, but mij attemtps failed. It
appeared that wen on the first location of the SCC4 (now used for
utopia) a buffer address is written, most CPM activities are halted,
including the SCM1 which I used as console port. The console driver did
write in the allocated buffer descriptors, but the tranmission of the
data was never acknowledged, thus hanging the kernel.
Anyone an idea what happened?
Theo.
^ permalink raw reply
* [PATCH] ppc32: Fix POWER3/POWER4 compiler error
From: Kumar Gala @ 2005-05-06 18:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
In separating out support for hardware floating point we missed the fact that
both POWER3 and POWER4 have HW FP. Enable CONFIG_PPC_FPU for POWER3
and POWER4 fixes the issue.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit c196b5792abdb89f18ee55fb5a84afe89b0fc92d
tree 82bf0144d326efbdfe33c81eb1a7e23bb9dc081b
parent 6741f3a7f9922391cd02b3ca1329e669497dc22f
author Kumar K. Gala <kumar.gala@freescale.com> 1115399859 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> 1115399859 -0500
Index: arch/ppc/Kconfig
===================================================================
--- cda5ab7ce1bc4b36cb164e6daee18c7649348fb4/arch/ppc/Kconfig (mode:100644 sha1:d0d94e56b90b9ec8ab65c4780c4b0804663482af)
+++ 82bf0144d326efbdfe33c81eb1a7e23bb9dc081b/arch/ppc/Kconfig (mode:100644 sha1:600f23d7fd33aae9e5115875ada43a289e075b5d)
@@ -77,9 +77,11 @@
bool "44x"
config POWER3
+ select PPC_FPU
bool "POWER3"
config POWER4
+ select PPC_FPU
bool "POWER4 and 970 (G5)"
config 8xx
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2] Updated platform additions for 82xx
From: Eugene Surovegin @ 2005-05-06 18:16 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded list
In-Reply-To: <1ee36950a2147d4208cf9af575be7478@embeddededge.com>
On Fri, May 06, 2005 at 01:45:58PM -0400, Dan Malek wrote:
>
> On May 6, 2005, at 1:32 PM, Eugene Surovegin wrote:
>
> >Yeah, I think 3 parameters approach is OK. IOCTL handlers are made
> >like this and so far they proved to be quite flexible.
>
> I thought we also discussed placing the PHY irq numbers in the
> platform data structure at one time? :-)
This is exactly what Vitaly is doing in his patches. My comment was
about general use of 3 parameters "feature" calls vs variadic ones,
not about you particular example for PHY IRQ :).
--
Eugene
^ permalink raw reply
* Re: [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
From: Marcelo Tosatti @ 2005-05-06 13:38 UTC (permalink / raw)
To: Dan Malek; +Cc: linux-ppc-embedded
In-Reply-To: <1b2c7da800815bcdd76ddf27a2ab9c55@embeddededge.com>
> >The following patch changes "mmu_mapin_ram" (hook used by mapin_ram),
> >to
> >begin creation of pagetables after the first 8Megs, preserving the
> >8Mbyte TLB entry.
>
> Please don't do this. It isn't necessary.
Why it is not necessary?
Have you read the section of the manual which I pasted here?
> >This changes the assumption that DMA allocations can start at the first
> >kernel address, given that those need to be marked uncached due to DMA
> >cache coherency issues.
>
> VM space for uncached DMA has always been allocated using vmalloc(),
> the location of the physical pages backing this space is irrelevant.
>
> The only thing you have to ensure is the virtual address is outside
> of the pinned entry.
What you replied to is:
"This changes the assumption that DMA allocations can start at the first
kernel address, given that those need to be marked uncached due to DMA
cache coherency issues."
I think we mean the same, yes?
> If something about the way the VM space is structured in 2.6 is
> different, we need to fix that in general.
>
> >Panto: FEC currently does
> >
> > mem_addr = __get_free_page(GFP_KERNEL);
> > cbd_base = (cbd_t *)mem_addr;
>
> This is just plain broken and it shouldn't do this.
>
> >We are still using v2.4 FEC driver, so this fixed it:
> >
> >// mem_addr = __get_free_page(GFP_KERNEL);
> > mem_addr = dma_alloc_coherent(NULL, PAGE_SIZE, &physaddr,
> > GFP_KERNEL);
>
> This is the proper way, and should be moved to the equivalent in 2.6.
>
> >Allocateing from the coherent memory DMA region. Which sits at, I
> >suppose,
> >after initial 8Megs in all configurations (should be always).
>
> You are making this too complicated :-) All we have to do is use the
> proper dma allocators and make sure the TLBs are pinned properly.
> That is all.
Sorry, but, what is too complicated?
The patch I sent does two things (pretty much the same thing you suggest
after stating that its "too complicated", AFAICS):
1) avoids the creation of pte tables in the 8Mbyte range, thus preserving
the pinned TLB entry.
2) restricts bootmem to above 8Mbyte region
And last thing is:
3) Memory for DMA pages must not be in the pinned region. ie. drivers
should not allocate memory directly for DMA purposes.
Dan, I would really enjoy having access to some of your precious 8xx
knowledge: share it, along with the correct way to fix this and the
other pending issues.
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2] Updated platform additions for 82xx
From: Dan Malek @ 2005-05-06 17:45 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded list
In-Reply-To: <20050506173246.GD19401@gate.ebshome.net>
On May 6, 2005, at 1:32 PM, Eugene Surovegin wrote:
> Yeah, I think 3 parameters approach is OK. IOCTL handlers are made
> like this and so far they proved to be quite flexible.
I thought we also discussed placing the PHY irq numbers in the
platform data structure at one time? :-) Of course, we still need
the feature_call to do any routing of the signal that may be required.
Thanks.
-- Dan
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2] Updated platform additions for 82xx
From: Eugene Surovegin @ 2005-05-06 17:32 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded list
In-Reply-To: <7ad6626ea88c1e1ec98d310f4db438f7@embeddededge.com>
On Fri, May 06, 2005 at 01:23:21PM -0400, Dan Malek wrote:
>
> On May 6, 2005, at 1:08 PM, Eugene Surovegin wrote:
>
> >Yeah, it's better, I'm only wondering what if some board has separate
> >PHY interrupt lines for each FCC? Define name - "PHY_INTERRUPT" was
> >chosen quite badly IMHO :).
>
> One of my feature_calls is:
> embed_feature_call(CPM_FTR_FCC1, REQ_FTR_PHY_INT, &irq)
>
> and so on for every Ethernet port. This presents my current coding
> challenge, do I want this to be a varargs function or we just always
> have
> three parameters, where the last one is ignored if not necessary, a
> pointer for an out value, or a pointer to a data structure for more
> complex information. Right now I have it coded as always three
> parameters.
Yeah, I think 3 parameters approach is OK. IOCTL handlers are made
like this and so far they proved to be quite flexible.
--
Eugene
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2] Updated platform additions for 82xx
From: Dan Malek @ 2005-05-06 17:23 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded list
In-Reply-To: <20050506170809.GC19401@gate.ebshome.net>
On May 6, 2005, at 1:08 PM, Eugene Surovegin wrote:
> Yeah, it's better, I'm only wondering what if some board has separate
> PHY interrupt lines for each FCC? Define name - "PHY_INTERRUPT" was
> chosen quite badly IMHO :).
One of my feature_calls is:
embed_feature_call(CPM_FTR_FCC1, REQ_FTR_PHY_INT, &irq)
and so on for every Ethernet port. This presents my current coding
challenge, do I want this to be a varargs function or we just always
have
three parameters, where the last one is ignored if not necessary, a
pointer for an out value, or a pointer to a data structure for more
complex information. Right now I have it coded as always three
parameters.
In addition, this feature call will set up whatever interrupt routing
is necessary. The driver only needs to check if a value is returned,
if not, no interrupt. It also may want to test if the returned irq is
the
same for all PHYS, since it may be needed in the interrupt handler.
Thanks.
-- Dan
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2] Updated platform additions for 82xx
From: Eugene Surovegin @ 2005-05-06 17:08 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <427B3465.1070502@ru.mvista.com>
On Fri, May 06, 2005 at 01:09:57PM +0400, Vitaly Bordug wrote:
> PHY_INTERRUPT is defined in the board-specific platforms/pq2ads.h
> (likewise approach was used in 2.4). Others from this define crowd
> should reside as they are IMHO, until we have some common board-specific
> header for 82xx (or all these will be scattered along different 82xx
> platform defines such as tqm8260.h etc. which is even worse). What do
> you think?
Yeah, it's better, I'm only wondering what if some board has separate
PHY interrupt lines for each FCC? Define name - "PHY_INTERRUPT" was
chosen quite badly IMHO :).
--
Eugene
^ permalink raw reply
* Re: [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
From: Dan Malek @ 2005-05-06 16:43 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050505172035.GB3339@logos.cnet>
On May 5, 2005, at 1:20 PM, Marcelo Tosatti wrote:
> As can be seen by BDI output from previous messages, the 8Mbyte TLB
> pinned entry is not being actually used.
We know it's not, we know it's broken, I'm working on it :-)
> The following patch changes "mmu_mapin_ram" (hook used by mapin_ram),
> to
> begin creation of pagetables after the first 8Megs, preserving the
> 8Mbyte TLB entry.
Please don't do this. It isn't necessary.
> This changes the assumption that DMA allocations can start at the first
> kernel address, given that those need to be marked uncached due to DMA
> cache coherency issues.
VM space for uncached DMA has always been allocated using vmalloc(),
the location of the physical pages backing this space is irrelevant.
The only
thing you have to ensure is the virtual address is outside of the pinned
entry. If something about the way the VM space is structured in 2.6 is
different, we need to fix that in general.
> Panto: FEC currently does
>
> mem_addr = __get_free_page(GFP_KERNEL);
> cbd_base = (cbd_t *)mem_addr;
This is just plain broken and it shouldn't do this.
> We are still using v2.4 FEC driver, so this fixed it:
>
> // mem_addr = __get_free_page(GFP_KERNEL);
> mem_addr = dma_alloc_coherent(NULL, PAGE_SIZE, &physaddr,
> GFP_KERNEL);
This is the proper way, and should be moved to the equivalent in 2.6.
> Allocateing from the coherent memory DMA region. Which sits at, I
> suppose,
> after initial 8Megs in all configurations (should be always).
You are making this too complicated :-) All we have to do is use the
proper dma allocators and make sure the TLBs are pinned properly.
That is all.
Thanks.
-- Dan
^ permalink raw reply
* Please activate your account
From: eBay @ 2005-05-06 14:52 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 17794 bytes --]
^ permalink raw reply
* Re: [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
From: Marcelo Tosatti @ 2005-05-06 11:39 UTC (permalink / raw)
To: Jason McMullan; +Cc: linux-ppc-embedded
In-Reply-To: <1115384665.9050.22.camel@jmcmullan.timesys>
On Fri, May 06, 2005 at 09:04:24AM -0400, Jason McMullan wrote:
> On Thu, 2005-05-05 at 14:20 -0300, Marcelo Tosatti wrote:
> > [snip snip]
> >
> > Allocateing from the coherent memory DMA region. Which sits at, I suppose,
> > after initial 8Megs in all configurations (should be always).
> >
>
>
> What if your board (ie the MPC885ADS) only has 8Mb? Soldered on.
Jason,
Oops, in that case you can't pin the 8Mbyte entry.
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Kumar Gala @ 2005-05-06 15:47 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050506145313.GE1221@smtp.west.cox.net>
On May 6, 2005, at 9:53 AM, Tom Rini wrote:
> On Fri, May 06, 2005 at 04:44:33PM +0200, Segher Boessenkool wrote:
> > >Well, say you are compiling for 405.=A0 You either need to have a =
gcc
> > >that was configured with --with-cpu=3D405, or you need to have =
hacked
> > >arch/ppc/Makefile to add -mcpu=3D405.=A0 In both cases the problem=20=
> doesn't
> > >arise.=A0 It only arises if you have a biarch gcc4 that was=20
> configured
> > >without any --with-cpu=3Dxxx option and is run without any =
-mcpu=3Dxxx
> > >option.
> >
> > It happens for any installation where the default chosen by the GCC
> > used is not the -mcpu=3DXXX flag you need used for your kernel.=A0 =
Which
> > is a much more general statement than the biarch one.=A0 Most =
people=20
> just
> > get lucky, because they compile code with a compiler that is=20
> defaulted
> > for their target, and userland and kernel use (about) the same=20
> options
> > on most targets.=A0 Not so in biarch land (bleeech).
>
> Note that up until very recently (and just a bit before conflicting
> opcodes were added), no -mcpu=3DXXX was required.=A0 For example, I=20=
> compiled
> a 44x kernel with a -mcpu=3D750 toolchain no problems shortly after =
Paul
> posted this.=A0 The only exception to this rule I can possibly think =
of=20
> is
> 85xx.=A0 But even that would be the "very recently" thing I mentioned =
as
> I know you can use an 82xx-set toolchain to build for 85xx.
>
> Having said that..
I do the same thing as well and the only issue I have is that 85xx=20
doesn't support strings thus the conditional we currently have for=20
-mstring.
- kumar=
^ 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