* Re: Kernel 2.6 on MPC8xx performance trouble...
From: Roger Larsson @ 2005-10-28 9:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200510280857.44625.david.jander@protonic.nl>
On Friday 28 October 2005 08.57, David Jander wrote:
> Hi all,
>
> Many people have said it before: 2.6 has a performance penalty specially
> for embdedded systems.
> But now that I have 2.6 running on our 100MHz MPC852T based board, I was
> shocked to see the result:
> The most simple task doing nothing but a closed loop of integer math runs
> at _half_ the speed compared to kernel 2.4.25!!!!!
>
> Here are the conditions for the test:
> - Bogomips are the same, so the CPU definitely runs at the same clock-rate
> (and not half) as with "2.4".
> - Enabling and disabling preemption doesn't have any impact (as expected
> for such kinds of tasks).
> - Setting HZ to 100 or 1000 also has only about 3% impact on speed.
> - The binary of the test program is the same in both cases (no re-compile
> with other optimizations by accident).
> - The hardware is the same (exact same board).
> - Certain hardware drivers that are not ported to "2.6" yet were present in
> "2.4" but (obviously) not in "2.6", but non of them could have a _positive_
> impact on performance.
> - Kernel versions are 2.4.25 (denx-devel) and 2.6.14-rc5 (denx-git
> 20051027).
>
> Result: The test takes 3 seconds on kernel-2.6 and 1.5 seconds on
> kernel-2.4. Here is what "time" has to say about it:
>
> real 0m3.119s
> user 0m3.080s
> sys 0m0.040s
>
> The test loop is pretty brain-dead, but that doesn't matter right now.
> This is it:
> [....]
> gettimeofday(&tv0,NULL);
> for(t=0L; t<10000000L; t++)
> {
> a+=b; /* Do something */
> }
> gettimeofday(&tv,NULL);
> [...]
>
> Any ideas?
> Am I misconfiguring something? Is 2.6 support for mpc8xx still broken
> (cache/tlb, mm, etc) or is 2.6 supposed to perform THAT bad??
Have you verified the system measured time with wall clock (wrist watch)?
System time could be wrong on one of the systems.
What is 'a' and 'b'? The only other explanation I can see is that your
"Do something" is more memory heavy than you think - array calculations?
(Cache problems should probably give a worse result, but you could check that
those config registers are the same).
/RogerL
^ permalink raw reply
* Re: Kernel 2.6 on MPC8xx performance trouble...
From: David Jander @ 2005-10-28 10:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200510281136.21575.roger.larsson@norran.net>
On Friday 28 October 2005 11:36, Roger Larsson wrote:
> >[...]
> > Result: The test takes 3 seconds on kernel-2.6 and 1.5 seconds on
> > kernel-2.4. Here is what "time" has to say about it:
> >
> > real 0m3.119s
> > user 0m3.080s
> > sys 0m0.040s
> >
> > The test loop is pretty brain-dead, but that doesn't matter right now.
> > This is it:
> > [....]
> > gettimeofday(&tv0,NULL);
> > for(t=0L; t<10000000L; t++)
> > {
> > a+=b; /* Do something */
> > }
> > gettimeofday(&tv,NULL);
> > [...]
> >
> > Any ideas?
> > Am I misconfiguring something? Is 2.6 support for mpc8xx still broken
> > (cache/tlb, mm, etc) or is 2.6 supposed to perform THAT bad??
>
> Have you verified the system measured time with wall clock (wrist watch)?
> System time could be wrong on one of the systems.
Yes. Wall-clock==gettimeofday-clock on both systems.
> What is 'a' and 'b'? The only other explanation I can see is that your
> "Do something" is more memory heavy than you think - array calculations?
> (Cache problems should probably give a worse result, but you could check
> that those config registers are the same).
They are just integers with fixed start values. These are in the loop, so it's
not an empty loop and hopefully the compiler won't out-optimize it so easily
(that is of course without specifying any optimization flags). Please don't
tell me it's a lousy benchmark, because I already know that! Be it as lousy
as it is, I shouldn't get _those_ results IMHO.
I have downloaded nbench (hopefully a more serious benchmark for raw computing
power), and the results are as follows (I deliberately excluded tests that
don't make sense (ie. use FP)):
Kernel 2.4.25:
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
Kernel 2.6.14-r5:
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 21.042 : 0.54 : 0.18
STRING SORT : 0.88215 : 0.39 : 0.06
BITFIELD : 6.0979e+06 : 1.05 : 0.22
FP EMULATION : 1.6453 : 0.79 : 0.18
IDEA : 110.25 : 1.69 : 0.50
Now, the strange thing is, IDEA is the only test where 2.6 is slightly faster
(results are consistent over repeated runs). Compiler options are: "-s
-static -Wall -O3 -msoft-float", FP-emulation in the kernel is never
activated.
I think I will need to look closer at how the "IDEA"-test works, but first
I'll have to run the nbench sources through "indent", because they are pretty
unreadable as is ;-)
I also downloaded oprofile, and am studying its manual right now. Hopefully
using this might get me a clue. If anybody already happens to know the
answer, please shout!
Greetings,
--
David Jander
^ permalink raw reply
* Patches for 2.6.15
From: Paul Mackerras @ 2005-10-28 13:05 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
If anyone has patches for arch/ppc{,64} and include/asm-ppc{,64} that
they would like to see go upstream now that 2.6.14 is out, other than
patches that are already in the powerpc-merge tree, please let me
know. I am planning to ask Linus to pull the powerpc-merge tree
shortly, and that will probably break your patches.
I think the merge tree is looking pretty good, although the merge is
by no means complete yet. The powermac, pseries and iseries platforms
seem to be working fine with ARCH=powerpc. 32-bit chrp is mostly
there but needs a bit more work.
If possible, I'd like to get to the point where we can remove
arch/ppc64 entirely by the end of the 2-week merge window for 2.6.15.
Paul.
^ permalink raw reply
* Re: Makefile check for older binutils broken?
From: Marcelo Tosatti @ 2005-10-28 8:52 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20051026220205.GH26475@smtp.west.cox.net>
On Wed, Oct 26, 2005 at 03:02:05PM -0700, Tom Rini wrote:
> On Wed, Oct 26, 2005 at 11:36:48AM -0200, Marcelo Tosatti wrote:
> >
> > Hi,
> >
> > While trying to compile 2.6.14-rc4 on my Pegasos (running Debian unstable):
> >
> > make[2]: Entering directory `/home/marcelo/8xx/linux-2.6.14-rc4'
> > *** 2.6 kernels no longer build correctly with old versions of binutils.
> > *** Please upgrade your binutils to 2.12.1 or newer
> > make[2]: *** [checkbin] Error 1
>
> What's your CONFIG_SHELL set to?
bash
>
> [snip]
> > marcelo@pegasos:~$ /bin/echo dssall | as -many -o /tmp/output.as >/dev/null 2>&1
> > marcelo@pegasos:~$ echo $?
>
> What about if you run the whole test on shell (if ...), does it work there?
> What shell are you running?
Yep, that does the trick. Is it good now?
--- arch/ppc/Makefile.orig 2005-10-26 13:04:43.000000000 -0500
+++ arch/ppc/Makefile 2005-10-28 08:43:22.153202928 -0500
@@ -132,12 +132,12 @@
false; \
fi ; \
fi
- @if ! [[ "/bin/echo dssall | $(AS) -many -o $(TOUT) >/dev/null 2>&1" ]]; then \
+ @(if ! /bin/echo dssall | $(AS) -many -o $(TOUT) >/dev/null 2>&1 ; then\
echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build ' ; \
echo 'correctly with old versions of binutils.' ; \
echo '*** Please upgrade your binutils to 2.12.1 or newer' ; \
false ; \
- fi
+ fi)
CLEAN_FILES += $(TOUT)
^ permalink raw reply
* Howto Cross Compile GCC to run on PPC Platform
From: Jeff Stevens @ 2005-10-28 15:55 UTC (permalink / raw)
To: linuxppc-embedded
I am trying to compile GCC on an x86 platform to
run natively on an embedded PPC platform. I am able
to compile gcc as a cross compiler (to run on x86),
but can't seem to get it to cross compile gcc (to run
on ppc). Does anyone know of a good HowTo to do this?
I'm currently downloading the source distro of ELDK,
so if it's already in there I'll find it, but if there
is one elsewhere online please let me know.
Thanks,
Jeff Stevens
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
^ permalink raw reply
* Re: How the linux use BAT
From: Noah yan @ 2005-10-28 15:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1130452630.29054.77.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]
Thans Ben very much. More questions below ... :)
On 10/27/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Thu, 2005-10-27 at 08:05 -0500, Noah yan wrote:
> > I am studying source code for power mac. I am curious how linux use
> > the BAT MMU.
> > The address translation of BAT MMU is parallel with that of
> > segment/page MMU. BAT MMU is known as superpages in other
> > architecture.
> > I am not good at the kernel coding part, hope that my questions share
> > the common fundermental with you and no stupid.
> >
> > Here is my questions:
> > Is the kernel turn BAT MMU on? if so, a BAT array have been setup for
> > that, which part of the kernel code does this?
> > If BAT MMU is used, how about segment/page address translation in
> > kernel, is this also enabled and page table is setup?
> >
> > If both BAT and seg/page are enabled, how the kernel make sure that
> > the correct one is used in adress translation?
>
> Both are used and they don't overlap (well, they can overlap but if they
> do, the BAT takes over).
>
> > Is kernel really use the segment MMU of the powerpc, I have an
> > impression that most kernel only use the page MMU?
>
> page MMU vs. segment MMU ? hrm... what do you mean ? :) There is one MMU
> in the "classsic" PowerPC and it does segment and hash table, you have to
> use both, you can't just use one or the other :) You virtual addresses
> go through the segments first to get the vsid which is then used along
> with the remaining bits of the address to hash into the hash table in
> order to get to the translations.
I am sorry that I did make it clear. It is a little confusing for me between
the hardware segment and the term "segment" or "section" used in a process's
address space (AS). One of my understanding is that a section in a process's
AS is mapped to a hardware segment, which sound straightforward but maybe
wrong because a process binary may have lots of segments that are not the
same size. Pure segment VM is also hard to maintain memory efficiency. Or,
several sections, such as different data section are in segments. I remember
in Linux x86 (posibbly 2.4), segment is not fully used in term of VM. The
segmentation of the kernel and userland are defined upon booting and never
changed later on.
Thanks very much!
Noah
The way linux uses BATs is for the kernel linear mapping. Linux uses by
> default (though that can be configued differently) a 3G/1G split, that
> is the low 3G of address space are used by userland (and covered by the
> user page tables) and the high 1G are used by the kernel. That kernel
> space itself is split into a bottom part up to 768Mb (by default, that
> can also be configured differently) which is the linear mapping, that is
> a single linear mapping of all RAM from 0xc0000000. The rest of the
> kernel space is mapped with page tables and known as the kernel virtual
> space, used for vmalloc and ioremap.
>
> The BATs are used for the linear mapping. They "override" the page
> tables over it if any (though we usually don't bother setting up PTEs
> over the space that is BAT mapped). They basically improve performances
> by not requiring to go through the hash trasnslation for most kernel
> accesses to memory and not using space in the TLB/ERAT.
>
> Ben.
>
>
>
[-- Attachment #2: Type: text/html, Size: 3963 bytes --]
^ permalink raw reply
* RE: Howto Cross Compile GCC to run on PPC Platform
From: Steven Blakeslee @ 2005-10-28 15:57 UTC (permalink / raw)
To: Jeff Stevens, linuxppc-embedded
> get it to cross compile gcc (to run on ppc). Does anyone=20
> know of a good HowTo to do this?
Karim Yaghmour's "Building Embedded Linux Systems"
=20
> I'm currently downloading the source distro of ELDK, so if=20
> it's already in there I'll find it, but if there is one=20
> elsewhere online please let me know.
Very good, full of features.
^ permalink raw reply
* [PATCH] ppc32: Remove internal PCI arbiter check on PPC40x
From: Stefan Roese @ 2005-10-28 15:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200509301452.52074.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 303 bytes --]
On PPC405GP/GPR it should be possible to enable PCI support, even when
the internal PCI arbiter is disabled (e.g. when using an external PCI
arbiter). The removed code didn't allow this, and also generated a
warning on PPC405EP platforms.
Signed-off-by: Stefan Roese <sr@denx.de>
Best regards,
Stefan
[-- Attachment #2: ppc405-pci-arbiter.patch --]
[-- Type: text/x-diff, Size: 1308 bytes --]
[PATCH] ppc32: Remove internal PCI arbiter check on PPC40x
On PPC405GP/GPR it should be possible to enable PCI support, even when
the internal PCI arbiter is disabled (e.g. when using an external PCI
arbiter). The removed code didn't allow this, and also generated a
warning on PPC405EP platforms.
Signed-off-by: Stefan Roese <sr@denx.de>
---
commit 7f14813879d885d7f8d7ef589bbd3050c451b6a7
tree 8c14f370df43abe61e9ace8ff243fdb16e5a8c4d
parent 741b2252a5e14d6c60a913c77a6099abe73a854a
author Stefan Roese <sr@denx.de> Fri, 28 Oct 2005 15:43:00 +0200
committer Stefan Roese <sr@denx.de> Fri, 28 Oct 2005 15:43:00 +0200
arch/ppc/syslib/ppc405_pci.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/ppc/syslib/ppc405_pci.c b/arch/ppc/syslib/ppc405_pci.c
--- a/arch/ppc/syslib/ppc405_pci.c
+++ b/arch/ppc/syslib/ppc405_pci.c
@@ -89,13 +89,6 @@ ppc4xx_find_bridges(void)
isa_mem_base = 0;
pci_dram_offset = 0;
-#if (PSR_PCI_ARBIT_EN > 1)
- /* Check if running in slave mode */
- if ((mfdcr(DCRN_CHPSR) & PSR_PCI_ARBIT_EN) == 0) {
- printk("Running as PCI slave, kernel PCI disabled !\n");
- return;
- }
-#endif
/* Setup PCI32 hose */
hose_a = pcibios_alloc_controller();
if (!hose_a)
\f
!-------------------------------------------------------------flip-
^ permalink raw reply
* Re: Patches for 2.6.15
From: Christopher Friesen @ 2005-10-28 16:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17250.8725.358204.62510@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> If possible, I'd like to get to the point where we can remove
> arch/ppc64 entirely by the end of the 2-week merge window for 2.6.15.
I haven't been following this seriously, so forgive me if this has
already been asked.
Under the unified architecture, what is the machine type in the "uname"
outout?
Chris
^ permalink raw reply
* Re: Makefile check for older binutils broken?
From: Tom Rini @ 2005-10-28 16:10 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-dev
In-Reply-To: <20051028085224.GA17520@logos.cnet>
On Fri, Oct 28, 2005 at 06:52:24AM -0200, Marcelo Tosatti wrote:
> On Wed, Oct 26, 2005 at 03:02:05PM -0700, Tom Rini wrote:
> > On Wed, Oct 26, 2005 at 11:36:48AM -0200, Marcelo Tosatti wrote:
> > >
> > > Hi,
> > >
> > > While trying to compile 2.6.14-rc4 on my Pegasos (running Debian unstable):
> > >
> > > make[2]: Entering directory `/home/marcelo/8xx/linux-2.6.14-rc4'
> > > *** 2.6 kernels no longer build correctly with old versions of binutils.
> > > *** Please upgrade your binutils to 2.12.1 or newer
> > > make[2]: *** [checkbin] Error 1
> >
> > What's your CONFIG_SHELL set to?
>
> bash
>
> >
> > [snip]
> > > marcelo@pegasos:~$ /bin/echo dssall | as -many -o /tmp/output.as >/dev/null 2>&1
> > > marcelo@pegasos:~$ echo $?
> >
> > What about if you run the whole test on shell (if ...), does it work there?
> > What shell are you running?
>
> Yep, that does the trick. Is it good now?
Er, that's odd. I was using writing parens, not shell parens :) Can
you test the failure case here by changing dssall to garbage? Also,
that's not a clean patch, but vs your last one that wasn't valid.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Patches for 2.6.15
From: Matt Porter @ 2005-10-28 17:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17250.8725.358204.62510@cargo.ozlabs.ibm.com>
On Fri, Oct 28, 2005 at 11:05:25PM +1000, Paul Mackerras wrote:
> If anyone has patches for arch/ppc{,64} and include/asm-ppc{,64} that
> they would like to see go upstream now that 2.6.14 is out, other than
> patches that are already in the powerpc-merge tree, please let me
> know. I am planning to ask Linus to pull the powerpc-merge tree
> shortly, and that will probably break your patches.
Ok, we have a set of 4xx patches that I plan to send to Andrew.
They are some existing 4xx SoC/board updates as well as a new
SoC/board. They are obviously mostly confined to the 4xx code paths
but there's likely conflicts in changes to Makefiles, etc.
Would you prefer these going upstream before or after the
powerpc-merge pull?
-Matt
^ permalink raw reply
* Re: Patches for 2.6.15
From: Andreas Schwab @ 2005-10-28 17:54 UTC (permalink / raw)
To: Christopher Friesen; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <43624B30.20600@nortel.com>
"Christopher Friesen" <cfriesen@nortel.com> writes:
> Under the unified architecture, what is the machine type in the "uname"
> outout?
I don't think that should change in any way.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Makefile check for older binutils broken?
From: Marcelo Tosatti @ 2005-10-28 13:14 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20051028161054.GB22245@smtp.west.cox.net>
On Fri, Oct 28, 2005 at 09:10:54AM -0700, Tom Rini wrote:
> On Fri, Oct 28, 2005 at 06:52:24AM -0200, Marcelo Tosatti wrote:
> > On Wed, Oct 26, 2005 at 03:02:05PM -0700, Tom Rini wrote:
> > > On Wed, Oct 26, 2005 at 11:36:48AM -0200, Marcelo Tosatti wrote:
> > > >
> > > > Hi,
> > > >
> > > > While trying to compile 2.6.14-rc4 on my Pegasos (running Debian unstable):
> > > >
> > > > make[2]: Entering directory `/home/marcelo/8xx/linux-2.6.14-rc4'
> > > > *** 2.6 kernels no longer build correctly with old versions of binutils.
> > > > *** Please upgrade your binutils to 2.12.1 or newer
> > > > make[2]: *** [checkbin] Error 1
> > >
> > > What's your CONFIG_SHELL set to?
> >
> > bash
> >
> > >
> > > [snip]
> > > > marcelo@pegasos:~$ /bin/echo dssall | as -many -o /tmp/output.as >/dev/null 2>&1
> > > > marcelo@pegasos:~$ echo $?
> > >
> > > What about if you run the whole test on shell (if ...), does it work there?
> > > What shell are you running?
> >
> > Yep, that does the trick. Is it good now?
>
> Er, that's odd. I was using writing parens, not shell parens :) Can
> you test the failure case here by changing dssall to garbage? Also,
> that's not a clean patch, but vs your last one that wasn't valid.
Yes thats bullshit (it does not work actually).
Give me some time figure out whats going to avoid wasting your time.
Sorry.
^ permalink raw reply
* Re: Patches for 2.6.15
From: Kumar Gala @ 2005-10-28 18:41 UTC (permalink / raw)
To: Christopher Friesen; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <43624B30.20600@nortel.com>
On Oct 28, 2005, at 11:00 AM, Christopher Friesen wrote:
> Paul Mackerras wrote:
>
>
>> If possible, I'd like to get to the point where we can remove
>> arch/ppc64 entirely by the end of the 2-week merge window for 2.6.15.
>>
>
> I haven't been following this seriously, so forgive me if this has
> already been asked.
>
> Under the unified architecture, what is the machine type in the
> "uname" outout?
When building the merge tree for a 32-bit cpu uname spits out:
Linux fred 2.6.14-rc5-g278144ed #9 Thu Oct 27 09:20:01 CDT 2005 ppc
unknown
- kumar
^ permalink raw reply
* Re: Kernel 2.6 on MPC8xx performance trouble...
From: Roger Larsson @ 2005-10-28 18:44 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200510281257.22650.david.jander@protonic.nl>
On Friday 28 October 2005 12.57, David Jander wrote:
> They are just integers with fixed start values. These are in the loop, so
> it's not an empty loop and hopefully the compiler won't out-optimize it so
> easily (that is of course without specifying any optimization flags).
> Please don't tell me it's a lousy benchmark, because I already know that!
> Be it as lousy as it is, I shouldn't get _those_ results IMHO.
>
> I have downloaded nbench (hopefully a more serious benchmark for raw
> computing power), and the results are as follows (I deliberately excluded
> tests that don't make sense (ie. use FP)):
>
> Kernel 2.4.25:
>
> 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
>
> Kernel 2.6.14-r5:
>
> TEST : Iterations/sec. : Old Index : New Index
>
> : : Pentium 90* : AMD K6/233*
>
> --------------------:------------------:-------------:------------
> NUMERIC SORT : 21.042 : 0.54 : 0.18
> STRING SORT : 0.88215 : 0.39 : 0.06
> BITFIELD : 6.0979e+06 : 1.05 : 0.22
> FP EMULATION : 1.6453 : 0.79 : 0.18
> IDEA : 110.25 : 1.69 : 0.50
>
>
What about the Pentium 90 and AMD K6? Are those values actual measured
results? By you? If not why do THEY differ between the kernel versions?
Is this a MPC8xx problem - can it be verified on a x86?
/RogerL
^ permalink raw reply
* Re: Patches for 2.6.15
From: Kumar Gala @ 2005-10-28 18:44 UTC (permalink / raw)
To: Matt Porter; +Cc: Andrew Morton, ppc-dev list, linuxppc64-dev
In-Reply-To: <20051028103041.B15268@cox.net>
On Oct 28, 2005, at 12:30 PM, Matt Porter wrote:
> On Fri, Oct 28, 2005 at 11:05:25PM +1000, Paul Mackerras wrote:
>
>> If anyone has patches for arch/ppc{,64} and include/asm-ppc{,64} that
>> they would like to see go upstream now that 2.6.14 is out, other than
>> patches that are already in the powerpc-merge tree, please let me
>> know. I am planning to ask Linus to pull the powerpc-merge tree
>> shortly, and that will probably break your patches.
>>
>
> Ok, we have a set of 4xx patches that I plan to send to Andrew.
> They are some existing 4xx SoC/board updates as well as a new
> SoC/board. They are obviously mostly confined to the 4xx code paths
> but there's likely conflicts in changes to Makefiles, etc.
>
> Would you prefer these going upstream before or after the
> powerpc-merge pull?
Can we ask Andrew to flush any ppc patches in -mm to linus before we
have Linus pull the merge tree.
The following are patches that should probably go to linus before the
merge tree that exist in 2.6.14-rc5-mm1:
(I may have missed some, but these where the obvious ones)
+ppc32-85xx-phy-platform-update.patch
+ppc32-ppc_sys-fixes-for-8xx-and-82xx.patch
ppc32 updates
+various-powerpc-32bit-ppc64-build-fixes.patch
+ppc64-reenable-make-install-with-defconfig.patch
+ppc64-change-name-of-target-file-during-make-install.patch
+ppc64-remove-duplicate-local-variable-in-set_preferred_console.patch
- kumar
^ permalink raw reply
* Re: Patches for 2.6.15
From: Kumar Gala @ 2005-10-28 18:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17250.8725.358204.62510@cargo.ozlabs.ibm.com>
On Oct 28, 2005, at 8:05 AM, Paul Mackerras wrote:
> If anyone has patches for arch/ppc{,64} and include/asm-ppc{,64} that
> they would like to see go upstream now that 2.6.14 is out, other than
> patches that are already in the powerpc-merge tree, please let me
> know. I am planning to ask Linus to pull the powerpc-merge tree
> shortly, and that will probably break your patches.
>
> I think the merge tree is looking pretty good, although the merge is
> by no means complete yet. The powermac, pseries and iseries platforms
> seem to be working fine with ARCH=powerpc. 32-bit chrp is mostly
> there but needs a bit more work.
>
> If possible, I'd like to get to the point where we can remove
> arch/ppc64 entirely by the end of the 2-week merge window for 2.6.15.
Can you merge this in:
http://patchwork.ozlabs.org/linuxppc/patch?id=2931
- kumar
^ permalink raw reply
* Re: Howto Cross Compile GCC to run on PPC Platform
From: Ryan Wilkins @ 2005-10-28 18:51 UTC (permalink / raw)
To: Jeff Stevens; +Cc: linuxppc-embedded
In-Reply-To: <20051028155510.17662.qmail@web33413.mail.mud.yahoo.com>
I've used crosstool-0.38 to generate an ARMv5b cross compiler and
then the script referenced from the link below to create the native
GCC from the cross compiler. It should really be not much different
to make a PPC native platform. I hope you have a fast machine.. It
takes a while.
http://sources.redhat.com/ml/crossgcc/2005-08/msg00037.html
Ryan Wilkins
On Oct 28, 2005, at 11:55 AM, Jeff Stevens wrote:
> I am trying to compile GCC on an x86 platform to
> run natively on an embedded PPC platform. I am able
> to compile gcc as a cross compiler (to run on x86),
> but can't seem to get it to cross compile gcc (to run
> on ppc). Does anyone know of a good HowTo to do this?
> I'm currently downloading the source distro of ELDK,
> so if it's already in there I'll find it, but if there
> is one elsewhere online please let me know.
^ permalink raw reply
* Re: Howto Cross Compile GCC to run on PPC Platform
From: Peter Hanson @ 2005-10-28 19:27 UTC (permalink / raw)
To: Steven Blakeslee; +Cc: linuxppc-embedded
In-Reply-To: <1628E43D99629C46988BE46087A3FBB93ADEE3@ep-01.EmbeddedPlanet.local>
On 10/28/05, Steven Blakeslee <BlakesleeS@embeddedplanet.com> wrote:
> > get it to cross compile gcc (to run on ppc). Does anyone
> > know of a good HowTo to do this?
>
> Karim Yaghmour's "Building Embedded Linux Systems"
>
>
> > I'm currently downloading the source distro of ELDK, so if
> > it's already in there I'll find it, but if there is one
> > elsewhere online please let me know.
>
> Very good, full of features.
My favorite cross tool chain site:
Building and Testing gcc/glibc cross toolchains
http://kegel.com/crosstool/
Look into Canadian crosses. At the very least you should find the
discussion helpful.
^ permalink raw reply
* Re: Patches for 2.6.15
From: Andrew Morton @ 2005-10-28 20:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <E053D1B7-2363-45D1-AEFC-83B8B5B4C4F8@freescale.com>
Kumar Gala <kumar.gala@freescale.com> wrote:
>
> Can we ask Andrew to flush any ppc patches in -mm to linus before we
> have Linus pull the merge tree.
Well I'd prefer that ;)
Paul?
^ permalink raw reply
* Re: Howto Cross Compile GCC to run on PPC Platform
From: Robert P. J. Day @ 2005-10-28 19:38 UTC (permalink / raw)
To: Peter Hanson; +Cc: Steven Blakeslee, linuxppc-embedded
In-Reply-To: <50e923300510281227i15609c9dt7778ecbe20920dfa@mail.google.com>
On Fri, 28 Oct 2005, Peter Hanson wrote:
> On 10/28/05, Steven Blakeslee <BlakesleeS@embeddedplanet.com> wrote:
> > > get it to cross compile gcc (to run on ppc). Does anyone
> > > know of a good HowTo to do this?
> >
> > Karim Yaghmour's "Building Embedded Linux Systems"
> >
> >
> > > I'm currently downloading the source distro of ELDK, so if
> > > it's already in there I'll find it, but if there is one
> > > elsewhere online please let me know.
> >
> > Very good, full of features.
>
> My favorite cross tool chain site:
>
> Building and Testing gcc/glibc cross toolchains
> http://kegel.com/crosstool/
the Linux From Scratch site also has some useful discussion on
building toolchains:
http://www.linuxfromscratch.org/
rday
^ permalink raw reply
* Re: MPC8xx support in 2.6 and [PATCH] USB host controller selection...
From: Marcelo Tosatti @ 2005-10-28 15:21 UTC (permalink / raw)
To: David Jander, Greg KH; +Cc: linux-ppc-embedded
In-Reply-To: <200510271439.48990.david.jander@protonic.nl>
Greg, please refer to the end of the message.
On Thu, Oct 27, 2005 at 02:39:48PM +0200, David Jander wrote:
>
> Hi all,
>
> I am trying to figure out if kernel-2.6.x is already a (stable) option for
> MPC8xx processors. Any hints? experience?
We're using v2.6.11 on production (with a custom board). Has survived
internal QA procedure, which took a couple of months under various
stress tests.
> I just rsynced DENX's git tree (cg-clone will crash on a 404 error).
> Problems I have found until now:
>
> - Processor identification is still shady. Thanks to Marcello's patch
> yesterday, it now boots up without problems, but this definitely needs to be
> done. Who is working on this part?
Vitaly, can you please push your patch upstream now that v2.6.14 is out?
> - USB Kconfig file for 2.6 kernel is broken. It is not correct to assume that
> you either have a PCI interface or a processor with internal HCI. Proof: We
> have a board based on MPC852T (no internal UHCI) which can plug into an
> (optional) daughter board with a ISP1160 on it. See attached patch.
Is it driven by the UHCI driver?
>From http://www.semiconductors.philips.com/cgi-bin/pldb/pip/isp1160.html
The ISP1160 is an embedded Universal Serial Bus (USB) Host Controller
(HC) that complies with Universal Serial Bus Specification Rev. 2.0,
supporting data transfer at full-speed (12 Mbit/s) and low-speed (1.5
Mbit/s).
> Maybe the patch should be sent elsewere since it has not much to do with PPC,
> so can someone please tell me where?
I guess that you should have something like
config USB_ARCH_HAS_HCD
default y if USB_ARCH_HAS_OHCI
default y if USB_ARCH_HAS_UHCI
config USB_ARCH_UHCI
default y if 8xx
Greg?
> Greetings,
>
> --
> David Jander
> --- drivers/usb/Kconfig.old 2005-10-27 14:26:03.701868944 +0200
> +++ drivers/usb/Kconfig 2005-10-27 14:26:37.729695928 +0200
> @@ -4,37 +4,9 @@
>
> menu "USB support"
>
> -# Host-side USB depends on having a host controller
> -# NOTE: dummy_hcd is always an option, but it's ignored here ...
> -# NOTE: SL-811 option should be board-specific ...
> -config USB_ARCH_HAS_HCD
> - boolean
> - default y if USB_ARCH_HAS_OHCI
> - default y if ARM # SL-811
> - default PCI
> -
> -# many non-PCI SOC chips embed OHCI
> -config USB_ARCH_HAS_OHCI
> - boolean
> - # ARM:
> - default y if SA1111
> - default y if ARCH_OMAP
> - default y if ARCH_LH7A404
> - default y if ARCH_S3C2410
> - default y if PXA27x
> - # PPC:
> - default y if STB03xxx
> - default y if PPC_MPC52xx
> - default y if 440EP
> - # MIPS:
> - default y if SOC_AU1X00
> - # more:
> - default PCI
> -
> # ARM SA1111 chips have a non-PCI based "OHCI-compatible" USB host interface.
> config USB
> tristate "Support for Host-side USB"
> - depends on USB_ARCH_HAS_HCD
> ---help---
> Universal Serial Bus (USB) is a specification for a serial bus
> subsystem which offers higher speeds and more features than the
^ permalink raw reply
* Re: Kernel 2.6 on MPC8xx performance trouble...
From: Wolfgang Denk @ 2005-10-28 20:37 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200510281257.22650.david.jander@protonic.nl>
In message <200510281257.22650.david.jander@protonic.nl> you wrote:
>
> > What is 'a' and 'b'? The only other explanation I can see is that your
> > "Do something" is more memory heavy than you think - array calculations?
> > (Cache problems should probably give a worse result, but you could check
> > that those config registers are the same).
>
> They are just integers with fixed start values. These are in the loop, so it's
> not an empty loop and hopefully the compiler won't out-optimize it so easily
> (that is of course without specifying any optimization flags). Please don't
> tell me it's a lousy benchmark, because I already know that! Be it as lousy
> as it is, I shouldn't get _those_ results IMHO.
Indeed, you should not get such results. If you compare with the
lmbench results of our 2.4/2.6 comparison, you will notice that we
did NOT see such behaviour. There was a perfromnce degradation for
pure integer tests, due to increased system overhead, but far from a
factor of 2.
See http://www.denx.de/wiki/pub/Know/Linux24vs26/lmbench_results
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
A fanatic is a person who can't change his mind and won't change the
subject. - Winston Churchill
^ permalink raw reply
* Re: Kernel 2.6 on MPC8xx performance trouble...
From: Marcelo Tosatti @ 2005-10-28 15:30 UTC (permalink / raw)
To: David Jander; +Cc: linux-ppc-embedded
In-Reply-To: <200510280857.44625.david.jander@protonic.nl>
On Fri, Oct 28, 2005 at 08:57:44AM +0200, David Jander wrote:
>
> Hi all,
>
> Many people have said it before: 2.6 has a performance penalty specially for
> embdedded systems.
> But now that I have 2.6 running on our 100MHz MPC852T based board, I was
> shocked to see the result:
> The most simple task doing nothing but a closed loop of integer math runs at
> _half_ the speed compared to kernel 2.4.25!!!!!
David,
Do you have CONFIG_PIN_TLB enabled?
If you do, please patch this in:
http://www.kernel.org/git/?p=linux/kernel/git/marcelo/8xx-fixes;a=commitdiff;h=a41ba028534c45280170c05c23609ea84f34b38a
And select DEBUG_PIN_TLBIE.
^ permalink raw reply
* Re: Howto Cross Compile GCC to run on PPC Platform
From: Bryan O'Donoghue @ 2005-10-28 20:48 UTC (permalink / raw)
To: Peter Hanson; +Cc: Steven Blakeslee, linuxppc-embedded
In-Reply-To: <50e923300510281227i15609c9dt7778ecbe20920dfa@mail.google.com>
Peter Hanson wrote:
> On 10/28/05, Steven Blakeslee <BlakesleeS@embeddedplanet.com> wrote:
>
>>>get it to cross compile gcc (to run on ppc). Does anyone
>>>know of a good HowTo to do this?
>>
>>Karim Yaghmour's "Building Embedded Linux Systems"
>>
>>
>>
>>> I'm currently downloading the source distro of ELDK, so if
>>>it's already in there I'll find it, but if there is one
>>>elsewhere online please let me know.
>>
>>Very good, full of features.
>
>
> My favorite cross tool chain site:
>
> Building and Testing gcc/glibc cross toolchains
> http://kegel.com/crosstool/
>
> Look into Canadian crosses. At the very least you should find the
> discussion helpful.
I'd use the ELDK if I were you as an x86 hosted cross compiler, if only
because it makes sense in terms of compiling bootloader & kernel with
the same toolchain. Also, if memory serves the ELDK comes with a powerpc
gcc in the supplied ppc root file system.
Alternatively : you can use the uClibc toolchain, to generate a similar
setup.
Here's a script I've thrown together since I sometimes need to generate
gcc toolchains easily for various targets. I've tested it with arm and
powerpc and because, it might be useful to switch between c libraries. ymmv.
http://netsoc.dit.ie/~deckard/software/build_compiler.sh. This script is
based on some excellent documents that Red Hat produced.
http://sources.redhat.com/ml/crossgcc/2005-08/msg00114/l-cross-ltr.pdf
--
"Caveat Emptor" -- James T. Kirk, in no such episode
^ 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