* Re: 440EP FPU support missing
From: Matt Porter @ 2005-11-08 23:02 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese, linuxppc64-dev
In-Reply-To: <1131489174.26096.0.camel@yoda.jdub.homelinux.org>
On Tue, Nov 08, 2005 at 04:32:54PM -0600, Josh Boyer wrote:
> On Tue, 2005-11-08 at 15:30 -0700, Matt Porter wrote:
> > On Tue, Nov 08, 2005 at 06:38:11PM +0100, Stefan Roese wrote:
> > > In the current linux version, Bamboo (440EP) won't compile anymore, because of
> > > missing fpu support:
> > >
> > > make uImage
> > > ...
> > > LD init/built-in.o
> > > LD .tmp_vmlinux1
> > > arch/ppc/kernel/head_44x.o(.text+0x868): In function `_start':
> > > : undefined reference to `KernelFP'
> > > make: *** [.tmp_vmlinux1] Error 1
> > >
> > > Somehow arch/ppc/kernel/fpu.S has disappeared. :-( I assume, this happened in
> > > the ppc/ppc64 -> powerpc merge. Any thoughts, why this file disappeared and
> > > how to solve this problem (just restore the original file)?
> >
> > arch/powerpc/kernel/fpu.S is being used now which doesn't have KernelFP.
> > I don't know why the 44x fpu support wasn't using
> > kernel_fp_unavailable_exception() before but I must have missed that
> > reviewing it.
> >
> > Try this patch.
>
> Doesn't this render the 440EP's FPU useless?
Does what render the 440EP's FPU useless? The supplied patch? I
don't think so, the path should be the same as classic PPC.
The patch simply replaces the KernelFP routine that used to be in
arch/ppc/kernel/fpu.S (and was removed inadvertently in the arch/powerpc/
merge) with a kernel_fp_unavailable_exception() call which does the
equivalent and is shared by others.
The exception still loads up the fpu is coming from userspace and
only goes down this path when getting an FP unavailable exception from
kernel space.
-Matt
^ permalink raw reply
* Re: [PATCH 2.6.14] ppc32: Fix CONFIG_PRINTK=n building
From: Matt Mackall @ 2005-11-08 22:39 UTC (permalink / raw)
To: Tom Rini; +Cc: Andrew Morton, Kumar Gala, linuxppc-dev
In-Reply-To: <20051108223631.GR3839@smtp.west.cox.net>
On Tue, Nov 08, 2005 at 03:36:31PM -0700, Tom Rini wrote:
> The following patch is needed to allow PRINTK=n to work on ppc32.
>
> Direct calls to printk from asm files can't be magically removed so we
> have to do it manually.
>
> Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Looks good.
Acked-by: Matt Mackall <mpm@selenic.com>
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH 2.6.14] ppc32: Fix CONFIG_PRINTK=n building
From: Matt Porter @ 2005-11-08 22:48 UTC (permalink / raw)
To: Tom Rini; +Cc: Andrew Morton, Kumar Gala, Matt Mackall, linuxppc-dev
In-Reply-To: <20051108223631.GR3839@smtp.west.cox.net>
On Tue, Nov 08, 2005 at 03:36:31PM -0700, Tom Rini wrote:
> The following patch is needed to allow PRINTK=n to work on ppc32.
>
> Direct calls to printk from asm files can't be magically removed so we
> have to do it manually.
>
> Signed-off-by: Tom Rini <trini@kernel.crashing.org>
>
> Index: linux-2.6.14/arch/ppc/kernel/fpu.S
> ===================================================================
> --- linux-2.6.14.orig/arch/ppc/kernel/fpu.S
This file doesn't exist in mainline. 2.6.14 is too old as a reference
for ppc patches due to the arch/powerpc/ merge.
-Matt
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Wolfgang Denk @ 2005-11-08 22:46 UTC (permalink / raw)
To: Tom Rini; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <20051108210204.GP3839@smtp.west.cox.net>
In message <20051108210204.GP3839@smtp.west.cox.net> you wrote:
>
> > Please do not remove stuff that is needed and used to work (in 2.4).
>
> Note the bug in question exists in 2.4, and I think really even 2.2.
Hm... as far as I can remember (and see in the change logs) the only
fix we implemented for our 2.4.25 tree to get swapping on a MPC8xx
working was a set of bad offsets in include/asm-ppc/pgtable.h - see
http://www.denx.de/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=commit;h=e6d7a1c83f9fd5820cdb85389d6a8f2207f3641d
With this change swapping works fine for us - some of our customers
have been using this code in production for over two years now.
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
Good morning. This is the telephone company. Due to repairs, we're
giving you advance notice that your service will be cut off indefi-
nitely at ten o'clock. That's two minutes from now.
^ permalink raw reply
* Re: 440EP FPU support missing
From: Matt Porter @ 2005-11-08 22:46 UTC (permalink / raw)
To: Stefan Roese, linuxppc-dev, linuxppc64-dev
In-Reply-To: <20051108223202.GA25185@localhost.localdomain>
On Wed, Nov 09, 2005 at 09:32:02AM +1100, David Gibson wrote:
> On Tue, Nov 08, 2005 at 06:38:11PM +0100, Stefan Roese wrote:
> > In the current linux version, Bamboo (440EP) won't compile anymore, because of
> > missing fpu support:
> >
> > make uImage
> > ...
> > LD init/built-in.o
> > LD .tmp_vmlinux1
> > arch/ppc/kernel/head_44x.o(.text+0x868): In function `_start':
> > : undefined reference to `KernelFP'
> > make: *** [.tmp_vmlinux1] Error 1
> >
> > Somehow arch/ppc/kernel/fpu.S has disappeared. :-( I assume, this happened in
> > the ppc/ppc64 -> powerpc merge. Any thoughts, why this file disappeared and
> > how to solve this problem (just restore the original file)?
>
> It's just moved to arch/powerpc/kernel/fpu.S. All you should need is
> to tweak the Makefiles so that it's included in your build.
Actually, the version in arch/powerpc/kernel/ is older than the version
removed from arch/ppc/kernel/. It is already being built...see my other
post.
-Matt
^ permalink raw reply
* [PATCH 2.6.14] ppc32: Fix CONFIG_PRINTK=n building
From: Tom Rini @ 2005-11-08 22:36 UTC (permalink / raw)
To: Andrew Morton, Paul Mackerras, Kumar Gala; +Cc: linuxppc-dev, Matt Mackall
The following patch is needed to allow PRINTK=n to work on ppc32.
Direct calls to printk from asm files can't be magically removed so we
have to do it manually.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Index: linux-2.6.14/arch/ppc/kernel/fpu.S
===================================================================
--- linux-2.6.14.orig/arch/ppc/kernel/fpu.S
+++ linux-2.6.14/arch/ppc/kernel/fpu.S
@@ -91,7 +91,9 @@ KernelFP:
ori r3,r3,86f@l
mr r4,r2 /* current */
lwz r5,_NIP(r1)
+#ifdef CONFIG_PRINTK
bl printk
+#endif
b ret_from_except
86: .string "floating point used in kernel (task=%p, pc=%x)\n"
.align 4,0
Index: linux-2.6.14/arch/ppc/kernel/head.S
===================================================================
--- linux-2.6.14.orig/arch/ppc/kernel/head.S
+++ linux-2.6.14/arch/ppc/kernel/head.S
@@ -846,7 +846,9 @@ KernelAltiVec:
ori r3,r3,87f@l
mr r4,r2 /* current */
lwz r5,_NIP(r1)
+#ifdef CONFIG_PRINTK
bl printk
+#endif
b ret_from_except
87: .string "AltiVec used in kernel (task=%p, pc=%x) \n"
.align 4,0
Index: linux-2.6.14/arch/ppc/kernel/head_fsl_booke.S
===================================================================
--- linux-2.6.14.orig/arch/ppc/kernel/head_fsl_booke.S
+++ linux-2.6.14/arch/ppc/kernel/head_fsl_booke.S
@@ -906,7 +906,9 @@ KernelSPE:
ori r3,r3,87f@l
mr r4,r2 /* current */
lwz r5,_NIP(r1)
+#ifdef CONFIG_PRINTK
bl printk
+#endif
b ret_from_except
87: .string "SPE used in kernel (task=%p, pc=%x) \n"
.align 4,0
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: 440EP FPU support missing
From: Josh Boyer @ 2005-11-08 22:32 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev, Stefan Roese, linuxppc64-dev
In-Reply-To: <20051108153036.F27232@cox.net>
On Tue, 2005-11-08 at 15:30 -0700, Matt Porter wrote:
> On Tue, Nov 08, 2005 at 06:38:11PM +0100, Stefan Roese wrote:
> > In the current linux version, Bamboo (440EP) won't compile anymore, because of
> > missing fpu support:
> >
> > make uImage
> > ...
> > LD init/built-in.o
> > LD .tmp_vmlinux1
> > arch/ppc/kernel/head_44x.o(.text+0x868): In function `_start':
> > : undefined reference to `KernelFP'
> > make: *** [.tmp_vmlinux1] Error 1
> >
> > Somehow arch/ppc/kernel/fpu.S has disappeared. :-( I assume, this happened in
> > the ppc/ppc64 -> powerpc merge. Any thoughts, why this file disappeared and
> > how to solve this problem (just restore the original file)?
>
> arch/powerpc/kernel/fpu.S is being used now which doesn't have KernelFP.
> I don't know why the 44x fpu support wasn't using
> kernel_fp_unavailable_exception() before but I must have missed that
> reviewing it.
>
> Try this patch.
Doesn't this render the 440EP's FPU useless?
josh
^ permalink raw reply
* Re: 440EP FPU support missing
From: David Gibson @ 2005-11-08 22:32 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <200511081838.11236.sr@denx.de>
On Tue, Nov 08, 2005 at 06:38:11PM +0100, Stefan Roese wrote:
> In the current linux version, Bamboo (440EP) won't compile anymore, because of
> missing fpu support:
>
> make uImage
> ...
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/ppc/kernel/head_44x.o(.text+0x868): In function `_start':
> : undefined reference to `KernelFP'
> make: *** [.tmp_vmlinux1] Error 1
>
> Somehow arch/ppc/kernel/fpu.S has disappeared. :-( I assume, this happened in
> the ppc/ppc64 -> powerpc merge. Any thoughts, why this file disappeared and
> how to solve this problem (just restore the original file)?
It's just moved to arch/powerpc/kernel/fpu.S. All you should need is
to tweak the Makefiles so that it's included in your build.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: 440EP FPU support missing
From: Matt Porter @ 2005-11-08 22:30 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <200511081838.11236.sr@denx.de>
On Tue, Nov 08, 2005 at 06:38:11PM +0100, Stefan Roese wrote:
> In the current linux version, Bamboo (440EP) won't compile anymore, because of
> missing fpu support:
>
> make uImage
> ...
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/ppc/kernel/head_44x.o(.text+0x868): In function `_start':
> : undefined reference to `KernelFP'
> make: *** [.tmp_vmlinux1] Error 1
>
> Somehow arch/ppc/kernel/fpu.S has disappeared. :-( I assume, this happened in
> the ppc/ppc64 -> powerpc merge. Any thoughts, why this file disappeared and
> how to solve this problem (just restore the original file)?
arch/powerpc/kernel/fpu.S is being used now which doesn't have KernelFP.
I don't know why the 44x fpu support wasn't using
kernel_fp_unavailable_exception() before but I must have missed that
reviewing it.
Try this patch.
-Matt
diff --git a/arch/ppc/kernel/head_booke.h b/arch/ppc/kernel/head_booke.h
index aeb349b..f3d274c 100644
--- a/arch/ppc/kernel/head_booke.h
+++ b/arch/ppc/kernel/head_booke.h
@@ -358,6 +358,6 @@ label:
NORMAL_EXCEPTION_PROLOG; \
bne load_up_fpu; /* if from user, just load it up */ \
addi r3,r1,STACK_FRAME_OVERHEAD; \
- EXC_XFER_EE_LITE(0x800, KernelFP)
+ EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception)
#endif /* __HEAD_BOOKE_H__ */
^ permalink raw reply related
* Re: fix swapping on 8xx?
From: Dan Malek @ 2005-11-08 22:30 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Tom Rini, David Jander, linuxppc-embedded
In-Reply-To: <20051108205259.A2870352B33@atlas.denx.de>
On Nov 8, 2005, at 3:52 PM, Wolfgang Denk wrote:
> Please do not remove stuff that is needed and used to work (in 2.4).
I'm not proposing we remove anything :-) It would just be nice
to eliminate the overhead of managing the PTEs if we don't
need such a feature. The complexity of the TLB miss handler
just keeps growing to add/fix this stuff, and it really shouldn't
be in that code path. All of this support should be pushed
into the error path, and if it was somewhat configurable we
wouldn't be in that path if not necessary.
Thanks.
-- Dan
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Tom Rini @ 2005-11-08 21:02 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <20051108205259.A2870352B33@atlas.denx.de>
On Tue, Nov 08, 2005 at 09:52:59PM +0100, Wolfgang Denk wrote:
> In message <20051108175658.GO3839@smtp.west.cox.net> you wrote:
> >
> > > Well, at least it sounds ugly together, but it is also at least conceiveable.
> > > There seem to be people who use PCMCIA for an IDE interface, so swapping may
> > > become desireable in some cases.
> >
> > I think Dan might be in the camp that says a properly designed embedded
> > system won't need to swap. And when I hear about how people do try and
> > swap on systems like this, I really start agreeing. Maybe we could make
> > 8xx just select SWAP=n? :)
>
> No! David is right. There are systems out in the field running with
> IDE harddisks attached (either through custom hardware interfaces or
> through standard PCMCIA adapters), and some of these actually need
> and use swap space.
>
> Please do not remove stuff that is needed and used to work (in 2.4).
Note the bug in question exists in 2.4, and I think really even 2.2.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Wolfgang Denk @ 2005-11-08 20:56 UTC (permalink / raw)
To: David Jander; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <27139.213.84.146.227.1131479070.squirrel@protonic.xs4all.nl>
In message <27139.213.84.146.227.1131479070.squirrel@protonic.xs4all.nl> you wrote:
>
> Needless to say, swap over nfs did never work reliably enough to even
> start compiling.
You can work around this. It's painfully slow, but it works. See
http://www.denx.de/wiki/view/DULG/SwappingOverNFS
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
Only a fool fights in a burning house.
-- Kank the Klingon, "Day of the Dove", stardate unknown
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Wolfgang Denk @ 2005-11-08 20:52 UTC (permalink / raw)
To: Tom Rini; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <20051108175658.GO3839@smtp.west.cox.net>
In message <20051108175658.GO3839@smtp.west.cox.net> you wrote:
>
> > Well, at least it sounds ugly together, but it is also at least conceiveable.
> > There seem to be people who use PCMCIA for an IDE interface, so swapping may
> > become desireable in some cases.
>
> I think Dan might be in the camp that says a properly designed embedded
> system won't need to swap. And when I hear about how people do try and
> swap on systems like this, I really start agreeing. Maybe we could make
> 8xx just select SWAP=n? :)
No! David is right. There are systems out in the field running with
IDE harddisks attached (either through custom hardware interfaces or
through standard PCMCIA adapters), and some of these actually need
and use swap space.
Please do not remove stuff that is needed and used to work (in 2.4).
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
"Virtual" means never knowing where your next byte is coming from.
^ permalink raw reply
* Re: fix swapping on 8xx?
From: David Jander @ 2005-11-08 19:44 UTC (permalink / raw)
To: Dan Malek; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <ae77b5dcfdaa24efebf92042907e2ce8@embeddededge.com>
>> I think Dan might be in the camp that says a properly designed embedded
>> system won't need to swap.
>
> I'm actually in the camp that knows the majority of systems
> running Linux aren't workstations and don't have disk drives.
> It would be nice to have selectable features for such applications.
Well, me too, but there are people out there trying to do strange stuff. I
remember myself even once trying to get swapping to work over nfs, because
I wanted to compile perl5 natively (overnight of course), since
cross-compiling perl is quite a bit of pain. Perl intends to
"include-together" enormous source files, that exhausted the whole 64Mbyte
RAM on my embedded board ;-)
Needless to say, swap over nfs did never work reliably enough to even
start compiling.
>>> It sounds tempting indeed, but should you really notice a performance
>>> increase out of this?
>
> Yes. Most importantly it adds some predictability which is quite
> measurable on this class of processor. It was a coding mistake way back
> in 2.2 that actually exposed this. I was taking some liberties by
> updating more status in the PTE than I should have, and Paulus
> made me fix it in 2.4 :-) It basically eliminates TLB faults associated
> with system status tracking, since we aren't paging there isn't any need
> to track page aging and such. If you are paging, it still
> functions properly, you may just not pick the most suitable pages to
> steal.
FYI, I have some benchmark results of yesterday's git of kernel-2.6 (with
_tlbie(address); just moved out of the two innermost if()'s in the
function update_mmu_cache()) compared to kernel 2.4.25 from denx, made
with "nbench". The results are quite interesting, and contradicting
(older) benchmark results, Wolfgang made a few months back:
kernel-2.6.14-git-20051107:
---------------------------
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 32.654 : 0.84 : 0.28
STRING SORT : 1.7408 : 0.78 : 0.12
BITFIELD : 8.3466e+06 : 1.43 : 0.30
FP EMULATION : 3.506 : 1.68 : 0.39
IDEA : 115.3 : 1.76 : 0.52
HUFFMAN : 27.855 : 0.77 : 0.25
LU DECOMPOSITION : 0.35932 : 0.02 : 0.01
kernel-2.4.25-devel-denx:
-------------------------
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 30.438 : 0.78 : 0.26
STRING SORT : 1.5842 : 0.71 : 0.11
BITFIELD : 7.9506e+06 : 1.36 : 0.28
FP EMULATION : 3.258 : 1.56 : 0.36
IDEA : 108.89 : 1.67 : 0.49
HUFFMAN : 26.281 : 0.73 : 0.23
LU DECOMPOSITION : 0.32765 : 0.02 : 0.01
This is all on the same hardware: MPC852T + 32Mbyte SDRAM running from
NFS. kernel 2.6 is faster all the way through!!
The results so far are pretty encouraging I'd say. Maybe something like
lmbench would help to shed more light on details important for kernel
testing, like context-switch overhead, mm, etc...
Nbench is quite useless here (a single task doing all sorts of nonsense,
almost no critical syscalls), but that's what makes the enormous
differences even more remarkable IMO. Maybe something is broken in 2.4?
Greetings,
--
David Jander
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Dan Malek @ 2005-11-08 18:57 UTC (permalink / raw)
To: Tom Rini; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <20051108175658.GO3839@smtp.west.cox.net>
On Nov 8, 2005, at 12:56 PM, Tom Rini wrote:
> I think Dan might be in the camp that says a properly designed embedded
> system won't need to swap.
I'm actually in the camp that knows the majority of systems
running Linux aren't workstations and don't have disk drives.
It would be nice to have selectable features for such applications.
>> It sounds tempting indeed, but should you really notice a performance
>> increase
>> out of this?
Yes. Most importantly it adds some predictability which is quite
measurable on this class of processor. It was a coding mistake way
back in 2.2 that actually exposed this. I was taking some liberties by
updating more status in the PTE than I should have, and Paulus
made me fix it in 2.4 :-) It basically eliminates TLB faults associated
with system status tracking, since we aren't paging there isn't any
need to track page aging and such. If you are paging, it still
functions properly, you may just not pick the most suitable pages
to steal.
Thanks.
-- Dan
^ permalink raw reply
* [PATCH] Remove arch/ppc/syslib/ppc4xx_pm.c
From: Alexey Dobriyan @ 2005-11-08 18:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev, Domen Puncer
From: Domen Puncer <domen@coderock.org>
Remove nowhere referenced file ("grep ppc4xx_pm -r ." didn't find anything)
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Index: linux-kj/arch/ppc/syslib/ppc4xx_pm.c
===================================================================
--- linux-kj.orig/arch/ppc/syslib/ppc4xx_pm.c 2005-11-08 20:46:23.000000000 +0300
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,47 +0,0 @@
-/*
- * Author: Armin Kuster <akuster@mvista.com>
- *
- * 2002 (c) MontaVista, Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- *
- * This an attempt to get Power Management going for the IBM 4xx processor.
- * This was derived from the ppc4xx._setup.c file
- */
-
-#include <linux/config.h>
-#include <linux/init.h>
-
-#include <asm/ibm4xx.h>
-
-void __init
-ppc4xx_pm_init(void)
-{
-
- unsigned int value = 0;
-
- /* turn off unused hardware to save power */
-#ifdef CONFIG_405GP
- value |= CPM_DCP; /* CodePack */
-#endif
-
-#if !defined(CONFIG_IBM_OCP_GPIO)
- value |= CPM_GPIO0;
-#endif
-
-#if !defined(CONFIG_PPC405_I2C_ADAP)
- value |= CPM_IIC0;
-#ifdef CONFIG_STB03xxx
- value |= CPM_IIC1;
-#endif
-#endif
-
-
-#if !defined(CONFIG_405_DMA)
- value |= CPM_DMA;
-#endif
-
- mtdcr(DCRN_CPMFR, value);
-
-}
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Tom Rini @ 2005-11-08 17:56 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200511081259.26525.david.jander@protonic.nl>
On Tue, Nov 08, 2005 at 01:59:26PM +0200, David Jander wrote:
> On Tuesday 08 November 2005 01:55, Dan Malek wrote:
> > On Nov 7, 2005, at 10:10 AM, Marcelo Tosatti wrote:
> > > The following is an attempt to fix swapping on 8xx by not touching
> > > _PAGE_ACCESSED bit if the page is not present.
> >
> > Ugh .... I suppose. I hate assembler code macros .......
> > Somehow, "swapping" and "8xx" just don't belong together.
>
> Well, at least it sounds ugly together, but it is also at least conceiveable.
> There seem to be people who use PCMCIA for an IDE interface, so swapping may
> become desireable in some cases.
I think Dan might be in the camp that says a properly designed embedded
system won't need to swap. And when I hear about how people do try and
swap on systems like this, I really start agreeing. Maybe we could make
8xx just select SWAP=n? :)
> > I'm tempted to add a configuration option that is the complete
> > opposite of this and assumes are really embedded system.
> > Mark pages as always accessed, data pages as always dirty,
> > and you can eliminate lots of TLB faults in systems that are
> > fairly static.
>
> It sounds tempting indeed, but should you really notice a performance increase
> out of this?
Compared to 8xx in 2.6 today? Absolutely.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* 440EP FPU support missing
From: Stefan Roese @ 2005-11-08 17:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc64-dev
In-Reply-To: <20051108093759.A26086@cox.net>
In the current linux version, Bamboo (440EP) won't compile anymore, because of
missing fpu support:
make uImage
...
LD init/built-in.o
LD .tmp_vmlinux1
arch/ppc/kernel/head_44x.o(.text+0x868): In function `_start':
: undefined reference to `KernelFP'
make: *** [.tmp_vmlinux1] Error 1
Somehow arch/ppc/kernel/fpu.S has disappeared. :-( I assume, this happened in
the ppc/ppc64 -> powerpc merge. Any thoughts, why this file disappeared and
how to solve this problem (just restore the original file)?
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] ppc32: fix perf_irq extern on e500
From: Matt Porter @ 2005-11-08 16:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc64-dev, paulus, linuxppc-embedded
In-Reply-To: <20051107190128.68d41294.akpm@osdl.org>
On Mon, Nov 07, 2005 at 07:01:28PM -0800, Andrew Morton wrote:
> Matt Porter <mporter@kernel.crashing.org> wrote:
> >
> > Add an extern reference to perf_irq on e500.
<snip>
> > #ifdef CONFIG_E500
> > +extern perf_irq_t perf_irq;
> > +
> > void performance_monitor_exception(struct pt_regs *regs)
> > {
> > perf_irq(regs);
>
> extern decls are placed in header files, please.
Here's the updated patch, addressing this for ppc64 as well. Paul,
would you prefer that this go through the powerpc-merge tree since
the updated version modifies arch/powerpc/?
-Matt
Fixes e500 build and cleans up traps.c by moving perf_irq extern to
pmc.h.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 07e5ee4..32cd797 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -898,10 +898,6 @@ void altivec_unavailable_exception(struc
die("Unrecoverable VMX/Altivec Unavailable Exception", regs, SIGABRT);
}
-#ifdef CONFIG_PPC64
-extern perf_irq_t perf_irq;
-#endif
-
#if defined(CONFIG_PPC64) || defined(CONFIG_E500)
void performance_monitor_exception(struct pt_regs *regs)
{
diff --git a/include/asm-powerpc/pmc.h b/include/asm-powerpc/pmc.h
index 2f3c3fc..5f41f3a 100644
--- a/include/asm-powerpc/pmc.h
+++ b/include/asm-powerpc/pmc.h
@@ -22,6 +22,7 @@
#include <asm/ptrace.h>
typedef void (*perf_irq_t)(struct pt_regs *);
+extern perf_irq_t perf_irq;
int reserve_pmc_hardware(perf_irq_t new_perf_irq);
void release_pmc_hardware(void);
^ permalink raw reply related
* RE: PPCBoot 2.0.0 Errors
From: Sette Agostino @ 2005-11-08 13:52 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
>>
>> As I told you, I tried to produce the U-boot, but I am nont confident on
the
>> version (1.0.0).
>No, indeed. This is ancient stuff. Use top of tree from the GIT repo
>(or CVS), or download the latest snapshot from our FTP server.
Ok, I did it and I produced a new u-boot
>> Could you suggest me the latest stale version I must get?
>May I suggest that you start reading the manual? See
>http://www.denx.de/wiki/DULG/Manual
Ok, I alreay read it, but it is not so easy to convince my bosses to change
the boot :-(.
Anyway I am going to take a closer look to the doc.
Thanks once again
Best Regards
Agostino Sette
^ permalink raw reply
* Re: PPCBoot 2.0.0 Errors
From: Wolfgang Denk @ 2005-11-08 13:38 UTC (permalink / raw)
To: Sette Agostino; +Cc: linuxppc-embedded
In-Reply-To: <69DF49BE936F4441980EC1D59F0ADC2F0108C29F@aqlby02a.siemens.it>
In message <69DF49BE936F4441980EC1D59F0ADC2F0108C29F@aqlby02a.siemens.it> you wrote:
>
> As I told you, I tried to produce the U-boot, but I am nont confident on the
> version (1.0.0).
No, indeed. This is ancient stuff. Use top of tree from the GIT repo
(or CVS), or download the latest snapshot from our FTP server.
> Could you suggest me the latest stale version I must get?
May I suggest that you start reading the manual? See
http://www.denx.de/wiki/DULG/Manual
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
I will not say that women have no character; rather, they have a new
one every day. -- Heine
^ permalink raw reply
* Re: fix swapping on 8xx?
From: David Jander @ 2005-11-08 11:59 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <b4fb08107c7bd17161f36e023035080a@embeddedalley.com>
On Tuesday 08 November 2005 01:55, Dan Malek wrote:
> On Nov 7, 2005, at 10:10 AM, Marcelo Tosatti wrote:
> > The following is an attempt to fix swapping on 8xx by not touching
> > _PAGE_ACCESSED bit if the page is not present.
>
> Ugh .... I suppose. I hate assembler code macros .......
> Somehow, "swapping" and "8xx" just don't belong together.
Well, at least it sounds ugly together, but it is also at least conceiveable.
There seem to be people who use PCMCIA for an IDE interface, so swapping may
become desireable in some cases.
> I'm tempted to add a configuration option that is the complete
> opposite of this and assumes are really embedded system.
> Mark pages as always accessed, data pages as always dirty,
> and you can eliminate lots of TLB faults in systems that are
> fairly static.
It sounds tempting indeed, but should you really notice a performance increase
out of this?
Greetings,
--
David Jander
^ permalink raw reply
* RE: PPCBoot 2.0.0 Errors
From: Sette Agostino @ 2005-11-08 9:18 UTC (permalink / raw)
To: wd, Sette Agostino; +Cc: linuxppc-embedded
Wolfgang,
As I told you, I tried to produce the U-boot, but I am nont confident =
on the
version (1.0.0).
Could you suggest me the latest stale version I must get?
Thanks
Best Regards,
Agostino Sette
TechnoLabs
Department of Innovation Software3
S.S. 17 Localit=E0 Boschetto
67100 L' Aquila (Italy)
Tel: (+39) 0862 344.557
Fax: (+39) 0862 344.623
e-mail: Agostino.Sette@siemens.com =20
=20
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]=20
Sent: marted=EC 8 novembre 2005 10.09
To: Sette Agostino
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: PPCBoot 2.0.0 Errors=20
In message =
<69DF49BE936F4441980EC1D59F0ADC2F0108C267@aqlby02a.siemens.it>
you wrote:
>=20
> I agree with you concerning the PPCBoot. In fact in other boards we =
are
using U-Boot.
> We tried to use U-Boot for MPC859 but we had some problems we are =
trying
to
> solve.
You cannot solve these problems by downgrading to PPCBoot. The
852/859/866 processors are definitelu *not* supported by PPCBoot -
the required changes of the clock handling were added much later. You
*must* use U-Boot.
> As far as you know to change the boot or the kernel on cards in field =
is
not
> so easy :-(
You mean you shipped boards to customers in the field in a state
where you did not even decide for a final version of the boot loader?
Gosh...
> We found an unexpected beahviour regarding the Linux time tick.=20
...whichis probablky cause by using PPCBoot which does not understand
to deal with a 859.
> Another interesting point is that the same kernel works well on other
TQM8xx
> modules, but not fot TQM859.
U-Boot is running perfectly fine on the TQM859 - we have these boards
here in our virtual lab; they are tested on a regular base.
> I will try to introduce the U-Boot, but I am not confident it will =
solve
the
> problem, what do you think about it?
I can *guarantee* you that PPCBoot is definitely worse on your =
hardware.
> Last question, which is the appropriate mailing list?
u-boot-users
Best regards,
Wolfgang Denk
--=20
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Always leave room to add an explanation if it doesn't work out.
^ permalink raw reply
* Re: PPCBoot 2.0.0 Errors
From: Wolfgang Denk @ 2005-11-08 9:08 UTC (permalink / raw)
To: Sette Agostino; +Cc: linuxppc-embedded
In-Reply-To: <69DF49BE936F4441980EC1D59F0ADC2F0108C267@aqlby02a.siemens.it>
In message <69DF49BE936F4441980EC1D59F0ADC2F0108C267@aqlby02a.siemens.it> you wrote:
>
> I agree with you concerning the PPCBoot. In fact in other boards we are using U-Boot.
> We tried to use U-Boot for MPC859 but we had some problems we are trying to
> solve.
You cannot solve these problems by downgrading to PPCBoot. The
852/859/866 processors are definitelu *not* supported by PPCBoot -
the required changes of the clock handling were added much later. You
*must* use U-Boot.
> As far as you know to change the boot or the kernel on cards in field is not
> so easy :-(
You mean you shipped boards to customers in the field in a state
where you did not even decide for a final version of the boot loader?
Gosh...
> We found an unexpected beahviour regarding the Linux time tick.
...whichis probablky cause by using PPCBoot which does not understand
to deal with a 859.
> Another interesting point is that the same kernel works well on other TQM8xx
> modules, but not fot TQM859.
U-Boot is running perfectly fine on the TQM859 - we have these boards
here in our virtual lab; they are tested on a regular base.
> I will try to introduce the U-Boot, but I am not confident it will solve the
> problem, what do you think about it?
I can *guarantee* you that PPCBoot is definitely worse on your hardware.
> Last question, which is the appropriate mailing list?
u-boot-users
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
Always leave room to add an explanation if it doesn't work out.
^ permalink raw reply
* RE: PPCBoot 2.0.0 Errors
From: Sette Agostino @ 2005-11-08 8:37 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
Hello Wolfgang,
Thanks for your answers.
I agree with you concerning the PPCBoot. In fact in other boards we are
using U-Boot.
We tried to use U-Boot for MPC859 but we had some problems we are =
trying to
solve.
As far as you know to change the boot or the kernel on cards in field =
is not
so easy :-(
Anyway, I would like to highlight I think the problem is more related =
to
the
kernel because when it starts I see the following error
init started: BusyBox v0.60.5 (2003.11.19-14:32+0000) multi-callmount:
Mounting devpts on /dev/pts failed: No su
ch file or directory
/opt/rc.project: /opt/bin/sinfo: No such file or directory
We check that slowing-down the UPM clock to 63 MHz (period=3D15.873ns) =
the
board showed a more stable behavior (no fault verified).
We start our investigation on the PPCBoot, but now we are moving on the
kernel.
No critical HW points have been found on the FLASH accesses, SDRAM =
accesses
and clocking circuitrty.
We found an unexpected beahviour regarding the Linux time tick.=20
Tracking with a HP16602 Bus Analyzer the bus activities of the faulty =
module
has been verified that the=20
interrupt service routine of the Decrementer timer, that I supposed to =
be
used to generate the OS time tick, it is not executed each 10ms.
Sometimes the period between 2 Decrementer interrupt service routines =
reach
hundreds of ms (but even as 10mS multiple)=20
such as some requests are missing.=20
Making the same tracking on a TQM866 module has been verified that the
interrupt service routines of the Decrementer timer are=20
all executed at the exact 10ms boundary.
Another interesting point is that the same kernel works well on other =
TQM8xx
modules, but not fot TQM859.
I will try to introduce the U-Boot, but I am not confident it will =
solve the
problem, what do you think about it?
Last question, which is the appropriate mailing list?
Thanks in advance for your support.
Best regards,
Agostino Sette
TechnoLabs
Department of Innovation Software3
S.S. 17 Localit=E0 Boschetto
67100 L' Aquila (Italy)
Tel: (+39) 0862 344.557
Fax: (+39) 0862 344.623
e-mail: Agostino.Sette@siemens.com =20
=20
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]=20
Sent: luned=EC 7 novembre 2005 23.10
To: Sette Agostino
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: PPCBoot 2.0.0 Errors=20
In message =
<69DF49BE936F4441980EC1D59F0ADC2F0108C12C@aqlby02a.siemens.it>
you wrote:
>=20
> I have the following problem at the PPCBoot startup:
>=20
> PPCBoot 2.0.0 (Oct 20 2005 - 12:28:22)
PPCBoot is a dead project. It was discontinued more than 3 years ago.
It is definitely a bad idea to use it for current projects. Use
U-Boot instead.
Also, this is completely off topic on this mailing list.
> CPU: unknown MPC859 (0x08010004) at 133 MHz: 16 kB I-Cache 8 kB =
D-Cache
Use U-Boot instead.
> Board: Siemens CCM
And don't use a board configuration that does not match your hardware.
> ## Booting image at 40180000 ...
> Image Name: Linux-2.4.20-rthal5
Argh... Ancient stuff again. Forget it.
> Anybody experienced the same problem? Any suggestions about how to =
solve
it?
Use current software. Read the documentation. Post on the appropriate
mailing lists.
Best regards,
Wolfgang Denk
--=20
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
My challenge to the goto-less programmer is to recode tcp_input()
without any gotos ... without any loss of efficiency (there has to be
a catch). - W. R. Stevens
^ 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