i2c-algo-8260, i2c-pm826 - I did the porting to linux-2.6.x
In case someone is interested, I have these drivers ported to linux-2.6.x (I use 2.6.7). Miguel - Forwarded by Miguel Valero/AxxessIT on 23.07.04 09:21 - Miguel Valero 21.07.04 12:17 To: linuxppc-embedded at lists.linuxppc.org cc: Subject:i2c-algo-8260, i2c-pm826 - has someone ported that to linux-2.6.x ? if so, I would very much appreciate the source code ! Miguel Valero ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
random ramblings on 8xx patches (long and tedious :-)
On Thu, 2004-07-22 at 19:35, Dan Malek wrote: On Jul 22, 2004, at 1:10 PM, Wells, Charles wrote: ... The real problem is that the MPC850 USB controller was designed for target-mode applications and not host-mode applications. And even in target mode I see unexpected underruns, handshake timeouts and a stucking interrupt endpoint. The software can recover from these errors though. There are Linux versions of software that work fine in many applications. USB in general doesn't rate high on my list of engineering successes. very much right. It works, we don't know why :) I'm never surprised when I plug something in to any kind of system and it doesn't work. -- Dan 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/
Hang in send() to a socket
Hi. I'm testing a program to send files thru a TCP socket on an MPC5200. The program itself is quite simple: reads block from file, adds headers for a custom protocol, and sends the packet to the socket. This works without problems on x86 architecture, but in PPC, the programs stops forever in one of the writings to the socket after having sent a random number of packets. Strace says that it stops on a send(), and netstat shows that the connection is stablished, and stays this way: Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 63903 160.100.100.169:12700 160.100.100.189:41097 ESTABLISHED Until the kernel destroys the socket. The program isn't hanged, and it detects when the socket closes (Connection timed out) if you wait enough, and exits properly. It just stops in send(). Is there any know problem with this on the MPC5200? The platform is a Lite5200, and kernel linuxppc_2_4_devel from Denx CVS. Thanks I?igo ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
random ramblings on 8xx patches (long and tedious :-)
On Thu, 22 Jul 2004, Matt Porter wrote: On Thu, Jul 22, 2004 at 08:00:01AM -0400, Robert P. J. Day wrote: [Remove long explanation] thoughts? i'm willing to help with menu reorg -- my only contribution to the 2.6 kernel was to thoroughly restructure the Filesystems menu. which means i like it, and i don't care what *you* think. ;-) You raise a lot of interesting concerns on usability for a newbie. Descriptive menu options with useful help info are a good thing. Please send a patch with your proposed changes so it can be reviewed. the first addition i'd like to see is a set of extra conditionals added to arch/ppc/config.in, to refine the type of processor. in some cases, it's not enough to know that you have an 8xx, and it's *too* refined to know that you have, say, a TDM850M. sometimes, you need to know only that you have an 823, or 850, or whatever. perhaps variables: CONFIG_8xx_823 CONFIG_8xx_850 CONFIG_8xx_860 or alternatively named CONFIG_PPC_823 CONFIG_PPC_850 and so on. i've already seen code in the kernel tree (can't remember where, sadly) that goes through a tedious preprocessor check when all it wanted to know was the actual processor. and all of this extra checking and setting could be done entirely within the arch/ppc/config.in file, with no harm to other files or small animals. (i suspect the same might hold true for 4xx, 6xx and others, but i haven't looked at those yet.) i can't design this patch just yet, as i'm not sure how many different variants are worth keeping track of. if there's a list someone could point me at, that would be just ducky. rday p.s. sadly, there's some inconsistency in the way the current variable names were chosen. in that same file, we have both of CONFIG_8xx and CONFIG_PPC_5xxx. even thought it's more verbose, it might have been safer to keep that PPC internal string to avoid potential conflicts. so it's a tossup as to what variable name would be the best choice to identify an 850: CONFIG_850 CONFIG_PPC_850 CONFIG_8xx_850 thoughts? yes, this is just me being pedantic. it gets worse. :-) ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] add mpc8xx watchdog driver
Hi Tom, this adds the 2.4 watchdog driver to linuxppc-2.5. The call to m8xx_wdt_handler_install() is already present in m8xx_setup.c. Please apply. Signed-off-by: Andreas Oberritter obi at saftware.de -- next part -- A non-text attachment was scrubbed... Name: watchdog.diff Type: text/x-patch Size: 10310 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20040723/877aeee9/attachment.bin
random ramblings on 8xx patches (long and tedious :-)
In message Pine.LNX.4.60.0407230821050.4487 at localhost.localdomain you wrote: CONFIG_850 CONFIG_PPC_850 CONFIG_8xx_850 thoughts? yes, this is just me being pedantic. it gets worse. :-) How far do you want to take this? 850 may not be detailed enough - is it a MPC850, MPC850DE, MPC850DSL, or a MPC850SR ? There is at least 40 differnt models of 8xx processors. Go and add 82xx and 85xx and 52xx and than start working down the 4xx, 7xx, 74xx, ... lines? I think this gives a LONG list... Best regards, 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 If something is different, it's either better or worse, and usually both.- Larry Wall ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] export m8xx_cpm_hostalloc
Hi Tom, to build an i2c driver as a module, m8xx_cpm_hostalloc must be exported. We are using a driver which is not in the kernel tree[1]. I tried to merge the in-kernel i2c driver with it, but I failed and don't have the time to investigate why our driver works with the dbox2 board and the in-kernel driver doesn't. This function has been exported in 2.4. Is it ok to do that for 2.6, too? Regards, Andreas [1]: http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/driver/i2c/dbox2_i2c.c?rev=1.28content-type=text/vnd.viewcvs-markup ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] export m8xx_cpm_hostalloc
Forgot to attach the patch, so here it is. -- next part -- A non-text attachment was scrubbed... Name: export_hostalloc.diff Type: text/x-patch Size: 791 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20040723/85b603a3/attachment.bin
[PATCH] add board_init() (was [PATCH] make platform_init() weak for 8xx)
Am Mo, den 19.07.2004 schrieb Tom Rini um 20:20: On Mon, Jul 19, 2004 at 07:34:28PM +0200, Andreas Oberritter wrote: On Mon, 2004-07-19 at 18:32, Tom Rini wrote: Second, this takes us in the direction of 82xx. Until the 82xx abstractions get flushed out a bit more, I remain unconvinced that they're really the right way to go (perhaps hooking the other direction would work better, e.g. platform_init() calls board_init(), with a weak version provided, and some functions forced to be provided by board.c, such as m8xx_map_io). I chose this way because it seemed to be a simple way to port the dbox2 board to 2.6 using the new device API. Is there another 8xx board which uses the device API for its onboard peripherials and can be used as a reference? Can I get my devices registered without modifying platform_init, or shall I send a patch with the board_init() you mentioned? See my board.c attached. There currently isn't a reference platform for what you speak of. My preference would be to see what I described given a shot to see if it looks better or worse (and it better, or worse, in the flow of things). How about this patch? Regards, Andreas -- next part -- A non-text attachment was scrubbed... Name: board_init.diff Type: text/x-patch Size: 843 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20040723/5aca346d/attachment.bin
[PATCH] export m8xx_cpm_hostalloc
On Fri, Jul 23, 2004 at 03:49:27PM +0200, Andreas Oberritter wrote: Hi Tom, to build an i2c driver as a module, m8xx_cpm_hostalloc must be exported. We are using a driver which is not in the kernel tree[1]. I tried to merge the in-kernel i2c driver with it, but I failed and don't have the time to investigate why our driver works with the dbox2 board and the in-kernel driver doesn't. This function has been exported in 2.4. Is it ok to do that for 2.6, too? Must the driver use hostalloc? I didn't think that i2c was called so early that kmalloc/bootmem_alloc() (or so) couldn't be used. -- Tom Rini http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
random ramblings on 8xx patches (long and tedious :-)
On Fri, 23 Jul 2004, Wolfgang Denk wrote: In message Pine.LNX.4.60.0407230821050.4487 at localhost.localdomain you wrote: CONFIG_850 CONFIG_PPC_850 CONFIG_8xx_850 thoughts? yes, this is just me being pedantic. it gets worse. :-) How far do you want to take this? 850 may not be detailed enough - is it a MPC850, MPC850DE, MPC850DSL, or a MPC850SR ? There is at least 40 differnt models of 8xx processors. Go and add 82xx and 85xx and 52xx and than start working down the 4xx, 7xx, 74xx, ... lines? I think this gives a LONG list... possibly, but there's no need for it to be infinitely detailed. if you look at arch/ppc/config.in, there's obviously a coarse categorization with things like CONFIG_6xx, CONFIG_8xx and so on. at the other extreme, there's specific models like CONFIG_ARCTIC2, etc. there's also *some* current refinement somewhere in the middle with conditionals like: if [ $CONFIG_TQM823M = y -o \ $CONFIG_TQM850M = y -o \ $CONFIG_TQM855M = y -o \ $CONFIG_TQM860M = y -o \ $CONFIG_TQM862M = y -o \ $CONFIG_NSCU= y ]; then define_bool CONFIG_TQM8xxM y so *someone* must have thought this approach was a good idea at some point. :-) so the obvious question is, is there any value for more of this mid-level categorization? if not, then we can just forget the idea and move on. but if there is, no one says it has to be patched in all at once. different people who work with different processors can submit patches relative to their area to make future work easier. if someone works primarily with, say, 4xx processors, they can submit a patch to add to the config.in file for that family refining the 4xx family. whatever makes their life easier. if no one cares about a particular family, no big deal. as a thought, what about additional variables of the form CONFIG_850, CONFIG_7xx, CONFIG_74xx, etc. (sadly, as i mentioned earlier, there's already some inconsistency between names like CONFIG_8xx and CONFIG_PPC_5xxx with that internal PPC_. technically, i would have preferred variables of the form CONFIG_PPC_, but i think the trend has already been established.) so, to start things off, here's a proposal. if this kind of refinement would have made/will make your life easier, email me directly with the patch you'd like to see added. i'll collect them all, paste them together, make sure they're aesthetically consistent, examine the final result as if i know what i'm doing, and submit the whole thing as one big patch. you don't need to be perfect with the first attempt, you can always save further, more detailed refinement for a later patch. thoughts? rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
850 Rev C (the USB fix)
850 Errata http://www.freescale.com/files/32bit/doc/errata/MPC850CE.pdf 850 Errata Summary http://www.freescale.com/files/netcomm/doc/errata/MPC850CESUMM.pdf rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] export m8xx_cpm_hostalloc
On Jul 23, 2004, at 10:02 AM, Tom Rini wrote: Must the driver use hostalloc? I didn't think that i2c was called so early that kmalloc/bootmem_alloc() (or so) couldn't be used. Should use ...consistent_alloc() -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] export m8xx_cpm_hostalloc
On Fri, Jul 23, 2004 at 10:41:36AM -0400, Dan Malek wrote: On Jul 23, 2004, at 10:02 AM, Tom Rini wrote: Must the driver use hostalloc? I didn't think that i2c was called so early that kmalloc/bootmem_alloc() (or so) couldn't be used. Should use ...consistent_alloc() Not having the full context handy (and trying to listen to rml right now), yes, that too could be the correct answer here. -- Tom Rini http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
random ramblings on 8xx patches (long and tedious :-)
In message Pine.LNX.4.60.0407230947570.5108 at localhost.localdomain you wrote: There is at least 40 differnt models of 8xx processors. Go and add 82xx and 85xx and 52xx and than start working down the 4xx, 7xx, 74xx, ... lines? I think this gives a LONG list... possibly, but there's no need for it to be infinitely detailed. if you look at arch/ppc/config.in, there's obviously a coarse categorization with things like CONFIG_6xx, CONFIG_8xx and so on. at the other extreme, there's specific models like CONFIG_ARCTIC2, etc. But if I understood you right you intend to use this selection to prevent the kconfig system to present options to the user which don't apply for this processor. So you need to know if this is for example a MPC860, MPC860T or MPC860P because the latter two have a FEC so you must enable the FEC options in kconfig, while the first one does not. Or you need to know if it's MPC850 which has only one SCC, or a MPC850DE, MPC850SR, or MPC850DSL which have two. If you want to be consequent, and only present such config options to the user that really apply to his hardware, then you must bite the bullet. if [ $CONFIG_TQM823M = y -o \ $CONFIG_TQM850M = y -o \ $CONFIG_TQM855M = y -o \ $CONFIG_TQM860M = y -o \ $CONFIG_TQM862M = y -o \ $CONFIG_NSCU= y ]; then define_bool CONFIG_TQM8xxM y so *someone* must have thought this approach was a good idea at some point. :-) This is (1) something different (because all these use the very same board), and (2) insignificant, as it it not part of the official kernel tree. so the obvious question is, is there any value for more of this mid-level categorization? if not, then we can just forget the idea and move on. It was you who started this, with the intention to prevent the user from selecting bogus config options. [My opinion is that this is not a high priority issue; if we can provide a working default configuration for a board this is fine; if the user changes this for his requirements we have to assume that he knows what he is doing. UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn but if there is, no one says it has to be patched in all at once. Arghh... Please don't. If we had different approaches in the kernel depoending on which processor family you're working with it would be just worse. so, to start things off, here's a proposal. if this kind of refinement would have made/will make your life easier, email me directly with the patch you'd like to see added. i'll collect them Please don't expect a patch from me. Best regards, 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 The thing is, as you progress in the Craft, you'll learn there is another rule... When you break rules, break 'em good and hard. - Terry Pratchett, _Wyrd Sisters_ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.4 versus 2.6 patches
i just realized that the sample excerpts i was posting from the ppc config files were from the 2.4 source tree, not 2.6, so for most of the folks on this list, i suspect they'd be more interested in patches to a 2.6-style Kconfig file, not a 2.4-style config.in file, correct? rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC5200, Hang in send() to a socket
[ I?igo Lopez Barranco writes: ] Hi. I'm testing a program to send files thru a TCP socket on an MPC5200. programs stops forever in one of the writings to the socket after having sent a random number of packets. Strace says that it stops on a send(), and netstat shows that the connection is stablished, and stays this way: I see this problem too during a FTP put operation. The network remains up as a concurrently executing ping has no problem and I can restart the FTP transfer which will happily transfer an random number of packets before halting again. I also noticed a nasty memory leak associated with this -- if I rerun the FTP transfer enough times the system will run out of memory. It may be related to lost RX packets. The RX error count seen from ifconfig adds up very quickly on a put. FTP get doesn't provoke this bug nearly as much. I'm looking into the driver, though I am quite unfamiliar with Linux networking kernel code. -- David Wolfe Digital Audio, Radio Telematics Freescale Semiconductor ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] export m8xx_cpm_hostalloc
On Fri, Jul 23, 2004 at 10:41:36AM -0400, Dan Malek wrote: On Jul 23, 2004, at 10:02 AM, Tom Rini wrote: Must the driver use hostalloc? I didn't think that i2c was called so early that kmalloc/bootmem_alloc() (or so) couldn't be used. Should use ...consistent_alloc() That doesn't exist in 2.6. Use dma_alloc_coherent(). -Matt ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
random ramblings on 8xx patches (long and tedious :-)
The family should be sufficient (say 8xx). Then everything should be automatically set up at run-time, based on probing code which should detect the rest. That's what OCP should do ideally when it is ready. In this day and age wasting 50k to kill every-single last ugly define in drivers or the setup code is worth it; again IMHO. This sounds like a good idea, especially since the setup code can probably be thrown away after startup. However, does this fully solve the problem? For instance if the user is deciding whether to include a UART or USB driver for SCC3 doesn't he needs to know at that time whether it's on chip or not? Perhaps udev handles this situation? Mark Chambers ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] export m8xx_cpm_hostalloc
On Jul 23, 2004, at 11:38 AM, Matt Porter wrote: That doesn't exist in 2.6. Use dma_alloc_coherent(). Rightthat one, too. :-) -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
random ramblings on 8xx patches (long and tedious :-)
In message 410123EE.4000602 at intracom.gr you wrote: IMHO we shouldn't even bother. oops??? Then everything should be automatically set up at run-time, based on probing code which should detect the rest. You must be joking. This is for embedded systems, and code size and especially boot time are critical. Also, this suggestion does not coder Robert's intention of preventint the user from selecting bogus configuration options for stuff which doesn't exist on his chip. Best regards, 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 Life sucks, but it's better than the alternative. - Peter da Silva ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux is not reliable enough?
I am working with a team on a project where their customer is concerned about the reliability of Linux. The customer wants to go with QNX because of the belief that QNX Neutrino is inherently more reliable. This belief revolves around the differences in design where drivers in QNX do not reside in the same address space as the (micro-)kernel. What the team was hoping to use is a MPC5200 based system and the ELDK. The team needs to specifically address their customer's concern that a single driver can crash the operating system in Linux, since the driver resides in the same memory space as the kernel. They need to present convincing arguments to the customer's Chief Software Architect. Does anyone know of any good resources/references to address these concerns? Any evidence, either way, that QNX Neutrino is more reliable? Will the ELDK be adopting any of the Carrier Grade Linux requirements for reliability? Any other projects like this of note? Does anyone know of any embedded Linux projects where human lives really do depend upon Linux to be robust and reliable? Is UserMode Linux a possibility? Can one create custom drivers for UML and mitigate risks that way? Any clever ideas? Any clever, actually tested, ideas? Despite all of the hype, would any of you be willing to look a customer in the eye and say that an embedded Linux system can be reliable enough for human lives to depend on it? Thanks, Kevin Dankwardt ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
