A Rootfs problem
When I use mke2fs format a partition, then mount it, cause the following error message: VFS: Can't find ext3 filesystem on /dev/hda1. VFS: Can't find an ext2 filesystem on /dev/hda1. Unable ro identify CD-ROM format. VFS: Can't find a romfs filesystem on dev hda1. mount: Mounting /dev/hda1 on /root/map failed: Invalid argument. Had I lost something in kernel configuration or RootFS?? Thanks, JohnsonCheng -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050809/a93617cb/attachment.htm
Fwd: [linuxppc] 2.6.12-3 header asm/usb.h missing ?
Begin forwarded message: From: Thomas S. thomas at schnuerer-online.de Date: August 8, 2005 4:48:03 PM CDT To: linux-kernel at vger.kernel.org Subject: [linuxppc] 2.6.12-3 header asm/usb.h missing ? Hello, Im using Kernel PPC on a MPC5200 board and try to use the onChip USB. In file /drivers/usb/host/ohci-ppc-soc.c a file asm/usb.h is included which seems to be missing. I cant find it anywhere , any ideas ? Thomas - To unsubscribe from this list: send the line unsubscribe linux- kernel in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Volunteers to test i2c-algo-8xx on v2.6?
Hello, Aristeu Sergio Rozanski Filho
In message 2005-08-08 21:05:23 aris at cathedrallabs.org you wrote:
Hi,
seems Debora need this too for 2.4 version. Debora, could you please
generate a diff against latest Wolfgang's development tree and submit to
him?
thank Aristeu,
I'm working with Wolfgang's ELDK-3.1.1,
diff against Wolfgang's ELDK-3.1.1 patch is attached.
= = = = = = = = = = = = = = = = = = = =
Debora Liu
deboralh at fel.com.cn
2005-08-09
begin 600 i2c_algo_8xx-port_to_2_6-eldk_3.1.1.patch
M9EF9B`M3F%R=2!L:6YUTR+C0N,C4O9')I=F5RR]I,F,O:3)C+6%L9V\M
M.'AX+F,@;EN=7 at M,BXT+C(U+65L9LO9')I=F5RR]I,F,O:3)C+6%L9V\M
M.'AX+F,*+2TM(QI;G5X+3(N-XR-2]DFEV97)S+VDR8R]I,F,M86QG;RTX
M'@N8PDR,#`U+3`X+3`Y(#$S.C`P.C,R+C`P,#`P,#`P,`K,[EMAIL PROTECTED],`HK*RL@
M;EN=7 at M,BXT+C(U+65L9LO9')I=F5RR]I,F,O:3)C+6%L9V\M.'AX+F,)
M,C`P,RTQ,BTS,`Q.#HT.#HT,BXP,#`P,#`P,[EMAIL PROTECTED],[EMAIL PROTECTED]
M(LT-PW($!`B`C:6YC;'5D92`\;EN=7 at O:3)C+6%L9V\M.'[EMAIL PROTECTED]B`*
M(-D969I;F4 at 0U!-7TU!6%]214%$34Q,PHM+RH at 5')Y('5N8V]M;65N=!T
M:ES(EF('EO=2!H879E(%N(]L95R($-052AE87)L:65R('1H86X@F5V
M($0T*2`J+PHM+RH@(V1E9FEN92!),D-?0TA)4%]%4E)[EMAIL PROTECTED]W1A
M=EC(-H87(@*FUO9'5L95]N86UE(#T@(FDR8U]A;=O7SAX([BTC95F
M:6YE($1%0E5'4AL979E;P@P@2XN+BD at 9\@R!BT)0D):[EMAIL PROTECTED]-P
M;5]D96)U9R`^/2!L979E;D at 7`HM0D)0EPFEN=LH2T523E]$14)51R`B
M)7,Z((@P at 7`HM0D)0D@(`@(`@;6]D=6QE7VYA;64L(,C('DI.R!
MBT)0D)?2!W:EL92 at P*0HMBLO*B`C95F:6YE($DR0U]#2$E07T524D%4
M02`J+R`O*B!4[EMAIL PROTECTED];VUM96YT('1H:7,@:68@6]U(AA=F4 at 86X@;VQD
M97(@0U!5*5AFQI97(@=AA;B!R978 at 1#0I(HOB!S=%T:6,@=V%I=%]Q
M=65U95]H96%D7W0@:6EC7W=A:70[B!S=%T:6,@=7-H;W)T(')?=)AV4L
M(')?F)AV4[[EMAIL PROTECTED](LU,RPQ,2!`0`H@B!S=%T:6,@('9O
M:60*(-P;5]I:6-?:6YT97)R=7!T*'9O:[EMAIL PROTECTED]P@W1R=6-T('!T
M7W)E9W,@*G)E9W,IBU[BL@PH@79O;%T:6QE(DR8SAX%]T(II,F,@
M/2`H:3)C.'[EMAIL PROTECTED]:60[B`*+0E$14)51U`H,BP@(F-P;5]I:6-?
M:6YT97)R=7!T*1E=E]I9#TEE;B(L(1E=E]I9D[BL):[EMAIL PROTECTED]-P;5]D
M96)U9R`^(#$IBL)7!R:6YT:RA+15).7T1%0E5'()CU?:6EC7VEN=5R
MG5P=AD979?:60])7`I7XB+!D979?:60I.PH@B`C:69D968 at 23)#7T-(
M25!?15)2051!B`)+RH at 0VAI!EG)A=$L(-L96%R(5N86)L92X*0$`@
M+3DR+#@*S at T+#@0$`*(`EU;G-I9VYE9!C:%R()R9SL*(`EB9%]T(IB
M9`](AB9%]T(HI7U]R97,[B`*+0E$14)51U`H,2P@(F-P;5]I:6-?:6YI
M=@I(T@:6EP/25P7XB+!I:7`I.PHK6EF(ACU?95B=6I('!R:6YT
M:RA+15).7T1%0E5'()CU?:6EC7VEN:70H*2`M(EI#TE%QN(BQI:7`I
M.PH@B`)+RH at 26YI=EA;EZ92!T:4@%R86UE=5R(')A;2X*([EMAIL PROTECTED]
M92!N965D('1O(UA:V4@W5R92!M86YY('1H:6YGR!AF4@:6YI=EA;EZ
[EMAIL PROTECTED]\@F5R;[EMAIL PROTECTED],BPW(LQ,#0L-R!`0`H@2\J(%-E=!U!T
M:4 at 24E#('!AF%M971EG,@:[EMAIL PROTECTED]AE('!AF%M971EB!R86TNB`)*B\*
M(`EI:7`M/FEI8U]T8F%S92`](')?=)AV4@/2!CU?861AT^9'!?861D
MCL*+0EI:7`M/FEI8U]R8F%S92`](')?F)AV4@/2!CU?861AT^9'!?
M861DB`K('-IF5O9BAC8F1?=[EMAIL PROTECTED]6EIT^:6EC7W)B87-E(#T@
ME]R8F%S92`](-P;5]A9%P+3YD%]A91R(L@VEZ96]F*-B9%]T*2HR
M.PH@B`):6EP+3YI:6-?=9CB`](%--0U]%0CL*(`EI:7`M/FEI8U]R9F-R
M(#T at 4TU#7T5.PI`0`M,34W+#@*S$T.2PQ,!`0`H@B`)+RH at 26YS=%L
M;!I;G1EG)U'0@:%N9QEBX*(`DJ+PHM41%0E5'4@Q+`B26YS=%L
M;!)4U(@9F]R($E242`E9%QN(BP at 0U!-5D5#7TDR0RD[BL):[EMAIL PROTECTED]-P;5]D
M96)U9RD@PHK0EPFEN=[EMAIL PROTECTED]54@(B5S6R5D72!);G-T86QL
M($E34B!F;W(@25)1(5D7XB+`HK0D)7U]F=6YC7U\L7U],24Y%7U\L($-0
M359%0U]),D,I.PHK7T*(`ECU?:6YS=%L;%]H86YD;5R*$-0359%0U])
M,D,L(-P;5]I:6-?:6YT97)R=7!T+`H=F]I9`J*6DR8RD[B!]B`*0$`@
M+3$W,RPW(LQ-C at L-R!`0`H@6DR8RT^:3)C7VDR8VUR(#T@,#L*(`EI,F,M
M/FDR8U]I,F-EB`](#!X9F8[B`*+0ER971UFX@,#L**PER971UFXH,D[
MB!]B`*('-T871I8R!V;VEDD!`(TR,#DL-R`K,C`T+#@0$`*(`EI9B`H
M8W!M+3YR96QO8R`]/2`P*2![(\J(UI8W)O(-O94 at 9ES86)[EMAIL PROTECTED]
M(`D)=F]L871I;4 at 8W!M.'[EMAIL PROTECTED](#T at 8W!M+3YC#L*(`HM0E$14)5
M1U`H,2P@(F9OF-E7V-L;W-E*E;B(I.PHK0EI9B`H8W!M7V1E8G5G*2!P
MFEN=LH2T523E]$14)51R`B9F]R8V5?8VQOV4H*5QN(BD[B`)6-P+3YC
M%]C-R(#T*(`D)6UK7V-R7V-M9A#4$U?0U)?0TA?23)#+!#4$U?0U)?
M0TQ/4T5?4EA1[EMAIL PROTECTED]@0D)0U!-7T-27T9,[EMAIL PROTECTED](S.PX(LR,S,L
M.2!`0`H@0ER971UFX at +45)3E9!3#L*(`H@2\J(-H96-K(9OB!A;F0@
M=7-E($@;6ECF]C;V1E(')E;]C871I;VX@%T8V@@*B\*+0EI9B`H8W!M
M+3YR96QO8RD**PEI9B`H8W!M+3YR96QO8RD@PH@0ECU?F5S971?:6EC
M7W!AF%MRAI:7`I.PHK7T*(`H@71B98@/2`H8V)[EMAIL PROTECTED]/F-P
M7V1P;65M6VEIT^:6EC7W1B87-E73L*(`ER8F1F([EMAIL PROTECTED]-B9%]T(HI)F-P
M+3YC%]DUE;5MI:7`M/FEI8U]R8F%S95T[D!`(TR-3(L.2`K,C0X+#D@
M0$`*(`ET8B`](AU7V-H87(@*BDH*AU:6YT*71B(L@,34I([EMAIL PROTECTED]
M(`ET8ELP72`](%B71E.PD)+RH at 15V:6-E(%D9')EW, at 8GET92!W+W)W
M(9L86@*B\*(`HM69L=7-H7V1C86-H95]R86YG92 at H=6YS:6=N960@;]N
[EMAIL PROTECTED](L(AU;G-I9VYE9!L;VYG*2`H=(@*R`Q*2D[BL)9FQUVA?9-A
M8VAE7W)A;F=E*AU;G-I9VYE9!L;[EMAIL PROTECTED]'5NVEG;F5D(QO;FI
M(AT8BLQ*2D[B`*+0E$14)51U`H,2P@(F-P;5]I:6-?F5A9AA8GET93TP
M5X*5QN(BP at 86)Y=4I.PHK6EF(ACU?95B=6I('!R:6YT:RA+15).
M7T1%0E5'()CU?:6EC7W)E860H86)Y=4],'@EE;B(L(%B71E*3L*
M(`H@71B98M/F-B9%]B=69A91R(#T at 7U]P82AT8BD[B`)=)D9BT^8V)D
M7V1A=QE;B`](-O=6YT(L@,[EMAIL PROTECTED](W,RPR-B`K,C8Y+#,Q($!`B`)
about building RTAI 24.1.12 at Linux 2.4.25
Hi All, I got some error while make RTAI, anybody know how to fix it please tell me,thanks. 1.I used ELDK version is ELDK version 3.1 ppc_8xx: Build 2004-11-10 2.My Linux is 2.4.25 -D2005-06-24 has been patch with patch-denx-linuxppc_2_4_devel-2005_06_23_1722 3.My hardware is MPC852T 32M SDRAM 8M Flash 4.I step by step build my RTAI by reading README.install, but stil fail. [root at banana rtai-24.1.12]# make mkdir -p modules make -C rtaidir CFLAGS=-I /root/rtai-24.1.12/include -I . -D__KERNEL__ -I/opt/eldk/usr/src/linuxppc_2_4_devel/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/opt/eldk/usr/src/linuxppc_2_4_devel/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -DMODULE -DMODULE MAKING_MODULES=1 modules make[1]: Entering directory `/root/rtai-24.1.12/rtaidir' /opt/eldk/usr/bin/ppc_8xx-gcc -I /root/rtai-24.1.12/include -I . -D__KERNEL__ -I/opt/eldk/usr/src/linuxppc_2_4_devel/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/opt/eldk/usr/src/linuxppc_2_4_devel/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -DMODULE -DMODULE -I. -DEXPORT_SYMTAB -c rtai-arch.c /root/rtai-24.1.12/include/asm/rtai_srq.h: In function `rtai_srq': /root/rtai-24.1.12/include/asm/rtai_srq.h:32: error: asm-specifier for variable `__sc_3' conflicts with asm clobber list /root/rtai-24.1.12/include/asm/rtai_srq.h:32: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /root/rtai-24.1.12/include/asm/rtai_srq.h:32: error: asm-specifier for variable `__sc_0' conflicts with asm clobber list /root/rtai-24.1.12/include/asm/rtai_srq.h:31: confused by earlier errors, bailing out make[1]: *** [rtai-arch.o] Error 1 make[1]: Leaving directory `/root/rtai-24.1.12/rtaidir' make: *** [_mod_rtaidir] Error 2 Best Regards Rober Hsu
mpc855t I2C and SCC1
Hello, Aristeu thank you, I had test these I2C updated, no problem but if my kernel support SCC1 as eth1, console no response when hit hwclock. CPU is mpc855t. Do SCC1 as eth1 working with I2C together? = = = = = = = = = = = = = = = = = = = = Debora Liu deboralh at fel.com.cn 2005-08-09
mpc855t I2C and SCC1
Hello, Debora Liu In message 2005-08-09 15:42:51 deboralh at fel.com.cn you wrote: Do SCC1 as eth1 working with I2C together? haha, it is my question. make menuconfig [*] I2C/SPI Microcode Patch = = = = = = = = = = = = = = = = = = = = Debora Liu deboralh at fel.com.cn 2005-08-09
A configure error for samba3 on ppc
Hi, JohnsonCheng! you wrote: When I configure samba3.0.10 on ppc as following command: CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib ./configure -host=powerpc-linux I got a configure error message as following: Configure: error: cannot run test program while cross compiling See 'config.log' for more details I think this is a samba configure bug, do anybody know how to pass it? No, it's not a bug. It's exactly what the message trys to tell you. Samba wants to do some tests. But as it's not a native build, it doesn't want to execute itself for the tests. Because samba might not run on a different platform as it was built for. If you want to do the tests, you need to let to do it on the target where it was built for and not where it was built on. Samba works fine over here on ppc embedded systems. Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Flash not getting in to Query Mode while Linux Bootup
Hi All,
I am porting Linux on the custom board PMC8266 (having MPC8266
microprocessor) based on the ADS8260 board.I am using ELDK1.1.1 and
Linux2.4.24.
I am using Intel StrataFlash Memory Chip (28F256J3A) where the JFFS2 filesystem
image is
located.
I am not able to mount the file system, and I am getting the following error
message during boot up
**
CFI: Found no pmc8260 flash memory device at location zero
**
During the dry run I have figured out that the error is occuring because the
Flash is getting in to the CFI Query mode,
The code snippet as in file drivers/mtd/chips/cfi_probe.c is as following:
static int cfi_probe_chip(struct map_info *map, __u32 base,
struct flchip *chips, struct cfi_private *cfi)
{
...
...
..
cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi-device_type, NULL);
cfi_send_gen_cmd(0x98, 0x55, base, map, cfi, cfi-device_type, NULL);
...
...
..
}
As per the data sheet the command sequence to set the flash in to CFI Query
mode is correct.
But what the kernel is getting at the Query Address is the Data present at that
location,instead of the expected
Query DATA i.e Q.R.Y
Please let me know how should i get rid of this problem.
Regards,
Vikrant BasotraIndiatimes Email now powered by APIC Advantage. Help!
Help
-- next part --
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050809/e2645b9a/attachment.htm
A configure error for samba3 on ppc
Yes. But how can I pass the testing? For cross-compile environment, the HOST and the TARGET are almost not the same, so many utility can configure for cross-compile with host setting except samba. It seems not sense. Thanks, Johnson Cheng -Original Message- From: Clemens Koller [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 09, 2005 6:24 PM To: JohnsonCheng Cc: linuxppc-embedded at ozlabs.org Subject: Re: A configure error for samba3 on ppc Hi, JohnsonCheng! you wrote: When I configure samba3.0.10 on ppc as following command: CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib ./configure -host=powerpc-linux I got a configure error message as following: Configure: error: cannot run test program while cross compiling See 'config.log' for more details I think this is a samba configure bug, do anybody know how to pass it? No, it's not a bug. It's exactly what the message trys to tell you. Samba wants to do some tests. But as it's not a native build, it doesn't want to execute itself for the tests. Because samba might not run on a different platform as it was built for. If you want to do the tests, you need to let to do it on the target where it was built for and not where it was built on. Samba works fine over here on ppc embedded systems. Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Volunteers to test i2c-algo-8xx on v2.6?
Hi Debora, I'm working with Wolfgang's ELDK-3.1.1, diff against Wolfgang's ELDK-3.1.1 patch is attached. could you please send it again as plain text to make easy to review? thanks! -- Aristeu
[PATCH] Support 440EP On-Chip OHCI USB Host Controller (v2)
This updated patch adds support for the AMCC 440EP on-chip
OHCI USB host controller. I tested it on the Bamboo board
using the 2.6.13-rc6 kernel.
This patch depends on my fix invalid function name
usb_hcd_put in ohci-ppc-soc.c patch from 2005-07-20:
http://patchwork.ozlabs.org/linuxppc/patch?id=1803
Thanks to Wade Farnsworth for a bug fix.
This patch supersedes my previous patch released on
2005-07-25 and duped on 2005-07-27.
Comments are welcome.
Signed-off-by: John Otken jotken at softadvances.com
diff -uprN a/arch/ppc/platforms/4xx/ibm440ep.c
b/arch/ppc/platforms/4xx/ibm440ep.c
--- a/arch/ppc/platforms/4xx/ibm440ep.c 2005-08-04 14:56:30.0 -0500
+++ b/arch/ppc/platforms/4xx/ibm440ep.c 2005-08-05 07:21:55.0 -0500
@@ -194,8 +194,37 @@ static struct resource usb_gadget_resour
},
};
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = 0x0EF601000,
+ .end= 0x0EF60107F,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = 40,
+ .end= 40,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
static u64 dma_mask = 0xULL;
+#include asm/usb.h
+
+static struct usb_hcd_platform_data platform_data;
+
+static struct platform_device ohci_usb_device = {
+ .name = ppc-soc-ohci,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev= {
+ .dma_mask = dma_mask,
+ .coherent_dma_mask = 0xULL,
+ .platform_data = platform_data,
+ }
+};
+
static struct platform_device usb_gadget_device = {
.name = musbhsfc,
.id = 0,
@@ -208,6 +237,7 @@ static struct platform_device usb_gadget
};
static struct platform_device *ibm440ep_devs[] __initdata = {
+ ohci_usb_device,
usb_gadget_device,
};
diff -uprN a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
--- a/drivers/usb/host/Kconfig 2005-08-04 14:56:33.0 -0500
+++ b/drivers/usb/host/Kconfig 2005-08-08 18:30:58.0 -0500
@@ -81,12 +81,12 @@ config USB_OHCI_HCD
config USB_OHCI_HCD_PPC_SOC
bool OHCI support for on-chip PPC USB controller
- depends on USB_OHCI_HCD (STB03xxx || PPC_MPC52xx)
+ depends on USB_OHCI_HCD (STB03xxx || PPC_MPC52xx || 440EP)
default y
select USB_OHCI_BIG_ENDIAN
---help---
- Enables support for the USB controller on the MPC52xx or
- STB03xxx processor chip. If unsure, say Y.
+ Enables support for the USB controller on the MPC52xx,
+ STB03xxx, or 440EP processor chip. If unsure, say Y.
config USB_OHCI_HCD_PCI
bool OHCI support for PCI-bus USB controllers
@@ -105,7 +105,7 @@ config USB_OHCI_BIG_ENDIAN
config USB_OHCI_LITTLE_ENDIAN
bool
depends on USB_OHCI_HCD
- default n if STB03xxx || PPC_MPC52xx
+ default n if STB03xxx || PPC_MPC52xx || 440EP
default y
config USB_UHCI_HCD
diff -uprN a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
--- a/drivers/usb/host/ohci.h 2005-08-04 14:56:33.0 -0500
+++ b/drivers/usb/host/ohci.h 2005-08-08 18:31:04.0 -0500
@@ -560,7 +560,7 @@ static inline u32 hc32_to_cpup (const st
* some big-endian SOC implementations. Same thing happens with PSW access.
*/
-#ifdef CONFIG_STB03xxx
+#if defined(CONFIG_STB03xxx) || defined(CONFIG_440EP)
#define OHCI_BE_FRAME_NO_SHIFT 16
#else
#define OHCI_BE_FRAME_NO_SHIFT 0
diff -uprN a/drivers/usb/Kconfig b/drivers/usb/Kconfig
--- a/drivers/usb/Kconfig 2005-08-04 14:56:33.0 -0500
+++ b/drivers/usb/Kconfig 2005-08-05 06:55:33.0 -0500
@@ -25,6 +25,7 @@ config USB_ARCH_HAS_OHCI
# PPC:
default y if STB03xxx
default y if PPC_MPC52xx
+ default y if 440EP
# MIPS:
default y if SOC_AU1X00
# more:
diff -uprN a/include/asm-ppc/usb.h b/include/asm-ppc/usb.h
--- a/include/asm-ppc/usb.h 1969-12-31 17:00:00.0 -0700
+++ b/include/asm-ppc/usb.h 2005-08-05 06:13:58.0 -0500
@@ -0,0 +1,13 @@
+/*
+ * ppc/usb.h:
+ *
+ */
+#ifndef _PPC_USB_H
+#define _PPC_USB_H
+
+struct usb_hcd_platform_data {
+ int (*start) (struct platform_device *pdev);
+ void (*stop) (struct platform_device *pdev);
+};
+
+#endif /* !(_PPC_USB_H) */
Volunteers to test i2c-algo-8xx on v2.6?
Hello, Aristeu Sergio Rozanski Filho
thank Aristeu,
I'm working with Wolfgang's ELDK-3.1.1,
diff against Wolfgang's ELDK-3.1.1 patch is attached.
begin 600 i2c_algo_8xx-port_to_2_6-eldk_3.1.1.patch
M9EF9B`M3F%R=2!L:6YUTR+C0N,C4O9')I=F5RR]I,F,O:3)C+6%L9V\M
M.'AX+F,@;EN=7 at M,BXT+C(U+65L9LO9')I=F5RR]I,F,O:3)C+6%L9V\M
M.'AX+F,*+2TM(QI;G5X+3(N-XR-2]DFEV97)S+VDR8R]I,F,M86QG;RTX
M'@N8PDR,#`U+3`X+3`Y(#$S.C`P.C,R+C`P,#`P,#`P,`K,[EMAIL PROTECTED],`HK*RL@
M;EN=7 at M,BXT+C(U+65L9LO9')I=F5RR]I,F,O:3)C+6%L9V\M.'AX+F,)
M,C`P,RTQ,BTS,`Q.#HT.#HT,BXP,#`P,#`P,[EMAIL PROTECTED],[EMAIL PROTECTED]
M(LT-PW($!`B`C:6YC;'5D92`\;EN=7 at O:3)C+6%L9V\M.'[EMAIL PROTECTED]B`*
M(-D969I;F4 at 0U!-7TU!6%]214%$34Q,PHM+RH at 5')Y('5N8V]M;65N=!T
M:ES(EF('EO=2!H879E(%N(]L95R($-052AE87)L:65R('1H86X@F5V
M($0T*2`J+PHM+RH@(V1E9FEN92!),D-?0TA)4%]%4E)[EMAIL PROTECTED]W1A
M=EC(-H87(@*FUO9'5L95]N86UE(#T@(FDR8U]A;=O7SAX([BTC95F
M:6YE($1%0E5'4AL979E;P@P@2XN+BD at 9\@R!BT)0D):[EMAIL PROTECTED]-P
M;5]D96)U9R`^/2!L979E;D at 7`HM0D)0EPFEN=LH2T523E]$14)51R`B
M)7,Z((@P at 7`HM0D)0D@(`@(`@;6]D=6QE7VYA;64L(,C('DI.R!
MBT)0D)?2!W:EL92 at P*0HMBLO*B`C95F:6YE($DR0U]#2$E07T524D%4
M02`J+R`O*B!4[EMAIL PROTECTED];VUM96YT('1H:7,@:68@6]U(AA=F4 at 86X@;VQD
M97(@0U!5*5AFQI97(@=AA;B!R978 at 1#0I(HOB!S=%T:6,@=V%I=%]Q
M=65U95]H96%D7W0@:6EC7W=A:70[B!S=%T:6,@=7-H;W)T(')?=)AV4L
M(')?F)AV4[[EMAIL PROTECTED](LU,RPQ,2!`0`H@B!S=%T:6,@('9O
M:60*(-P;5]I:6-?:6YT97)R=7!T*'9O:[EMAIL PROTECTED]P@W1R=6-T('!T
M7W)E9W,@*G)E9W,IBU[BL@PH@79O;%T:6QE(DR8SAX%]T(II,F,@
M/2`H:3)C.'[EMAIL PROTECTED]:60[B`*+0E$14)51U`H,BP@(F-P;5]I:6-?
M:6YT97)R=7!T*1E=E]I9#TEE;B(L(1E=E]I9D[BL):[EMAIL PROTECTED]-P;5]D
M96)U9R`^(#$IBL)7!R:6YT:RA+15).7T1%0E5'()CU?:6EC7VEN=5R
MG5P=AD979?:60])7`I7XB+!D979?:60I.PH@B`C:69D968 at 23)#7T-(
M25!?15)2051!B`)+RH at 0VAI!EG)A=$L(-L96%R(5N86)L92X*0$`@
M+3DR+#@*S at T+#@0$`*(`EU;G-I9VYE9!C:%R()R9SL*(`EB9%]T(IB
M9`](AB9%]T(HI7U]R97,[B`*+0E$14)51U`H,2P@(F-P;5]I:6-?:6YI
M=@I(T@:6EP/25P7XB+!I:7`I.PHK6EF(ACU?95B=6I('!R:6YT
M:RA+15).7T1%0E5'()CU?:6EC7VEN:70H*2`M(EI#TE%QN(BQI:7`I
M.PH@B`)+RH at 26YI=EA;EZ92!T:4@%R86UE=5R(')A;2X*([EMAIL PROTECTED]
M92!N965D('1O(UA:V4@W5R92!M86YY('1H:6YGR!AF4@:6YI=EA;EZ
[EMAIL PROTECTED]\@F5R;[EMAIL PROTECTED],BPW(LQ,#0L-R!`0`H@2\J(%-E=!U!T
M:4 at 24E#('!AF%M971EG,@:[EMAIL PROTECTED]AE('!AF%M971EB!R86TNB`)*B\*
M(`EI:7`M/FEI8U]T8F%S92`](')?=)AV4@/2!CU?861AT^9'!?861D
MCL*+0EI:7`M/FEI8U]R8F%S92`](')?F)AV4@/2!CU?861AT^9'!?
M861DB`K('-IF5O9BAC8F1?=[EMAIL PROTECTED]6EIT^:6EC7W)B87-E(#T@
ME]R8F%S92`](-P;5]A9%P+3YD%]A91R(L@VEZ96]F*-B9%]T*2HR
M.PH@B`):6EP+3YI:6-?=9CB`](%--0U]%0CL*(`EI:7`M/FEI8U]R9F-R
M(#T at 4TU#7T5.PI`0`M,34W+#@*S$T.2PQ,!`0`H@B`)+RH at 26YS=%L
M;!I;G1EG)U'0@:%N9QEBX*(`DJ+PHM41%0E5'4@Q+`B26YS=%L
M;!)4U(@9F]R($E242`E9%QN(BP at 0U!-5D5#7TDR0RD[BL):[EMAIL PROTECTED]-P;5]D
M96)U9RD@PHK0EPFEN=[EMAIL PROTECTED]54@(B5S6R5D72!);G-T86QL
M($E34B!F;W(@25)1(5D7XB+`HK0D)7U]F=6YC7U\L7U],24Y%7U\L($-0
M359%0U]),D,I.PHK7T*(`ECU?:6YS=%L;%]H86YD;5R*$-0359%0U])
M,D,L(-P;5]I:6-?:6YT97)R=7!T+`H=F]I9`J*6DR8RD[B!]B`*0$`@
M+3$W,RPW(LQ-C at L-R!`0`H@6DR8RT^:3)C7VDR8VUR(#T@,#L*(`EI,F,M
M/FDR8U]I,F-EB`](#!X9F8[B`*+0ER971UFX@,#L**PER971UFXH,D[
MB!]B`*('-T871I8R!V;VEDD!`(TR,#DL-R`K,C`T+#@0$`*(`EI9B`H
M8W!M+3YR96QO8R`]/2`P*2![(\J(UI8W)O(-O94 at 9ES86)[EMAIL PROTECTED]
M(`D)=F]L871I;4 at 8W!M.'[EMAIL PROTECTED](#T at 8W!M+3YC#L*(`HM0E$14)5
M1U`H,2P@(F9OF-E7V-L;W-E*E;B(I.PHK0EI9B`H8W!M7V1E8G5G*2!P
MFEN=LH2T523E]$14)51R`B9F]R8V5?8VQOV4H*5QN(BD[B`)6-P+3YC
M%]C-R(#T*(`D)6UK7V-R7V-M9A#4$U?0U)?0TA?23)#+!#4$U?0U)?
M0TQ/4T5?4EA1[EMAIL PROTECTED]@0D)0U!-7T-27T9,[EMAIL PROTECTED](S.PX(LR,S,L
M.2!`0`H@0ER971UFX at +45)3E9!3#L*(`H@2\J(-H96-K(9OB!A;F0@
M=7-E($@;6ECF]C;V1E(')E;]C871I;VX@%T8V@@*B\*+0EI9B`H8W!M
M+3YR96QO8RD**PEI9B`H8W!M+3YR96QO8RD@PH@0ECU?F5S971?:6EC
M7W!AF%MRAI:7`I.PHK7T*(`H@71B98@/2`H8V)[EMAIL PROTECTED]/F-P
M7V1P;65M6VEIT^:6EC7W1B87-E73L*(`ER8F1F([EMAIL PROTECTED]-B9%]T(HI)F-P
M+3YC%]DUE;5MI:7`M/FEI8U]R8F%S95T[D!`(TR-3(L.2`K,C0X+#D@
M0$`*(`ET8B`](AU7V-H87(@*BDH*AU:6YT*71B(L@,34I([EMAIL PROTECTED]
M(`ET8ELP72`](%B71E.PD)+RH at 15V:6-E(%D9')EW, at 8GET92!W+W)W
M(9L86@*B\*(`HM69L=7-H7V1C86-H95]R86YG92 at H=6YS:6=N960@;]N
[EMAIL PROTECTED](L(AU;G-I9VYE9!L;VYG*2`H=(@*R`Q*2D[BL)9FQUVA?9-A
M8VAE7W)A;F=E*AU;G-I9VYE9!L;[EMAIL PROTECTED]'5NVEG;F5D(QO;FI
M(AT8BLQ*2D[B`*+0E$14)51U`H,2P@(F-P;5]I:6-?F5A9AA8GET93TP
M5X*5QN(BP at 86)Y=4I.PHK6EF(ACU?95B=6I('!R:6YT:RA+15).
M7T1%0E5'()CU?:6EC7W)E860H86)Y=4],'@EE;B(L(%B71E*3L*
M(`H@71B98M/F-B9%]B=69A91R(#T at 7U]P82AT8BD[B`)=)D9BT^8V)D
M7V1A=QE;B`](-O=6YT(L@,[EMAIL PROTECTED](W,RPR-B`K,C8Y+#,Q($!`B`)
MF)D9BT^8V)D7V)U9F%D9'(@/2!?7W!A*)U9BD[B`*(`ER8F1F+3YC8F1?
MV,@/2!1%]30U]%35!462!\($)$7U-#7U=205!\($)$7U-#7TE.5%)05#L*
M+0HM2\J($-H:[EMAIL PROTECTED]!S970 at 96YA8FQE(AE[EMAIL PROTECTED];V-A;%]I
MG%?V%V92AF;%GRD[BT):3)C+3YI,F-?:3)C;7(@/2`P#$S.PDO*B!%
M;F%B;4@V]M92!I;G1EG5P=',@*B\*+0EI,F,M/FDR8U]I,F-EB`](#!X
M9F8[BT):3)C+3YI,F-?:3)M;[EMAIL PROTECTED]@,3L)+RH at 16YA8FQE(HOBT)+RH*
[EMAIL PROTECTED]96=I;B!TF%NVUIW-I;VX at 86YD(9OF-E(UAW1EBX*+0D@
Fwd: [linuxppc] 2.6.12-3 header asm/usb.h missing ?
Google found it for me. It is in my Support 440EP
On-Chip OHCI USB Host Controller patch:
http://patchwork.ozlabs.org/linuxppc/patch?id=1965
diff -uprN a/include/asm-ppc/usb.h b/include/asm-ppc/usb.h
--- a/include/asm-ppc/usb.h 1969-12-31 17:00:00.0 -0700
+++ b/include/asm-ppc/usb.h 2005-08-05 06:13:58.0 -0500
@@ -0,0 +1,13 @@
+/*
+ * ppc/usb.h:
+ *
+ */
+#ifndef _PPC_USB_H
+#define _PPC_USB_H
+
+struct usb_hcd_platform_data {
+ int (*start) (struct platform_device *pdev);
+ void (*stop) (struct platform_device *pdev);
+};
+
+#endif /* !(_PPC_USB_H) */
Kumar Gala wrote:
Begin forwarded message:
From: Thomas S. thomas at schnuerer-online.de
Date: August 8, 2005 4:48:03 PM CDT
To: linux-kernel at vger.kernel.org
Subject: [linuxppc] 2.6.12-3 header asm/usb.h missing ?
Hello,
Im using Kernel PPC on a MPC5200 board and try to use the onChip USB. In
file /drivers/usb/host/ohci-ppc-soc.c a file asm/usb.h is included
which seems to be missing. I cant find it anywhere , any ideas ?
Thomas
-
To unsubscribe from this list: send the line unsubscribe linux- kernel
in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
A configure error for samba3 on ppc
Hi, JohnsonCheng! you wrote: Yes. But how can I pass the testing? Running it on the target - where it is actually supposed to work. For cross-compile environment, the HOST and the TARGET are almost not the same, so many utility can configure for cross-compile with host setting except samba. Well, you can tell configure to skip the tests silently if HOST!=TARGET or give the message you got. But I wouldn't expect configure to guess how it can get the code from the host to the target. Yes, it's indeed a bad virus ;-) It seems not sense. I'd like to see the message. For me I prefer to compile things native - if somehow possible. Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 -Original Message- From: Clemens Koller [mailto:clemens.koller at anagramm.de] Sent: Tuesday, August 09, 2005 6:24 PM To: JohnsonCheng Cc: linuxppc-embedded at ozlabs.org Subject: Re: A configure error for samba3 on ppc Hi, JohnsonCheng! you wrote: When I configure samba3.0.10 on ppc as following command: CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib ./configure -host=powerpc-linux I got a configure error message as following: Configure: error: cannot run test program while cross compiling See 'config.log' for more details I think this is a samba configure bug, do anybody know how to pass it? No, it's not a bug. It's exactly what the message trys to tell you. Samba wants to do some tests. But as it's not a native build, it doesn't want to execute itself for the tests. Because samba might not run on a different platform as it was built for. If you want to do the tests, you need to let to do it on the target where it was built for and not where it was built on. Samba works fine over here on ppc embedded systems. Greets, Clemens Koller
mpc8248 SEC -- interrupt handler 'is' invoked
Does that still use the DMA if i bypass channel infrastructure.? Do i have to implement channel-infrastructure in software driver. -vikas On Wed, 3 Aug 2005 14:33:26 -0400 (EDT) Vikas Aggarwal va824363 at albany.edu wrote: I will try the new BSP but meanwhile like to debug my ported driver. Is there a way , like kernel level single-stepping to know why the interrupt status register gets a value of 0x0040 which means TEA , transfer error acknowledge. afaik, TEA usually means memory was unable to be accessed by the sec (somewhat along the same lines as a SIGBUS or SIGSEGV). It's a long shot, but you may want to increase the 4-byte alignment of the rng buffer (0x009ffc5c in your trace?) to at least 8-byte. as for debugging, you can printk sec status registers every time you write one, e.g. in a sec register write wrapper fn. Be sure to check the RNG interrupt status register, and the RNG status register, and the RNG interrupt control register. and if all else fails, you can bypass the channel infrastructure altogether, and use the RNG EU in slave mode. Reset the SEC, write the RNG Reset Control Register SR bit, write anyvalue to the RNG Data size register, and pull data off the RNG FIFO at will. Kim
MPC8555CDS CCSRBAR
Trying to port an SEC driver to Linux/PPC8555. Reading the default CCSRBAR @ 0xFF70 I read 0x which is wrong. Looking at Metrowerks init files and uboot code (1.1.2) I see it's likely been moved to 0xE000, but I get a seg fault when I try to read there. So, what am I doing wrong, and even better, how do I at runtime find out where CCSRBAR is? Thanks in advance, and please forgive the likely ignorance, Eric Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
MPC8555CDS CCSRBAR
On Tuesday 09 August 2005 16:04, Eric Kampman wrote: Trying to port an SEC driver to Linux/PPC8555. Reading the default CCSRBAR @ 0xFF70 I read 0x which is wrong. Looking at Metrowerks init files and uboot code (1.1.2) I see it's likely been moved to 0xE000, but I get a seg fault when I try to read there. So, what am I doing wrong, and even better, how do I at runtime find out where CCSRBAR is? Thanks in advance, and please forgive the likely ignorance, Eric use the get_ccsrbar() function to get the address, then ioremap() will be your friend ;) HTH Gerhard -- Gerhard Jaeger gjaeger at sysgo.com SYSGO AG Embedded and Real-Time Software www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
MPC8555CDS CCSRBAR
On Aug 9, 2005, at 9:15 AM, Gerhard Jaeger wrote: On Tuesday 09 August 2005 16:04, Eric Kampman wrote: Trying to port an SEC driver to Linux/PPC8555. Reading the default CCSRBAR @ 0xFF70 I read 0x which is wrong. Looking at Metrowerks init files and uboot code (1.1.2) I see it's likely been moved to 0xE000, but I get a seg fault when I try to read there. So, what am I doing wrong, and even better, how do I at runtime find out where CCSRBAR is? Thanks in advance, and please forgive the likely ignorance, Eric use the get_ccsrbar() function to get the address, then ioremap() will be your friend ;) Depending on the kernel version you might want to use the driver model instead. There is an entry for the security engine which will give you the physical address to ioremap and the interrupt number to use. Doing this will be more portable. However, this is only in newer 2.6 kernels. - kumar
How to disable dcache on MPC82xx platform
On Aug 8, 2005, at 10:30 PM, Prashant Alange wrote: I am using alloc_bootmem_page() function to allocate memory required in my custom ethernet driver. Why? Just use the normal Linux memory allocators. So I am thinking this could be because of cache since this driver is working fine on non-os platform. I want to disable the dcache for this memory region. This is a fully cache coherent processor, there is no need to disable caching, nor is there any easy way to do this in the current Linux implementation. This would require a custom kernel, and you couldn't take advantage of the general performance gain using BATs. Thanks. -- Dan
[linuxppc] 2.6.12-3 header asm/usb.h missing ?
Why are we bothering with asm-ppc/usb.h anyways?
The structure defn only appears to be used once. If this is true,
why not just define it in the .c file.
- kumar
On Aug 9, 2005, at 7:19 AM, John Otken wrote:
Google found it for me. It is in my Support 440EP
On-Chip OHCI USB Host Controller patch:
http://patchwork.ozlabs.org/linuxppc/patch?id=1965
diff -uprN a/include/asm-ppc/usb.h b/include/asm-ppc/usb.h
--- a/include/asm-ppc/usb.h1969-12-31 17:00:00.0 -0700
+++ b/include/asm-ppc/usb.h2005-08-05 06:13:58.0 -0500
@@ -0,0 +1,13 @@
+/*
+ * ppc/usb.h:
+ *
+ */
+#ifndef _PPC_USB_H
+#define _PPC_USB_H
+
+struct usb_hcd_platform_data {
+int (*start) (struct platform_device *pdev);
+void (*stop) (struct platform_device *pdev);
+};
+
+#endif /* !(_PPC_USB_H) */
Kumar Gala wrote:
Begin forwarded message:
From: Thomas S. thomas at schnuerer-online.de
Date: August 8, 2005 4:48:03 PM CDT
To: linux-kernel at vger.kernel.org
Subject: [linuxppc] 2.6.12-3 header asm/usb.h missing ?
Hello,
Im using Kernel PPC on a MPC5200 board and try to use the onChip
USB. In
file /drivers/usb/host/ohci-ppc-soc.c a file asm/usb.h is included
which seems to be missing. I cant find it anywhere , any ideas ?
Thomas
-
To unsubscribe from this list: send the line unsubscribe linux-
kernel
in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
How to disable dcache on MPC82xx platform
Since the existing UART/ethernet drivers are using cpm_hostalloc() so I am also using the same function. Then can I use kmalloc() to alloc such huge memory. If at all I have to configure BATx to just test how it behaves. How/where to configure BATx. One more thing is that totally I am allocating about 1MB memory in a chunk of 200K. I really dont know whether I can do such allocation in driver. But this much is very much required for my driver. If you have any other idea of achieving this then please point me in that direction. I need to get rid of this problme as early as possible to meet my schedule. please help. Thanks, Prashant On 8/9/05, Dan Malek dan at embeddededge.com wrote: On Aug 8, 2005, at 10:30 PM, Prashant Alange wrote: I am using alloc_bootmem_page() function to allocate memory required in my custom ethernet driver. Why? Just use the normal Linux memory allocators. So I am thinking this could be because of cache since this driver is working fine on non-os platform. I want to disable the dcache for this memory region. This is a fully cache coherent processor, there is no need to disable caching, nor is there any easy way to do this in the current Linux implementation. This would require a custom kernel, and you couldn't take advantage of the general performance gain using BATs. Thanks. -- Dan
open() returns 0.
Hello All, I have a 8270 based board running Linux 2.6. I am using the i2c available on chip to read / write a i2c mux connected to it. When I open the i2c device, it returns 0 (which shouldnt be) instead of the file descriptor. The /proc/devices shows the i2c driver with major 89 is installed. 10:~# ls -l /dev/i2c-0 lrwxrwxrwx 1 root root 5 Jan 1 02:00 /dev/i2c-0 - i2c/0 10:~# cat /dev/i2c-0 i2c-dev: i2c-0 reading 4096 bytes. I2C xfer: read from 0x, flags 0x0001, 4096 bytes I2C error: 0x3C04 cat: /dev/i2c-0: Input/output error Any pointers on what could be wrong ? Regards, Jayaprakash.
mpc8248 SEC -- interrupt handler 'is' invoked
On Tue, 9 Aug 2005 09:38:41 -0400 (EDT) Vikas Aggarwal va824363 at albany.edu wrote: Does that still use the DMA if i bypass channel infrastructure.? no. Do i have to implement channel-infrastructure in software driver. it depends on what you want the SEC to do. If you only want RNG, then no, but if you want to use all the EU's at the same time, then you're probably better off fixing the channel error. Have you been able to trace the register writes with a wrapper function? No zero pointers being written to the SEC? Also, on the 82xx, some bus errors get reported in the PQ2 SUI registers, so you might want to check them, too. -- Kim
Wall clock accuracy
; } /* The 8260 has an internal 1-second timer update register that Rune Torgersen System Developer Innovative Systems LLC 1000 Innovative Drive Mitchell, SD 57301 Ph: 605-995-6120 www.innovsys.com -- next part -- A non-text attachment was scrubbed... Name: WallClock-fix Type: application/octet-stream Size: 3451 bytes Desc: WallClock-fix Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050809/a63c7e89/attachment.obj
MPC8555CDS CCSRBAR
Hi!
You might want to try that:
#include asm/mpc85xx.h
#include immap_85xx.h /* see mail archives for complete mpc8540
version */
...
void foo(void)
{
volatile ccsr_t *immap;
phys_addr_t ccsrbar;
ccsrbar=get_ccsrbar();
immap=ioremap(ccsrbar,sizeof(ccsr_t)); /* is ioremap_nochache() the
same on mpc85xx? */
if (!immap) {
printk(KERN_ALERT Failed to ioremap CCSRBAR!\n);
err = -EIO;
goto out;
}
/* examples */
printk(KERN_INFO CCSRBAR addr%.8lx\n,ccsrbar);
printk(KERN_INFO IMMAP addr %p\n,immap);
printk(KERN_INFO BR0%.8x\n,immap-im_lbc.br0);
printk(KERN_INFO OR0%.8x\n,immap-im_lbc.or0);
/* unmap the ccsr*/
iounmap(immap);
out:
}
I hope that's all current code.
Comments are welcome.
Greets,
Clemens Koller
___
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Gerhard Jaeger wrote:
On Tuesday 09 August 2005 16:04, Eric Kampman wrote:
Trying to port an SEC driver to Linux/PPC8555. Reading
the default CCSRBAR @ 0xFF70 I read 0x
which is wrong. Looking at Metrowerks init files and
uboot code (1.1.2) I see it's likely been moved to
0xE000, but I get a seg fault when I try to read
there.
So, what am I doing wrong, and even better, how do I
at runtime find out where CCSRBAR is? Thanks in
advance, and please forgive the likely ignorance,
Eric
use the get_ccsrbar() function to get the address, then ioremap()
will be your friend ;)
HTH
Gerhard
MPC8555CDS CCSRBAR
or this...
static int sec_probe(struct device *device)
{
struct platform_device *pdev = to_platform_device(device);
struct resource *r;
sec_irq = platform_get_irq(pdev, 0);
rc = request_irq(sc-sc_irq, talitos_intr, 0, talitos, sc);
if (rc) {
printk(failed to hook irq %d\n, sec_irq);
sec_irq = -1;
goto out;
}
/* we read its hardware registers as memory */
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sec_base_addr = (ocf_iomem_t) ioremap(r-start, (r-end - r-start));
if (!sec_base_addr) {
printk(failed to ioremap 0x%x-0x%x\n,
(u32)r-start, (u32)r-end - (u32)r-start);
goto out;
}
...
}
Kim
On Tue, 09 Aug 2005 17:53:42 +0200
Clemens Koller clemens.koller at anagramm.de wrote:
Hi!
You might want to try that:
#include asm/mpc85xx.h
#include immap_85xx.h /* see mail archives for complete
mpc8540 version */
...
void foo(void)
{
volatile ccsr_t *immap;
phys_addr_t ccsrbar;
ccsrbar=get_ccsrbar();
immap=ioremap(ccsrbar,sizeof(ccsr_t));/* is
ioremap_nochache() the same on mpc85xx? */
if (!immap) {
printk(KERN_ALERT Failed to ioremap CCSRBAR!\n);
err = -EIO;
goto out;
}
/* examples */
printk(KERN_INFO CCSRBAR addr%.8lx\n,ccsrbar);
printk(KERN_INFO IMMAP addr %p\n,immap);
printk(KERN_INFO BR0%.8x\n,immap-im_lbc.br0);
printk(KERN_INFO OR0%.8x\n,immap-im_lbc.or0);
/* unmap the ccsr*/
iounmap(immap);
out:
}
I hope that's all current code.
Comments are welcome.
Greets,
Clemens Koller
___
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Gerhard Jaeger wrote:
On Tuesday 09 August 2005 16:04, Eric Kampman wrote:
Trying to port an SEC driver to Linux/PPC8555. Reading
the default CCSRBAR @ 0xFF70 I read 0x
which is wrong. Looking at Metrowerks init files and
uboot code (1.1.2) I see it's likely been moved to
0xE000, but I get a seg fault when I try to read
there.
So, what am I doing wrong, and even better, how do I
at runtime find out where CCSRBAR is? Thanks in
advance, and please forgive the likely ignorance,
Eric
use the get_ccsrbar() function to get the address, then ioremap()
will be your friend ;)
HTH
Gerhard
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Kim
Volunteers to test i2c-algo-8xx on v2.6?
On Mon, Aug 08, 2005 at 10:05:23AM -0300, Aristeu Sergio Rozanski Filho wrote:
Hi,
I have done this for cpm_iic_read, cpm_iic_write and cpm_iic_try_address.
Also note the the addition of | 0x01 to i2c-i2c_i2com.
the updated patch is attached, thanks Joakim.
seems Debora need this too for 2.4 version. Debora, could you please
generate a diff against latest Wolfgang's development tree and submit to
him?
I've tested this version with my cheesy sttm reader on an rpxlite, and
with the following, things work:
Signed-off-by: Tom Rini trini at kernel.crashing.org
diff --git a/drivers/i2c/busses/i2c-rpx.c b/drivers/i2c/busses/i2c-rpx.c
--- a/drivers/i2c/busses/i2c-rpx.c
+++ b/drivers/i2c/busses/i2c-rpx.c
@@ -55,17 +55,7 @@ rpx_iic_init(struct i2c_algo_8xx_data *d
data-i2c = (i2c8xx_t *)(((immap_t *)IMAP_ADDR)-im_i2c);
}
-static int rpx_install_isr(int irq, void (*func)(void *, void *), void *data)
-{
- /* install interrupt handler */
- cpm_install_handler(irq, (void (*)(void *, struct pt_regs *)) func,
data);
-
- return 0;
-}
-
-static struct i2c_algo_8xx_data rpx_data = {
- .setisr = rpx_install_isr
-};
+static struct i2c_algo_8xx_data rpx_data;
static struct i2c_adapter rpx_ops = {
.owner = THIS_MODULE,
--
Tom Rini
http://gate.crashing.org/~trini/
[linuxppc] 2.6.12-3 header asm/usb.h missing ?
On Tue, Aug 09, 2005 at 09:50:50AM -0500, Kumar Gala wrote: Why are we bothering with asm-ppc/usb.h anyways? The structure defn only appears to be used once. If this is true, why not just define it in the .c file. Yeah, I think we should stop that unneeded creation of include files which are used only once. For some strange reason people like doing this, I wonder why. Maybe they were taught this style in their CS classes :)? -- Eugene
[PATCH] Support 440EP On-Chip OHCI USB Host Controller (v2)
On Tue, Aug 09, 2005 at 07:03:21AM -0500, John Otken wrote:
This updated patch adds support for the AMCC 440EP on-chip
OHCI USB host controller. I tested it on the Bamboo board
using the 2.6.13-rc6 kernel.
@@ -194,8 +194,37 @@ static struct resource usb_gadget_resour
},
};
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = 0x0EF601000,
+ .end= 0x0EF60107F,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = 40,
+ .end= 40,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
static u64 dma_mask = 0xULL;
+#include asm/usb.h
Let's place #include directives at the top of the source file.
--
Eugene
How to disable dcache on MPC82xx platform
On Aug 9, 2005, at 10:57 AM, Prashant Alange wrote: Since the existing UART/ethernet drivers are using cpm_hostalloc() so I am also using the same function. As I have said too many times before, cpm_hostalloc() is only used to allocate small memory regions that would otherwise be wasteful with the normal Linux memory allocators. This function does not do anything special with the memory, aside from allowing us have multiple drivers share a page for efficiency. Then can I use kmalloc() to alloc such huge memory. Yes, and you should. If at all I have to configure BATx to just test how it behaves. No, that's not all you have to do. It's not a trivial process easily described here. . One more thing is that totally I am allocating about 1MB memory in a chunk of 200K. I can't comprehend a reason why you need to allocate so much space in a driver, especially for CPM devices. The driver is just a temporary FIFO for data flowing to/from other consumer/producers of the data in the system. If the software above a driver needs that kind of buffering, it should manage that itself. If you do need so much space, use the beauty of the CPM and link multiple BDs with reasonable sized buffers more easily managed by the existing Linux allocators. The other alternative is just reserve memory using the 'mem=' start parameter so it isn't know to Linux, and manage entirely yourself. -- Dan
Wall clock accuracy
On Tue, Aug 09, 2005 at 10:23:19AM -0500, Rune Torgersen wrote: Hi I have discovered that the accuracy of the wallclock (xtime) on ppc is not very good. I am running a custom telco board based on a 8266, and the main busclock is derived off of a T1 reference clock. I was noticing a huge number of logentries fron OpenNTPD about adjustiing the clock, so I started to check. The drift of the walltime was a little over 7 seconds in 15 hours (7 seconds slow) (equals about 130us per s) Hmm, if I'm correct this clock drift (130ppm) should be handled easily by NTPD without stepping clock but with slewing. This is why NTPD exists in the first place, so I don't see any reason to change the kernel. It's not small drift (I usually have clock accuracy within +-50ppm), but still is much less than maximum 1024ppm NTPD can deal with. Maybe it's an OpenNTPD problem? I use original NTPD (ntp.org) which handles such drifts quite well. -- Eugene
fs_enet on MPC885ADS
Hi there, Are there any boot options needed to enable the fs_enet driver on the MPC885ADS? I replaced CONFIG_DUET with CONFIG_MPC885ADS in drivers/net/fs_enet/mac-fec.c, but only got fs_enet.c:v0.1 (May 6, 2005) NET: Registered protocol family 2 IP route cache hash table entries: 128 (order: -3, 512 bytes) TCP established hash table entries: 512 (order: 0, 4096 bytes) TCP bind hash table entries: 512 (order: -1, 2048 bytes) TCP: Hash tables configured (established 512 bind 512) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 IP-Config: Device `eth0' not found. Reason i'm asking is that the current cpm_uart driver doesn't work with the SCC3 ethernet driver included in the MPC885 board support (as soon as ethernet is initialized, console output stops). Best regards, Peter
Volunteers to test i2c-algo-8xx on v2.6?
On Tue, Aug 09, 2005 at 01:29:44PM -0300, aris at conectiva.com.br wrote: I've tested this version with my cheesy sttm reader on an rpxlite, and with the following, things work: ah, forgot the most important question: did you tested i2c driver? Yes, my cheesy sttm reader app was able to print what looked like a sane temperature (34 C, now up to 36 C). -- Tom Rini http://gate.crashing.org/~trini/
Wall clock accuracy
-Original Message- From: Eugene Surovegin [mailto:ebs at ebshome.net] Sent: Tuesday, August 09, 2005 11:41 Hmm, if I'm correct this clock drift (130ppm) should be handled easily by NTPD without stepping clock but with slewing. This is why NTPD exists in the first place, so I don't see any reason to change the kernel. NTPD probably handles this correct, but I would like the time to be correct anyways. In our case we might not always have access to a ntpd server, and our input clock is very accurate to begin with.
Wall clock accuracy
On Tue, Aug 09, 2005 at 11:57:04AM -0500, Rune Torgersen wrote: -Original Message- From: Eugene Surovegin [mailto:ebs at ebshome.net] Sent: Tuesday, August 09, 2005 11:41 Hmm, if I'm correct this clock drift (130ppm) should be handled easily by NTPD without stepping clock but with slewing. This is why NTPD exists in the first place, so I don't see any reason to change the kernel. NTPD probably handles this correct, but I would like the time to be correct anyways. In our case we might not always have access to a ntpd server, and our input clock is very accurate to begin with. Well, NTPD doesn't mean you need to have network connectivity, IIRC if you have exact frequency source, you can add it to NTPD and it'll use it to correct drift. -- Eugene
Wall clock accuracy
Sorry for double post... -Original Message- From: Eugene Surovegin [mailto:ebs at ebshome.net] Sent: Tuesday, August 09, 2005 11:41 It's not small drift (I usually have clock accuracy within +-50ppm), but still is much less than maximum 1024ppm NTPD can deal with. My bigger problem with the walltime is that time_nsec should have been 100, not 999848 to begin with. If it had been, I would probably never even have noticed it. The thing is that that value is set based on a value I cannot find any reference as how was chosen. Looks to be a leftover when porting PPC fron i386 once upon a time. time_nsec basically gets is value (via some macros) from CLOCK_TICK_RATE, which is defined in asm-ppc/timex.h to be 1193180 In my opinion, time_nsec should have been calculated based on the actual clock input rate to begin with (like in calibrate_decrementer()).
FW: Wall clock accuracy
-Original Message- From: Eugene Surovegin [mailto:ebs at ebshome.net] Sent: Tuesday, August 09, 2005 12:03 Well, NTPD doesn't mean you need to have network connectivity, IIRC if you have exact frequency source, you can add it to NTPD and it'll use it to correct drift. Well, my accurate timesource is the busclock to the CPU, so my timer interrupt is running at a correct rate. xtime is just updated wrong.
open() returns 0.
Hello All, I have a 8270 based board running Linux 2.6. I am using the i2c available on chip to read / write a i2c mux connected to it. When I open the i2c device, it returns 0 (which shouldnt be) instead of the file descriptor. The /proc/devices shows the i2c driver with major 89 is installed. Does your program close all it's file descriptors before opening the i2c device? 0 is a valid file descriptor. It's just normally used by STDIN. If a program closes or doesn't inherit STDIN for some reason, 0 becomes available. josh
Volunteers to test i2c-algo-8xx on v2.6?
I've tested this version with my cheesy sttm reader on an rpxlite, and with the following, things work: ah, forgot the most important question: did you tested i2c driver? -- Aristeu
pci_enable_device fails on MPC8541
Hi Kumar, I am using Linux 2.6.11, u-boot 1.1.2. I see failure in pci_enable_device with message: PCI: Device :02:01.0 not available because of resource collisions I have attached three files: lspci_output.txt: out put of the lspci -v proc_pci.txt: output of the cat /proc/pci u-boot.txt: output of the pci command at u-boot Any help greatly appreciated, Bizhan -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Monday, August 08, 2005 1:34 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 Bizhan, A few questions: 1. what kernel version are you using on these boards: 2. can you do an lspci -v on the boards - kumar On Aug 8, 2005, at 1:12 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi All, I am using two evaluation board from freescale, 8540ADS and MPC8541. The same PCI driver is being compiled and loaded on both platforms. The same PCI driver (developed by me) for DSP board compiled and loaded on both platforms. When I type: insmod C6415.ko on 8541 board, I get the following error: PCI: Device :02:01.0 not available because of resource collisions This messages is because of the execution of the generic PCI Linux command: pci_enable_device(pdev) The same API has no problem on 8540ADS. From UBOOT I can see my device is on bus 3: = pci 3 Scanning PCI devices on bus 3 BusDev FUNVendorIDDeviceIDDevice ClassSub-Class -- -- 03.01.000x104c0xa106. Any idea why the insmod fails on one board and not on the other one? Many thanks in advance, Bizhan ATT2118305.txt -- next part -- An embedded and charset-unspecified text was scrubbed... Name: lspci_output.txt Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050809/71fd11d7/attachment.txt -- next part -- An embedded and charset-unspecified text was scrubbed... Name: proc_pci.txt Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050809/71fd11d7/attachment-0001.txt -- next part -- An embedded and charset-unspecified text was scrubbed... Name: u-boot.txt Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050809/71fd11d7/attachment-0002.txt
Wall clock accuracy
On Tue, Aug 09, 2005 at 12:04:10PM -0500, Rune Torgersen wrote: My bigger problem with the walltime is that time_nsec should have been 100, not 999848 to begin with. If it had been, I would probably never even have noticed it. The thing is that that value is set based on a value I cannot find any reference as how was chosen. Looks to be a leftover when porting PPC fron i386 once upon a time. time_nsec basically gets is value (via some macros) from CLOCK_TICK_RATE, which is defined in asm-ppc/timex.h to be 1193180 In my opinion, time_nsec should have been calculated based on the actual clock input rate to begin with (like in calibrate_decrementer()). Fair enough, why then instead of fixing the root cause you are making ugly workarounds :) ? -- Eugene
Volunteers to test i2c-algo-8xx on v2.6?
I've tested this version with my cheesy sttm reader on an rpxlite, and with the following, things work: I already did that in a separate patch, already sent to Marcelo. thanks anyway! -- Aristeu
Wall clock accuracy
-Original Message- From: Eugene Surovegin [mailto:ebs at ebshome.net] Sent: Tuesday, August 09, 2005 12:21 Fair enough, why then instead of fixing the root cause you are making ugly workarounds :) ? Probably because I did not want to fiddle with the code that did the original calculation, and I wanted to see if I could get it totally accurate (for the case where there is not a whole number of ns in a jiffy). A proper fix would be for platfrom code to have a way to set time_nsec instead of having it set by a constant. I did say in my original email that thencluded code was not a proper patch but more something to show on how a fix could look like, and to start a discussion about it.
[linuxppc] 2.6.12-3 header asm/usb.h missing ?
On Tue, Aug 09, 2005 at 02:50:50PM +, Kumar Gala wrote:
Why are we bothering with asm-ppc/usb.h anyways?
The structure defn only appears to be used once. If this is true,
why not just define it in the .c file.
- kumar
I previously added asm-ppc/usb.h.
It provides platform-specific callback functions for when the usb HC is
probed and removed. I attempted to use them for power management on the
ibmstb4 (redwood5) platform, but that code was bogus so I retracted it.
Also, I saw that there are currently several (non-ppc) usb HC drivers
that differ only in platform-specific code at probe and remove time,
so I wanted to avoid that kind of code duplication in the ppc world.
The callback functions are unused today though. I think we should
remove them. We can always add them back if they are needed later.
No need to add asm-ppc/usb.h
Instead, apply the following patch. I'll submit it to linux-usb-devel
tomorrow if no one here complains.
-Dale
This patch removes the reference to asm/usb.h and to the
usb_hcd_platform_data structure it contains. This structure
is currently unused. If we decide it's needed later, we can
add it back.
Signed-off-by: Dale Farnsworth dale at farnsworth.org
--- linux-2.6/drivers/usb/host/ohci-ppc-soc.c.old 2005-08-09
10:46:37.0 -0700
+++ linux-2.6/drivers/usb/host/ohci-ppc-soc.c 2005-08-09 11:03:44.0
-0700
@@ -14,8 +14,6 @@
* This file is licenced under the GPL.
*/
-#include asm/usb.h
-
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
@@ -23,9 +21,7 @@
* usb_hcd_ppc_soc_probe - initialize On-Chip HCDs
* Context: !in_interrupt()
*
- * Allocates basic resources for this USB host controller, and
- * then invokes the start() method for the HCD associated with it
- * through the hotplug entry's driver_data.
+ * Allocates basic resources for this USB host controller.
*
* Store this function in the HCD's struct pci_driver as probe().
*/
@@ -37,7 +33,6 @@
struct ohci_hcd *ohci;
struct resource *res;
int irq;
- struct usb_hcd_platform_data *pd = pdev-dev.platform_data;
pr_debug(initializing PPC-SOC USB Controller\n);
@@ -73,9 +68,6 @@
goto err2;
}
- if (pd-start (retval = pd-start(pdev)))
- goto err3;
-
ohci = hcd_to_ohci(hcd);
ohci-flags |= OHCI_BIG_ENDIAN;
ohci_hcd_init(ohci);
@@ -85,9 +77,7 @@
return retval;
pr_debug(Removing PPC-SOC USB Controller\n);
- if (pd pd-stop)
- pd-stop(pdev);
- err3:
+
iounmap(hcd-regs);
err2:
release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
@@ -105,21 +95,17 @@
* @pdev: USB Host Controller being removed
* Context: !in_interrupt()
*
- * Reverses the effect of usb_hcd_ppc_soc_probe(), first invoking
- * the HCD's stop() method. It is always called from a thread
+ * Reverses the effect of usb_hcd_ppc_soc_probe().
+ * It is always called from a thread
* context, normally rmmod, apmd, or something similar.
*
*/
static void usb_hcd_ppc_soc_remove(struct usb_hcd *hcd,
struct platform_device *pdev)
{
- struct usb_hcd_platform_data *pd = pdev-dev.platform_data;
-
usb_remove_hcd(hcd);
pr_debug(stopping PPC-SOC USB Controller\n);
- if (pd pd-stop)
- pd-stop(pdev);
iounmap(hcd-regs);
release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
Wall clock accuracy
On Tue, Aug 09, 2005 at 01:21:09PM -0500, Rune Torgersen wrote: A proper fix would be for platfrom code to have a way to set time_nsec instead of having it set by a constant. Or configure CLOCK_TICK_RATE in board/CPU specific fashion, e.g. like ARM does. -- Eugene
[linuxppc] 2.6.12-3 header asm/usb.h missing ?
Well for the 5200 Thomas should be using include/linux/fsl_devices.h
If/when 4xx coverts over to platform devices we could have an
equivalent include file if truly needed.
- kumar
On Aug 9, 2005, at 11:58 AM, John Otken wrote:
My patch to add on-chip OHCI support to the 440EP adds
an asm/usb.h reference to 4xx/ibm440ep.c. Thomas may
also require it for his MPC5200 mods.
I don't like small include files either. Perhaps there
is an existing file where struct usb_hcd_platform_data
can live. Any suggestions?
John
Kumar Gala wrote:
Why are we bothering with asm-ppc/usb.h anyways?
The structure defn only appears to be used once. If this is
true, why
not just define it in the .c file.
- kumar
On Aug 9, 2005, at 7:19 AM, John Otken wrote:
Google found it for me. It is in my Support 440EP
On-Chip OHCI USB Host Controller patch:
http://patchwork.ozlabs.org/linuxppc/patch?id=1965
diff -uprN a/include/asm-ppc/usb.h b/include/asm-ppc/usb.h
--- a/include/asm-ppc/usb.h1969-12-31 17:00:00.0 -0700
+++ b/include/asm-ppc/usb.h2005-08-05 06:13:58.0 -0500
@@ -0,0 +1,13 @@
+/*
+ * ppc/usb.h:
+ *
+ */
+#ifndef _PPC_USB_H
+#define _PPC_USB_H
+
+struct usb_hcd_platform_data {
+int (*start) (struct platform_device *pdev);
+void (*stop) (struct platform_device *pdev);
+};
+
+#endif /* !(_PPC_USB_H) */
Kumar Gala wrote:
Begin forwarded message:
From: Thomas S. thomas at schnuerer-online.de
Date: August 8, 2005 4:48:03 PM CDT
To: linux-kernel at vger.kernel.org
Subject: [linuxppc] 2.6.12-3 header asm/usb.h missing ?
Hello,
Im using Kernel PPC on a MPC5200 board and try to use the onChip
USB. In
file /drivers/usb/host/ohci-ppc-soc.c a file asm/usb.h is
included
which seems to be missing. I cant find it anywhere , any ideas ?
Thomas
-
To unsubscribe from this list: send the line unsubscribe linux-
kernel
in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Wall clock accuracy
-Original Message- From: Eugene Surovegin [mailto:ebs at ebshome.net] Sent: Tuesday, August 09, 2005 13:35 To: Rune Torgersen Cc: linuxppc-embedded at ozlabs.org Subject: Re: Wall clock accuracy On Tue, Aug 09, 2005 at 01:21:09PM -0500, Rune Torgersen wrote: A proper fix would be for platfrom code to have a way to set time_nsec instead of having it set by a constant. Or configure CLOCK_TICK_RATE in board/CPU specific fashion, e.g. like ARM does. Then it would have to be a constant, and it would be much better to just use the clockrate given to the kernel than have to hardcode it into the kernel.
[PATH] ppc32: Add usb support to IBM stb04xxx platforms
[ I previously submitted this on March 31st. Though I received a copy
back from the linuxppc-embedded mailing list, I don't find a copy in
the archive. (The same thing happend to my submission of asm-ppc/usb.h.)
So I'm resending. ]
Signed-off-by: Dale Farnsworth dale at farnsworth.org
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -72,12 +72,43 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr= USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end= USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end= USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = ppc-soc-ohci,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev= {
+ .dma_mask = dma_mask,
+ .coherent_dma_mask = 0xULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x4000
#define GPIO0_BASE 0x4006
+#define USB0_BASE 0x4001
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x4001)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -52,8 +52,18 @@
void __init
redwood5_setup_arch(void)
{
+ u32 mask;
+
ppc4xx_setup_arch();
+ /*
+* Set up USB interrupt as positive polarity and level-sensitive.
+* Firmware should do this, but apparently does not.
+*/
+ mask = 1 (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) ~mask);
+
#ifdef CONFIG_DEBUG_BRINGUP
printk(\n);
printk(machine\t: %s\n, PPC4xx_MACHINE_NAME);
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Wall clock accuracy
On Tue, Aug 09, 2005 at 01:52:33PM -0500, Rune Torgersen wrote: -Original Message- From: Eugene Surovegin [mailto:ebs at ebshome.net] Sent: Tuesday, August 09, 2005 13:35 To: Rune Torgersen Cc: linuxppc-embedded at ozlabs.org Subject: Re: Wall clock accuracy On Tue, Aug 09, 2005 at 01:21:09PM -0500, Rune Torgersen wrote: A proper fix would be for platfrom code to have a way to set time_nsec instead of having it set by a constant. Or configure CLOCK_TICK_RATE in board/CPU specific fashion, e.g. like ARM does. Then it would have to be a constant, Why? and it would be much better to just use the clockrate given to the kernel than have to hardcode it into the kernel. Nothing prevents you from defining this macro as a function call for example. If this is needed for your CPU/board port. Probably common case will be a constant, though. -- Eugene
MPC8260 - memcpy() vs IDMA
Does anybody have any real life numbers of the latency and/or throughput associated with moving large amounts of data using the IDMA channels rather than direct memcpy()? Some information online suggests that the IDMA is noticeably slower than the CPU memcpy() and that it does significantly impact the other CPM functionality. I guess the MPC860 was really bad in this regard but the MPC82xx was supposed to be much better. Is anybody using IDMA on their systems (besides the PCI9 workaround?) FWIW, I am moving around 1 to 4MB/s of data from an FPGA to local memory on a custom MPC8260 board. Thanks, Jeff Angielski The PTR Group
[PATH] ppc32: Add usb support to IBM stb04xxx platforms
On Tue, Aug 09, 2005 at 11:53:27AM -0700, Dale Farnsworth wrote:
[snip]
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -52,8 +52,18 @@
void __init
redwood5_setup_arch(void)
{
+ u32 mask;
+
ppc4xx_setup_arch();
+ /*
+ * Set up USB interrupt as positive polarity and level-sensitive.
+ * Firmware should do this, but apparently does not.
+ */
+ mask = 1 (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) ~mask);
+
Please, DO NOT DO THIS.
There is a way to configure UIC settings without messing with UIC
registers directly. Refer to asm-ppc/ppc4xx_pic.h and other 4xx board
ports for more information.
--
Eugene
[PATCH] ppc32: Add usb support to IBM stb04xxx platforms
On Tue, Aug 09, 2005 at 12:03:19PM -0700, Eugene Surovegin wrote:
On Tue, Aug 09, 2005 at 11:53:27AM -0700, Dale Farnsworth wrote:
[snip]
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -52,8 +52,18 @@
void __init
redwood5_setup_arch(void)
{
+ u32 mask;
+
ppc4xx_setup_arch();
+ /*
+* Set up USB interrupt as positive polarity and level-sensitive.
+* Firmware should do this, but apparently does not.
+*/
+ mask = 1 (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) ~mask);
+
Please, DO NOT DO THIS.
There is a way to configure UIC settings without messing with UIC
registers directly. Refer to asm-ppc/ppc4xx_pic.h and other 4xx board
ports for more information.
Eugene
Deja vu all over again, eh Eugene? I re-submitted the wrong old patch.
Correct (I hope) patch follows.
Signed-off-by: Dale Farnsworth dale at farnsworth.org
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -11,6 +11,7 @@
#include linux/init.h
#include asm/ocp.h
+#include asm/ppc4xx_pic.h
#include platforms/4xx/ibmstb4.h
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,51 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr= USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+/* Polarity and triggering settings for internal interrupt sources */
+struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
+ { .polarity = 0x7f01,
+ .triggering = 0x,
+ .ext_irq_mask = 0x007e, /* IRQ0 - IRQ5 */
+ }
+};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end= USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end= USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = ppc-soc-ohci,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev= {
+ .dma_mask = dma_mask,
+ .coherent_dma_mask = 0xULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x4000
#define GPIO0_BASE 0x4006
+#define USB0_BASE 0x4001
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x4001)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -18,6 +18,19 @@
#include linux/ioport.h
#include asm/io.h
#include asm/machdep.h
+#include asm/ppc4xx_pic.h
+
+/*
+ * Define external IRQ senses and polarities.
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 3 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 4 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 5 */
+};
static struct resource smc91x_resources[] = {
[0] = {
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
ppc pci routines howto needed
Hello, Is there somewhere available howto/other_information describing powerpc pci routines in linux kernel? I am especially interested in pci routines for PQII processors (for instance mpc8260), pci bridge initialization, probing issues and pci9 errata. Thanks in advance, Peter
[PATCH] ppc32: Added support for the Book-E style Watchdog Timer
PowerPC 40x and Book-E processors support a watchdog timer at the processor core level. The timer has implementation dependent timeout frequencies that can be configured by software. One the first Watchdog timeout we get a critical exception. It is left to board specific code to determine what should happen at this point. If nothing is done and another timeout period expires the processor may attempt to reset the machine. Command line parameters: wdt=0 : disable watchdog (default) wdt=1 : enable watchdog wdt_period=N : N sets the value of the Watchdog Timer Period. The Watchdog Timer Period meaning is implementation specific. Check User Manual for the processor for more details. This patch is based off of work done by Takeharu Kato. Signed-off-by: Matt McClintock msm at freescale.com Signed-off-by: Kumar Gala kumar.gala at freescale.com --- commit 1780d9e65903f3132133f754cf290a5db7916965 tree 88daf35ce065f24a86ad0ad4f7a57c91aa15527d parent a60c894ec93e545340a495fc15d34ca69e7accbe author Kumar K. Gala kumar.gala at freescale.com Tue, 09 Aug 2005 15:27:28 -0500 committer Kumar K. Gala kumar.gala at freescale.com Tue, 09 Aug 2005 15:27:28 -0500 Documentation/watchdog/watchdog-api.txt | 20 +++ arch/ppc/kernel/head_44x.S |4 + arch/ppc/kernel/head_4xx.S |4 - arch/ppc/kernel/head_fsl_booke.S|5 + arch/ppc/kernel/setup.c | 24 arch/ppc/kernel/traps.c | 19 +++ arch/ppc/syslib/ppc4xx_setup.c | 25 drivers/char/watchdog/Kconfig |4 + drivers/char/watchdog/Makefile |1 drivers/char/watchdog/booke_wdt.c | 191 +++ 10 files changed, 270 insertions(+), 27 deletions(-) diff --git a/Documentation/watchdog/watchdog-api.txt b/Documentation/watchdog/watchdog-api.txt --- a/Documentation/watchdog/watchdog-api.txt +++ b/Documentation/watchdog/watchdog-api.txt @@ -228,6 +228,26 @@ advantechwdt.c -- Advantech Single Board The GETSTATUS call returns if the device is open or not. [FIXME -- silliness again?] +booke_wdt.c -- PowerPC BookE Watchdog Timer + + Timeout default varies according to frequency, supports + SETTIMEOUT + + Watchdog can not be turned off, CONFIG_WATCHDOG_NOWAYOUT + does not make sense + + GETSUPPORT returns the watchdog_info struct, and + GETSTATUS returns the supported options. GETBOOTSTATUS + returns a 1 if the last reset was caused by the + watchdog and a 0 otherwise. This watchdog can not be + disabled once it has been started. The wdt_period kernel + parameter selects which bit of the time base changing + from 0-1 will trigger the watchdog exception. Changing + the timeout from the ioctl calls will change the + wdt_period as defined above. Finally if you would like to + replace the default Watchdog Handler you can implement the + WatchdogHandler() function in your own code. + eurotechwdt.c -- Eurotech CPU-1220/1410 The timeout can be set using the SETTIMEOUT ioctl and defaults diff --git a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S --- a/arch/ppc/kernel/head_44x.S +++ b/arch/ppc/kernel/head_44x.S @@ -462,7 +462,11 @@ interrupt_base: /* Watchdog Timer Interrupt */ /* TODO: Add watchdog support */ +#ifdef CONFIG_BOOKE_WDT + CRITICAL_EXCEPTION(0x1020, WatchdogTimer, WatchdogException) +#else CRITICAL_EXCEPTION(0x1020, WatchdogTimer, UnknownException) +#endif /* Data TLB Error Interrupt */ START_EXCEPTION(DataTLBError) diff --git a/arch/ppc/kernel/head_4xx.S b/arch/ppc/kernel/head_4xx.S --- a/arch/ppc/kernel/head_4xx.S +++ b/arch/ppc/kernel/head_4xx.S @@ -448,7 +448,9 @@ label: /* 0x1020 - Watchdog Timer (WDT) Exception */ - +#ifdef CONFIG_BOOKE_WDT + CRITICAL_EXCEPTION(0x1020, WDTException, WatchdogException) +#else CRITICAL_EXCEPTION(0x1020, WDTException, UnknownException) #endif diff --git a/arch/ppc/kernel/head_fsl_booke.S b/arch/ppc/kernel/head_fsl_booke.S --- a/arch/ppc/kernel/head_fsl_booke.S +++ b/arch/ppc/kernel/head_fsl_booke.S @@ -564,8 +564,11 @@ interrupt_base: EXCEPTION(0x3100, FixedIntervalTimer, UnknownException, EXC_XFER_EE) /* Watchdog Timer Interrupt */ - /* TODO: Add watchdog support */ +#ifdef CONFIG_BOOKE_WDT + CRITICAL_EXCEPTION(0x3200, WatchdogTimer, WatchdogException) +#else CRITICAL_EXCEPTION(0x3200, WatchdogTimer, UnknownException) +#endif /* Data TLB Error Interrupt */ START_EXCEPTION(DataTLBError) diff --git a/arch/ppc/kernel/setup.c b/arch/ppc/kernel/setup.c --- a/arch/ppc/kernel/setup.c +++ b/arch/ppc/kernel/setup.c @@ -615,6 +615,30 @@ machine_init(unsigned long r3, unsigned if (ppc_md.progress) ppc_md.progress(id mach(): done, 0x200); } +#ifdef CONFIG_BOOKE_WDT +/* Checks wdt=x and wdt_period=xx
mpc8248 SEC -- interrupt handler 'is' invoked
The address returned by kmalloc=0x009ffc5c is 4 byte aligned. Are u advicing that dma_map_single() should return 8 byte aligned , becuase thats what gets written into the Data-Paclet_descriptor later. regards -vikas On Wed, 3 Aug 2005 14:33:26 -0400 (EDT) Vikas Aggarwal va824363 at albany.edu wrote: I will try the new BSP but meanwhile like to debug my ported driver. Is there a way , like kernel level single-stepping to know why the interrupt status register gets a value of 0x0040 which means TEA , transfer error acknowledge. afaik, TEA usually means memory was unable to be accessed by the sec (somewhat along the same lines as a SIGBUS or SIGSEGV). It's a long shot, but you may want to increase the 4-byte alignment of the rng buffer (0x009ffc5c in your trace?) to at least 8-byte. as for debugging, you can printk sec status registers every time you write one, e.g. in a sec register write wrapper fn. Be sure to check the RNG interrupt status register, and the RNG status register, and the RNG interrupt control register. and if all else fails, you can bypass the channel infrastructure altogether, and use the RNG EU in slave mode. Reset the SEC, write the RNG Reset Control Register SR bit, write anyvalue to the RNG Data size register, and pull data off the RNG FIFO at will. Kim
[PATCH] ppc32: Add usb support to IBM stb04xxx platforms
Support ochi-ppc-soc.c on IBM stb04xxx platforms
Signed-off-by: Dale Farnsworth dale at farnsworth.org
Signed-off-by: Matt Porter mporter at kernel.crashing.org
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -11,6 +11,7 @@
#include linux/init.h
#include asm/ocp.h
+#include asm/ppc4xx_pic.h
#include platforms/4xx/ibmstb4.h
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,51 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr= USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+/* Polarity and triggering settings for internal interrupt sources */
+struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
+ { .polarity = 0x7f01,
+ .triggering = 0x,
+ .ext_irq_mask = 0x007e, /* IRQ0 - IRQ5 */
+ }
+};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end= USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end= USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = ppc-soc-ohci,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev= {
+ .dma_mask = dma_mask,
+ .coherent_dma_mask = 0xULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x4000
#define GPIO0_BASE 0x4006
+#define USB0_BASE 0x4001
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x4001)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -18,6 +18,19 @@
#include linux/ioport.h
#include asm/io.h
#include asm/machdep.h
+#include asm/ppc4xx_pic.h
+
+/*
+ * Define external IRQ senses and polarities.
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 3 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 4 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 5 */
+};
static struct resource smc91x_resources[] = {
[0] = {
How to disable dcache on MPC82xx platform
Thanks Dan for your explaination. I am linking multiple BDs only but no of BDs are very large in my case so I am allocating the memory and updating the BD pointer for all BDs. I am thinking of using mem start parameter option. I even tried using __get_free_page instead of using cpm_hostalloc() but that also did not help. If i use mem= option as kernel command line argument then I will have to just ioremap() this reserved address in my driver and start accessing the memory. I do not have to worry about cache related things. right? Thanks again, Prashant On 8/9/05, Dan Malek dan at embeddededge.com wrote: On Aug 9, 2005, at 10:57 AM, Prashant Alange wrote: Since the existing UART/ethernet drivers are using cpm_hostalloc() so I am also using the same function. As I have said too many times before, cpm_hostalloc() is only used to allocate small memory regions that would otherwise be wasteful with the normal Linux memory allocators. This function does not do anything special with the memory, aside from allowing us have multiple drivers share a page for efficiency. Then can I use kmalloc() to alloc such huge memory. Yes, and you should. If at all I have to configure BATx to just test how it behaves. No, that's not all you have to do. It's not a trivial process easily described here. . One more thing is that totally I am allocating about 1MB memory in a chunk of 200K. I can't comprehend a reason why you need to allocate so much space in a driver, especially for CPM devices. The driver is just a temporary FIFO for data flowing to/from other consumer/producers of the data in the system. If the software above a driver needs that kind of buffering, it should manage that itself. If you do need so much space, use the beauty of the CPM and link multiple BDs with reasonable sized buffers more easily managed by the existing Linux allocators. The other alternative is just reserve memory using the 'mem=' start parameter so it isn't know to Linux, and manage entirely yourself. -- Dan
[PATCH] ppc32: Added support for the Book-E style Watchdog Timer
Kumar Gala galak at freescale.com wrote:
PowerPC 40x and Book-E processors support a watchdog timer at the processor
core level. The timer has implementation dependent timeout frequencies
that can be configured by software.
One the first Watchdog timeout we get a critical exception. It is left
to board specific code to determine what should happen at this point. If
nothing is done and another timeout period expires the processor may
attempt to reset the machine.
Command line parameters:
wdt=0 : disable watchdog (default)
wdt=1 : enable watchdog
wdt_period=N : N sets the value of the Watchdog Timer Period.
The Watchdog Timer Period meaning is implementation specific. Check
User Manual for the processor for more details.
This patch is based off of work done by Takeharu Kato.
...
+#ifdef CONFIG_BOOKE_WDT
+/* Checks wdt=x and wdt_period=xx command-line option */
+int __init early_parse_wdt(char *p)
+{
+ extern u32 wdt_enable;
+
+ if (p strncmp(p, 0, 1) != 0)
+wdt_enable = 1;
+
+ return 0;
+}
+early_param(wdt, early_parse_wdt);
+
+int __init early_parse_wdt_period (char *p)
+{
+ extern u32 wdt_period;
+
+ if (p)
+ wdt_period = simple_strtoul(p, NULL, 0);
+
+ return 0;
+}
Would prefer to see the declaration of wdt_period in a header file, please.
But beware that wdt_enable() is already a static symbol in a couple of
watchdog drivers. It might be best to rename the ppc global to something
less generic-sounding while you're there.
How to disable dcache on MPC82xx platform
On Aug 9, 2005, at 5:50 PM, Prashant Alange wrote: ... I am linking multiple BDs only but no of BDs are very large in my case so I am allocating the memory and updating the BD pointer for all BDs. I don't understand what you mean here. If i use mem= option as kernel command line argument then I will have to just ioremap() this reserved address in my driver and start accessing the memory. I do not have to worry about cache related things. right? Yes. -- Dan
gen550_dbg.c cannot handle 16 or 32 bit access to UART registers
Hi, The arch/ppc/syslib/gen550_dbg.c assumes UART registers are all accessed in bytes. However in some designs the bus connected to UART can only be addressed in 32 or 16 bits. So some flexibility is desirable. And the change is kinda trivial. Before making this trivial change, I'm confused about two sets of defintions on io_type. In linux/serial.h, the following are defined. #define SERIAL_IO_PORT 0 #define SERIAL_IO_HUB6 1 #define SERIAL_IO_MEM 2 However in linux/serial_core.h, these are defined. #define UPIO_PORT (0) #define UPIO_HUB6 (1) #define UPIO_MEM(2) #define UPIO_MEM32 (3) Which set of defintion is better to be used in defining SERIAL_PORT_DFNS? Currently gen550_gdb.c use SERAIL_IO_ macros. Either adding a new macro SERIAL_IO_MEM32 in linux/serial.h or just use what are already there. Are these two sets duplicated? If they are, maybe one of them will be deprecated soon. Regards, -Shawn.
[PATCH] ppc32: Added support for the Book-E style Watchdog Timer
On Aug 9, 2005, at 5:01 PM, Andrew Morton wrote:
Kumar Gala galak at freescale.com wrote:
PowerPC 40x and Book-E processors support a watchdog timer at the
processor
core level. The timer has implementation dependent timeout
frequencies
that can be configured by software.
One the first Watchdog timeout we get a critical exception. It is
left
to board specific code to determine what should happen at this point.
If
nothing is done and another timeout period expires the processor may
attempt to reset the machine.
Command line parameters:
wdt=0 : disable watchdog (default)
wdt=1 : enable watchdog
wdt_period=N : N sets the value of the Watchdog Timer Period.
The Watchdog Timer Period meaning is implementation specific. Check
User Manual for the processor for more details.
This patch is based off of work done by Takeharu Kato.
...
+#ifdef CONFIG_BOOKE_WDT
+/* Checks wdt=x and wdt_period=xx command-line option */
+int __init early_parse_wdt(char *p)
+{
+extern u32 wdt_enable;
+
+if (p strncmp(p, 0, 1) != 0)
+ wdt_enable = 1;
+
+return 0;
+}
+early_param(wdt, early_parse_wdt);
+
+int __init early_parse_wdt_period (char *p)
+{
+extern u32 wdt_period;
+
+if (p)
+wdt_period = simple_strtoul(p, NULL, 0);
+
+return 0;
+}
Would prefer to see the declaration of wdt_period in a header file,
please.
But beware that wdt_enable() is already a static symbol in a couple of
watchdog drivers. It might be best to rename the ppc global to
something
less generic-sounding while you're there.
Ok, will make these changes and send an updated patch.
- kumar
pci_enable_device fails on MPC8541
Do you need support for the VIA IDE controller? I'm not sure if that is causing you issues. Also, can you try enabling DEBUG in arch/ppc/kernel/pci.c and send a boot log. I'm trying to figure out what is causing the resource conflict. It appears that the memory resource is reasonable, but there could be possible conflict on the IO resource side. Also, if you can send logs of the same thing from the working 8540 ADS that would be helpful. - kumar On Aug 9, 2005, at 12:18 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi Kumar, I am using Linux 2.6.11, u-boot 1.1.2. I see failure in pci_enable_device with message: PCI: Device :02:01.0 not available because of resource collisions I have attached three files: lspci_output.txt: out put of the lspci -v proc_pci.txt: output of the cat /proc/pci u-boot.txt: output of the pci command at u-boot Any help greatly appreciated, Bizhan -Original Message- From: Kumar Gala [mailto:kumar.gala at freescale.com] Sent: Monday, August 08, 2005 1:34 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 Bizhan, A few questions: 1. what kernel version are you using on these boards: 2. can you do an lspci -v on the boards - kumar On Aug 8, 2005, at 1:12 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi All, I am using two evaluation board from freescale, 8540ADS and MPC8541. The same PCI driver is being compiled and loaded on both platforms. The same PCI driver (developed by me) for DSP board compiled and loaded on both platforms. When I type: insmod C6415.ko on 8541 board, I get the following error: PCI: Device :02:01.0 not available because of resource collisions This messages is because of the execution of the generic PCI Linux command: pci_enable_device(pdev) The same API has no problem on 8540ADS. From UBOOT I can see my device is on bus 3: = pci 3 Scanning PCI devices on bus 3 BusDev FUNVendorIDDeviceIDDevice ClassSub-Class - - -- 03.01.000x104c0xa106. Any idea why the insmod fails on one board and not on the other one? Many thanks in advance, Bizhan ATT2118305.txt lspci_output.txt proc_pci.txt u-boot.txt
[Fwd: Wall clock accuracy]
Geoff Levand wrote:
FYI...
Original Message
Subject: Wall clock accuracy
Date: Tue, 9 Aug 2005 10:23:19 -0500
From: Rune Torgersen runet at innovsys.com
To: linuxppc-embedded at ozlabs.org
Hi
I have discovered that the accuracy of the wallclock (xtime) on ppc is
not very good.
I am running a custom telco board based on a 8266, and the main busclock
is derived off of a T1 reference clock.
I was noticing a huge number of logentries fron OpenNTPD about
adjustiing the clock, so I started to check.
The drift of the walltime was a little over 7 seconds in 15 hours (7
seconds slow) (equals about 130us per s)
When I checked around, I found that xtime is updated in kernel/time.c
and is updated by time_nsec nanoseconds per timer interrupt.
This value is hardcoded (through some obscure macros) to be 999848
ns/timertick. Tis is 152ns slow per timertick. This works out to be
152us per second, almost the value I found.
The problem here is that the CLOCK_TICK_RATE is not correctly defined.
This should be the rate at which the decrementer is clocked in hertz.
If this is properly defined the tick_nsec value will be what works to to
be an integral number of these that gives an nsec value less than or
equal to what LATCH says you should be using for the number of
decrementer counts in a jiffie. It is important that this be correctly
defined so that a) LATCH is right and b) the jiffies to/from conversions
are done right. These conversions rely on TICK_NSEC to get the right
answer. (Also, so you don't step into a computing mess, it is important
that these be defined at compile time so the compiler can do the heavy
lifting. If defined as variables the conversions will take a LOT longer
(and use more code to boot).)
If you are getting 999848, it would appear that you are using the x86
value which, I assume, is NOT right for a PPC, but then the PPC is NOT
my strong suit...
George
I have tried a few workarounds, and made one that modifies time_nsec
before update_wall_time_one_tick() is called.
With this fix (which is 8260 specific at the time) I have less than 1 ms
drift after 5 days.
The fix works by calculating how many ns and fractions of ns there is in
one timer-tick (one jiffie).
Then, at each timer interrupt, I accumulate the ns fractions, and add
whole ns to the timer when needed.
This is tested on 8266 under 80.00MHz and 82.575360MHz main busclock. It
also works correct if HZ=1024 instead of 1000
It is not meant as a patch to be added to the kernel right now, but more
of a possible solution to a problem that it doesn't seem anybody has
noticed before.
Index: arch/ppc/kernel/time.c
===
--- arch/ppc/kernel/time.c(revision 20)
+++ arch/ppc/kernel/time.c(working copy)
@@ -119,6 +119,11 @@
EXPORT_SYMBOL(profile_pc);
#endif
+
+#ifdef CONFIG_8260
+extern unsigned long get_ns_delta(void); /*
arch/ppc/syslib/m8260_setup.c */
+extern unsigned long tick_nsec; /* kernel/time.c */
+#endif
/*
* timer_interrupt - gets called when the decrementer overflows,
* with interrupts disabled.
@@ -148,6 +153,10 @@
/* We are in an interrupt, no need to save/restore flags
*/
write_seqlock(xtime_lock);
tb_last_stamp = jiffy_stamp;
+
+#ifdef CONFIG_8260
+ tick_nsec = get_ns_delta();
+#endif
do_timer(regs);
/*
@@ -179,7 +188,7 @@
write_sequnlock(xtime_lock);
}
if ( !disarm_decr[smp_processor_id()] )
- set_dec(next_dec);
+ set_dec(next_dec-1);
last_jiffy_stamp(cpu) = jiffy_stamp;
if (ppc_md.heartbeat !ppc_md.heartbeat_count--)
Index: arch/ppc/syslib/m8260_setup.c
===
--- arch/ppc/syslib/m8260_setup.c (revision 20)
+++ arch/ppc/syslib/m8260_setup.c (working copy)
@@ -31,6 +31,8 @@
#include cpm2_pic.h
+#include linux/module.h
+
unsigned char __res[sizeof(bd_t)];
extern void cpm2_reset(void);
@@ -82,16 +84,63 @@
/* The decrementer counts at the system (internal) clock frequency
* divided by four.
*/
+unsigned long tb_time_nsec;
+unsigned long tb_frac_nsec;
+unsigned long tb_frac_limit;
+
+extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
+
static void __init
m8260_calibrate_decr(void)
+{
+bd_t *binfo = (bd_t *)__res;
+int freq, divisor, tick_freq;
+uint64_t tmp;
+printk(Calibrating Decrementer\n);
+
+freq = binfo-bi_busfreq;
+divisor = 4;
+
+/* get rounded off decrementer frequency */
+tick_freq = (freq + 3) / 4;
+
+/* get number of timebase ticks per jiffy (timerint) */
+tb_ticks_per_jiffy = (tick_freq + (HZ/2)) / HZ;
+tb_to_us = mulhwu_scale_factor(tick_freq,
passing ram= argument to kernel
Hi, I am trying to pass ram= argument to kernel and my bootcmd is as shown below tftpboot 0300 prashant/root.img; tftpboot 0010 prashant/uImage; setenv b ootargs root=/dev/ram ram=60M ip=10.67.65.68:10.67.65.39:255.255.255.0:MPC8270:eth1:off; bootm 0010 0300 I have 64 MB RAM on my system. With above command if I boot the board and see cat /proc/meminfo I still see 64MB RAM. Can anyone tell me, how to pass ram argument. Thanks, Prashant
passing ram= argument to kernel
I think you want mem=60M - kumar On Tue, 9 Aug 2005, Prashant Alange wrote: Hi, I am trying to pass ram= argument to kernel and my bootcmd is as shown below tftpboot 0300 prashant/root.img; tftpboot 0010 prashant/uImage; setenv b ootargs root=/dev/ram ram=60M ip=10.67.65.68:10.67.65.39:255.255.255.0:MPC8270:eth1:off; bootm 0010 0300 I have 64 MB RAM on my system. With above command if I boot the board and see cat /proc/meminfo I still see 64MB RAM. Can anyone tell me, how to pass ram argument. Thanks, Prashant ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
pci_enable_device fails on MPC8541
Bizhan, I noticed that lspci reports SERR on the secondary side of the bridge from bus 0 to bus 2. Do you know what's causing SERR to be asserted? Kylo On 8/9/05, Bizhan Gholikhamseh (bgholikh) bgholikh at cisco.com wrote: Hi Kumar, I am using Linux 2.6.11, u-boot 1.1.2. I see failure in pci_enable_device with message: PCI: Device :02:01.0 not available because of resource collisions I have attached three files: lspci_output.txt: out put of the lspci -v proc_pci.txt: output of the cat /proc/pci u-boot.txt: output of the pci command at u-boot Any help greatly appreciated, Bizhan -Original Message- From: Kumar Gala [mailto:kumar.gala at freescale.com] Sent: Monday, August 08, 2005 1:34 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 Bizhan, A few questions: 1. what kernel version are you using on these boards: 2. can you do an lspci -v on the boards - kumar On Aug 8, 2005, at 1:12 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi All, I am using two evaluation board from freescale, 8540ADS and MPC8541. The same PCI driver is being compiled and loaded on both platforms. The same PCI driver (developed by me) for DSP board compiled and loaded on both platforms. When I type: insmod C6415.ko on 8541 board, I get the following error: PCI: Device :02:01.0 not available because of resource collisions This messages is because of the execution of the generic PCI Linux command: pci_enable_device(pdev) The same API has no problem on 8540ADS. From UBOOT I can see my device is on bus 3: = pci 3 Scanning PCI devices on bus 3 BusDev FUNVendorIDDeviceIDDevice ClassSub-Class -- -- 03.01.000x104c0xa106. Any idea why the insmod fails on one board and not on the other one? Many thanks in advance, Bizhan ATT2118305.txt ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
