* RE: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Ho Jeffrey-r26191 @ 2006-07-11 22:49 UTC (permalink / raw)
To: 'Florian Boelstler', linuxppc-embedded
Hi Florian,
I have done the PCI config cycle under u-boot. This is very simple and able to find the PEX EP attached to the MPC8548.
In this log, it is reading a pair of MPC8548E connected together using PEX.
Please see the log below:
U-Boot 1.1.4 (Apr 12 2006 - 11:40:53)
CPU: 8548_E, Version: 1.1, (0x80390011)
Core: e500v2, Version: 1.0, (0x80210010)
Clock Configuration:
CPU:1333 MHz, CCB: 533 MHz,
DDR: 266 MHz, LBC: 33 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: MPC85xx Processor Card Rev. A.
-- Boot Flash is U30
SRIO: X4 2.5Gbps
PEX : X4 2.5Gbps
PCI1: 32 bit, async
PCI2: disabled
I2C: ready
DRAM: Initializing
DDR: 256 MB
FLASH: 16 MB
L2 cache 512KB: enabled
In: serial
Out: serial
Err: serial
Net: eTSEC0: PHY is Marvell 88E1111S (1410cc1)
eTSEC1: PHY is Realtek RTL821x (1cc912)
eTSEC2: PHY is Marvell 88E1111S (1410cc1)
eTSEC3: PHY id ffffffff is not supported!
eTSEC0, eTSEC1, eTSEC2 [PRIME], eTSEC3
eTSEC0 & eTSEC1 in Reduce mode
eTSEC2 & eTSEC3 in Reduce mode
Hit any key to stop autoboot: 0
MPC8548E_Rev1.1=> mm e000a000 <-setup command register
e000a000: 8000f800 ? 80000004 Bus master, SERR, Memory space
e000a004: 02001000 ? 06011000
e000a008: 00000000 ? .
MPC8548E_Rev1.1=> mm e000a000 <-Set secondary bus num = 1
e000a000: 80000004 ? 80000018 Subordinate bus num = 3
e000a004: 00000000 ? 00010300
e000a008: 00000000 ? .
MPC8548E_Rev1.1=> mm e000a000 <-Check PEX agent ID
e000a000: 80000018 ? 80010000
e000a004: 57191200 ? .
MPC8548E_Rev1.1=> mm e000a000 <-Set PEX agent BAR0 (PEXCSRBAR)
e000a000: 80010010 ? 80010010 PEXCSRBAR = 0x80000000
e000a004: 00000000 ? 00000080 This is the PCI address space
e000a008: 00000000 ? .
MPC8548E_Rev1.1=> mm e000a000 <-Set PEX agent command register
e000a000: 80010014 ? 80010004 Bus master, SERR, Memory space
e000a004: 00001000 ? 06011000
e000a008: 00000000 ? .
MPC8548E_Rev1.1=>
mw e000ac20 00080000; <-Set TAR = 0x80000000 (PCI address space)
mw e000ac24 0; <-Set 32:64bit TAR = 0x0 (PCI address space)
mw e000ac28 000a0000; <-Set WBA = 0xa0000000 (ECM, e500 address space)
mw e000ac30 8004401A <-Set normal R/W, enable Outbound window
MPC8548E_Rev1.1=>
MPC8548E_Rev1.1=>
MPC8548E_Rev1.1=> mm e000a000 <-check PEX agent BAR0 if written
e000a000: 80010010 ?
e000a004: 00000080 ? .
MPC8548E_Rev1.1=> md a0000000 <-read PEX agent CCSRBAR address use 0xa0000000
a0000000: 000ff700 00000000 00000000 00000000 ................
a0000010: 00000000 00000000 00000000 00000000 ................
a0000020: 00000000 00000000 00000000 00000000 ................
a0000030: 00000000 00000000 00000000 00000000 ................
a0000040: 00000000 00000000 00000000 00000000 ................
a0000050: 00000000 00000000 00000000 00000000 ................
a0000060: 00000000 00000000 00000000 00000000 ................
a0000070: 00000000 00000000 00000000 00000000 ................
a0000080: 00000000 00000000 00000000 00000000 ................
a0000090: 00000000 00000000 00000000 00000000 ................
a00000a0: 00000000 00000000 00000000 00000000 ................
a00000b0: 00000000 00000000 00000000 00000000 ................
a00000c0: 00000000 00000000 00000000 00000000 ................
a00000d0: 00000000 00000000 00000000 00000000 ................
a00000e0: 00000000 00000000 00000000 00000000 ................
a00000f0: 00000000 00000000 00000000 00000000 ................
Regards,
Jeffrey Ho
Freescale Semiconductor HK Ltd
Tel: 852-26668050
> -----Original Message-----
> From:
> linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.
> org] On Behalf Of Florian Boelstler
> Sent: Monday, June 26, 2006 6:48 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
>
> Hi,
>
> I am currently working on a MPC8548-based development system.
> Linux kernel version is 2.6.11 with patches delivered from
> Freescale (BSP MPC8548CDS 02/24/2006).
>
> Kernel configuration contains a warning message for CONFIG_PEX:
> "This requires hardware modification to work correctly if
> your CPU version < 2.0 and will break the PCI bus. [...]"
>
> I was wondering whether enabling PCIe makes PCI bus
> functionality unusable at all (including kernel functionality
> for detecting devices behind a transparent PCI-to-PCI bridge).
>
> Our setup connects a transparent PLX8516 PCI-to-PCI bridge to
> the PCIe port of the MPC8548 daughter board. Behind that
> bridge is another PCIe capable device.
> MPC8548 is configured to run as PCIe host mode.
>
> When trying to lookup the PCIe devices using lspci I can only
> see the PPC itself and the bridge.
> However I cannot see the device(s) behind the bridge.
>
> Is there another method for detecting PCI(e) devices?
> Is "BSP MPC8548CDS 02/24/2006" the latest version
> corresponding to that hardware?
>
> Thanks in advance,
>
> Florian
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* [PATCH] PMAC_APM_EMU should depend on ADB_PMU
From: Daniel Drake @ 2006-07-11 21:25 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, kugelfang
From: Danny van Dyk <kugelfang@gentoo.org>
This patch fixes undefined refereneces to pmu_ symbols on 2.6.17.
Signed-Off-By: Danny van Dyk <kugelfang@gentoo.org>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Index: linux/drivers/macintosh/Kconfig
===================================================================
--- linux.orig/drivers/macintosh/Kconfig
+++ linux/drivers/macintosh/Kconfig
@@ -100,7 +100,7 @@ config PMAC_SMU
config PMAC_APM_EMU
tristate "APM emulation"
- depends on PPC_PMAC && PPC32 && PM
+ depends on PPC_PMAC && PPC32 && PM && ADB_PMU
config PMAC_MEDIABAY
bool "Support PowerBook hotswap media bay"
^ permalink raw reply
* some problems on the SystemACE driver.
From: Ming Liu @ 2006-07-11 19:47 UTC (permalink / raw)
To: ammubhai; +Cc: linuxppc-embedded
Dear Ameet,
Sorry to bother you again but I am totally confused on the systemACE
driver. First let me show you the problem.
1. I downloaded the linux kernel of 2.6.17.1, also the patch for SystemACE
driver. Applied the patch to the kernel. Replaced the xparameters_ml403.h
with the generated file xparameters_ml300.h from Xilinx EDK. Make
menuconfig, make dep and make zImage. Then the error shows like this:
drivers/block/xilinx_sysace/xsysace.c:120:6: warning:
"XPAR_XSYSACE_MEM_WIDTH" is not defined
drivers/block/xilinx_sysace/xsysace.c: In function `XSysAce_LookupConfig':
drivers/block/xilinx_sysace/xsysace.c:366: error:
`XPAR_XSYSACE_NUM_INSTANCES' undeclared (first use in this function)
drivers/block/xilinx_sysace/xsysace.c:366: error: (Each undeclared
identifier is reported only once
drivers/block/xilinx_sysace/xsysace.c:366: error: for each function it
appears in.)
make[3]: *** [drivers/block/xilinx_sysace/xsysace.o] Error 1
make[2]: *** [drivers/block/xilinx_sysace] Error 2
make[1]: *** [drivers/block] Error 2
make: *** [drivers] Error 2
I think this is because of the no inclusion of the xparameters header file.
So I change #include "xparameters.h" into #include "
/home/mingliu/linux-2.6.17.1/arch/ppc/platforms/4xx/xparameters/xparameters.h"
in the files of xsysace.c and xsysace_g.c, using the full address to
specify the header file. In fact, this is not a serious problem and it
often happens. But, after the modification, another problem happened:
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o(.text+0x2234a): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x2235e): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x22364): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssert'
drivers/built-in.o(.text+0x22372): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x2237a): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x22394): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssert'
drivers/built-in.o(.text+0x223a2): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x223aa): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x22cd6): In function `XSysAce_Initialize':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x22cdc): In function `XSysAce_Initialize':
: undefined reference to `XAssert'
drivers/built-in.o(.text+0x22cea): In function `XSysAce_Initialize':
: undefined reference to `XAssertStatus'
......( a long information to say that undefined reference to the XAssert
things.)
Also, I tried this in the kernel 2.6.16-rc5. (In fact I prefer this version
because the temac driver is for this version. ) The same problem happened.
I checked the source code. The problem happened in the file
driver/block/xilinx_sysace/adapter.c, etc. Also, the XAssert things are
defined in the file arch/ppc/platforms/4xx/xilinx_ocp/xbasic_types.c. (In
2.6.16 kernel, it is also defined in driver/xilinx_edk/xbasic_types.c.
There are two copies of this file. ) I think the problem is, the systemACE
files cannot link together with the xbasic_types.c file.
I heard that you have tested this driver. Have you got this problem? Why
there are so many strange problems for me while you have tested without
problem? Without the CF card, I cannot try the Temac driver and my work is
totally blocked. So I have to ask for your suggestion. Really anxious for
your useful guidance. Thanks a lot!!!!!!
Regards
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: Linux v2.6.18-rc1
From: Steve Fox @ 2006-07-11 17:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1152566236.1576.100.camel@localhost.localdomain>
On Tue, 2006-07-11 at 07:17 +1000, Benjamin Herrenschmidt wrote:
> it's most certainly an irq problem as I just rewrote the irq logic of
> powerpc :) There have been some issues and I've just sent some new
> patches fixing them, let's see if that's enough. I'll give a js20 a try
> today at work.
FWIW, I tried applying the 3 non-Apple-specific patches posted on 7/10
but this didn't help.
--
Steve Fox
IBM Linux Technology Center
^ permalink raw reply
* No init found
From: morelli.gab @ 2006-07-11 15:34 UTC (permalink / raw)
To: linuxppc-embedded
help!!
i not understand, because when load the Kernel-2.6 in my board the system=
block on following message
"Kernel panic - not syncing: No init found. Try passing init=3D option t=
o kernel"
my filesystem contain the process init into folder sbin i build it whit a=
busybox-1.1.3
...
mtdblock_open
ok
mtdblock: read on "cramfs" at 0x400, size 0x200
mtdblock: read on "cramfs" at 0x600, size 0x200
mtdblock_release
ok
mtdblock_open
ok
mtdblock: read on "cramfs" at 0x0, size 0x200
mtdblock: read on "cramfs" at 0x200, size 0x200
mtdblock: read on "cramfs" at 0x400, size 0x200
kernel panic........
thanks to all
^ permalink raw reply
* Maple platform - adding graphics to IBM PIBS firmware
From: jf simon @ 2006-07-11 13:28 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1152567817.1576.114.camel@localhost.localdomain>
Hi,
We have designed a VME CPU card based on IBM Maple platform.
We've had problems making it work with a PCI/PMC graphic card we've also
designed based around the ATI Radeon 7000 (RV100 QY). To solve this we
have linux consultants helping us in emulating the ATI video BIOS at the
linux kernel level.
But we would like to modify the PIBs firmware with simple routines
(scroll,..) to use the graphic screen attached to the ATI as a text
(alphanumeric) console. The keyboard would be USB.
Is this possible even if the video BIOs didn't previously initialize
the ATI graphic chip?
I realize this question doesn't really belong here...but not sure where
to ask, sorry about that.
Thanks a lot
-jf simon
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com
^ permalink raw reply
* Re: regarding lspci
From: Sergei Shtylyov @ 2006-07-11 11:59 UTC (permalink / raw)
To: rahul; +Cc: linuxppc-embedded
In-Reply-To: <44B381B7.1030500@gmail.com>
Hello.
rahul wrote:
> I am facing some problem in applying the patch.
> I have copied the pacth to a file "patch-pciutils"
> [root@localhost pciutils-2.1.11]# file patch-pciutils
> patch-pciutils: 'diff' output text
> [root@localhost pciutils-2.1.11]#
> when i gave the command :
> [root@localhost pciutils-2.1.11]# patch -p1 patch-pciutils
> .
> .
> Nothing happens even after 3/4 minutes...so i am stopping it by ctrl+c.
> None of the files are edited.
No wonder, patch(1) expects the patch to be fed thru stdin, so you should
have typed:
patch -p1 < patch-pciutils
> Thanks & Regards
> Rahul
WBR, Sergei
^ permalink raw reply
* Re: regarding lspci
From: Claus Gindhart @ 2006-07-11 12:04 UTC (permalink / raw)
To: rahul; +Cc: ilugc, linuxppc-embedded
In-Reply-To: <44B381B7.1030500@gmail.com>
Hi Rahul,
Maybe, its better, if you do the modification by hand. This has the advantage,
that you know, what happens.
Just, search for the following lines
--------------8-<----------------------
sys=`uname -s`
rel=`uname -r`
if [ "$sys" = "AIX" -a -x /usr/bin/oslevel -a -x /usr/sbin/lsattr ]
then
rel=`/usr/bin/oslevel`
proc=`/usr/sbin/lsdev -C -c processor -S available -F name | head -1`
cpu=`/usr/sbin/lsattr -F value -l $proc -a type | sed 's/_.*//'`
else
cpu=`uname -m | sed 's/^i.86$/i386/;s/^sun4u$/sparc64/'`
fi
echo " $sys/$cpu $rel"
--------------8-<----------------------
Comment them out; they can not work, when cross compiling, because they try to
detect Kernel version and architecture by using host tools
Then, add the following lines
--------------8-<----------------------
sys=Linux
rel=2.6.13 (or whatever Kernel version you have)
cpu=ppc
--------------8-<----------------------
--
Mit freundlichen Gruessen / Best regards
Claus Gindhart
SW R&D
Kontron Modular Computers
phone :++49 (0)8341-803-374
mailto:claus.gindhart@kontron-modular.com
http://www.kontron.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
D-- G e++> h--- !r x+++
------END GEEK CODE BLOCK------
^ permalink raw reply
* Re: regarding lspci
From: Mark Zhan @ 2006-07-11 9:42 UTC (permalink / raw)
To: rahul; +Cc: ilugc, linuxppc-embedded list
In-Reply-To: <44B36F85.3010703@gmail.com>
It seems that busybox doesn't support lspci command.
rahul 写道:
> Hi All
>
> My target system is powerpc , linux-2.6.11.
> when i give the lspci in my target system , it says "can't find the
> command".
> I have seen in the ramdisk directory, i could not see the lspci utility
> or pci utilities. Even in the busybox i could not find the utility.
> In linux i have enabled the pci support.
>
> How to get the utility to busybox. I have searched in the net but could
> not succeed.
> Can anyone please help me in this regard. plz correct me if i am missing
> some basic configuration .
>
> Thanks & Regards
> Rahul
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: regarding lspci
From: rahul @ 2006-07-11 10:47 UTC (permalink / raw)
To: Claus Gindhart; +Cc: ilugc, linuxppc-embedded
In-Reply-To: <200607111147.21820.claus.gindhart@kontron-modular.com>
[-- Attachment #1: Type: text/plain, Size: 3253 bytes --]
Hi Claus.Gindhart
I am facing some problem in applying the patch.
I have copied the pacth to a file "patch-pciutils"
[root@localhost pciutils-2.1.11]# file patch-pciutils
patch-pciutils: 'diff' output text
[root@localhost pciutils-2.1.11]#
when i gave the command :
[root@localhost pciutils-2.1.11]# patch -p1 patch-pciutils
.
.
Nothing happens even after 3/4 minutes...so i am stopping it by ctrl+c.
None of the files are edited.
In the patch u sent , let me know wether it is complete one or configure
file is left as it is after the lines
c=config.h
echo >$c "#define ARCH_`echo $cpu | tr 'a-z' 'A-Z'`"
Thanks & Regards
Rahul
Claus Gindhart wrote:
>Rahul,
>
>you need to download the pciutils (e.g. 2.1.11) tarball, and cross compile it
>for PPC.
>
>However, i had to patch the configure script to make it cross-compilable. Here
>is the patch
>
>---------------------------8-<-----------------------------------------------
>diff -Nurd pciutils-2.1.11.ori/lib/configure pciutils-2.1.11/lib/configure
>--- pciutils-2.1.11.ori/lib/configure 2003-01-04 13:29:23.000000000 +0100
>+++ pciutils-2.1.11/lib/configure 2006-05-29 11:08:00.000000000 +0200
>@@ -12,17 +12,20 @@
> echo_n "Configuring libpci for your system..."
> sharedir=${1:-/usr/share}
> version=${2:-0.0}
>-sys=`uname -s`
>-rel=`uname -r`
>-if [ "$sys" = "AIX" -a -x /usr/bin/oslevel -a -x /usr/sbin/lsattr ]
>-then
>- rel=`/usr/bin/oslevel`
>- proc=`/usr/sbin/lsdev -C -c processor -S available -F name | head -1`
>- cpu=`/usr/sbin/lsattr -F value -l $proc -a type | sed 's/_.*//'`
>-else
>- cpu=`uname -m | sed 's/^i.86$/i386/;s/^sun4u$/sparc64/'`
>-fi
>-echo " $sys/$cpu $rel"
>+sys=Linux
>+rel=2.6.13
>+cpu=ppc
>+#sys=`uname -s`
>+#rel=`uname -r`
>+#if [ "$sys" = "AIX" -a -x /usr/bin/oslevel -a -x /usr/sbin/lsattr ]
>+#then
>+# rel=`/usr/bin/oslevel`
>+# proc=`/usr/sbin/lsdev -C -c processor -S available -F name | head -1`
>+# cpu=`/usr/sbin/lsattr -F value -l $proc -a type | sed 's/_.*//'`
>+#else
>+# cpu=`uname -m | sed 's/^i.86$/i386/;s/^sun4u$/sparc64/'`
>+#fi
>+#echo " $sys/$cpu $rel"
>
> c=config.h
> echo >$c "#define ARCH_`echo $cpu | tr 'a-z' 'A-Z'`"
>---------------------------8-<-----------------------------------------------
>
>For the build, i called
>export CROSS=$(CROSS_COMPILE)
>make HOST=$(ARCH)
>
>However, depending on your environment, it might by slightly different in your
>case.
>
>
>On Tuesday 11 July 2006 11:29, rahul wrote:
>
>
>>Hi All
>>
>>My target system is powerpc , linux-2.6.11.
>>when i give the lspci in my target system , it says "can't find the
>>command".
>>I have seen in the ramdisk directory, i could not see the lspci utility
>>or pci utilities. Even in the busybox i could not find the utility.
>>In linux i have enabled the pci support.
>>
>>How to get the utility to busybox. I have searched in the net but could
>>not succeed.
>>Can anyone please help me in this regard. plz correct me if i am missing
>>some basic configuration .
>>
>>Thanks & Regards
>>Rahul
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>>
>
>
>
[-- Attachment #2: Type: text/html, Size: 3918 bytes --]
^ permalink raw reply
* openIPMI for PPC
From: salvatore cusenza @ 2006-07-11 10:38 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 179 bytes --]
Hi,
I have not been able to get OpneIPMI library to compile
with ELDK.
I have not found so far suggestions about building
and configuring OpenIPMI for ppc.
Could anybody help me?
[-- Attachment #2: Type: text/html, Size: 224 bytes --]
^ permalink raw reply
* Re: regarding lspci
From: Claus Gindhart @ 2006-07-11 9:47 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: ilugc
In-Reply-To: <44B36F85.3010703@gmail.com>
Rahul,
you need to download the pciutils (e.g. 2.1.11) tarball, and cross compile it
for PPC.
However, i had to patch the configure script to make it cross-compilable. Here
is the patch
---------------------------8-<-----------------------------------------------
diff -Nurd pciutils-2.1.11.ori/lib/configure pciutils-2.1.11/lib/configure
--- pciutils-2.1.11.ori/lib/configure 2003-01-04 13:29:23.000000000 +0100
+++ pciutils-2.1.11/lib/configure 2006-05-29 11:08:00.000000000 +0200
@@ -12,17 +12,20 @@
echo_n "Configuring libpci for your system..."
sharedir=${1:-/usr/share}
version=${2:-0.0}
-sys=`uname -s`
-rel=`uname -r`
-if [ "$sys" = "AIX" -a -x /usr/bin/oslevel -a -x /usr/sbin/lsattr ]
-then
- rel=`/usr/bin/oslevel`
- proc=`/usr/sbin/lsdev -C -c processor -S available -F name | head -1`
- cpu=`/usr/sbin/lsattr -F value -l $proc -a type | sed 's/_.*//'`
-else
- cpu=`uname -m | sed 's/^i.86$/i386/;s/^sun4u$/sparc64/'`
-fi
-echo " $sys/$cpu $rel"
+sys=Linux
+rel=2.6.13
+cpu=ppc
+#sys=`uname -s`
+#rel=`uname -r`
+#if [ "$sys" = "AIX" -a -x /usr/bin/oslevel -a -x /usr/sbin/lsattr ]
+#then
+# rel=`/usr/bin/oslevel`
+# proc=`/usr/sbin/lsdev -C -c processor -S available -F name | head -1`
+# cpu=`/usr/sbin/lsattr -F value -l $proc -a type | sed 's/_.*//'`
+#else
+# cpu=`uname -m | sed 's/^i.86$/i386/;s/^sun4u$/sparc64/'`
+#fi
+#echo " $sys/$cpu $rel"
c=config.h
echo >$c "#define ARCH_`echo $cpu | tr 'a-z' 'A-Z'`"
---------------------------8-<-----------------------------------------------
For the build, i called
export CROSS=$(CROSS_COMPILE)
make HOST=$(ARCH)
However, depending on your environment, it might by slightly different in your
case.
On Tuesday 11 July 2006 11:29, rahul wrote:
> Hi All
>
> My target system is powerpc , linux-2.6.11.
> when i give the lspci in my target system , it says "can't find the
> command".
> I have seen in the ramdisk directory, i could not see the lspci utility
> or pci utilities. Even in the busybox i could not find the utility.
> In linux i have enabled the pci support.
>
> How to get the utility to busybox. I have searched in the net but could
> not succeed.
> Can anyone please help me in this regard. plz correct me if i am missing
> some basic configuration .
>
> Thanks & Regards
> Rahul
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Mit freundlichen Gruessen / Best regards
Claus Gindhart
SW R&D
Kontron Modular Computers
phone :++49 (0)8341-803-374
ailto:claus.gindhart@kontron-modular.com
http://www.kontron.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
D-- G e++> h--- !r x+++
------END GEEK CODE BLOCK------
^ permalink raw reply
* regarding lspci
From: rahul @ 2006-07-11 9:29 UTC (permalink / raw)
To: linuxppc-embedded list, ilugc
Hi All
My target system is powerpc , linux-2.6.11.
when i give the lspci in my target system , it says "can't find the
command".
I have seen in the ramdisk directory, i could not see the lspci utility
or pci utilities. Even in the busybox i could not find the utility.
In linux i have enabled the pci support.
How to get the utility to busybox. I have searched in the net but could
not succeed.
Can anyone please help me in this regard. plz correct me if i am missing
some basic configuration .
Thanks & Regards
Rahul
^ permalink raw reply
* OpenIPMI for ppc
From: salvatore cusenza @ 2006-07-11 8:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 219 bytes --]
Hi,
I'm trying to cross-compile OpenIPMI-1.4.27 library for ppc (MPC852 and
linux-2.4.20 Denk's distribution).
I have not found so far suggestions about building and configuring OpenIPMI
for ppc.
Could anybody help me?
[-- Attachment #2: Type: text/html, Size: 263 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Xserve cpu-meter LEDs
From: Benjamin Herrenschmidt @ 2006-07-11 5:04 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: debian-powerpc@lists.debian.org
This is a very preliminary driver for the front-panel CPU-meter blue
LEDs of the Xserve. I've tested it on an Xserve G5, though it should
work on the old G4 ones as well.
It's a bit rough at the moment. I want to add a proper PWM to the DMA
sample buffers in order to have a per-LED intensity value so we can make
smoother/funnier things with the LEDs (right now it's 0 or 0xff -> off
or on) and I want to add a userland interface that allows to mmap the
"user buffer" (which contains per-LED 8 bits samples containing an
intensity) in which case the in-kernel CPU-meter control would get
disabled and userland would be free to do whatever it wants.
Also, the CPU-meter thing itself is also a bit simplistic, one may want
to transform the load value through a nice curve and
But that's a first cut and I won't have time to hack on it for some time
now (at least til end of august) so if somebody else wants to play with
it, feel free and send me patches :)
Index: linux-irq-work/drivers/macintosh/rack-meter.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-irq-work/drivers/macintosh/rack-meter.c 2006-07-11 14:58:22.000000000 +1000
@@ -0,0 +1,539 @@
+#define DEBUG
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/dma-mapping.h>
+#include <linux/kernel_stat.h>
+
+#include <asm/io.h>
+#include <asm/prom.h>
+#include <asm/machdep.h>
+#include <asm/pmac_feature.h>
+#include <asm/dbdma.h>
+#include <asm/dbdma.h>
+#include <asm/macio.h>
+#include <asm/keylargo.h>
+
+/* Number of samples in a sample buffer */
+#define SAMPLE_COUNT 256
+
+/* CPU meter sampling rate in ms */
+#define CPU_SAMPLING_RATE 250
+
+struct rackmeter_dma {
+ struct dbdma_cmd cmd[4] ____cacheline_aligned;
+ u32 mark ____cacheline_aligned;
+ u32 buf1[SAMPLE_COUNT] ____cacheline_aligned;
+ u32 buf2[SAMPLE_COUNT] ____cacheline_aligned;
+} ____cacheline_aligned;
+
+struct rackmeter_cpu {
+ struct work_struct sniffer;
+ cputime64_t prev_wall;
+ cputime64_t prev_idle;
+} ____cacheline_aligned;
+
+struct rackmeter {
+ struct macio_dev *mdev;
+ unsigned int irq;
+ struct device_node *i2s;
+ u8 *ubuf;
+ struct dbdma_regs __iomem *dma_regs;
+ void __iomem *i2s_regs;
+ dma_addr_t dma_buf_p;
+ struct rackmeter_dma *dma_buf_v;
+ int stale_irq;
+ struct rackmeter_cpu cpu[2];
+};
+
+/* To be set as a tunable */
+static int rackmeter_ignore_nice;
+
+/* This GPIO is whacked by the OS X driver when initializing */
+#define RACKMETER_MAGIC_GPIO 0x78
+
+/* This is copied from cpufreq_ondemand, maybe we should put it in
+ * a common header somewhere
+ */
+static inline cputime64_t get_cpu_idle_time(unsigned int cpu)
+{
+ cputime64_t retval;
+
+ retval = cputime64_add(kstat_cpu(cpu).cpustat.idle,
+ kstat_cpu(cpu).cpustat.iowait);
+
+ if (rackmeter_ignore_nice)
+ retval = cputime64_add(retval, kstat_cpu(cpu).cpustat.nice);
+
+ return retval;
+}
+
+static void rackmeter_setup_i2s(struct rackmeter *rm)
+{
+ struct macio_chip *macio = rm->mdev->bus->chip;
+
+ /* First whack magic GPIO */
+ pmac_do_feature_call(PMAC_FTR_WRITE_GPIO, NULL,
+ RACKMETER_MAGIC_GPIO, 5);
+
+
+ /* Call feature code to enable the sound channel and the proper
+ * clock sources
+ */
+ pmac_do_feature_call(PMAC_FTR_SOUND_CHIP_ENABLE, rm->i2s, 0, 1);
+
+ /* Power i2s and stop i2s clock. We whack MacIO FCRs directly for now.
+ * This is a bit racy, thus we should add new platform functions to
+ * handle that. snd-aoa needs that too
+ */
+ MACIO_BIS(KEYLARGO_FCR1, KL1_I2S0_ENABLE);
+ MACIO_BIC(KEYLARGO_FCR1, KL1_I2S0_CLK_ENABLE_BIT);
+ (void)MACIO_IN32(KEYLARGO_FCR1);
+ udelay(10);
+
+ /* Then setup i2s. For now, we use the same magic value that
+ * the OS X driver seems to use. We might want to play around
+ * with the clock divisors later
+ */
+ out_le32(rm->i2s_regs + 0x10, 0x01fa0000);
+ (void)in_le32(rm->i2s_regs + 0x10);
+ udelay(10);
+
+ /* Fully restart i2s*/
+ MACIO_BIS(KEYLARGO_FCR1, KL1_I2S0_CELL_ENABLE |
+ KL1_I2S0_CLK_ENABLE_BIT);
+ (void)MACIO_IN32(KEYLARGO_FCR1);
+ udelay(10);
+}
+
+static void rackmeter_set_default_pattern(struct rackmeter *rm)
+{
+ int i;
+
+ for (i = 0; i < 16; i++) {
+ if (i < 8)
+ rm->ubuf[i] = (i & 1) * 255;
+ else
+ rm->ubuf[i] = ((~i) & 1) * 255;
+ }
+}
+
+static void rackmeter_setup_dbdma(struct rackmeter *rm)
+{
+ struct rackmeter_dma *db = rm->dma_buf_v;
+ struct dbdma_cmd *cmd = db->cmd;
+
+ /* Make sure dbdma is reset */
+ DBDMA_DO_RESET(rm->dma_regs);
+
+ db->mark = 0;
+
+ pr_debug("rackmeter: mark offset=0x%lx\n",
+ offsetof(struct rackmeter_dma, mark));
+ pr_debug("rackmeter: buf1 offset=0x%lx\n",
+ offsetof(struct rackmeter_dma, buf1));
+ pr_debug("rackmeter: buf2 offset=0x%lx\n",
+ offsetof(struct rackmeter_dma, buf2));
+
+ /* Prepare 4 dbdma commands for the 2 buffers */
+ memset(cmd, 0, 4 * sizeof(struct dbdma_cmd));
+ st_le16(&cmd->req_count, 4);
+ st_le16(&cmd->command, STORE_WORD | INTR_ALWAYS | KEY_SYSTEM);
+ st_le32(&cmd->phy_addr, rm->dma_buf_p +
+ offsetof(struct rackmeter_dma, mark));
+ st_le32(&cmd->cmd_dep, 0x02000000);
+ cmd++;
+
+ st_le16(&cmd->req_count, SAMPLE_COUNT * 4);
+ st_le16(&cmd->command, OUTPUT_MORE);
+ st_le32(&cmd->phy_addr, rm->dma_buf_p +
+ offsetof(struct rackmeter_dma, buf1));
+ cmd++;
+
+ st_le16(&cmd->req_count, 4);
+ st_le16(&cmd->command, STORE_WORD | INTR_ALWAYS | KEY_SYSTEM);
+ st_le32(&cmd->phy_addr, rm->dma_buf_p +
+ offsetof(struct rackmeter_dma, mark));
+ st_le32(&cmd->cmd_dep, 0x01000000);
+ cmd++;
+
+ st_le16(&cmd->req_count, SAMPLE_COUNT * 4);
+ st_le16(&cmd->command, OUTPUT_MORE | BR_ALWAYS);
+ st_le32(&cmd->phy_addr, rm->dma_buf_p +
+ offsetof(struct rackmeter_dma, buf2));
+ st_le32(&cmd->cmd_dep, rm->dma_buf_p);
+
+ /* Program the DBDMA and start it */
+ mb();
+ out_le32(&rm->dma_regs->cmdptr_hi, 0);
+ out_le32(&rm->dma_regs->cmdptr, rm->dma_buf_p);
+ out_le32(&rm->dma_regs->control, (RUN << 16) | RUN);
+}
+
+static void rackmeter_do_timer(void *data)
+{
+ struct rackmeter *rm = data;
+ unsigned int cpu = smp_processor_id();
+ struct rackmeter_cpu *rcpu = &rm->cpu[cpu];
+ cputime64_t cur_jiffies, total_idle_ticks;
+ unsigned int total_ticks, idle_ticks;
+ int i, offset, load;
+
+ cur_jiffies = jiffies64_to_cputime64(get_jiffies_64());
+ total_ticks = (unsigned int)cputime64_sub(cur_jiffies,
+ rcpu->prev_wall);
+ rcpu->prev_wall = cur_jiffies;
+
+ total_idle_ticks = get_cpu_idle_time(cpu);
+ idle_ticks = (unsigned int) cputime64_sub(total_idle_ticks,
+ rcpu->prev_idle);
+ rcpu->prev_idle = total_idle_ticks;
+
+ /* We do a very dumb calculation to update the LEDs for now,
+ * we'll do better once we have actual PWM implemented
+ */
+ load = (8 * (total_ticks - idle_ticks)) / total_ticks;
+
+ offset = cpu << 3;
+ for (i = 0; i < 8; i++)
+ rm->ubuf[i + offset] = (load > i) ? 0xff : 0;
+
+ schedule_delayed_work_on(cpu, &rcpu->sniffer,
+ msecs_to_jiffies(CPU_SAMPLING_RATE));
+}
+
+static void rackmeter_init_cpu_sniffer(struct rackmeter *rm)
+{
+ unsigned int cpu;
+
+ /* This driver works only with 1 or 2 CPUs numbered 0 and 1,
+ * but that's really all we have on Apple Xserve
+ */
+ for_each_online_cpu(cpu) {
+ struct rackmeter_cpu *rcpu;
+
+ if (cpu > 1)
+ continue;
+ rcpu = &rm->cpu[cpu];;
+ INIT_WORK(&rcpu->sniffer, rackmeter_do_timer, rm);
+ rcpu->prev_idle = get_cpu_idle_time(cpu);
+ rcpu->prev_wall = jiffies64_to_cputime64(get_jiffies_64());
+ schedule_delayed_work_on(cpu, &rm->cpu[cpu].sniffer,
+ msecs_to_jiffies(CPU_SAMPLING_RATE));
+ }
+}
+
+static int rackmeter_setup(struct rackmeter *rm)
+{
+ pr_debug("rackmeter: setting up i2s..\n");
+ rackmeter_setup_i2s(rm);
+
+ pr_debug("rackmeter: setting up default pattern..\n");
+ rackmeter_set_default_pattern(rm);
+
+ pr_debug("rackmeter: setting up dbdma..\n");
+ rackmeter_setup_dbdma(rm);
+
+ pr_debug("rackmeter: start CPU measurements..\n");
+ rackmeter_init_cpu_sniffer(rm);
+
+ printk(KERN_INFO "RackMeter initialized\n");
+
+ return 0;
+}
+
+/* XXX FIXME: No PWM yet, this is 0/1 */
+static u32 rackmeter_calc_sample(struct rackmeter *rm, unsigned int index)
+{
+ int led;
+ u32 sample = 0;
+
+ for (led = 0; led < 16; led++) {
+ sample >>= 1;
+ sample |= ((rm->ubuf[led] >= 0x80) << 15);
+ }
+ return (sample << 17) | (sample >> 15);
+}
+
+static irqreturn_t rackmeter_irq(int irq, void *arg, struct pt_regs *regs)
+{
+ struct rackmeter *rm = arg;
+ struct rackmeter_dma *db = rm->dma_buf_v;
+ unsigned int mark, i;
+ u32 *buf;
+
+ /* Flush PCI buffers with an MMIO read. Maybe we could actually
+ * check the status one day ... in case things go wrong, though
+ * this never happened to me
+ */
+ (void)in_le32(&rm->dma_regs->status);
+
+ /* Make sure the CPU gets us in order */
+ rmb();
+
+ /* Read mark */
+ mark = db->mark;
+ if (mark != 1 && mark != 2) {
+ printk(KERN_WARNING "rackmeter: Incorrect DMA mark 0x%08x\n",
+ mark);
+ /* We allow for 3 errors like that (stale DBDMA irqs) */
+ if (++rm->stale_irq > 3) {
+ printk(KERN_ERR "rackmeter: Too many errors,"
+ " stopping DMA\n");
+ DBDMA_DO_RESET(rm->dma_regs);
+ }
+ return IRQ_HANDLED;
+ }
+
+ /* Next buffer we need to fill is mark value */
+ buf = mark == 1 ? db->buf1 : db->buf2;
+
+ /* Fill it now. This routine converts the 8 bits depth sample array
+ * into the PWM bitmap for each LED.
+ */
+ for (i = 0; i < SAMPLE_COUNT; i++)
+ buf[i] = rackmeter_calc_sample(rm, i);
+
+
+ return IRQ_HANDLED;
+}
+
+static int rackmeter_probe(struct macio_dev* mdev,
+ const struct of_device_id *match)
+{
+ struct device_node *i2s = NULL, *np = NULL;
+ struct rackmeter *rm = NULL;
+ struct resource ri2s, rdma;
+ int rc = -ENODEV;
+
+ pr_debug("rackmeter_probe()\n");
+
+ /* Get i2s-a node */
+ while ((i2s = of_get_next_child(mdev->ofdev.node, i2s)) != NULL)
+ if (strcmp(i2s->name, "i2s-a") == 0)
+ break;
+ if (i2s == NULL) {
+ pr_debug(" i2s-a child not found\n");
+ goto bail;
+ }
+ /* Get lightshow or virtual sound */
+ while ((np = of_get_next_child(i2s, np)) != NULL) {
+ if (strcmp(np->name, "lightshow") == 0)
+ break;
+ if ((strcmp(np->name, "sound") == 0) &&
+ get_property(np, "virtual", NULL) != NULL)
+ break;
+ }
+ if (np == NULL) {
+ pr_debug(" lightshow or sound+virtual child not found\n");
+ goto bail;
+ }
+
+ /* Create and initialize our instance data */
+ rm = kzalloc(sizeof(struct rackmeter), GFP_KERNEL);
+ if (rm == NULL) {
+ printk(KERN_ERR "rackmeter: failed to allocate memory !\n");
+ rc = -ENOMEM;
+ goto bail_release;
+ }
+ rm->mdev = mdev;
+ rm->i2s = i2s;
+ dev_set_drvdata(&mdev->ofdev.dev, rm);
+ /* Check resources availability. We need at least resource 0 and 1 */
+#if 0 /* Use that when i2s-a is finally an mdev per-se */
+ if (macio_resource_count(mdev) < 2 || macio_irq_count(mdev) < 2) {
+ printk(KERN_ERR
+ "rackmeter: found match but lacks resources: %s"
+ " (%d resources, %d interrupts)\n",
+ mdev->ofdev.node->full_name);
+ rc = -ENXIO;
+ goto bail_free;
+ }
+ if (macio_request_resources(mdev, "rackmeter")) {
+ printk(KERN_ERR
+ "rackmeter: failed to request resources: %s\n",
+ mdev->ofdev.node->full_name);
+ rc = -EBUSY;
+ goto bail_free;
+ }
+ rm->irq = macio_irq(mdev, 1);
+#else
+ rm->irq = irq_of_parse_and_map(i2s, 1);
+ if (rm->irq == NO_IRQ ||
+ of_address_to_resource(i2s, 0, &ri2s) ||
+ of_address_to_resource(i2s, 1, &rdma)) {
+ printk(KERN_ERR
+ "rackmeter: found match but lacks resources: %s",
+ mdev->ofdev.node->full_name);
+ rc = -ENXIO;
+ goto bail_free;
+ }
+#endif
+
+ pr_debug(" i2s @0x%08x\n", (unsigned int)ri2s.start);
+ pr_debug(" dma @0x%08x\n", (unsigned int)rdma.start);
+ pr_debug(" irq %d\n", rm->irq);
+
+ rm->ubuf = (u8 *)__get_free_page(GFP_KERNEL);
+ if (rm->ubuf == NULL) {
+ printk(KERN_ERR
+ "rackmeter: failed to allocate samples page !\n");
+ rc = -ENOMEM;
+ goto bail_release;
+ }
+
+ rm->dma_buf_v = dma_alloc_coherent(&macio_get_pci_dev(mdev)->dev,
+ sizeof(struct rackmeter_dma),
+ &rm->dma_buf_p, GFP_KERNEL);
+ if (rm->dma_buf_v == NULL) {
+ printk(KERN_ERR
+ "rackmeter: failed to allocate dma buffer !\n");
+ rc = -ENOMEM;
+ goto bail_free_samples;
+ }
+#if 0
+ rm->i2s_regs = ioremap(macio_resource_start(mdev, 0), 0x1000);
+#else
+ rm->i2s_regs = ioremap(ri2s.start, 0x1000);
+#endif
+ if (rm->i2s_regs == NULL) {
+ printk(KERN_ERR
+ "rackmeter: failed to map i2s registers !\n");
+ rc = -ENXIO;
+ goto bail_free_dma;
+ }
+#if 0
+ rm->dma_regs = ioremap(macio_resource_start(mdev, 1), 0x100);
+#else
+ rm->dma_regs = ioremap(rdma.start, 0x100);
+#endif
+ if (rm->dma_regs == NULL) {
+ printk(KERN_ERR
+ "rackmeter: failed to map dma registers !\n");
+ rc = -ENXIO;
+ goto bail_unmap_i2s;
+ }
+
+ rc = rackmeter_setup(rm);
+ if (rc) {
+ printk(KERN_ERR
+ "rackmeter: failed to initialize !\n");
+ rc = -ENXIO;
+ goto bail_unmap_dma;
+ }
+
+ rc = request_irq(rm->irq, rackmeter_irq, 0, "rackmeter", rm);
+ if (rc != 0) {
+ printk(KERN_ERR
+ "rackmeter: failed to request interrupt !\n");
+ goto bail_stop_dma;
+ }
+ of_node_put(np);
+ return 0;
+
+ bail_stop_dma:
+ DBDMA_DO_RESET(rm->dma_regs);
+ bail_unmap_dma:
+ iounmap(rm->dma_regs);
+ bail_unmap_i2s:
+ iounmap(rm->i2s_regs);
+ bail_free_dma:
+ dma_free_coherent(&macio_get_pci_dev(mdev)->dev,
+ sizeof(struct rackmeter_dma),
+ rm->dma_buf_v, rm->dma_buf_p);
+ bail_free_samples:
+ free_page((unsigned long)rm->ubuf);
+ bail_release:
+#if 0
+ macio_release_resources(mdev);
+#endif
+ bail_free:
+ kfree(rm);
+ bail:
+ of_node_put(i2s);
+ of_node_put(np);
+ dev_set_drvdata(&mdev->ofdev.dev, NULL);
+ return rc;
+}
+
+static int rackmeter_remove(struct macio_dev* mdev)
+{
+ struct rackmeter *rm = dev_get_drvdata(&mdev->ofdev.dev);
+
+ /* Clear reference to private data */
+ dev_set_drvdata(&mdev->ofdev.dev, NULL);
+
+ /* Stop/reset dbdma */
+ DBDMA_DO_RESET(rm->dma_regs);
+
+ /* Release the IRQ */
+ free_irq(rm->irq, rm);
+
+ /* Unmap registers */
+ iounmap(rm->dma_regs);
+ iounmap(rm->i2s_regs);
+
+ /* Free DMA */
+ dma_free_coherent(&macio_get_pci_dev(mdev)->dev,
+ sizeof(struct rackmeter_dma),
+ rm->dma_buf_v, rm->dma_buf_p);
+
+ /* Free samples */
+ free_page((unsigned long)rm->ubuf);
+
+#if 0
+ /* Release resources */
+ macio_release_resources(mdev);
+#endif
+
+ /* Get rid of me */
+ kfree(rm);
+
+ return 0;
+}
+
+static int rackmeter_shutdown(struct macio_dev* dev)
+{
+ return 0;
+}
+
+static struct of_device_id rackmeter_match[] = {
+ { .name = "i2s" },
+ { }
+};
+
+static struct macio_driver rackmeter_drv = {
+ .name = "rackmeter",
+ .owner = THIS_MODULE,
+ .match_table = rackmeter_match,
+ .probe = rackmeter_probe,
+ .remove = rackmeter_remove,
+ .shutdown = rackmeter_shutdown,
+};
+
+
+static int __init rackmeter_init(void)
+{
+ pr_debug("rackmeter_init()\n");
+
+ return macio_register_driver(&rackmeter_drv);
+}
+
+static void __exit rackmeter_exit(void)
+{
+ pr_debug("rackmeter_exit()\n");
+
+ macio_unregister_driver(&rackmeter_drv);
+}
+
+module_init(rackmeter_init);
+module_exit(rackmeter_exit);
+
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Benjamin Herrenschmidt <benh@kernel.crashing.org>");
+MODULE_DESCRIPTION("RackMeter: Support vu-meter on XServe front panel");
Index: linux-irq-work/drivers/macintosh/Kconfig
===================================================================
--- linux-irq-work.orig/drivers/macintosh/Kconfig 2006-07-10 16:12:38.000000000 +1000
+++ linux-irq-work/drivers/macintosh/Kconfig 2006-07-10 16:45:50.000000000 +1000
@@ -218,4 +218,11 @@
tristate "Support for ANS LCD display"
depends on ADB_CUDA && PPC_PMAC
+config PMAC_RACKMETER
+ tristate "Support for Apple XServe front panel LEDs"
+ depends on PPC_PMAC
+ help
+ This driver procides some support to control the front panel
+ blue LEDs "vu-meter" of the XServer macs.
+
endmenu
Index: linux-irq-work/drivers/macintosh/Makefile
===================================================================
--- linux-irq-work.orig/drivers/macintosh/Makefile 2006-07-10 16:12:38.000000000 +1000
+++ linux-irq-work/drivers/macintosh/Makefile 2006-07-10 16:45:50.000000000 +1000
@@ -42,3 +42,4 @@
windfarm_smu_sensors.o \
windfarm_max6690_sensor.o \
windfarm_lm75_sensor.o windfarm_pid.o
+obj-$(CONFIG_PMAC_RACKMETER) += rack-meter.o
Index: linux-irq-work/include/asm-powerpc/dbdma.h
===================================================================
--- linux-irq-work.orig/include/asm-powerpc/dbdma.h 2006-07-10 16:12:38.000000000 +1000
+++ linux-irq-work/include/asm-powerpc/dbdma.h 2006-07-10 16:45:50.000000000 +1000
@@ -95,7 +95,13 @@
#define DBDMA_DO_STOP(regs) do { \
out_le32(&((regs)->control), (RUN|FLUSH)<<16); \
while(in_le32(&((regs)->status)) & (ACTIVE|FLUSH)) \
- ; \
+ ; \
+} while(0)
+
+#define DBDMA_DO_RESET(regs) do { \
+ out_le32(&((regs)->control), (ACTIVE|DEAD|WAKE|FLUSH|PAUSE|RUN)<<16);\
+ while(in_le32(&((regs)->status)) & (RUN)) \
+ ; \
} while(0)
#endif /* _ASM_DBDMA_H_ */
^ permalink raw reply
* Re: [PATCH] powerpc: unify 32 and 64bit panic_on_oops messages
From: Horms @ 2006-07-11 1:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Anton Blanchard
In-Reply-To: <20060706101521.GE26612@verge.net.au>
First up, sorry for the silly subject in the original post, that was an
error.
Secondly, when I sent the x86_64 version of this patch Andi Kleen
pointed out that calling ssleep() will just cause an early panic if the
code is in interrupt context. Accordingly, I plan to post patches to
remoove the ssleep(). So please ignore the patch that is bellow.
Thanks
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
On Thu, 6 Jul 2006 19:15:22 +0900, Horms wrote:
> I have been looking at unifying the way that panic_on_oops logs
> what it is doing between the different architectures that implement it.
> The first cab off the rank is the patch below which removes a seemingly
> silly difference between the behaviour on 32 and 64 bit powerpc.
>
> I have not been able to test this as I do not have a ppc64 machine
> at my disposal. However I did test that it compiles thanks to
> the wonders of crosstool.
>
> Signed-Off-By: Horms <horms@verge.net.au>
>
> arch/powerpc/kernel/traps.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 52f5659..908231a 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -157,10 +157,8 @@ #endif
> panic("Fatal exception in interrupt");
>
> if (panic_on_oops) {
> -#ifdef CONFIG_PPC64
> printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
> ssleep(5);
> -#endif
> panic("Fatal exception");
> }
> do_exit(err);
^ permalink raw reply
* Re: ppc -> powerpc porting
From: Benjamin Herrenschmidt @ 2006-07-10 21:43 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0607102135330.10561@poirot.grange>
On Mon, 2006-07-10 at 21:43 +0200, Guennadi Liakhovetski wrote:
> On Mon, 10 Jul 2006, Vitaly Bordug wrote:
>
> > On Mon, 10 Jul 2006 12:14:24 -0500
> > "Rune Torgersen" <runet@innovsys.com> wrote:
> >
> > > To make my life a little easier: Does anybody have a list of stuff to
> > > watch out for/need to do when porting a board from ppc to powerpc?
> > > The board uses a Freescale 8265 and runs under 2.6.17, using platfrom
> > > device support for accessing fs_enet driver.
>
> Look at Documentation/powerpc/booting-without-of.txt -
You guys be careful, if you use OpenPIC/MPIC, that there is an error in
that documentation for the interrupt specifier definition. I'll send an
updated documentation soon with some more details about the OF interrupt
tree, but in the meantime, the proper sense encoding for MPIC is:
0 = rising edge
1 = negative level
2 = positive level
3 = falling edge
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Make snd-aoa cope with lack of line-output-detect property
From: Benjamin Herrenschmidt @ 2006-07-10 21:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1152537082.30697.37.camel@localhost>
On Mon, 2006-07-10 at 15:11 +0200, Johannes Berg wrote:
> On Mon, 2006-07-10 at 22:39 +1000, Paul Mackerras wrote:
> > The snd-aoa stuff falls over on my G4 powerbook (1.5GHz Albook) with a
> > null pointer dereference in of_find_property. It turns out that this
> > was because it couldn't find a device node for the line-output detect
> > GPIO. This patch fixes it.
>
> That's interesting. I thought I was running this code. Hmm :>
Slightly different model I suppose, 5,4 vs. 5,6 no ? Paul, can you send
Johannes a dumb of your device-tree ?
> I should probably drop the get_irq function completely and do that in
> line. And yes, that should be NO_IRQ I guess. I'll prepare a patch
> later.
Ben.
^ permalink raw reply
* Re: Linux v2.6.18-rc1
From: Benjamin Herrenschmidt @ 2006-07-10 21:17 UTC (permalink / raw)
To: Alan Cox; +Cc: Steve Fox, linuxppc-dev, linux-kernel
In-Reply-To: <1152542413.27368.131.camel@localhost.localdomain>
> That in repeat generally means the IRQ logic on the platform has been
> broken. If we don't get interrupts we don't work very well.
>
> Also check if booting with "nodma" set on the relevant ide interface
> makes a difference. Just to be sure. If it does then submit patches to
> fix the bug.
it's most certainly an irq problem as I just rewrote the irq logic of
powerpc :) There have been some issues and I've just sent some new
patches fixing them, let's see if that's enough. I'll give a js20 a try
today at work.
Ben.
^ permalink raw reply
* Re: Linux v2.6.18-rc1
From: Benjamin Herrenschmidt @ 2006-07-10 21:16 UTC (permalink / raw)
To: will_schmidt; +Cc: Steve Fox, linuxppc-dev, linux-kernel
In-Reply-To: <1152537672.28828.4.camel@farscape.rchland.ibm.com>
On Mon, 2006-07-10 at 08:21 -0500, Will Schmidt wrote:
> On Sun, 2006-09-07 at 20:34 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2006-07-07 at 10:41 -0500, Steve Fox wrote:
> > > We've got a ppc64 machine that won't boot with this due to an IDE error.
> >
> > What machine precisely ?
>
> I see a slightly more verbose version on a JS20 blade.
Can you try with the new patches I posted yesterday ?
Ben.
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Arnd Bergmann @ 2006-07-10 20:49 UTC (permalink / raw)
To: Mike Kravetz
Cc: Bryan Rosenburg, linuxppc-dev, Nathan Lynch, Christopher Yeoh
In-Reply-To: <20060710203510.GA30793@w-mikek2.ibm.com>
On Monday 10 July 2006 22:35, Mike Kravetz wrote:
> On Thu, Jun 22, 2006 at 03:56:09PM -0700, Mike Kravetz wrote:
> > This version addresses all comments received except Arnd's issue
> > with an #ifdef for each function in the assembly file.
>
> I was thinking of changing the names of all the assembly routines from
> plpar_hcall_*() to plpar_hcall_*_asm(). The instrumented version of the
> routines would be named plpar_hcall_*_inst(). Then, the header file
> would contain definitions such as:
>
> #ifdef CONFIG_HCALL_STATS
> #define plpar_hcall_*() plpar_hcall_*_inst()
> .
> #else
> #define plpar_hcall_*() plpar_hcall_*_asm()
> .
> #endif
>
> Is that any better than all the individual #ifdefs in the .S file? Is it
> still too ugly?
>
I guess it's better to have the #ifdef in the header file, but then
again, you could just as well save some source lines doing
#ifndef CONFIG_HCALL_STATS
#define plpar_hcalldef(x) plpar_call_ ## x ## _asm
#else
#define plpar_hcalldef(x) plpar_call_ ## x ## _inst
#endif
#define plpar_call_foo plpar_hcalldef(foo)
Arnd <><
^ permalink raw reply
* FW: ppc -> powerpc porting
From: Rune Torgersen @ 2006-07-10 20:38 UTC (permalink / raw)
To: linuxppc-dev
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]=20
> Sent: Monday, July 10, 2006 12:42
> We have mpc8272 under arch/powerpc as work-in-progress,=20
> latest fs_enet being merged now.
>=20
> I think it'll be a week or 2 before first submit, so it may=20
> make sense just to wait a bit :)
Ok. I sor of used the ppc version of the 8272 to get fs_enet working.=20
fs_enet is not my main concern. My concern is everything else... OF
tree, new IRQ code (we have two local IRQ muxes in FPGA modeled afrer
the PCI mux on 8266ADS). Our current port is running on 2.6.12. We have
a 2.6 17 port working, but have not started using it yet. I want to wait
until we have ported to powerpc/=20
^ permalink raw reply
* RE: ppc -> powerpc porting
From: Rune Torgersen @ 2006-07-10 20:36 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20060710214158.1d8dcf2c@vitb.ru.mvista.com>
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]=20
> Sent: Monday, July 10, 2006 12:42
> We have mpc8272 under arch/powerpc as work-in-progress,=20
> latest fs_enet being merged now.
>=20
> I think it'll be a week or 2 before first submit, so it may=20
> make sense just to wait a bit :)
Ok. I sor of used the ppc version of the 8272 to get fs_enet working.=20
fs_enet is not my main concern. My concern is everything else... OF
tree, new IRQ code (we have two local IRQ muxes in FPGA modeled afrer
the PCI mux on 8266ADS). Our current port is running on 2.6.12. We have
a 2.6 17 port working, but have not started using it yet. I want to wait
until we have ported to powerpc/=20
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-07-10 20:35 UTC (permalink / raw)
To: linuxppc-dev
Cc: Bryan Rosenburg, Christopher Yeoh, Nathan Lynch, Arnd Bergmann
In-Reply-To: <20060622225609.GA4877@w-mikek2.ibm.com>
On Thu, Jun 22, 2006 at 03:56:09PM -0700, Mike Kravetz wrote:
> This version addresses all comments received except Arnd's issue
> with an #ifdef for each function in the assembly file.
I was thinking of changing the names of all the assembly routines from
plpar_hcall_*() to plpar_hcall_*_asm(). The instrumented version of the
routines would be named plpar_hcall_*_inst(). Then, the header file
would contain definitions such as:
#ifdef CONFIG_HCALL_STATS
#define plpar_hcall_*() plpar_hcall_*_inst()
.
#else
#define plpar_hcall_*() plpar_hcall_*_asm()
.
#endif
Is that any better than all the individual #ifdefs in the .S file? Is it
still too ugly?
I'm open to any suggestions.
Thanks,
--
Mike
^ permalink raw reply
* Re: ppc -> powerpc porting
From: Guennadi Liakhovetski @ 2006-07-10 19:43 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20060710214158.1d8dcf2c@vitb.ru.mvista.com>
On Mon, 10 Jul 2006, Vitaly Bordug wrote:
> On Mon, 10 Jul 2006 12:14:24 -0500
> "Rune Torgersen" <runet@innovsys.com> wrote:
>
> > To make my life a little easier: Does anybody have a list of stuff to
> > watch out for/need to do when porting a board from ppc to powerpc?
> > The board uses a Freescale 8265 and runs under 2.6.17, using platfrom
> > device support for accessing fs_enet driver.
Look at Documentation/powerpc/booting-without-of.txt - there's a section
on that. I am attempting the same sort of conversion for an embedded
mpc8241 board, so, would be glad to share ideas / experiences, I think, we
won't offend others if we just discuss our problems on this list, maybe
even somebody else will find it useful:-)) The first step I am trying to
perform is to switch to the device-tree boot. Does your board already use
it or does it have OF?
> We have mpc8272 under arch/powerpc as work-in-progress, latest fs_enet being merged now.
>
> I think it'll be a week or 2 before first submit, so it may make sense just to wait a bit :)
Yep, you could wait, but, you see, an example will be great, but, I am
afraid, all ports will be pretty different, so, we'll all have to "invent
the wheel." Is your code available somewhere in some repository to have a
look at?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ 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