Issues with raw write using MTD Char Driver
Greetings all, Hi, I have 8MB AMD29FXX flash organized as 16 chips of 0.5 MB each as DIMM package on a MPC885 board. The same is accessed as a 4 x 2MB interleaved flash, of effective sector size 256k. I'm using the MTD concatation option to interleave thes chips. I'm using Arabella Linux, kernel 2.4.25. When I attempt to write a 256k chunk of data to an erased sector the kerel crashes with the followng dump Waitin c03b2000[25] 'driv_mtd' Last syscall: 4 last math last altivec GPR00: 0004 7DC0 000A 0001 0008 3006C2A4 0001 GPR08: 7CD0 0190 0001 10010EAC 300052EC 30005140 30005000 GPR16: 0002 00CC riv_mtd' Last syscall: 4 last math last altivec GPR00: 0004 7DC0 000A 0001 0008 3006C2A4 0001 GPR08: 7CD0 0190 0001 10010EAC 300052EC 30005140 30005000 GPR16: 0002 00CC 300050A0 00CC 30002D6C 3C1C 3915 30005154 GPR24: 3130 3000 1000 1000 0003 10014000 Call backtrace: 18A0 30026FE0 30026FFC 1780 7F74 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing <0>Rebooting in 180 seconds.. However when I try to write to the same sector in smaller chunks of 512 bytes, with a sleep of a few microseconds, the write operation to entire sector is successful, however a warning is raised. Warning: DQ5 raised while program operation was in progress, however operation completed OK I have the following is my kernel configuration : CONFIG_MTD=y CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CONCAT=y CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y CONFIG_MTD_JEDECPROBE=y CONFIG_MTD_GEN_PROBE=y CONFIG_MTD_CFI_ADV_OPTIONS=y CONFIG_MTD_CFI_BE_BYTE_SWAP=y CONFIG_MTD_CFI_GEOMETRY=y CONFIG_MTD_CFI_B4=y CONFIG_MTD_CFI_I4=y CONFIG_MTD_CFI_AMDSTD=y CONFIG_MTD_PHYSMAP=y CONFIG_MTD_PHYSMAP_START=280 CONFIG_MTD_PHYSMAP_LEN=80 CONFIG_MTD_PHYSMAP_BUSWIDTH=4 Is there a maximum chunk that be written to a sector a one shot? What am I doing wrong? TIA, -raghav- ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC855T
Hi
I'm trying to compile a ppc kernel and having some problems. I
followed the http://penguinppc.org/embedded/ and installed gcc and
binutils to powerpc. When I try compile 2.6.7 kernel, I had this:
CC arch/ppc/kernel/traps.o
In file included from arch/ppc/kernel/traps.c:29:
include/linux/interrupt.h:47: error: parse error before '(' token
include/linux/interrupt.h:47: warning: function declaration isn't a prototype
include/linux/interrupt.h:47: error: parse error before '*' token
include/linux/interrupt.h:47: error: `irqreturn_t' declared as
function returning a function
include/linux/interrupt.h:47: warning: function declaration isn't a prototype
include/linux/interrupt.h:47: error: 'irqreturn_t' redeclared as
different kind of symbol
include/asm/mpc8xx.h:99: error: previous declaration of 'irqreturn_t' was here
include/linux/interrupt.h:47: error: parse error before "unsigned"
arch/ppc/kernel/traps.c: In function `AltivecUnavailException':
arch/ppc/kernel/traps.c:650: warning: unsigned int format, long
unsigned int arg (arg 3)
make[1]: *** [arch/ppc/kernel/traps.o] Error 1
make: *** [arch/ppc/kernel] Error 2
When I let the kernel config to 6xx/7xx/74xx/8260 processor, I'm able
to compile the kernel without problems. When I change to 8xx
processor, I got this error.
I'm trying set am cross compile enviroment to MPC855T box. Can you
give some light?
Thanks
--
-
?v? Sulamita Garcia
/(_)\ LinuxChix Brasil
^ ^ http://www.linuxchix.org.br/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Issues with raw write using MTD Char Driver
In message you wrote: > > Hi, I have 8MB AMD29FXX flash organized as 16 chips of 0.5 MB each as DIMM > package on a > MPC885 board. The same is accessed as a 4 x 2MB interleaved flash, of > effective sector size > 256k. I'm using the MTD concatation option to interleave thes chips. I'm > using Arabella Linux, > kernel 2.4.25. Why are you posting the same messages to different mailing lists (like the MTD list and this one)? Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de "Plan to throw one away. You will anyway." - Fred Brooks, "The Mythical Man Month" ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCI scanning and devices initialization
Stefano Gaiotto wrote: >Dear colleagues, > >I'm trying to use a device connected to a PCI bus, more exactly a >PCI/PCMCIA bridge >with u-boot-1.1.1 and Linux (2.4.24 and 2.6.8) in a board with MPC8270. > >Both u-boot and Linux, during scanning procedure show me only the PCI >bridge [1057/18c0] but I can't see the devices connected to the bus. > >I'm a novice with PCI bus and I'm not sure the board is good (is the first >prototype) and so I'd like to know if scanning procedure should tell me the >devices >connected or I have to do some device initialization before I can see them >during scanning. > >I suppose I should see them during scanning and then initialise them via >PCI bus. > >If my assumption is true, shall I suppose my hardware is not good? Or >anything else? > > Hi Yes, there may be something wrong with your hardware. I'm not familiar with the MPC8270 PCI code but your devices should show up during scan. At the PCI init, PCI devices don't yet have an address, so the host detects them using configuration cycles. Theses uses a different addressing scheme, using each address line as a kind of "chip select". So the devices know the host is "talking" to it just by looking at it's IDSEL line going asserted. If on your board the IDSEL isn't wired properly then it won't work. Hopefully if that's the case, you can just wire it by hand, it's not a high speed signal. Also, I've come accross some simple FPGA implementation of PCI devices that just didn't respond to config ... Sylvain PS: I'm not a PCI expert and that's just my understanding. There is probably a lot of things that can go wrong. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCI scanning and devices initialization
Dear colleagues, I'm trying to use a device connected to a PCI bus, more exactly a PCI/PCMCIA bridge with u-boot-1.1.1 and Linux (2.4.24 and 2.6.8) in a board with MPC8270. Both u-boot and Linux, during scanning procedure show me only the PCI bridge [1057/18c0] but I can't see the devices connected to the bus. I'm a novice with PCI bus and I'm not sure the board is good (is the first prototype) and so I'd like to know if scanning procedure should tell me the devices connected or I have to do some device initialization before I can see them during scanning. I suppose I should see them during scanning and then initialise them via PCI bus. If my assumption is true, shall I suppose my hardware is not good? Or anything else? Thank you for your attention Regards, Stefano ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[Linux-ATM-General] Fw: MPHY supported in mpc8260sar
And exactly how many PHY's is that? Gilad. On Wed, 2004-08-18 at 10:31, Zoran Stojsavljevic wrote: > I enhanced 8260 ATM driver... now I am able to support maximum number > of PHYs by mpc8260. With up to eight priorities per each PHY. > > Just an additional info... :) > > - Original Message - > From: "Zoran Stojsavljevic" > Sent: Thursday, August 05, 2004 11:09 AM > Subject: MPHY supported in mpc8260sar > > > I finally achieved multiphy mpc8260sar (with some limitations). The > > driver is able to support 8 PHYs (one PHY per unique priority). The > > driver is developed out of Peter's McCormick single PHY version. > > > > For some unknow reason I could NOT achieve MPHY support with only > > one priority (for example highest PRIority 0). In order to make MPHY > > to work correctly I assigned a unique priority per PHY. With 8 PHYs > > the mapping looks like: PHY0/PRIO0, PHY1/PRIO1... PHY7/PRIO7, eg. > > PHYx/PRIOx, where x is in range [0..7]! > > > > The another limitation is that I did NOT fix the VP range, eg. I am > > using only VP0 (one VP) with different VCs, where least three (3) > > significant bits of each VC assume the selected PHY. In other words, > > I am using 8 nas interfaces, and VCs (decimal radix) from 40 (0x28) > > to 47 (0x2F), where VC 40 is attached to PHY0, VC 41 to PHY1... VC47 > > to PHY7. While issuing ATM xmit command I am deriving least three > > significant bits of currently processed VC and I'm putting them to > > the COMM_INFO words (offset 0x86, field PHY#), described in section > > 30.14 of MPC8260 PowerQUICC II Family Reference Manual (Revision 1, > > date 05/2003). > > > > If you all find this info of (some) interest, I can do the patch > > (against latest version in CVS) so we can store this limited edition > > of the MPHY version under the mpc8260sar driver project. > > > > - Original Message - > > From: "Alex Zeffertt" > > Sent: Monday, January 26, 2004 1:41 PM > > Subject: Announcement: MPHY now supported in mpc860sar > > > > > Just a quick note to say that multi-phy is now supported by the > > > mpc860sar ATM driver, thanks to a patch by Rodolfo Giometti. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[Linux-ATM-General] Fw: MPHY supported in mpc8260sar
I guess, lower 16 PHYs. With some enhancement to the driver it could reach 32 (additions for the upper 16 PHY lookup table). The limitation is that there is still only one VP (0) and 64 VCs available without any change to the driver's code. I guess, if used for aDSL, 16 PHYs will be the maximum number of supported PHYs, because of BW limitations. Do not forget that UTOPIA can support 155 Mbps... but this is in the ideal case, where there is single PHY0 with single priority 0 used. I guess (not sure yet) if you would like to support 16 aDSL PHYs, there will be theoretically no more than 1.5 Mbps per PHY BW achievement (PHYs 0, 1, 2 and 3 excluded from this, they have HW 0 cell insertion mechanismus, so they are able to achieve much faster output). Just assumption. Regards, Zoran - Original Message - From: "Gilad Rom" <[EMAIL PROTECTED]> Sent: Wednesday, August 18, 2004 9:45 AM Subject: Re: MPHY supported in mpc8260sar > And exactly how many PHY's is that? > > On Wed, 2004-08-18 at 10:31, Zoran Stojsavljevic wrote: > > I enhanced 8260 ATM driver... now I am able to support maximum > > number of PHYs by mpc8260. With up to eight priorities per each PHY. > > > > Just an additional info... :) > > > > - Original Message - > > From: "Zoran Stojsavljevic" > > Sent: Thursday, August 05, 2004 11:09 AM > > Subject: MPHY supported in mpc8260sar > > > > > I finally achieved multiphy mpc8260sar (with some limitations). > > > The driver is able to support 8 PHYs (one PHY per unique > > > priority). The driver is developed out of Peter's McCormick single > > > PHY version. > > > > > > For some unknow reason I could NOT achieve MPHY support with only > > > one priority (for example highest PRIority 0). In order to make > > > MPHY to work correctly I assigned a unique priority per PHY. > > > With 8 PHYs the mapping looks like: PHY0/PRIO0, PHY1/PRIO1... > > > PHY7/PRIO7, eg. PHYx/PRIOx, where x is in range [0..7]! > > > > > > The another limitation is that I did NOT fix the VP range, eg. I > > > am using only VP0 (one VP) with different VCs, where least three > > > (3) significant bits of each VC assume the selected PHY. In other > > > words, I am using 8 nas interfaces, and VCs (decimal radix) from > > > 40 (0x28) to 47 (0x2F), where VC 40 is attached to PHY0, VC 41 > > > to PHY1... VC47 to PHY7. While issuing ATM xmit command I am > > > deriving least three significant bits of currently processed VC > > > and I'm putting them to the COMM_INFO words (offset 0x86, field > > > PHY#), described in section 30.14 of MPC8260 PowerQUICC II Family > > > Reference Manual (Revision 1, date 05/2003). > > > > > > If you all find this info of (some) interest, I can do the patch > > > (against latest version in CVS) so we can store this limited > > > edition of the MPHY version under the mpc8260sar driver project. > > > > > > - Original Message - > > > From: "Alex Zeffertt" > > > Sent: Monday, January 26, 2004 1:41 PM > > > Subject: Announcement: MPHY now supported in mpc860sar > > > > > > > Just a quick note to say that multi-phy is now supported by the > > > > mpc860sar ATM driver, thanks to a patch by Rodolfo Giometti. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
uart.c doesn't compile
This driver has been replaced with drivers/serial/cpm_uart/ - kumar On Aug 18, 2004, at 2:30 AM, Jaap-Jan Boor wrote: > > Hi, > > I pulled the latest linuxppc-2.5 using bk and try > to build for 8xx (FADS). It seems uart.c doesn't > build anymore for SMCs: > > CC arch/ppc/8xx_io/uart.o > arch/ppc/8xx_io/uart.c: In function `change_speed': > arch/ppc/8xx_io/uart.c:992: warning: implicit declaration of function > `m8xx_cpm_setbrg' > arch/ppc/8xx_io/uart.c: In function `rs_8xx_init': > arch/ppc/8xx_io/uart.c:2689: error: `dp_addr' undeclared (first use in > this function) > arch/ppc/8xx_io/uart.c:2689: error: (Each undeclared identifier is > reported only once > arch/ppc/8xx_io/uart.c:2689: error: for each function it appears in.) > make[1]: *** [arch/ppc/8xx_io/uart.o] Error 1 > make: *** [arch/ppc/8xx_io] Error 2 > > should dp_addr not be changed in dp_offset? > > Jaap-Jan > > -- > J.G.J. Boor Anton Philipsweg 1 > Software Engineer 1223 KZ Hilversum > AimSys bv tel. +31 35 689 1941 > Postbus 2194, 1200 CD Hilversum mailto:jjboor at aimsys.nl > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Fw: MPHY supported in mpc8260sar
I enhanced 8260 ATM driver... now I am able to support maximum number of PHYs by mpc8260. With up to eight priorities per each PHY. Just an additional info... :) Regards, Zoran Stojsavljevic DKTS Pupin Telecom zoransto at dkts.co.yu - Original Message - From: "Zoran Stojsavljevic" <[EMAIL PROTECTED]> Sent: Thursday, August 05, 2004 11:09 AM Subject: MPHY supported in mpc8260sar > I finally achieved multiphy mpc8260sar (with some limitations). The > driver is able to support 8 PHYs (one PHY per unique priority). The > driver is developed out of Peter's McCormick single PHY version. > > For some unknow reason I could NOT achieve MPHY support with only > one priority (for example highest PRIority 0). In order to make MPHY > to work correctly I assigned a unique priority per PHY. With 8 PHYs > the mapping looks like: PHY0/PRIO0, PHY1/PRIO1... PHY7/PRIO7, eg. > PHYx/PRIOx, where x is in range [0..7]! > > The another limitation is that I did NOT fix the VP range, eg. I am > using only VP0 (one VP) with different VCs, where least three (3) > significant bits of each VC assume the selected PHY. In other words, > I am using 8 nas interfaces, and VCs (decimal radix) from 40 (0x28) > to 47 (0x2F), where VC 40 is attached to PHY0, VC 41 to PHY1... VC47 > to PHY7. While issuing ATM xmit command I am deriving least three > significant bits of currently processed VC and I'm putting them to the > COMM_INFO words (offset 0x86, field PHY#), described in section 30.14 > of MPC8260 PowerQUICC II Family Reference Manual (Revision 1, date > 05/2003). > > If you all find this info of (some) interest, I can do the patch > (against latest version in CVS) so we can store this limited edition > of the MPHY version under the mpc8260sar driver project. > > - Original Message - > From: "Alex Zeffertt" > Sent: Monday, January 26, 2004 1:41 PM > Subject: Announcement: MPHY now supported in mpc860sar > > > Just a quick note to say that multi-phy is now supported by the > > mpc860sar ATM driver, thanks to a patch by Rodolfo Giometti. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
uart.c doesn't compile
Hi, I pulled the latest linuxppc-2.5 using bk and try to build for 8xx (FADS). It seems uart.c doesn't build anymore for SMCs: CC arch/ppc/8xx_io/uart.o arch/ppc/8xx_io/uart.c: In function `change_speed': arch/ppc/8xx_io/uart.c:992: warning: implicit declaration of function `m8xx_cpm_setbrg' arch/ppc/8xx_io/uart.c: In function `rs_8xx_init': arch/ppc/8xx_io/uart.c:2689: error: `dp_addr' undeclared (first use in this function) arch/ppc/8xx_io/uart.c:2689: error: (Each undeclared identifier is reported only once arch/ppc/8xx_io/uart.c:2689: error: for each function it appears in.) make[1]: *** [arch/ppc/8xx_io/uart.o] Error 1 make: *** [arch/ppc/8xx_io] Error 2 should dp_addr not be changed in dp_offset? Jaap-Jan -- J.G.J. Boor Anton Philipsweg 1 Software Engineer 1223 KZ Hilversum AimSys bv tel. +31 35 689 1941 Postbus 2194, 1200 CD Hilversum mailto:jjboor at aimsys.nl ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCI scanning and devices initialization
Hi, > Yes, there may be something wrong with your hardware. This could only be _one_ reason > At the PCI init, PCI devices don't yet have an address, so the host > detects them using configuration cycles. Theses uses a different > addressing scheme, using each address line as a kind of "chip select". > So the devices know the host is "talking" to it just by > looking at it's > IDSEL line going asserted. If on your board the IDSEL isn't wired > properly then it won't work. Hopefully if that's the case, > you can just > wire it by hand, it's not a high speed signal. Does the U-Boot PCI setup routine handles PCI devices behind a "PCI to anything" bridge? Sometimes simple code ignores bridges. Don't know the current U-Boot implementation. If not, there is no chance to access any devices behind it (even if the hardware is correct). JB ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
