* 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
* Re: MPC8xx support in 2.6 and [PATCH] USB host controller selection...
From: Greg KH @ 2005-10-28 20:43 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: David Jander, linux-ppc-embedded
In-Reply-To: <20051028152109.GB18915@logos.cnet>
On Fri, Oct 28, 2005 at 01:21:09PM -0200, Marcelo Tosatti wrote:
> Greg, please refer to the end of the message.
> > - 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.
Then please send the proper patch to the linux-usb-devel mailing list.
> Is it driven by the UHCI driver?
It shouldn't be :)
> >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).
We already have a driver for this device in the kernel tree, right?
> > 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?
I don't understand what you are trying to fix up here. What is wrong
with the current checks? If your arch/board has support for the 1160
and we have the Kconfig set wrong for that, we can easily change it.
thanks,
greg k-h
^ permalink raw reply
* Re: Howto Cross Compile GCC to run on PPC Platform
From: Wolfgang Denk @ 2005-10-28 20:51 UTC (permalink / raw)
To: Jeff Stevens; +Cc: linuxppc-embedded
In-Reply-To: <20051028155510.17662.qmail@web33413.mail.mud.yahoo.com>
In message <20051028155510.17662.qmail@web33413.mail.mud.yahoo.com> you 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
It is.
> is one elsewhere online please let me know.
Note that released versions of the ELDK (up to and including ELDK
3.1.1) require a RedHat-7.3 build host. Don't waste your time on
trying later Linux distros ;-)
Current top-of-tree in CVS should build under Fedora Core 4; but this
code has not been released yet - it is beta quality only.
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
"Any excuse will serve a tyrant." - Aesop
^ permalink raw reply
* memcpy for unaligned memory regions
From: Olaf Hering @ 2005-10-28 21:42 UTC (permalink / raw)
To: linuxppc-dev
The vmlinux.coff is constantly crashing for me, depending on the size
and location of the vmlinux.gz and the ramdisk. The 601 can not handle
unaligned memory access that cross a page boundary (or whatever).
So I tweaked the memcpy.S from arch/ppc64/boot to deal with this.
Does this look ok?
.globl memmove
memmove:
cmpwi 0,r5,0
beqlr
cmplw 0,r3,r4
bgt backwards_memcpy
/* fall through */
.globl memcpy
memcpy:
cmpwi 0,r5,0
beqlr
andi. r0,r4,3 /* get src word aligned */
beq 20f
10: subfic r0,r0,4
cmpd r0,r5
blt 11f
mr r0,r5
11: mtctr r0
12: lbz r7,0(r4)
stb r7,0(r3)
addi r4,r4,1
addi r3,r3,1
bdnz 12b
subf. r5,r0,r5
beqlr
20: andi. r0,r3,3 /* get dest word aligned */
beq 30f
subfic r0,r0,4
cmpd r0,r5
blt 21f
mr r0,r5
21: mtctr r0
22: lbz r7,0(r4)
stb r7,0(r3)
addi r4,r4,1
addi r3,r3,1
bdnz 22b
subf. r5,r0,r5
beqlr
andi. r0,r4,3 /* get src word aligned */
bne 10b
30:
rlwinm. r7,r5,32-3,3,31 /* r7 = r5 >> 3 */
addi r6,r3,-4
addi r4,r4,-4
beq 32f /* if less than 8 bytes to do */
mtctr r7
31: lwz r7,4(r4)
lwzu r8,8(r4)
stw r7,4(r6)
stwu r8,8(r6)
bdnz 31b
andi. r5,r5,7
32: cmplwi 0,r5,4
blt 33f
lwzu r0,4(r4)
addi r5,r5,-4
stwu r0,4(r6)
33: cmpwi 0,r5,0
beqlr
mtctr r5
addi r4,r4,3
addi r6,r6,3
34: lbzu r0,1(r4)
stbu r0,1(r6)
bdnz 34b
blr
.globl backwards_memcpy
backwards_memcpy:
add r6,r3,r5
add r4,r4,r5
andi. r0,r4,3 /* get src word aligned */
beq 20f
10: cmpd r0,r5
blt 11f
mr r0,r5
11: mtctr r0
12: lbzu r7,-1(r4)
stbu r7,-1(r6)
bdnz 12b
subf. r5,r0,r5
beqlr
20: andi. r0,r6,3 /* get dest word aligned */
beq 30f
cmpd r0,r5
blt 21f
mr r0,r5
21: mtctr r0
22: lbzu r7,-1(r4)
stbu r7,-1(r6)
bdnz 22b
subf. r5,r0,r5
beqlr
andi. r0,r4,3 /* get src word aligned */
bne 10b
30:
rlwinm. r7,r5,32-3,3,31 /* r7 = r5 >> 3 */
beq 32f
mtctr r7
31: lwz r7,-4(r4)
lwzu r8,-8(r4)
stw r7,-4(r6)
stwu r8,-8(r6)
bdnz 31b
andi. r5,r5,7
32: cmplwi 0,r5,4
blt 33f
lwzu r0,-4(r4)
subi r5,r5,4
stwu r0,-4(r6)
33: cmpwi 0,r5,0
beqlr
mtctr r5
34: lbzu r0,-1(r4)
stbu r0,-1(r6)
bdnz 34b
blr
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: How the linux use BAT
From: Benjamin Herrenschmidt @ 2005-10-28 22:39 UTC (permalink / raw)
To: Noah yan; +Cc: linuxppc-dev
In-Reply-To: <59521b110510280856y9c39f4by54cadd01830ded07@mail.gmail.com>
On Fri, 2005-10-28 at 10:56 -0500, Noah yan wrote:
>
> 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.
No, there is no relationship. The kernel just sets up enough segments to
map the entire process address space, this is irrelevant to the actual
program sections.
> 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.
The segmentation mecanism on PowerPC is slightly different. We change
segments when context switching as they contain the "vsid" which acts as
a kind of context ID, thus we can keep entry for more than one
context/process in the hash table, we don't have to flush it on context
switches.
> 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.
>
>
>
^ permalink raw reply
* Re: Patches for 2.6.15
From: Arnd Bergmann @ 2005-10-28 23:11 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: akpm, linuxppc-dev
In-Reply-To: <17250.8725.358204.62510@cargo.ozlabs.ibm.com>
On Freedag 28 Oktober 2005 15:05, 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. =A0I am planning to ask Linus to pull the powerpc-merge tree
> shortly, and that will probably break your patches.
Out of my spufs patches, I'd like to have at least the reservation
for my two system call numbers in there so we don't get any conflicts
on that front. The patch follows in another mail.
=46rom my point of view, the spufs itself could go in at this point,
but I have the feeling that the real concerns from other people
will come up at the moment that I post them for inclusion.=20
Andrew, are you ok with including spufs in -mm when the merge
tree is upstream?
> 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.
Ok, I'll do a new patch to move over the BPA files then to get
my stuff out of the way ASAP.
Arnd <><
^ permalink raw reply
* [PATCH] reserve syscall numbers for Cell
From: Arnd Bergmann @ 2005-10-28 23:16 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: linuxppc-dev
In-Reply-To: <200510290111.13867.arnd@arndb.de>
This creates two powerpc specific dummy system calls that will
later be used on the Cell platform to manage SPUs.
Reserve the system call numbers now so we don't accidentally
use the same numbers for different system calls.
Signed-off-by: Arnd Bergmann <arndb@de.ibm.com>
---
Please apply to merge tree
--- a/kernel/sys_ni.c 2005-10-29 00:46:21.000000000 +0200
+++ b/kernel/sys_ni.c 2005-10-29 00:47:37.000000000 +0200
@@ -90,3 +90,5 @@
cond_syscall(sys32_ipc);
cond_syscall(sys32_sysctl);
cond_syscall(ppc_rtas);
+cond_syscall(sys_spu_run);
+cond_syscall(sys_spu_create);
--- a/arch/powerpc/kernel/systbl.S 2005-10-29 00:39:49.000000000 +0200
+++ b/arch/powerpc/kernel/systbl.S 2005-10-29 00:44:48.000000000 +0200
@@ -319,3 +319,5 @@
SYSCALL(inotify_init)
SYSCALL(inotify_add_watch)
SYSCALL(inotify_rm_watch)
+SYSCALL(spu_run)
+SYSCALL(spu_create)
--- a/include/asm-powerpc/unistd.h 2005-10-29 00:34:40.000000000 +0200
+++ b/include/asm-powerpc/unistd.h 2005-10-29 00:35:52.000000000 +0200
@@ -297,7 +297,9 @@
#define __NR_inotify_add_watch 276
#define __NR_inotify_rm_watch 277
-#define __NR_syscalls 278
+#define __NR_spu_run 278
+#define __NR_spu_create 279
+#define __NR_syscalls 280
#ifdef __KERNEL__
#define __NR__exit __NR_exit
^ 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