* Re: [PATCH 3/5 v2] Add the platform device support with RapidIO to MPC8641HPCN platform.
From: Segher Boessenkool @ 2007-06-28 18:26 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus, linux-kernel, Zhang Wei-r63237
In-Reply-To: <200706281647.57408.arnd@arndb.de>
> Of course, looking at the device tree, rapidio is a device, not a bus,
> because it does not have a device_type and it does not have any
> children
> of its own.
It's a device _of course_, but it's also a bus parent, since
it has a "#address-cells" not equal to zero (and, if this used
real OF, it would have decode-unit and encode-unit methods).
A quite empty bus perhaps heh (in this device tree, anyway).
Segher
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Guennadi Liakhovetski @ 2007-06-28 19:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18051.22185.374607.755419@cargo.ozlabs.ibm.com>
On Thu, 28 Jun 2007, Paul Mackerras wrote:
> Guennadi Liakhovetski writes:
>
> > These two i2c patches:
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
> >
> > also would be nice to get in, although, they only make sense with an ack
> > from Scott Wood and another patch from him, as explained in links above...
>
> Looks OK, but the first of those two patches doesn't have a
> Signed-off-by: line, and the description is not suitable.
>
> Please repost that patch with a nice description that describes what
> the patch does and why, without references to other web pages. You
> don't need to describe what is different from previous patches or who
> suggested those changes.
Sure, no problem, will repost with a description and a Signed-off-by...
but, not giving Scott Wood credit for that patch doesn't seem right.
Scott, is it ok with you if I repost that patch with your "Signed-off-by"
first and mine second? And, Paul, as Scott noticed in another email and as
I mentioned in the above post too, we also need this one, please:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036333.html
As soon as we clarify these 2, I'll repost.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* cuImage question
From: Bizhan Gholikhamseh (bgholikh) @ 2007-06-28 21:54 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
Hi All,
I am kind of new to the concept of "cuImage" and I am not able to find
any info on the net(?).
We are using older version of the uboot: 1.1.2. I have compiled the
latest kernel from git tree for
MPC8541E from freescale.
I would appreciate any hints on how to use 'cuImage" to load this image
with our legacy uboot version?
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1452 bytes --]
^ permalink raw reply
* mpc8270 & Intel 82551ER on 2.6.17.14
From: Nicholas Hickman @ 2007-06-28 22:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3417 bytes --]
I am having trouble getting two 82551ER Ethernet controllers running in
Linux. I am able to scan the PCI bus and see the devices and I was even
able to program the EEPROM from U-boot.
In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c. I've
been using the e100 drive that comes with the 2.6.17.14 kernel and have
also tried the driver directly from Intel. Both give the same results.
The PCI scan shows the correct output for how the device should be
configured.
The situation is when I use the ethtool with the driver loaded and eth0
not configured with ifconfig I get this:
SCB Status Word (Lower Word) 0x0000
RU Status: Idle
CU Status: Idle
---- Interrupts Pending ----
Flow Control Pause: no
Early Receive: no
Software Generated Interrupt: no
MDI Done: no
RU Not In Ready State: no
CU Not in Active State: no
RU Received Frame: no
CU Completed Command: no
SCB Command Word (Upper Word) 0x0100
RU Command: No Command
CU Command: No Command
Software Generated Interrupt: no
---- Interrupts Masked ----
ALL Interrupts: yes
Flow Control Pause: no
Early Receive: no
RU Not In Ready State: no
CU Not in Active State: no
RU Received Frame: no
CU Completed Command: no
MDI/MDI-X Status: MDI
With eth0 configured using the command "ifconfig eth0 192.168.1.7
netmask 255.255.255.0 up" I get this:
SCB Status Word (Lower Word) 0x6450
RU Status: Ready
CU Status: Suspended
---- Interrupts Pending ----
Flow Control Pause: no
Early Receive: no
Software Generated Interrupt: yes
MDI Done: no
RU Not In Ready State: no
CU Not in Active State: yes
RU Received Frame: yes
CU Completed Command: no
SCB Command Word (Upper Word) 0x0000
RU Command: No Command
CU Command: No Command
Software Generated Interrupt: no
---- Interrupts Masked ----
ALL Interrupts: no
Flow Control Pause: no
Early Receive: no
RU Not In Ready State: no
CU Not in Active State: no
RU Received Frame: no
CU Completed Command: no
MDI/MDI-X Status: MDI
If I issue a PING out of the port and sniff the traffic on the
destination PC I see the ARP requests and I send the reply, but the
embedded machine sees nothing. If I use ethtool or even ifconfig to
view the statistics on the port they both show that there are no packets
in or out.
I have no idea where to go with this. It seems like the PCI bus is
working, but possibly not the Interrupt handler.
Nicholas Hickman
Applications Engineer
DTech Labs, Inc.
[-- Attachment #2: Type: text/html, Size: 9048 bytes --]
^ permalink raw reply
* Re: PCI IO range limitation
From: Matt Sealey @ 2007-06-28 23:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <1183052634.5521.284.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
>> Hi,
>>
>> Trying to change PCI IO window base for 52xx target I found that
>> we are pretty much limited to a "0" offset only.
>
> We just fixed that for 64 bits but 32 bits still has the limitation.
> Note that it's not a very good idea to have your IO range at !0 if
> you're going to use anything ISA-like, such as a VGA video card or other
> legacy devices behind a PCI southbridge or SuperIO.
The chances of that on an MPC52xx platform are practically zero, aren't
they?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: PCI IO range limitation
From: Benjamin Herrenschmidt @ 2007-06-29 0:13 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <46844692.1040804@genesi-usa.com>
On Fri, 2007-06-29 at 00:38 +0100, Matt Sealey wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
> >> Hi,
> >>
> >> Trying to change PCI IO window base for 52xx target I found that
> >> we are pretty much limited to a "0" offset only.
> >
> > We just fixed that for 64 bits but 32 bits still has the limitation.
> > Note that it's not a very good idea to have your IO range at !0 if
> > you're going to use anything ISA-like, such as a VGA video card or other
> > legacy devices behind a PCI southbridge or SuperIO.
>
> The chances of that on an MPC52xx platform are practically zero, aren't
> they?
Euh... don't you use VGA video cards on Efika ? :-)
Ben.
^ permalink raw reply
* Re: cuImage question
From: Kumar Gala @ 2007-06-29 3:14 UTC (permalink / raw)
To: Bizhan Gholikhamseh; +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A436@xmb-sjc-212.amer.cisco.com>
On Jun 28, 2007, at 4:54 PM, Bizhan Gholikhamseh ((bgholikh)) wrote:
> Hi All,
> I am kind of new to the concept of "cuImage" and I am not able to
> find any info on the net(?).
>
> We are using older version of the uboot: 1.1.2. I have compiled the
> latest kernel from git tree for
> MPC8541E from freescale.
>
> I would appreciate any hints on how to use 'cuImage" to load this
> image with our legacy uboot version?
Take a look at arch/powerpc/boot/ and the Kconfig DEVICE_TREE option.
- k
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Kumar Gala @ 2007-06-29 3:15 UTC (permalink / raw)
To: Erik Christiansen; +Cc: linuxppc-embedded
In-Reply-To: <20070628083624.GE8794@dd.nec.com.au>
On Jun 28, 2007, at 3:36 AM, Erik Christiansen wrote:
> On Thu, Jun 28, 2007 at 05:44:30PM +1000, Erik Christiansen wrote:
>> Encountering a kernel build error with ARCH=ppc, after configuring
>> as much as
>> possible for MPC8248, I've just tried ARCH=powerpc on
>> linux-2.6.21.5, with this
>> slightly scary result:
>
> Oh dear. Please excuse the noise. That was clearly acute lack of
> familiarity with menuconfig. <blush>
>
> Minus fingerfumbling, ARCH=powerpc starts to build, before coughing
> up a
> bunch of compiler errors:
>
> cpm2_common.c:63: error: 'CPM_MAP_ADDR' undeclared
>
> Is that due to this patch not being accepted?:
> http://patchwork.ozlabs.org/linuxppc/patch?id=8891
>
> If the patch's "State Superseded" means something else fixes the build
> failure, then how could I lay my grubby paws on that little gem?
It probably means there was a newer version of the patch w/changes
made to it based on feedback.
- k
^ permalink raw reply
* RE: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Zhang Wei-r63237 @ 2007-06-29 4:01 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <5f0438212493766009684d63e41c85cc@kernel.crashing.org>
Hi, Segher,=20
=20
> > + - #address-cells : Address representation for=20
> "rapidio" devices.
> > + This field represents the number of cells needed to represent
> > + the RapidIO address of the registers. For=20
> supporting more than
> > + 32-bits RapidIO address, this field should be <2>.
> > + See 1) above for more details on defining #address-cells.
>=20
> What does the RapidIO standard say about number of address
> bits? You want to follow that, so all RapidIO devices can
> use the same #address-cells, not just the FSL ones. Also,
> are there different kinds of address spaces on the bus, or
> is it just one big memory-like space?
>=20
>=20
I've checked the specification of RapidIO. The supporting of RapidIO
extended address modes are 66, 50 and 34 bit.
The Freescale's silicons is only support 34 bit address now.
Do you mean I should not use words -- 'should be <2>'?
The #address-cells should be assigned according the address mode
supported by silicon.
Thanks!
Wei.
^ permalink raw reply
* Please pull from 'for_paulus' branch
From: Kumar Gala @ 2007-06-29 5:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for_paulus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_paulus
to receive the following updates:
arch/powerpc/Kconfig | 6
arch/powerpc/Makefile | 19
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 99 +++-
arch/powerpc/kernel/Makefile | 2
arch/powerpc/kernel/pci-common.c | 454 ++++++++++++++++++++
arch/powerpc/kernel/pci_32.c | 476 ----------------------
arch/powerpc/kernel/pci_64.c | 391 ------------------
arch/powerpc/kernel/ppc_ksyms.c | 4
arch/powerpc/platforms/4xx/Kconfig | 11
arch/powerpc/platforms/52xx/Kconfig | 2
arch/powerpc/platforms/52xx/efika.c | 9
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 18
arch/powerpc/platforms/82xx/Kconfig | 3
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 17
arch/powerpc/platforms/83xx/Kconfig | 8
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 7
arch/powerpc/platforms/83xx/mpc832x_mds.c | 7
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 7
arch/powerpc/platforms/83xx/mpc834x_itx.c | 7
arch/powerpc/platforms/83xx/mpc834x_mds.c | 7
arch/powerpc/platforms/83xx/mpc836x_mds.c | 7
arch/powerpc/platforms/83xx/mpc83xx.h | 6
arch/powerpc/platforms/83xx/pci.c | 18
arch/powerpc/platforms/85xx/Kconfig | 5
arch/powerpc/platforms/85xx/mpc85xx.h | 2
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 10
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 17
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 7
arch/powerpc/platforms/85xx/pci.c | 11
arch/powerpc/platforms/86xx/Kconfig | 3
arch/powerpc/platforms/86xx/mpc86xx.h | 11
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 12
arch/powerpc/platforms/86xx/pci.c | 67 ++-
arch/powerpc/platforms/Kconfig | 24 +
arch/powerpc/platforms/Kconfig.cputype | 306 ++++++++++++--
arch/powerpc/platforms/cell/Kconfig | 1
arch/powerpc/platforms/celleb/Kconfig | 1
arch/powerpc/platforms/chrp/Kconfig | 1
arch/powerpc/platforms/chrp/Makefile | 3
arch/powerpc/platforms/chrp/pci.c | 7
arch/powerpc/platforms/embedded6xx/Kconfig | 5
arch/powerpc/platforms/embedded6xx/holly.c | 2
arch/powerpc/platforms/embedded6xx/linkstation.c | 10
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 9
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.h | 5
arch/powerpc/platforms/iseries/pci.c | 2
arch/powerpc/platforms/maple/Kconfig | 1
arch/powerpc/platforms/maple/pci.c | 6
arch/powerpc/platforms/pasemi/Kconfig | 1
arch/powerpc/platforms/pasemi/pci.c | 4
arch/powerpc/platforms/powermac/Kconfig | 2
arch/powerpc/platforms/powermac/pci.c | 14
arch/powerpc/platforms/ps3/Kconfig | 1
arch/powerpc/sysdev/Makefile | 3
arch/powerpc/sysdev/fsl_pcie.c | 171 -------
arch/powerpc/sysdev/indirect_pci.c | 44 +-
arch/powerpc/sysdev/mv64x60_pci.c | 7
arch/powerpc/sysdev/tsi108_pci.c | 10
arch/ppc/syslib/Makefile | 1
arch/ppc/syslib/indirect_pci.c | 134 ++++++
include/asm-powerpc/machdep.h | 2
include/asm-powerpc/mpc86xx.h | 6
include/asm-powerpc/pci-bridge.h | 129 ++++-
include/asm-powerpc/pci.h | 7
64 files changed, 1299 insertions(+), 1350 deletions(-)
Arnd Bergmann (7):
[POWERPC] move 82xx/83xx/86xx Kconfig options to platform selection
[POWERPC] autoselect optimal -mcpu= flag by platform
[POWERPC] rename add_bridge to avoid namespace clashes
[POWERPC] mpc82xx_ads build fix
[POWERPC] kill isa_{io,mem}_base definitions for !PCI
[POWERPC] fix building without PCI
[POWERPC] disallow building powermac and tsi108 without PCI
Kumar Gala (18):
[POWERPC] Remove set_cfg_type for PCI indirect users that don't need it
[POWERPC] 52xx: Remove support for PCI bus_offset
[POWERPC] Pass the pci_controller into pci_exclude_device
[POWERPC] Remove hack to determine the 2nd PHBs bus number
[POWERPC] Remove bus_offset in places its not really used
[POWERPC] Added self_busno to indicate which bus number the PHB is
[POWERPC] Removed remnants of bus_offset
[POWERPC] Added indirect_type to handle variants of PCI ops
[POWERPC] 86xx: Workaround PCI_PRIMARY_BUS usage
[POWERPC] Merge asm-ppc/pci-bridge.h into asm-power/pci-bridge.h
[POWERPC] Remove local_number from pci_controller
[POWERPC] Removed dead code related to PCI on ppc32
[POWERPC] Use global_number in ppc32 pci_controller
[POWERPC] Merge ppc32 and ppc64 pcibios_alloc_controller() prototypes
[POWERPC] Move pci_bus_to_hose users to pci_bus_to_host
[POWERPC] Move common PCI code out of pci_32/pci_64
[POWERPC] Use ppc64 style list management for pci_controller on ppc32
[POWERPC] Add copyright header to pci-common.c based on pci_{32,64}.c
Wade Farnsworth (1):
[POWERPC] 86xx: Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
York Sun (1):
[POWERPC] Let subordinate transparent bridges be transparent.
Zhang Wei (4):
[POWERPC] Remove PCI-e errata for MPC8641 silicon ver 1.0
[POWERPC] 86xx: Avoid system halt if link training isn't at least L0.
[POWERPC] MPC8641HPCN: Set IDE in ULI1575 to not native mode.
[POWERPC] 86xx: Created quirk_fsl_pcie_transparent() to initialize bridge resources.
^ permalink raw reply
* Re: [patch 2/9] autoselect optimal -mcpu= flag by platform
From: Paul Mackerras @ 2007-06-29 5:58 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev
In-Reply-To: <20070616000618.314570319@arndb.de>
arnd@arndb.de writes:
> +config PPC_CPU_SELECTION
> + bool "Advanced CPU selection"
Please provide some reasonable help for this option. As it is at the
moment, I get asked whether I want "Advanced CPU selection" - whatever
that is - and as a user I have no clue whether I want it or not. The
prompt is pretty uninformative. Do I want to be able to select an
advanced CPU? Well I suppose I do - who would want to select a
retarded CPU? - but that's presumably not what the question's about.
Paul.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Paul Mackerras @ 2007-06-29 6:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <Pine.LNX.4.64.0706290023590.15748@blarg.am.freescale.net>
Kumar Gala writes:
> Please pull from 'for_paulus' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_paulus
Unfortunately with those commits I get this when compiling for a
64-bit target:
{standard input}: Assembler messages:
{standard input}:668: Error: Unrecognized opcode: `sldi'
{standard input}:676: Error: Unrecognized opcode: `sldi'
{standard input}:694: Error: Unrecognized opcode: `sldi'
{standard input}:952: Error: Unrecognized opcode: `slwi'
{standard input}:953: Error: Unrecognized opcode: `sldi'
{standard input}:1121: Error: Unrecognized opcode: `sldi'
{standard input}:1359: Error: Unrecognized opcode: `sldi'
{standard input}:1464: Error: Unrecognized opcode: `srdi'
make[2]: *** [init/main.o] Error 1
make[1]: *** [init] Error 2
make: *** [_all] Error 2
It turns out that with Arnd's patches we now get "-mcpu=powerpc64" on
the command line, and that means that gcc *doesn't* put "-mppc64" the
as command line, and as barfs on the 64-bit instructions. That's
presumably a gcc bug, but we'll have to work around it. I think the
best thing is just to not put the -mcpu=powerpc64 in CFLAGS when no
specific CPU is selected.
Paul.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Kumar Gala @ 2007-06-29 7:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <18052.42546.78964.805791@cargo.ozlabs.ibm.com>
On Jun 29, 2007, at 1:26 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Please pull from 'for_paulus' branch of
>>
>> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
>> for_paulus
>
> Unfortunately with those commits I get this when compiling for a
> 64-bit target:
>
> {standard input}: Assembler messages:
> {standard input}:668: Error: Unrecognized opcode: `sldi'
> {standard input}:676: Error: Unrecognized opcode: `sldi'
> {standard input}:694: Error: Unrecognized opcode: `sldi'
> {standard input}:952: Error: Unrecognized opcode: `slwi'
> {standard input}:953: Error: Unrecognized opcode: `sldi'
> {standard input}:1121: Error: Unrecognized opcode: `sldi'
> {standard input}:1359: Error: Unrecognized opcode: `sldi'
> {standard input}:1464: Error: Unrecognized opcode: `srdi'
> make[2]: *** [init/main.o] Error 1
> make[1]: *** [init] Error 2
> make: *** [_all] Error 2
>
> It turns out that with Arnd's patches we now get "-mcpu=powerpc64" on
> the command line, and that means that gcc *doesn't* put "-mppc64" the
> as command line, and as barfs on the 64-bit instructions. That's
> presumably a gcc bug, but we'll have to work around it. I think the
> best thing is just to not put the -mcpu=powerpc64 in CFLAGS when no
> specific CPU is selected.
I dropped the patch and re-pushed my tree w/o it.
Let me know if you have any issues.
- k
^ permalink raw reply
* Re: mpc8270 & Intel 82551ER on 2.6.17.14
From: Pradyumna Sampath @ 2007-06-29 8:12 UTC (permalink / raw)
To: Nicholas Hickman; +Cc: linuxppc-embedded
In-Reply-To: <8140AAF341CC904BA92C3D6A5A1909782A2FA3@ditech-1.ditechllc.com>
Hi Nicholas,
On 6/29/07, Nicholas Hickman <nhickman@dtechlabs.com> wrote:
>
>
> I am having trouble getting two 82551ER Ethernet controllers running in
> Linux. I am able to scan the PCI bus and see the devices and I was even
> able to program the EEPROM from U-boot.
>
> In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c. I've been
> using the e100 drive that comes with the 2.6.17.14 kernel and have also
> tried the driver directly from Intel. Both give the same results. The PCI
> scan shows the correct output for how the device should be configured.
<snip..>
I have the same, exact same problem. But there are some of the
differences with the setup though. I have an MPC5200B and the other
difference is that I have a 2.6.21-rt3. However its the same ethernet
controller.
I am trying out a few things here, some of them being complete
guesses. But if I hit something, I will let this list know. Anyone
else had similar issues ? Request you to please holler.
regards
prady
--
htp://prady.livejournal.com
^ permalink raw reply
* Re: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Segher Boessenkool @ 2007-06-29 9:05 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F3281@zch01exm26.fsl.freescale.net>
>>> + - #address-cells : Address representation for
>> "rapidio" devices.
>>> + This field represents the number of cells needed to represent
>>> + the RapidIO address of the registers. For
>> supporting more than
>>> + 32-bits RapidIO address, this field should be <2>.
>>> + See 1) above for more details on defining #address-cells.
>>
>> What does the RapidIO standard say about number of address
>> bits? You want to follow that, so all RapidIO devices can
>> use the same #address-cells, not just the FSL ones. Also,
>> are there different kinds of address spaces on the bus, or
>> is it just one big memory-like space?
>
> I've checked the specification of RapidIO. The supporting of RapidIO
> extended address modes are 66, 50 and 34 bit.
These three are all two bits more than some "regular" size --
do those two extra bits have some special meaning perhaps,
like an address space identifier or something?
> The Freescale's silicons is only support 34 bit address now.
> Do you mean I should not use words -- 'should be <2>'?
> The #address-cells should be assigned according the address mode
> supported by silicon.
No. The #address-cells is determined by the bus binding,
so that all RapidIO busses on the planet can be represented
in a similar way in the OF device tree. Take for example
the PCI binding, which gives you three address cells -- one
to distinguish between different address spaces (configuration
space, legacy I/O space, memory mapped space) and to contain
some flags (prefetchable vs. non-prefetchable, etc.); the
other two 32-bit cells contain a 64-bit address, although
config and legacy I/O never are more than 32 bit, and many
PCI devices can't do 64-bit addressing at all.
Now, there is no OF binding for RapidIO yet of course, but
it would be good to start thinking about one while doing
the binding for your specific controller -- it will make
life easier down the line for everyone, including yourself.
Segher
^ permalink raw reply
* flashing file system
From: sarpa @ 2007-06-29 9:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I want to flash my file system which is in squashfs format in to my mpc5200
board. I have bdi2000. But it recognises .bin, .sss (S19), .hex formats. But
i don't know how to flash a file system (it is not showing any file type).
Do we need to convert it into any other format such as .bin? please help me
Thanks & Regards,
VS
--
View this message in context: http://www.nabble.com/flashing-file-system-tf3998851.html#a11357002
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Segher Boessenkool @ 2007-06-29 9:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <18052.42546.78964.805791@cargo.ozlabs.ibm.com>
>> Please pull from 'for_paulus' branch of
>>
>> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
>> for_paulus
>
> Unfortunately with those commits I get this when compiling for a
> 64-bit target:
>
> {standard input}: Assembler messages:
> {standard input}:668: Error: Unrecognized opcode: `sldi'
[etc.]
> It turns out that with Arnd's patches we now get "-mcpu=powerpc64" on
> the command line, and that means that gcc *doesn't* put "-mppc64" the
> as command line, and as barfs on the 64-bit instructions. That's
> presumably a gcc bug, but we'll have to work around it.
It is not. -mcpu=powerpc64 doesn't select an ABI, and your
GCC presumably defaults to the 32-bit ABI. Use -m64 on the
GCC command line, too, you need it, and it solves this issue
as a side effect.
It would be a bug if GCC would allow 64-bit insns in the
32-bit ABI for Linux, but that is currently not the case :-(
> I think the
> best thing is just to not put the -mcpu=powerpc64 in CFLAGS when no
> specific CPU is selected.
That would be the "use the compiler default CPU" option.
Segher
^ permalink raw reply
* RE: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Zhang Wei-r63237 @ 2007-06-29 9:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <8ee77b5f79ee0c0c5ead1f0acbe95bda@kernel.crashing.org>
Hi, Segher,=20
> DTS sector to the document of booting-without-of.txt file.
>=20
> >>> + - #address-cells : Address representation for
> >> "rapidio" devices.
> >>> + This field represents the number of cells needed=20
> to represent
> >>> + the RapidIO address of the registers. For
> >> supporting more than
> >>> + 32-bits RapidIO address, this field should be <2>.
> >>> + See 1) above for more details on defining #address-cells.
> >>
> >> What does the RapidIO standard say about number of address
> >> bits? You want to follow that, so all RapidIO devices can
> >> use the same #address-cells, not just the FSL ones. Also,
> >> are there different kinds of address spaces on the bus, or
> >> is it just one big memory-like space?
> >
> > I've checked the specification of RapidIO. The supporting of RapidIO
> > extended address modes are 66, 50 and 34 bit.
>=20
> These three are all two bits more than some "regular" size --
> do those two extra bits have some special meaning perhaps,
> like an address space identifier or something?
>=20
> > The Freescale's silicons is only support 34 bit address now.
> > Do you mean I should not use words -- 'should be <2>'?
> > The #address-cells should be assigned according the address mode
> > supported by silicon.
>=20
> No. The #address-cells is determined by the bus binding,
> so that all RapidIO busses on the planet can be represented
> in a similar way in the OF device tree. Take for example
> the PCI binding, which gives you three address cells -- one
> to distinguish between different address spaces (configuration
> space, legacy I/O space, memory mapped space) and to contain
> some flags (prefetchable vs. non-prefetchable, etc.); the
> other two 32-bit cells contain a 64-bit address, although
> config and legacy I/O never are more than 32 bit, and many
> PCI devices can't do 64-bit addressing at all.
>=20
> Now, there is no OF binding for RapidIO yet of course, but
> it would be good to start thinking about one while doing
> the binding for your specific controller -- it will make
> life easier down the line for everyone, including yourself.
>=20
How about I add more words here for more clear expression?
Such as "<2> for 34 and 50 bit address, <3> for 66 bit address".
Thanks!
Wei.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Paul Mackerras @ 2007-06-29 9:31 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <fd3e668b664f28db6aa3071b1abdc642@kernel.crashing.org>
Segher Boessenkool writes:
> It is not. -mcpu=powerpc64 doesn't select an ABI, and your
> GCC presumably defaults to the 32-bit ABI. Use -m64 on the
> GCC command line, too, you need it, and it solves this issue
> as a side effect.
No, actually the command line had -m64 on it. The situation is this:
gcc -m64 -mtune=power4 works
gcc -m64 -mcpu=powerpc64 -mtune=power4 fails.
The problem is in the spec file where it works out what parameters to
pass to `as'. Without any -mcpu it correctly defaults to passing
-mppc64 (when -m64 is given). It then also has a list of -mcpu values
and the corresponding flag to pass to as, but powerpc64 isn't in that
list. Thus with -mcpu=powerpc64 we don't get -mppc64 passed to as.
Paul.
^ permalink raw reply
* Re: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Segher Boessenkool @ 2007-06-29 9:49 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F3312@zch01exm26.fsl.freescale.net>
>> No. The #address-cells is determined by the bus binding,
>> so that all RapidIO busses on the planet can be represented
>> in a similar way in the OF device tree. Take for example
>> the PCI binding, which gives you three address cells -- one
>> to distinguish between different address spaces (configuration
>> space, legacy I/O space, memory mapped space) and to contain
>> some flags (prefetchable vs. non-prefetchable, etc.); the
>> other two 32-bit cells contain a 64-bit address, although
>> config and legacy I/O never are more than 32 bit, and many
>> PCI devices can't do 64-bit addressing at all.
>>
>> Now, there is no OF binding for RapidIO yet of course, but
>> it would be good to start thinking about one while doing
>> the binding for your specific controller -- it will make
>> life easier down the line for everyone, including yourself.
>>
> How about I add more words here for more clear expression?
> Such as "<2> for 34 and 50 bit address, <3> for 66 bit address".
You should more explicitly define the address format, i.e.
what every bit means -- just saying it is 64 or 96 bits isn't
enough. While you're doing that, think of a way that can
represent _every possible_ RapidIO address, not just the ones
supported by this particular controller.
Segher
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Segher Boessenkool @ 2007-06-29 9:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <18052.53604.173632.186062@cargo.ozlabs.ibm.com>
>> It is not. -mcpu=powerpc64 doesn't select an ABI, and your
>> GCC presumably defaults to the 32-bit ABI. Use -m64 on the
>> GCC command line, too, you need it, and it solves this issue
>> as a side effect.
>
> No, actually the command line had -m64 on it. The situation is this:
>
> gcc -m64 -mtune=power4 works
> gcc -m64 -mcpu=powerpc64 -mtune=power4 fails.
>
> The problem is in the spec file where it works out what parameters to
> pass to `as'. Without any -mcpu it correctly defaults to passing
> -mppc64 (when -m64 is given). It then also has a list of -mcpu values
> and the corresponding flag to pass to as, but powerpc64 isn't in that
> list. Thus with -mcpu=powerpc64 we don't get -mppc64 passed to as.
Oh okay, badness. What's the GCC PR #?
Segher
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Vladislav Buzov @ 2007-06-29 10:41 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20928a2e8680e3d9214f1eb24ea87abd@kernel.crashing.org>
Segher Boessenkool wrote:
>>>> First, I'm looking for a help and advice why the current _set_L2CR()
>>>> implementation may not work for MPC7450 (namely 7448 with 1Mb L2 cache
>>>> installed). Is it a bug in _set_L2CR() or a hardware problem.
>>>
>>>
>>> I think that if anyone here could answer this straight
>>> away, the source code would have been fixed already ;-)
>>
>>
>> I think I can try to answer this question. Please, look through my
>> thoughts below and correct me if I'm somewhere wrong.
>
>
> You forgot step 0: the goal of flushing the caches here
> is to make sure there is no data at all in there after it
> has finished.
>
>> The current scheme of flushing the caches is based on a number of
>> consecutive lwz/dcbf instructions. A contiguous memory region
>> (started from zero) is read by series of lwz commands and then cache
>> is flushed using a sequence of dcbf instructions with addresses from
>> this memory range. If I understand correctly, to get this approach
>> working it is required to guarantee that after reading the memory
>> region, each line in a cache should be used and keep data from this
>> region. Otherwise, if some cache lines keep data from another address
>> range they will not be flushed by the dcbf instructions sequence.
>
>
> Yes, you need to ensure there is nothing interfering (SMP
> agents, DMA agents, prefetch engines...), and you need to
> know the line replacement policy, to make this work;
> furthermore, you need to be quite careful in your code to
> make sure the intended L2 stores are the _only_ L2 traffic
> you generate.
>
>> Further, how cache lines are utilized is dictated by a cache lines
>> replacement policy. I didn't go in to details deeply, but on MPC7450
>> L1 cache lines replacement policy seems to satisfy the requirement
>> above. At least the MPC7450 reference manual describes L1 cache
>> flushing algorithm based on a sequence of lwz/dcbf instructions.
>>
>> But regarding to L2/L3 caches, the manual describes two different
>> cache line replacement policies. And the both are pseudo-random
>
>
> At least on is the "standard" PowerPC pseudo-LRU tree, no?
> That one flushes fine using this strategy.
The PLRU is implemented in the the L1 cache only, And yes, it does allow
to flush the cache using the lwz/dcbf sequence.
The L2/L3 caches use two different pseudo-random number generators based
on CPU clocks. The first one is just 3-bit modulo 8 counter incremented
on every clock cycle. On each cache miss it is used to choice a cache
line in a set. The second is more complicated and consists of 16 latches
clocked on every clock cycle with 3 XOR functions. And L2/L3 take
"random" numbers from 3 latches of 16.
>
>> and differ by implementation of random number generator. It means
>> that a cache line in a set is chosen randomly, and that, in turn,
>> means that there is a probability that some cache lines are not used
>> during reading of the contiguous memory region and not flushed by the
>> dcbf instruction sequence.
>
>
> Knowing that there is no "outside" interference, and knowing
> the "random" algorithm, can give plenty guarantees.
Agree. In case of cache flushing there is no interference and all the
instructions use known numbers of clock cycles, so it is possible (at
least in theory) to predict all the "random" numbers and to say whether
all the cache lines will be used or not in each particular case. But
the nature of the algorithms does not guarantee the preferable result in
general.
>
>> For example, on MPC7448 there is a eight-way set-associative 1Mb L2
>> cache that consist of 2048 sets x 8 ways per set. And even if a set N
>> has been accessed M times (M > 8) there is a chance that some cache
>> line is set N has never been used, but another line has been used
>> twice or more. Of course, the probability of such situation decreases
>> with increasing of N.
>
Opps, misprint.. I meant M in last sentence :-)
Thank you,
Vlad.
>
> You can make sure, too. Just trying to statistically get
> to the point where you are sure the whole cache is flushed
> is not going to work *at all*, you need to use deeper knowledge
> of how the cache works.
>
>> Current _set_L2CR() implementation reads first 4Mb of memory to flush
>> the L2 cache. I have increased this size up to 16 Mb and now things
>> work fine. But I don't think that is a right way to fix the problem
>> because there is no any way to define the upper limit of memory size
>> to guarantee flushing of each cache line. 16Mb is too large though.
>> It seems more reasonable to use a stable and guaranteed way to flush
>> the cache implemented in hardware.
>
>
> Yes, use the hardware flush mechanism. Please :-)
>
> [I think the erratum is about insn fetches to L2 that you
> have no way too stop. <handwaving>Something like that,
> anyway.</handwaving>]
>
>
> Segher
>
^ permalink raw reply
* Re: 83xx: requesting external interrupts
From: Joakim Tjernlund @ 2007-06-29 11:34 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1178892748.9018.13.camel@saruman.qstreams.net>
On Fri, 2007-05-11 at 10:12 -0400, Ben Warren wrote:
> Alex,
>=20
> On Fri, 2007-05-11 at 10:29 +0100, Alex Zeffertt wrote:
> > Hi,
> >=20
> > Thanks for your reply Ben, but I think my problem is slightly =
different. It is not
> > that the sense (high/low/rising/falling) of the interrupt is wrong, =
but that the
> > kernel will not allow me to register the handler.
> >=20
> > I've changed my code to:
> >=20
> > struct device_node *np =3D of_find_node_by_type(NULL, "ipic");
> > struct irq_host *host =3D irq_find_host(np);
> > int rc;
> >=20
> > unsigned int virq =3D irq_find_mapping(host, 5);
> > set_irq_type(virq, IRQ_TYPE_EDGE_FALLING);
> > rc =3D request_irq(virq, mpc832xemds_phy_interrupt, =
IRQF_SHARED, "pm5384", dev);
> >=20
> > but the last line still returns a non-zero error code.
> >=20
> > Is there a new way of requesting to install a handler for external =
interrupts? I
> > can't find any powerpc examples in the kernel tree....
> >=20
> Sorry, I missed a bit of the implementation. You need to register the
> IRQs before attempting to attach an ISR. Here's some sample code that
> works for me. You'll probably need different IRQs, based on what your
> board does:
>=20
> /* All external IRQs + Generic timer IRQs must be initialized by BSP =
*/
> const int bsp_irqs[] =3D {48, 17, 18, 19, 20, 21, 22, 23, 90, 78, 84, =
72};
>=20
> Add this to your BSP IRQ init code (void __init xxx_init_IRQs())
>=20
>=20
> for (i=3D0;i<sizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
> virq =3D irq_create_mapping(NULL, bsp_irqs[i]);
>=20
> That should do it.
>=20
> regards,
> Ben
Hi Ben
I too am adding such a IRQ for my PHY connected to external IRQ2.
The PHY is connetced to UCC2.
I have this in my DTS for the PHY:
mdio@2320 {
#address-cells =3D <1>;
#size-cells =3D <0>;
reg =3D <2320 18>;
device_type =3D "mdio";
compatible =3D "ucc_geth_phy";
phy1: ethernet-phy@0 {
interrupt-parent =3D <&ipic>;
interrupts =3D <12 2>; //EXT IRQ2
reg =3D <0>; // 0
device_type =3D "ethernet-phy";
interface =3D <3>; //ENET_100_MII
};
Now the things is that the IRQ works with and without the
/* All external IRQs + Generic timer IRQs must be initialized by BSP */
const int bsp_irqs[] =3D {48, 17, 18, 19, 20, 21, 22, 23, 90, 78, 84, =
72};
for (i=3D0;i<sizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
virq =3D irq_create_mapping(NULL, bsp_irqs[i]);
code in my bsp. There is one difference though.
Printing the irq num in phy_interrupt:
static irqreturn_t phy_interrupt(int irq, void *dev_id)
{
struct net_device *dev =3D (struct net_device *)dev_id;
struct ucc_geth_private *ugeth =3D netdev_priv(dev);
ugeth_vdbg("%s: IN", __FUNCTION__);
printk(KERN_ERR "PHY IRQ:%d \n", irq);
Shows a difference:
with the bsp code added it prints:
PHY IRQ:18
and when I remove the bsp code it prints:
PHY IRQ:19
So what is correct, should I add the bsp code or not?
Jocke
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Mariusz Kozlowski @ 2007-06-29 12:32 UTC (permalink / raw)
To: Andrew Morton, paulus, xfs-masters; +Cc: linuxppc-dev, linux-kernel, xfs
In-Reply-To: <20070628034321.38c9f12b.akpm@linux-foundation.org>
Hello,
allmodconfig on powerpc (iMac g3) fails due to
git-kgdb.patch. allmodconfig defaults should be changed?
CC arch/powerpc/kernel/kgdb.o
arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected
in .config. Unselect one of them.
make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
make: *** [arch/powerpc/kernel] Blad 2
anyway after unselecting XMON we can see:
CC [M] fs/xfs/linux-2.6/xfs_ioctl32.o
fs/xfs/linux-2.6/xfs_ioctl32.c: In function 'xfs_ioc_bulkstat_compat':
fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: 'xfs_inumbers_fmt_compat'
undeclared (first use in this function)
fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is
reported only once
fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.)
make[2]: *** [fs/xfs/linux-2.6/xfs_ioctl32.o] Blad 1
make[1]: *** [fs/xfs] Blad 2
This is just allmodconfig - not a .config that's used daily by users but I'm
used to compiling the kernel using it anyway 8)
Regards,
Mariusz
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Sergei Shtylyov @ 2007-06-29 12:54 UTC (permalink / raw)
To: kgdb-bugreport
Cc: linux-kernel, linuxppc-dev, Mariusz Kozlowski, paulus,
jason.wessel, Andrew Morton
In-Reply-To: <200706291432.10128.m.kozlowski@tuxland.pl>
Hello.
Mariusz Kozlowski wrote:
> allmodconfig on powerpc (iMac g3) fails due to
> git-kgdb.patch. allmodconfig defaults should be changed?
> CC arch/powerpc/kernel/kgdb.o
> arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected
> in .config. Unselect one of them.
> make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
> make: *** [arch/powerpc/kernel] Blad 2
I'm not sure if this will work out but maybe it's worth to disable XMON if
KGDB is selected, like this?
config XMON
bool "Include xmon kernel debugger"
depends on DEBUGGER && !KGDB
> Regards,
> Mariusz
WBR, Sergei
^ 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