* MPC8xx support in 2.6 and [PATCH] USB host controller selection...
From: David Jander @ 2005-10-27 12:39 UTC (permalink / raw)
To: linux-ppc-embedded
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
Hi all,
I am trying to figure out if kernel-2.6.x is already a (stable) option for
MPC8xx processors. Any hints? experience?
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?
- 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.
Maybe the patch should be sent elsewere since it has not much to do with PPC,
so can someone please tell me where?
Greetings,
--
David Jander
[-- Attachment #2: usb-hcd-selection.patch --]
[-- Type: text/x-diff, Size: 1111 bytes --]
--- 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: MPC8xx support in 2.6 and [PATCH] USB host controller selection...
From: Vitaly Bordug @ 2005-10-27 12:57 UTC (permalink / raw)
To: David Jander; +Cc: linux-ppc-embedded
In-Reply-To: <200510271439.48990.david.jander@protonic.nl>
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?
What option do you mean? The last kernel supports a number of 8xx, and I
have MPC885ADS and MPC866ADS run it without major problems.
> 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?
>
The fix is in the mm tree. And it has been submitted here as well btw.
> - 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.
>
> 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 linux-usb-devel@lists.sourceforge.net is the correct place to
issue this.
>
> Greetings,
>
>
>
> ------------------------------------------------------------------------
>
> --- 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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Sincerely,
Vitaly
^ permalink raw reply
* How the linux use BAT
From: Noah yan @ 2005-10-27 13:05 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
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?
Is kernel really use the segment MMU of the powerpc, I have an impression
that most kernel only use the page MMU?
Thanks in advance.
[-- Attachment #2: Type: text/html, Size: 973 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: only build idle_6xx for 6xx
From: Kumar Gala @ 2005-10-27 13:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Kumar Gala, linuxppc64-dev
In-Reply-To: <17248.45467.698310.551177@cargo.ozlabs.ibm.com>
On Oct 27, 2005, at 5:53 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>
>> For the current time idle_6xx only applies to 6xx ppc32 CPUs
>>
>
>
>> +extra-$(CONFIG_6xx) += idle_6xx.o
>>
>
>
>> -obj-$(CONFIG_PPC32) += entry_32.o idle_6xx.o setup_32.o
>> misc_32.o
>> +obj-$(CONFIG_PPC32) += entry_32.o setup_32.o misc_32.o
>>
>
> Why does idle_6xx.o become an extra- rather than an obj- ?
Because I copied and pasted the line from arch/ppc/kernel/Makefile w/
o paying any attention to it. I'll send a proper patch :)
(I'm really trying to see if you actually look at our patches or not :)
- kumar
^ permalink raw reply
* Re: MPC8xx support in 2.6 and [PATCH] USB host controller selection...
From: Wolfgang Denk @ 2005-10-27 13:47 UTC (permalink / raw)
To: David Jander; +Cc: linux-ppc-embedded
In-Reply-To: <200510271439.48990.david.jander@protonic.nl>
In message <200510271439.48990.david.jander@protonic.nl> you wrote:
>
> I am trying to figure out if kernel-2.6.x is already a (stable) option for
> MPC8xx processors. Any hints? experience?
> I just rsynced DENX's git tree (cg-clone will crash on a 404 error).
Make sure to use current versions of git resp. cogito.
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
Every program has at least one bug and can be shortened by at least
one instruction - from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.
^ permalink raw reply
* Board based on MPC7447 and MV64462
From: Ashish Bijlani @ 2005-10-27 13:17 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
Hi,
I've added platform support for a board based on MPC7447A and MV64462
Marvell Discovery III system controller. I modified code for Katana to make
it work for this board. The ethernet and serial are working fine but I don't
see anything in "lspci" output. Also I don't see timer in "cat
/proc/interrupts". Does anybody have any idea on this? Thanks in advance.
Thanks,
Ashish
[-- Attachment #2: Type: text/html, Size: 436 bytes --]
^ permalink raw reply
* [PATCH][UPDATED] powerpc: only build idle_6xx for 6xx
From: Kumar Gala @ 2005-10-27 13:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
For the current time idle_6xx only applies to 6xx ppc32 CPUs
Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
---
commit e3b3bc6d075bd1d07caa64bcaa3add128a0cb6f3
tree e41cfdec6b3565258cb5bee14078a23f8be3b6ff
parent 0f72dedad02fc2869ddc13ff2f6998ec7dfdcbc1
author Kumar K. Gala <kumar.gala@freescale.com> Thu, 27 Oct 2005 08:53:36 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 27 Oct 2005 08:53:36 -0500
arch/powerpc/kernel/Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -33,11 +33,12 @@ extra-y += vmlinux.lds
obj-y += process.o init_task.o time.o \
prom.o systbl.o traps.o setup-common.o
-obj-$(CONFIG_PPC32) += entry_32.o idle_6xx.o setup_32.o misc_32.o
+obj-$(CONFIG_PPC32) += entry_32.o setup_32.o misc_32.o
obj-$(CONFIG_PPC64) += setup_64.o misc_64.o
obj-$(CONFIG_PPC_OF) += prom_init.o
obj-$(CONFIG_MODULES) += ppc_ksyms.o
obj-$(CONFIG_BOOTX_TEXT) += btext.o
+obj-$(CONFIG_6xx) += idle_6xx.o
ifeq ($(CONFIG_PPC_ISERIES),y)
$(obj)/head_64.o: $(obj)/lparmap.s
^ permalink raw reply
* Re: MPC8xx support in 2.6 and [PATCH] USB host controller selection...
From: Jeff Angielski @ 2005-10-27 14:28 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: David Jander, linux-ppc-embedded
In-Reply-To: <20051027134735.8E7C6353E30@atlas.denx.de>
On Thu, 2005-10-27 at 15:47 +0200, Wolfgang Denk wrote:
> In message <200510271439.48990.david.jander@protonic.nl> you wrote:
> >
> > I am trying to figure out if kernel-2.6.x is already a (stable) option for
> > MPC8xx processors. Any hints? experience?
> > I just rsynced DENX's git tree (cg-clone will crash on a 404 error).
>
> Make sure to use current versions of git resp. cogito.
I get the same errors using using the latest versions: git version
0.99.8f and cogito-0.15. FWIW, the u-boot.git came down just fine.
> cg-clone http://www.denx.de/git/linux-2.6-denx.git linux-2.6-denx
defaulting to local storage area
10:24:51 URL:http://www.denx.de/git/linux-2.6-denx.git/HEAD [41/41] ->
"refs/heads/.origin-fetching" [1]
progress: 1 objects, 264 bytes
walk b2304e619029b177db18dc771f2b9ba8cd273b81
progress: 3 objects, 1180 bytes
walk cb7f6ec5c2d64db78984188461dc29b72e924180
progress: 4 objects, 1424 bytes
error: The requested URL returned error: 404
Getting pack list
error: The requested URL returned error: 404
Getting alternates list
error: Unable to find ca442d313d86dc67e0a2e5d584b465bd382cbf5c under
http://www.denx.de/git/linux-2.6-denx.git/
Cannot obtain needed blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c
while processing commit cb7f6ec5c2d64db78984188461dc29b72e924180.
cg-fetch: objects fetch failed
cg-clone: fetch failed
Jeff Angielski
The PTR Group
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Mark A. Greer @ 2005-10-27 18:17 UTC (permalink / raw)
To: Ashish Bijlani; +Cc: linuxppc-embedded
In-Reply-To: <ec55b17e0510270617k368b4555gf3f37e07cee3b4e6@mail.gmail.com>
On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote:
> Hi,
>
> I've added platform support for a board based on MPC7447A and MV64462
> Marvell Discovery III system controller. I modified code for Katana to make
> it work for this board. The ethernet and serial are working fine but I don't
> see anything in "lspci" output.
Do you have any pci devices? If not, then that's to be expected.
If you do, then you have something messed up in your code and they
aren't being found.
> Also I don't see timer in "cat /proc/interrupts".
Neither do I... :)
Mark
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Sven Luther @ 2005-10-27 18:49 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20051027181751.GD9628@mag.az.mvista.com>
On Thu, Oct 27, 2005 at 11:17:51AM -0700, Mark A. Greer wrote:
> On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote:
> > Hi,
> >
> > I've added platform support for a board based on MPC7447A and MV64462
> > Marvell Discovery III system controller. I modified code for Katana to make
> > it work for this board. The ethernet and serial are working fine but I don't
> > see anything in "lspci" output.
>
> Do you have any pci devices? If not, then that's to be expected.
> If you do, then you have something messed up in your code and they
> aren't being found.
They should at least shgow the northbridge pci ids, no ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Christoph Hellwig @ 2005-10-27 19:26 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Sven Luther
In-Reply-To: <20051025182434.GA13982@xyzzy.farnsworth.org>
> I don't think this is really dependent on PPC_MULTIPLATFORM,
> and the driver also supports 64460.
This is not a PCI driver so adding a device table is wrong.
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Sven Luther @ 2005-10-27 19:57 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Sven Luther, linuxppc-dev
In-Reply-To: <20051027192655.GA13945@lst.de>
On Thu, Oct 27, 2005 at 09:26:55PM +0200, Christoph Hellwig wrote:
> > I don't think this is really dependent on PPC_MULTIPLATFORM,
> > and the driver also supports 64460.
>
> This is not a PCI driver so adding a device table is wrong.
Sure, please provide us with a patch to add hotplug support to those platform
drivers who are not pci :)
In the meantime, this is no worse than how this was done previously, namely
having discover match the northbridge pci id.
Friendly,
Sven Luther
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Mark A. Greer @ 2005-10-27 20:04 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-embedded
In-Reply-To: <20051027184921.GA11742@localhost.localdomain>
On Thu, Oct 27, 2005 at 08:49:21PM +0200, Sven Luther wrote:
> On Thu, Oct 27, 2005 at 11:17:51AM -0700, Mark A. Greer wrote:
> > On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote:
> > > Hi,
> > >
> > > I've added platform support for a board based on MPC7447A and MV64462
> > > Marvell Discovery III system controller. I modified code for Katana to make
> > > it work for this board. The ethernet and serial are working fine but I don't
> > > see anything in "lspci" output.
> >
> > Do you have any pci devices? If not, then that's to be expected.
> > If you do, then you have something messed up in your code and they
> > aren't being found.
>
> They should at least shgow the northbridge pci ids, no ?
No b/c the regs for the bridge are not pci compliant so the bridge is
"excluded" or hidden from the generic pci code (which is where lspci
gets its info from). If it wasn't, the generic pci code would get
confused as would the bridge.
Mark
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Mark A. Greer @ 2005-10-27 20:11 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20051027200447.GC13847@mag.az.mvista.com>
On Thu, Oct 27, 2005 at 01:04:47PM -0700, Mark A. Greer wrote:
> On Thu, Oct 27, 2005 at 08:49:21PM +0200, Sven Luther wrote:
> > On Thu, Oct 27, 2005 at 11:17:51AM -0700, Mark A. Greer wrote:
> > > On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote:
> > > > Hi,
> > > >
> > > > I've added platform support for a board based on MPC7447A and MV64462
> > > > Marvell Discovery III system controller. I modified code for Katana to make
> > > > it work for this board. The ethernet and serial are working fine but I don't
> > > > see anything in "lspci" output.
> > >
> > > Do you have any pci devices? If not, then that's to be expected.
> > > If you do, then you have something messed up in your code and they
> > > aren't being found.
> >
> > They should at least shgow the northbridge pci ids, no ?
>
> No b/c the regs for the bridge are not pci compliant so the bridge is
> "excluded" or hidden from the generic pci code (which is where lspci
> gets its info from). If it wasn't, the generic pci code would get
> confused as would the bridge.
Actually, I guess this is more to hide the bridge from the pci_auto when
it walks the pci buses. If the pci resources are already allocated
correctly (as in pegasos?) it may not confuse the generic pci code.
Even if it doesn't get confused, its by luck. The bridge's pci regs
are NOT pci compliant and, IMHO, its iffy to assume that things woun't
get messed up.
Mark
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Sven Luther @ 2005-10-27 20:30 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20051027200447.GC13847@mag.az.mvista.com>
On Thu, Oct 27, 2005 at 01:04:47PM -0700, Mark A. Greer wrote:
> On Thu, Oct 27, 2005 at 08:49:21PM +0200, Sven Luther wrote:
> > On Thu, Oct 27, 2005 at 11:17:51AM -0700, Mark A. Greer wrote:
> > > On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote:
> > > > Hi,
> > > >
> > > > I've added platform support for a board based on MPC7447A and MV64462
> > > > Marvell Discovery III system controller. I modified code for Katana to make
> > > > it work for this board. The ethernet and serial are working fine but I don't
> > > > see anything in "lspci" output.
> > >
> > > Do you have any pci devices? If not, then that's to be expected.
> > > If you do, then you have something messed up in your code and they
> > > aren't being found.
> >
> > They should at least shgow the northbridge pci ids, no ?
>
> No b/c the regs for the bridge are not pci compliant so the bridge is
> "excluded" or hidden from the generic pci code (which is where lspci
> gets its info from). If it wasn't, the generic pci code would get
> confused as would the bridge.
The pegasos OF allows access to the pci config area through rtas, and those
call filter out any dangerous accesses. And since you didn't know about rtas,
i will explain for others who may be in other cases.
RTAS is a OpenFirmware/CHRP extension (RunTimeAbstraction..., not sure about
the S), which provides a set of methods which will run even when linux has
taken over and overwritten the firmware, providing stuff like halt/reset,
pci-read|write-config, nvram-fetch|store, clock access functions, ...
Friendly,
Sven Luther
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Sven Luther @ 2005-10-27 20:38 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20051027201105.GD13847@mag.az.mvista.com>
On Thu, Oct 27, 2005 at 01:11:05PM -0700, Mark A. Greer wrote:
> Actually, I guess this is more to hide the bridge from the pci_auto when
> it walks the pci buses. If the pci resources are already allocated
> correctly (as in pegasos?) it may not confuse the generic pci code.
> Even if it doesn't get confused, its by luck. The bridge's pci regs
> are NOT pci compliant and, IMHO, its iffy to assume that things woun't
> get messed up.
As said, the pci access rtas functions will stop any access to the non-pci
compliant regs.
Friendly,
Sven Luther
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Mark A. Greer @ 2005-10-27 20:47 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-embedded
In-Reply-To: <20051027203017.GA13787@localhost.localdomain>
All,
For the record, Sven, Matt Porter, and I talked about this some more on
IRC. I think we agreed that the best solution would be to register a
pci quirk for the bad regs and no longer hide the bridge.
Anyone think that's a bad idea?
Mark
^ permalink raw reply
* Re: MPC8xx support in 2.6 and [PATCH] USB host controller selection...
From: Wolfgang Denk @ 2005-10-27 21:08 UTC (permalink / raw)
To: jeff; +Cc: David Jander, linux-ppc-embedded
In-Reply-To: <1130423323.8477.24.camel@nighteyes.site>
In message <1130423323.8477.24.camel@nighteyes.site> you wrote:
>
> > > I just rsynced DENX's git tree (cg-clone will crash on a 404 error).
> >
> > Make sure to use current versions of git resp. cogito.
>
> I get the same errors using using the latest versions: git version
> 0.99.8f and cogito-0.15. FWIW, the u-boot.git came down just fine.
...
> Cannot obtain needed blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c
> while processing commit cb7f6ec5c2d64db78984188461dc29b72e924180.
> cg-fetch: objects fetch failed
> cg-clone: fetch failed
Don't know what that means. Accessing the tree using rsync://...
works fine.
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
An expert is a person who avoids the small errors while sweeping on
to the grand fallacy.
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Nicolas DET @ 2005-10-27 21:14 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Sven Luther, linuxppc-dev
In-Reply-To: <20051027192655.GA13945@lst.de>
Le jeudi 27 octobre 2005 à 21:26 +0200, Christoph Hellwig a écrit :
> > I don't think this is really dependent on PPC_MULTIPLATFORM,
> > and the driver also supports 64460.
>
> This is not a PCI driver so adding a device table is wrong.
>
I think we all agree ;-).
The point is to have a 'quick' way to get this module automagicly loaded
until we get a proper super duper OFW devices hotplug or whatsoeever
support.
Regards
^ permalink raw reply
* Re: How the linux use BAT
From: Benjamin Herrenschmidt @ 2005-10-27 22:37 UTC (permalink / raw)
To: Noah yan; +Cc: linuxppc-dev
In-Reply-To: <59521b110510270605k6e098826w2d37c50e82ddd758@mail.gmail.com>
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.
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
* NFS can not mount (linuxppc2.2.4 mpc5200 lxt971)
From: ÏÄÓê @ 2005-10-28 2:54 UTC (permalink / raw)
To: linuxppc-embedded
I have ported linuxppc2.2.4 to my board based on ICECUBE.
One board can not mount NFS(eth0 = lxt971), Message as follow:
eth0: config: auto-negotiation on, 100HDX, 10HDX.
IP-Config: Complete:
device=eth0, addr=198.87.102.211, mask=255.255.255.0, gw=198.87.102.140,
host=oops, domain=, nis-domain=(none),
bootserver=198.87.102.140, rootserver=198.98.102.140, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 198.98.102.140
eth0: status: link up, Unknown speed/duplex, auto-negotiation complete, remote f
ault.
portmap: server 198.98.102.140 not responding, timed out
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 198.98.102.140
portmap: server 198.98.102.140 not responding, timed out
Root-NFS: Unable to get mountd port number from server, using default
mount: server 198.98.102.140 not responding, timed out
Root-NFS: Server returned error -5 while mounting /opt/eldk/ppc_82xx
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00
But i can ping the board from my PC:
Pinging 198.87.102.211 with 32 bytes of data:
Reply from 198.87.102.211: bytes=32 time<10ms TTL=64
Reply from 198.87.102.211: bytes=32 time<10ms TTL=64
Reply from 198.87.102.211: bytes=32 time<10ms TTL=64
Reply from 198.87.102.211: bytes=32 time<10ms TTL=64
The other boards using the same program can mount NFS on the same server.
What part of this board might be wrong?
Thanks!
^ permalink raw reply
* Kernel 2.6 on MPC8xx performance trouble...
From: David Jander @ 2005-10-28 6:57 UTC (permalink / raw)
To: linux-ppc-embedded
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??
Greetings,
--
David Jander
^ permalink raw reply
* SMP Design
From: Suresh Chandra Mannava @ 2005-10-28 7:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am working on a symmetric multiprocessing(SMP) based board design.
Now, I am into feasibility analysis.
Here are my queries
What qualifies a CPU to be capable of SMP?
Hardware cache coherency
test-and-set, compare-and-swap or load-link/ store-conditional
instructions.
Unique Id(read this in Intel MP specs) Is it required for
powerpc-smp?
CPU-local interrupt controller (intel specific) Is it required
for powerpc-smp
OpenPIC, interrupt routing
what are the other points that support SMP for a CPU. I read that ppc
603 won't support pure SMP.
I am searching for the "considerations for SMP design using powerpc
processors"
please provide pointers for the same.
Can I find any reference design for SMP boards? I am interested
architecture part, interrupt routing and OpenPIC stuff.
I find it hard to find information on SMP board design.
Waiting for your response.
Thanks and Regards,
Suresh Chandra Mannava.
^ permalink raw reply
* Re: NFS can not mount (linuxppc2.2.4 mpc5200 lxt971)
From: Esben Nielsen @ 2005-10-28 7:49 UTC (permalink / raw)
To: ÏÄÓê; +Cc: linuxppc-embedded
In-Reply-To: <200510281054.AA34079032@NARI-RELAYS.COM>
On Fri, 28 Oct 2005, =CF=C4=D3=EA wrote:
> I have ported linuxppc2.2.4 to my board based on ICECUBE.
> One board can not mount NFS(eth0 =3D lxt971), Message as follow:
>=20
> eth0: config: auto-negotiation on, 100HDX, 10HDX.
> IP-Config: Complete:
> device=3Deth0, addr=3D198.87.102.211, mask=3D255.255.255.0, gw=3D19=
8.87.102.140,
> host=3Doops, domain=3D, nis-domain=3D(none),
> bootserver=3D198.87.102.140, rootserver=3D198.98.102.140, rootpath=
=3D
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Looking up port of RPC 100003/2 on 198.98.102.140
> eth0: status: link up, Unknown speed/duplex, auto-negotiation complete, r=
emote f
> ault.
> portmap: server 198.98.102.140 not responding, timed out
> Root-NFS: Unable to get nfsd port number from server, using default
> Looking up port of RPC 100005/1 on 198.98.102.140
> portmap: server 198.98.102.140 not responding, timed out
> Root-NFS: Unable to get mountd port number from server, using default
> mount: server 198.98.102.140 not responding, timed out
> Root-NFS: Server returned error -5 while mounting /opt/eldk/ppc_82xx
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "nfs" or 02:00
> Please append a correct "root=3D" boot option
> Kernel panic: VFS: Unable to mount root fs on 02:00
>=20
> But i can ping the board from my PC:
>=20
> Pinging 198.87.102.211 with 32 bytes of data:
>=20
> Reply from 198.87.102.211: bytes=3D32 time<10ms TTL=3D64
> Reply from 198.87.102.211: bytes=3D32 time<10ms TTL=3D64
> Reply from 198.87.102.211: bytes=3D32 time<10ms TTL=3D64
> Reply from 198.87.102.211: bytes=3D32 time<10ms TTL=3D64
>=20
>=20
> The other boards using the same program can mount NFS on the same server.
>=20
> What part of this board might be wrong?=20
>=20
I can't tell you what is wrong, but I have seen the same error:
It works fine on the Lite5200 proto board but not on our custom board :-(
Esben
> Thanks!
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* 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
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